From ef519f92b99ea71a353a9c847fe1235e8d8634e8 Mon Sep 17 00:00:00 2001 From: hkimw <54717101+hkimw@users.noreply.github.com> Date: Sat, 23 May 2026 11:23:04 +0900 Subject: [PATCH] docs: define BYOL synthesis license model --- docs/commercial/README.md | 5 + .../byol-synthesis-license-model.md | 308 ++++++++++++++++++ 2 files changed, 313 insertions(+) create mode 100644 docs/commercial/byol-synthesis-license-model.md diff --git a/docs/commercial/README.md b/docs/commercial/README.md index adeae5f83..c18508efb 100644 --- a/docs/commercial/README.md +++ b/docs/commercial/README.md @@ -21,6 +21,11 @@ them requires explicit written agreement under applicable law. | [Commercial](commercial-track.md) | Customers needing supported deliverables: ProCore, Enterprise SDK, ASICKit, model porting, integration support, certification | Commercial offerings under separate terms. Pricing TBD. | | [Capital](capital-track.md) | Sponsors, strategic customers, external investors | Distinct funding mechanisms with distinct legal forms. | +The BYOL synthesis policy lives in +[byol-synthesis-license-model.md](byol-synthesis-license-model.md). It +defines the customer-owned Vivado / Quartus license boundary for local, +isolated VM, and hybrid synthesis flows. + ## Separation matrix The full role separation lives in diff --git a/docs/commercial/byol-synthesis-license-model.md b/docs/commercial/byol-synthesis-license-model.md new file mode 100644 index 000000000..9d80b75b8 --- /dev/null +++ b/docs/commercial/byol-synthesis-license-model.md @@ -0,0 +1,308 @@ +--- +orphan: true +--- + +> Draft operational policy; not legal advice; not a contract. +> Subject to qualified legal review before binding use. + +# BYOL synthesis license model + +This page defines the PCCX bring-your-own-license model for FPGA +synthesis and implementation tooling. The policy boundary is simple: +PCCX can orchestrate or guide a build, but the customer installs, +activates, and operates vendor FPGA tools under the customer's own +license rights. + +PCCX must not own, distribute, resell, share, proxy, or inspect vendor +license secrets for AMD Vivado, Altera Quartus Prime, or other FPGA EDA +tools. Customer license files, authorization codes, portal credentials, +floating-license server addresses, and license environment variables +remain in the customer-controlled environment. + +## Supported operating modes + +### Local mode + +Local mode keeps the toolchain and license state on the customer's +machine. + +1. The customer installs Vivado, Quartus Prime, or another supported + vendor tool on the customer's workstation or build server. +2. The customer accepts the applicable vendor EULA and activates the + license directly with the vendor. +3. PCCX Desktop or PCCX CLI invokes the local tool through a thin + adapter. +4. PCCX records only non-secret build state: selected vendor, tool + version, target device, exit status, sanitized logs, and customer + selected artifacts. + +PCCX does not receive the vendor account login, authorization code, +license file, license server address, or license environment value. + +### Isolated VM mode + +Isolated VM mode is for customers who want PCCX cloud coordination while +keeping vendor license activation inside a customer-specific execution +environment. + +1. PCCX provisions or identifies a VM dedicated to one customer. +2. The customer signs into the VM and installs the vendor toolchain. +3. The customer activates the license directly in that VM or points the + tool at a customer-controlled floating-license server when the + customer's vendor terms allow it. +4. PCCX sends build job metadata to the VM-side runner and receives only + sanitized status, logs, and artifacts. + +Required controls: + +- one customer per VM; +- no golden image containing activated vendor tools or license files; +- no PCCX access path that copies, displays, or exports license secrets; +- encrypted VM disks and customer-specific teardown policy; +- log redaction for paths, environment values, host IDs, and license + diagnostics that may reveal customer license data. + +### Hybrid mode + +Hybrid mode keeps AI planning and account coordination in PCCX cloud +while synthesis runs locally. + +1. PCCX cloud manages project state, review workflow, and build + recommendations. +2. A local PCCX client pulls a build plan and executes the vendor tool on + the customer's machine. +3. The local client returns sanitized progress and artifacts. +4. License discovery and vendor execution never leave the local + environment. + +Hybrid mode is the default recommendation when the customer wants cloud +workflow support but does not want vendor tooling or license material in +cloud infrastructure. + +## Module boundary + +The BYOL module should be structured as a narrow policy and adapter +boundary: + +```text +modules/byol-license/ + interfaces/ + LicenseProvider + BitstreamRequest + BuildResult + core/ + policy + orchestration + adapters/ + xilinx-vivado-local + xilinx-vivado-vm + intel-quartus-local + intel-quartus-vm + lattice + microchip + ui/ + LicenseSetup + BuildDashboard +``` + +`interfaces/` contains the stable contract. It must be vendor-neutral and +must not include a field for license keys, license files, authorization +codes, portal passwords, or raw license environment variables. + +`core/` is pure policy and orchestration code. It validates mode, +customer consent, artifact policy, and redaction requirements. It must +reject any request that tries to upload or store a vendor license secret. + +`adapters/` are the only components that know tool-specific commands, +preflight checks, and report locations. Adapters execute inside the +customer-controlled environment for local and hybrid mode, or inside the +customer-dedicated VM for isolated VM mode. + +`ui/` owns user setup and build status. It should guide the customer to +the vendor's own installation and licensing flow, then run a local or VM +preflight. It should never present an upload field for vendor license +files or authorization codes. + +## Interface shape + +The contract should describe capability, not secrets: + +```text +LicenseProvider.check() + input: vendor, tool, mode, target_device + output: vendor, tool, detected_version, status, checked_at + +BitstreamRequest + source_ref + target_device + vendor_tool + mode + build_profile + artifact_policy + customer_license_responsibility_ack + no_vendor_license_secret_ingress_ack + +BuildResult + request_id + status + tool_version + started_at + completed_at + sanitized_log_refs + artifact_refs + redaction_report +``` + +`LicenseProvider.check()` may report `ready`, `not_detected`, +`tool_missing`, `license_unavailable`, or `unknown`. It must not return +the content or raw location of a vendor license file or license server. + +`BitstreamRequest` must include customer acknowledgements that the +customer is using only licenses they control, that vendor terms remain +the customer's responsibility, and that PCCX is not receiving vendor +license secrets. + +`BuildResult` must be safe to store in PCCX systems. If a log contains a +license diagnostic, the raw log stays local and the stored copy must be +redacted first. + +## User flow + +1. The customer signs up for PCCX and selects a plan. +2. When a synthesis or implementation action is requested, PCCX shows a + "license activation required" setup step. +3. The customer chooses Local, Isolated VM, or Hybrid mode. +4. PCCX shows vendor-specific setup links and local preflight commands. +5. The customer installs the vendor toolchain and activates the license + directly with the vendor or with the customer's company license + server. +6. PCCX runs a preflight through the selected adapter. +7. The build dashboard shows tool readiness, target device, current + stage, sanitized logs, and artifacts. +8. Any failed license check is reported as a customer-environment action: + install, activate, select a valid license server, or contact the + vendor. + +## UI requirements + +`LicenseSetup` should include: + +- mode selector: Local, Isolated VM, Hybrid; +- vendor selector: Vivado, Quartus Prime, Lattice, Microchip; +- setup checklist: install tool, accept vendor EULA, activate license, + run preflight; +- explicit acknowledgements that the customer owns or is authorized to + use the vendor license; +- no input for vendor account passwords, authorization codes, license + files, or raw license server values. + +`BuildDashboard` should include: + +- selected mode and vendor tool; +- detected tool version; +- target device and build profile; +- build stage and exit status; +- sanitized log viewer; +- artifact list; +- redaction status; +- customer action items when the tool or license is unavailable. + +The UI should avoid implying that PCCX supplies Vivado, Quartus Prime, +or vendor IP licenses. It should say that the customer is using the +customer's own vendor license in the customer's environment. + +## EULA review notes + +This review is a product-design summary, not a legal conclusion. The +model is designed to avoid vendor-tool resale and redistribution by +keeping the vendor relationship between the customer and the vendor. +Qualified counsel should review final customer terms before launch. + +AMD's public product licensing page states that the AMD/Xilinx End User +License Agreement applies to Vivado Design Suite tools and to certain +included LogiCORE IP components. The Vivado installation guide also says +the command-line installer requires acceptance of the Xilinx EULA. The +current AMD/Xilinx EULA text states that only software items for which +the licensee has applicable authorization codes are validly licensed, +and it places responsibility for third-party licenses on the licensee. + +Altera's current Quartus Prime licensing guide states that Quartus Prime +Lite supports selected devices without license files, while Quartus +Prime Pro and Standard require a paid fixed or floating license. It also +states that subscriptions are set up and managed in the Altera FPGA +Self-Service Licensing Center, where the customer can generate a +`license.dat` file. A fixed license is tied to the NIC ID of the +computer on which the software is installed. + +Design conclusion for PCCX: + +- Local mode is the cleanest BYOL path because the customer runs the + vendor tool on the customer's machine. +- Isolated VM mode can be acceptable only if the VM is customer-specific + and the customer performs activation without exposing license secrets + to PCCX. +- Hybrid mode is acceptable when PCCX cloud only manages planning and + status while synthesis executes locally. +- Multi-tenant shared runners, PCCX-managed vendor license pools, and + uploaded customer license files are out of scope. + +Official references: + +- AMD Product Licensing: + +- AMD Vivado release notes, installation, and licensing guide: + +- AMD/Xilinx End User License Agreement: + +- Altera FPGA Software Installation and Licensing: + +- Quartus Prime Software License: + +- Altera Self-Service Licensing Center workflow: + + +## Customer terms checklist + +Before a commercial launch, PCCX terms should state: + +- The customer is responsible for obtaining, maintaining, and complying + with all vendor FPGA tool licenses. +- PCCX does not sell, sublicense, lease, lend, host, or distribute + Vivado, Quartus Prime, vendor IP cores, or vendor license rights. +- PCCX does not request or store vendor license files, authorization + codes, account credentials, or license-server secrets. +- The customer authorizes PCCX only to invoke or coordinate the selected + toolchain in the customer-controlled environment. +- The customer must not use PCCX to bypass vendor license restrictions, + seat limits, geographic limits, export controls, or project/IP license + restrictions. +- Vendor EULAs and IP-license terms control the vendor tools and vendor + IP. PCCX terms control PCCX software and services only. + +## Security controls + +The implementation must treat vendor license material as customer +secrets: + +- block upload fields and API fields for vendor license files, license + keys, authorization codes, and portal credentials; +- redact common license environment variables such as `LM_LICENSE_FILE` + and vendor-specific equivalents before logs leave the build host; +- store only sanitized build logs in PCCX cloud; +- keep raw tool logs local by default; +- prevent cross-customer VM reuse unless storage has been destroyed and + the VM has been rebuilt from a clean image; +- isolate customer build artifacts from other tenants; +- keep access logs for who initiated builds, without recording license + values. + +## Future implementation gate + +No runtime adapter should be enabled until these checks pass: + +- documented customer consent flow; +- adapter contract tests proving license-secret fields are rejected; +- log redaction tests for license-like environment variables and common + vendor diagnostics; +- per-mode threat model review; +- qualified legal review of the customer terms and vendor-EULA posture.