-
Notifications
You must be signed in to change notification settings - Fork 5
Vendor core rights
One major class of proprietary cores used in HDL designs are those provided by FPGA or structured ASIC vendors. This page mostly discusses Xilinx licensing, just because that's what I have the most experience with.
Here is what I believe to be the main relevant license text from Xilinx's end user license, Section 3.A.3 (retrieved April 17, 2013):
- (3) Distributable Components License.
- A. Certain Definitions. "Distributable Component(s)" means those files supplied by Xilinx that are contained within certain Software tools (such as in EDK, Core Generator and System Generator) and that are identified by Xilinx in such tool or its associated documentation as either (a) an IP core (or a LogiCORE product), which is designed for use in programming functionality onto a Xilinx Device (hereafter a "Core"), or (b) a software driver (or a device driver), which is designed for use in enabling a Xilinx Device to interoperate with other independent software programs such as an operating system (hereafter a "Driver"). Distributable Components may be supplied by Xilinx in either (y) source code form, such as a Core provided in VHDL or Verilog form or a Driver provided in C language source form (hereafter "Modifiable Form"), or (z) a format other than source code, such as a Core provided in netlist form or encrypted netlist form or a Driver provided in complied object code form (hereafter "Restricted Form"). For purposes of clarity, a "Core" as used herein includes only a "Core" provided by Xilinx in the Software tools listed above at no additional charge, and not any fee-based LogiCORE products which are licensed separately under other agreements.
- B. Modification Rights. For Distributable Components supplied by Xilinx in Modifiable Form, Licensee may modify such Distributable Components, provided that such modifications are limited to enabling such Distributable Components to, in the case of a Core, program only a Xilinx Device, and in the case of a Driver, enable only a Xilinx Device to interoperate with other independent software programs such as an operating system. Licensee shall have no right to modify a Distributable Component that is supplied by Xilinx in a Restricted Form.
- C. Distribution Rights. Licensee may distribute Distributable Components (including when modified per Section 3(a)(3)B (Modification Rights) above), provided that either (a) such Distributable Components have been converted into a machine executable form, such as in the case of a Core, a Bitstream, and in the case of a Driver, in compiled object code form; or (b) the recipient thereof has a valid license from Xilinx to use the same Software. In all cases Distributable Components shall be distributed only for use to program a Xilinx Device.
Ideally, the development process with such cores looks like this: <pre> License a License b | | +-----------+ V +-------------+ V +-------------+ |XCO file |--->Coregen--> | HDL files |---> Synthesis--> .... ----> Bitgen -> | "Bitstream" | |(user spec)| | (generated) | ^ 2 | (generated) | | 0 | | 1 | | | 4 | +-----------+ +-------------+ | +-------------+ | +-----------------+ | | Other HDL files |-------------------------------+ | (user-written) | | 3 | +-----------------+ </pre>
As I read the license text -- and I believe Xilinx agrees [1]-- the associated rights are as follows:
- The developer has all rights to 0 and 3 (even though a Xilinx tool may have been used to generate 0).
- Xilinx claims some legal rights w/r/t 1, 2, and 4.
- Xilinx permits the developer to modify but not distribute 1 and 2.
- Xilinx licenses the developer to distribute 4 but only for the purposes of programming a Xilinx device.
Under ideal circumstances, the restrictions on 1 and 2 are slightly inconvenient. In particular, in typical development work flow, the files in 1 will be explicitly included as source files in the project. A developer who wishes to share his or her source code therefore has to go out of his or her way to identify and exclude such files before sharing.
The previous paragraphs talk about the "ideal" case. In practice, it's very common to have to manually edit the generated files, as drawn below.
<pre> License a ------------------------------ | / \ +-----------+ V +-------------+ v +-----------+ | |XCO file |--->Coregen--> | HDL files |------> Edit ---> | HDL files | ---+--> Synthesis--> .... |(user spec)| | (generated) | | (modified)| ^ 2 | 0 | | 1.a | | 1.b | | +-----------+ +-------------+ +-----------+ | | +-----------------+ | | Other HDL files |---------------------------------------------------------------------+ | (user-written) | | 3 | +-----------------+ </pre>
This creates a significant problem for sharing source code. The modified files in 1.b are presumably restricted by Xilinx's license terms, but they are necessary parts of the design's source code, and cannot be automatically generated from the freely-distributable 0.
The best solution I can think of is for the developer to share differences (e.g. patch files) between the modified and generated code. In principle, such differences would consist solely of the developer's original contribution, and the copyright holder for 1.a should have no reason to object to their distribution. That being said, I suspect that this is not cut-and-dried: Normal difference files contain portions of the original file to indicate what is to be replaced. It's easy to imagine a difference format that does not (e.g. by referring to positions in the original file without including any of its text, or by storing a checksum of the original text instead of the text itself) but this might still be a derived work in the eyes of the law[2].
I think the best solution is to work with core vendors to find a solution which they'll explicitly allow. When the core vendor is also the FPGA vendor (e.g. Xilinx), it seems to me that they have every incentive to support this: A growing free-HDL ecosystem is a growing FPGA customer base. (They might not think the additional demand will be worth their trouble, but at least it's positive).
Altera is the second largest[3] manufacturer of FPGA devices. I haven't personally worked with their software, but I imagine the issues to be generally similar.
Relevant clauses seem to be spread throughout Altera's MegaCore Function License Agreement (retrieved April 18, 2013). I've reproduced what appear to be key ones below:
- 1.6 “Licensed Products” means Altera Device(s) in which the MegaCore Function, in whole or part, or, if applicable, as modified by Licensee or Contractor under this Agreement, are implemented pursuant to the terms of this Agreement.
- 1.7“Licensee” means You.
- 1.8 “MegaCore Function” means one or more design files, including simulation models (such as VHDL and Verilog HDL, Quartus simulation, Matlab, Simulink, etc.) and other models, each of which may be provided in encrypted source code or object code formats, where each design file implements or supports the implementation of a specific logic function into an Altera Device.“MegaCore Function” expressly excludes the components, files, or portions that are subject to the applicable license agreement(s) set forth in the License.txt file.
- 2.License to the Deliverables:
- 2.1 Subject to the terms and conditions of this Agreement and unless Licensee has acquired the MegaCore Function through Altera’s OpenCore Plus Evaluation Program, Altera grants to Licensee a non-transferable and non-sublicensable (except as expressly set forth herein), non-exclusive, perpetual, royalty-free, and world-wide license to:
- (a)design with, parameterize, compile, route, and generate programming files and netlists with the Deliverables for implementation in Altera Devices; and
- (b)if the Licensed File Format is “Source Code”, modify and create derivative works, in whole or in part, of the Deliverables for implementation in Altera Devices; and
- (c)program Altera Devices with the Deliverables; and
- (f)if the Licensee Type is “End User”, manufacture or have manufactured, distribute or have distributed, sell or have sold, or otherwise market or have marketed products containing one or more Licensed Products.
- 2.7 All Intellectual Property embodied in the Deliverables, including enhancements, corrections, improvements, modified versions, or derivative works thereof, in whole or in part, that is created, conceived, or first reduced to practice (a) solely by or on behalf of Altera, (b) solely by or on behalf of Licensee, or (c) by Altera and Licensee jointly shall be the sole and exclusive property of Altera Corporation or its subsidiaries.
- 4.License Grant to Altera
- 4.1 If Licensee provides Altera with comments or suggestions for the modification, correction, improvement, or enhancement of (a) the Deliverables, (b) any Confidential Information disclosed by Altera to Licensee, or (c) Altera products that may embody such Confidential Information, then Licensee grants to Altera a nonexclusive, irrevocable, worldwide, royalty-free license, including the right to sublicense Altera licensees and customers, under Licensee’s Intellectual Property, the right to use and disclose such comments or suggestions in any manner Altera chooses and to display, perform, copy, have copied, make, have made, use, sell, offer to sell, have sold, and otherwise dispose of Altera’s and its sublicensees’ products embodying such comments in any manner and via any media Altera chooses, but without reference to the source of such comments and/or suggestions.
The situation seems similar to that of the Xilinx license: 1. Altera claims rights to all works derived from their Deliverables. 2. Those derived works would include developers' modifications to Altera-derived source code. 3. Those derived works would include binary files generated generated by combining Altera's code with the developer's code. 4. The developer's rights to both type of derived files are only specifically for use in programming Altera devices.
- ^ Based on discussion with Adam Covington, who worked with Xilinx on licensing code for the NetFPGA project under the GNU GPL. This should not be considered an official statement from Adam, Stanford, or Xilinx.
- ^ These also introduce technical concerns. Most basically, defining a new format would generally break compatibility with existing tools. Also, tools like "patch" use the text from the original file to make the desired change even when the "new original" file differs slightly from the "original original." Without this functionality, any variation in the generated HDL files could break the patching process.
- ^ See List and comparison of FPGA companies on fpgadeveloper.com.