... | ... | @@ -58,8 +58,8 @@ your designs with one of the three following suffixes: S, L or P: |
|
|
files in their FPGA, when they distribute the bitstream (either
|
|
|
putting it online or shipping a product with it) they need to make
|
|
|
the rest of the HDL design available under CERN-OHL-S as well.
|
|
|
- CERN-OHL-L is a weakly reciprocal licence. For the example above, if
|
|
|
you release your part of the design under CERN-OHL-L, somebody who
|
|
|
- CERN-OHL-W is a weakly reciprocal licence. For the example above, if
|
|
|
you release your part of the design under CERN-OHL-W, somebody who
|
|
|
distributes a bitstream which includes your part does not need to
|
|
|
distribute the rest of the design files as well.
|
|
|
- CERN-OHL-P is a permissive licence. It allows people to take your
|
... | ... | @@ -198,7 +198,7 @@ respect. |
|
|
|
|
|
#### Q: What can I do to ensure that people who receive a piece of hardware I designed get access to the design files?
|
|
|
|
|
|
A: You would have to use the -L or -S variants, and include in your distribution a Notice saying you want Products to display the Source Location for your design files and how that should be done for the particular bit of hardware your design files represent. Section 4 in the -L and -S texts gives permission to Make and Convey Products, and specifies that your Notice should be honoured:
|
|
|
A: You would have to use the -W or -S variants, and include in your distribution a Notice saying you want Products to display the Source Location for your design files and how that should be done for the particular bit of hardware your design files represent. Section 4 in the -W and -S texts gives permission to Make and Convey Products, and specifies that your Notice should be honoured:
|
|
|
|
|
|
> If specified in a Notice, the Product must visibly and securely display the Source
|
|
|
Location on it or its packaging in the manner specified in that Notice.
|
... | ... | @@ -208,7 +208,7 @@ If you are not the original designer, you can also take the design and modify it |
|
|
#### Q: My PCB is made of ICs, which are made of plastic, metal and a chip, which is itself made of silicon. How far do I need to go in terms of providing the source designs for all this?
|
|
|
|
|
|
A: The ICs in your design qualify as "Available Components" in
|
|
|
CERN-OHL-S and CERN-OHL-L (the two cases where this question makes
|
|
|
CERN-OHL-S and CERN-OHL-W (the two cases where this question makes
|
|
|
sense). Therefore, as a Licensee, you can reference them (as when you
|
|
|
draw a symbol for them in a schematic) without any need to distribute
|
|
|
their associated sources. In this case the IC may be a custom design
|
... | ... | @@ -217,9 +217,9 @@ Licensor. |
|
|
|
|
|
#### Q: What are "Available Components"?
|
|
|
|
|
|
A: "Available Components" in CERN OHL play a similar role to "System Libraries" in GPL/LGPL. These are components that we assume people generally have access to. As such, people can recreate a Product by using CERN OHL licensed designs and getting these Available Components separately. A resistor is a typical example of an Available Component. In reciprocal licences such as CERN-OHL-L and CERN-OHL-S, it is important to clearly define the scope of the reciprocal obligations. The concept of Available Component is key in that regard. If you take a CERN OHL licensed design and modify the value of a resistor, you don't need to release the resistor design itself. This is because Available Components are excluded from the reciprocal obligation of releasing the sources. This makes the reciprocal licences more practical to work with, since many of these Available Components are proprietary and access to their design sources, and the right to distribute them, is very limited in most cases.
|
|
|
A: "Available Components" in CERN OHL play a similar role to "System Libraries" in GPL/LGPL. These are components that we assume people generally have access to. As such, people can recreate a Product by using CERN OHL licensed designs and getting these Available Components separately. A resistor is a typical example of an Available Component. In reciprocal licences such as CERN-OHL-W and CERN-OHL-S, it is important to clearly define the scope of the reciprocal obligations. The concept of Available Component is key in that regard. If you take a CERN OHL licensed design and modify the value of a resistor, you don't need to release the resistor design itself. This is because Available Components are excluded from the reciprocal obligation of releasing the sources. This makes the reciprocal licences more practical to work with, since many of these Available Components are proprietary and access to their design sources, and the right to distribute them, is very limited in most cases.
|
|
|
|
|
|
Incidentally, the definition of "Available Component" is the only part where CERN-OHL-L and CERN-OHL-S differ. Under CERN-OHL-S, only physical parts (e.g. a resistor or an ASIC) qualify as Available Components. CERN-OHL-L allows both physical and non-physical parts (e.g. an HDL core) to qualify as an Available Component. So e.g. an FPGA design licensed under CERN-OHL-L can have proprietary cores in it, provided they are Available (e.g. they can be purchased by anybody).
|
|
|
Incidentally, the definition of "Available Component" is the only part where CERN-OHL-W and CERN-OHL-S differ. Under CERN-OHL-S, only physical parts (e.g. a resistor or an ASIC) qualify as Available Components. CERN-OHL-W allows both physical and non-physical parts (e.g. an HDL core) to qualify as an Available Component. So e.g. an FPGA design licensed under CERN-OHL-W can have proprietary cores in it, provided they are Available (e.g. they can be purchased by anybody).
|
|
|
|
|
|
|
|
|
-----
|
... | ... | @@ -230,7 +230,7 @@ Incidentally, the definition of "Available Component" is the only part where CER |
|
|
|
|
|
A: The CERN OHL license does not extend to the code running in that
|
|
|
processor. The processor falls under the definition of "Available
|
|
|
Component" in CERN-OHL-S and CERN-OHL-L (the two cases where there could
|
|
|
Component" in CERN-OHL-S and CERN-OHL-W (the two cases where there could
|
|
|
be a potential issue). So does the flash (or other) memory chip that may
|
|
|
host the code prior to power-up. The CERN OHL has no concern with the
|
|
|
contents of that flash. You could of course choose to licence that code
|
... | ... | @@ -246,7 +246,7 @@ A: This is another way of asking the question above. Yes, they are allowed. |
|
|
|
|
|
## Questions about FPGA and ASIC design
|
|
|
|
|
|
#### Q: An FPGA design is licensed under CERN-OHL-S or CERN-OHL-L. What are the implications regarding proprietary primitives and macros used in the design?
|
|
|
#### Q: An FPGA design is licensed under CERN-OHL-S or CERN-OHL-W. What are the implications regarding proprietary primitives and macros used in the design?
|
|
|
|
|
|
A: Proprietary blocks readily available in the design tools fall under
|
|
|
the definition of "Available Components" and it is therefore not
|
... | ... | @@ -254,7 +254,7 @@ required to ship them when you distribute the design sources or products |
|
|
based on those
|
|
|
designs.
|
|
|
|
|
|
#### Q: An ASIC design is licensed under CERN-OHL-S or CERN-OHL-L. What are the implications regarding proprietary primitives and macros used in the design?
|
|
|
#### Q: An ASIC design is licensed under CERN-OHL-S or CERN-OHL-W. What are the implications regarding proprietary primitives and macros used in the design?
|
|
|
|
|
|
Because of the way primitive libraries (e.g. the so-called
|
|
|
[PDKs](https://en.wikipedia.org/wiki/Process_design_kit) and [standard
|
... | ... | @@ -266,7 +266,7 @@ excluding them makes the resulting licence applicable in only an |
|
|
extremely reduced number of cases now and in the short-term future:
|
|
|
those where the PDKs and standard cells are released as Open Source
|
|
|
Hardware. Those who would like a reciprocal licence which works with
|
|
|
proprietary PDKs and standard cells should use CERN-OHL-L and not
|
|
|
proprietary PDKs and standard cells should use CERN-OHL-W and not
|
|
|
CERN-OHL-S.
|
|
|
|
|
|
#### Q: Is an FPGA bitstream a Product according to the definition of Product in CERN OHL?
|
... | ... | @@ -276,10 +276,10 @@ therefore a Product, provided that those sources are licensed under the |
|
|
CERN
|
|
|
OHL.
|
|
|
|
|
|
#### Q: I would like to combine CERN-OHL-L and CERN-OHL-S licensed cores in the same FPGA design. Is it possible? What will be the resulting licensing scheme for the top level?
|
|
|
#### Q: I would like to combine CERN-OHL-W and CERN-OHL-S licensed cores in the same FPGA design. Is it possible? What will be the resulting licensing scheme for the top level?
|
|
|
|
|
|
A: Yes, both can be combined, and the licence for the top level will be CERN-OHL-S in order to comply with clauses 3.2 and 3.3.d in the CERN-OHL-S licence under which some of the components are licensed. The CERN-OHL-L similarly requires the top level to be CERN-OHL-L when there are CERN-OHL-L cores in it, so this could at first sight look like an issue, but section 7.3 in CERN-OHL-L says
|
|
|
> You may treat Covered Source licensed under CERN-OHL-L as licensed under CERN-OHL-S if and only if all Available Components referenced in the Covered Source comply with the corresponding definition of Available Component for CERN-OHL-S.
|
|
|
A: Yes, both can be combined, and the licence for the top level will be CERN-OHL-S in order to comply with clauses 3.2 and 3.3.d in the CERN-OHL-S licence under which some of the components are licensed. The CERN-OHL-W similarly requires the top level to be CERN-OHL-W when there are CERN-OHL-W cores in it, so this could at first sight look like an issue, but section 7.3 in CERN-OHL-W says
|
|
|
> You may treat Covered Source licensed under CERN-OHL-W as licensed under CERN-OHL-S if and only if all Available Components referenced in the Covered Source comply with the corresponding definition of Available Component for CERN-OHL-S.
|
|
|
|
|
|
so the top level must be CERN-OHL-S in order to comply with both licences.
|
|
|
|
... | ... | @@ -331,10 +331,10 @@ affected. |
|
|
|
|
|
## Questions about distribution
|
|
|
|
|
|
#### Q: Does private distribution of sources or products trigger any obligations in CERN-OHL-S and CERN-OHL-L?
|
|
|
#### Q: Does private distribution of sources or products trigger any obligations in CERN-OHL-S and CERN-OHL-W?
|
|
|
|
|
|
A: If you distribute a product privately, and the sources for that
|
|
|
product are licensed under CERN-OHL-S or CERN-OHL-L, then you need to
|
|
|
product are licensed under CERN-OHL-S or CERN-OHL-W, then you need to
|
|
|
make the sources available to the recipient of that product. No need to
|
|
|
distribute them more widely. The recipient of those sources of course
|
|
|
has the right to make them available to the public.
|
... | ... | @@ -349,7 +349,7 @@ A: No. To explain why, let's take the case of an FPGA design. If any block is GP |
|
|
|
|
|
So, we could add a clause to CERN-OHL-S which says that any design licensed under CERN-OHL-S can be relicensed under GPL by the licensee. This would allow the combination of GPL and CERN-OHL-S in the same design. We decided not to do that for various reasons, in particular:
|
|
|
* We think that GPL [is not an optimal license for the case of hardware](https://www.ohwr.org/project/cernohl/wikis/CERN-OHL-v2-draft#q-why-not-use-existing-licences-such-as-gpl-and-any-in-the-family-of-creative-commons-licences). For example, in the case described above, after carefully reading the GPL3 text, one could very well argue that any primitive/macro libraries from the FPGA vendor (Xilinx, Altera/Intel...) should be distributed too, which is explicitly forbidden in the licensing of those libraries.
|
|
|
* When drafting the CERN-OHL-S and CERN-OHL-L, we took special care to guarantee, to the biggest possible extent, that the recipients of hardware get access to its design files. There are special provisions in the licence texts to ensure that, which don't exist in GPL. One example is the ability for a licensor to specify that the URL for a design should be physically engraved in the final product. Allowing people to relicense under GPL would provide an easy means to escape such obligations. The lack of an appropriate reciprocal licensing regime for hardware was one of the key reasons to draft the CERN-OHL to begin with.
|
|
|
* When drafting the CERN-OHL-S and CERN-OHL-W, we took special care to guarantee, to the biggest possible extent, that the recipients of hardware get access to its design files. There are special provisions in the licence texts to ensure that, which don't exist in GPL. One example is the ability for a licensor to specify that the URL for a design should be physically engraved in the final product. Allowing people to relicense under GPL would provide an easy means to escape such obligations. The lack of an appropriate reciprocal licensing regime for hardware was one of the key reasons to draft the CERN-OHL to begin with.
|
|
|
|
|
|
The rationale document explains all this with other words:
|
|
|
|
... | ... | @@ -370,7 +370,7 @@ The rationale document explains all this with other words: |
|
|
|
|
|
#### Q: More specifically, I would like to use a [GPL2-licensed core](https://wiki.analog.com/resources/fpga/peripherals/jesd204) in my design. What are the consequences on the licensing of the rest of the files in that design?
|
|
|
|
|
|
A: If you release a product based on that design, for example if you are shipping a product containing an FPGA whose configuration bitstream has been derived from the GPL2-licensed and other sources, then according to the GPL2 terms, you are distributing the "Program" in object code form. This means you need to provide access to all the sources, and these sources must all be licensed under GPL2. This is where incompatibility issues can arise. Permissive licences such as Solderpad and CERN-OHL-P will allow re-interpreting the licensing terms in the licence so that you can treat the files as licensed under GPL2. Reciprocal licences such as CERN-OHL-L and CERN-OHL-S will not allow this re-interpretation. This makes it impossible to use cores licensed under GPL2 (or GPL3 for that matter) in a design which also uses cores licensed under CERN-OHL-L and CERN-OHL-S.
|
|
|
A: If you release a product based on that design, for example if you are shipping a product containing an FPGA whose configuration bitstream has been derived from the GPL2-licensed and other sources, then according to the GPL2 terms, you are distributing the "Program" in object code form. This means you need to provide access to all the sources, and these sources must all be licensed under GPL2. This is where incompatibility issues can arise. Permissive licences such as Solderpad and CERN-OHL-P will allow re-interpreting the licensing terms in the licence so that you can treat the files as licensed under GPL2. Reciprocal licences such as CERN-OHL-W and CERN-OHL-S will not allow this re-interpretation. This makes it impossible to use cores licensed under GPL2 (or GPL3 for that matter) in a design which also uses cores licensed under CERN-OHL-W and CERN-OHL-S.
|
|
|
|
|
|
|
|
|
### Files
|
... | ... | |