This page is a container serving as a basis for communication during the drafting process of the next version of CERN OHL. Our current choice is to split the licence in three:
- A permissive licence called CERN-OHL-P (see draft)
- A weakly reciprocal licence called CERN-OHL-L (see draft)
- A strongly reciprocal licence called CERN-OHL-S (see draft)
There was a demand for a permissive option in CERN OHL, and including it as an exception in the main licence text proved a bit cumbersome. Once we decided to split P, it also made sense to split L and S. Below, we try to anticipate some questions and provide answers. There is also a rationale document which further explains our intentions and the mechanisms we have put in place to fulfil them in the licence texts. Therefore, there are in total five documents you can use in the process of contributing feedback to this drafting process: the three licence drafts, this FAQ and the rationale document.
In the FAQ below, we use the term "CERN OHL" when we refer generically to the three licences.
Frequently Asked Questions about CERN OHL
CERN OHL general questions
Q: What does CERN OHL try to achieve?
A: The CERN Open Hardware Licence aims at providing a solid legal basis for the sharing of hardware designs. In this release, we intend to give Licensors different options for the sharing mechanism: strongly reciprocal, weakly reciprocal and permissive.
Q: What is the scope of CERN OHL?
A: The licence is meant to cover Open Source Hardware (OSHW) designs. It has no concern with proprietary developments. When we drafted it, we also made sure it can be used for free and open source software, even if that is not its main aim.
Q: What are the rights the licence rests upon?
A: The licence texts make no assumptions about the rights that will be invoked to sustain them. These may include but are not limited to copyright, patents, design rights and database rights.
Q: Why is CERN doing this?
A: One of the most important parts of CERN's mandate is knowledge dissemination. OSHW is a natural way to disseminate hardware designs done at CERN to the rest of society. It is also important that a licence such as CERN OHL is stewarded by an institution whose mandate and values can guarantee its stability over time.
Q: Why not use existing licences such as GPL and any in the family of Creative Commons licences?
A: The CERN OHL was drafted with hardware in mind. The fact that the licensed materials are going to take part in the process of creating hardware has various implications. For example, the presence of patents is more pervasive in the hardware world than in software or in works of art. The CERN OHL appropriately has a patent licensing section, which is lacking for example in CC licenses. The realities of hardware design in terms of design tools are also very different from those of software. It is for example very common to design Application Specific Integrated Circuits (ASICs) using proprietary tools with proprietary libraries which are an integral part of the final design. Something similar happens with the design of Field Programmable Gate Arrays (FPGAs). These realities need to be taken into account in the drafting of the licence if we don't want a strongly reciprocal licence which can only apply in an extremely reduced number of cases. Finally, it is important for a licence to contain text that practitioners can easily relate to. The CERN OHL strives to use clear terms and definitions that have easily recognisable and intuitive meanings for hardware designers.
Q: Will you seek OSI and FSF approval/endorsement?
A: Yes, we want the CERN OHL to be as respectful of the four freedoms and the Open Source Definition as established free and open source software licences. The process of getting endorsement or approval from these respected institutions will surely make the licence better.
Q: Is this licence a contract? If it is, what is the consideration in this contract?
A: Yes, the CERN OHL is a contract. Bare licences don't exist in civil law countries. Both Licensors and Licensees have obligations under the CERN OHL which count as consideration.
Q: Who has the right to enforce this licence?
A: In free and open source software licences, it is the rights holders (typically copyright holders) who are able to enforce the licence against infringers. People who receive the code, unless they are also contributors, cannot (for example, if you receive GPL code and want access to the source code, you have to find a rights holder in the code, and get them to complain about the non-conformance). You are not able to do that yourself. The CERN OHL adopts the same rationale. However, a relatively simple licence text change would potentially allow recipients of Products and Covered Source to enforce against whoever they received them from. Our concerns are that this would potentially open any contributors up to potential liability from downstream recipients, and thus limit licence adoption, but it is an issue which should be understood and discussed before a final decision is made for this version.
Questions about hardware licensing
Q: Copyright does not cover hardware. How do you implement strongly reciprocal licensing in CERN-OHL-S?
A: Roughly speaking, the hardware equivalent of a binary object in the free and open-source software world would be a tangible object made thanks to design files licensed under an OSHW licence. So implementing a reciprocal licence involves solving the challenge of ensuring that the recipient of a piece of hardware gets access to the original design files. CERN-OHL-S provides two mechanisms to ensure that:
- The licence explicitly asks a Licensee to provide an easy way to access the design Source to recipients of products when (s)he makes and distributes products based on CERN-OHL-S licensed designs.
- For cases in which a tangible piece of hardware changes hands many times before reaching the final recipient, it is impossible to enforce the obligations above without making the licence text much more complicated and incurring in many extra contractual relations. The original designer though, can make it much more likely for the recipient to get access to the design files by including a URL or similar in the design, in a place where it will result in a visible imprinted label in the final object. The CERN-OHL-S requests that downstream Licensees respect that Notice and modify it accordingly if they modify the design files. It also requires that they make the Complete Source for the Product available to the recipient of any Product. The easiest way to do this, and the one which we encourage, is to make the Complete Source available from a Source Location (which is typically a public repository). However, it is also possible (although more cumbersome), to distribute Source and a Product privately, so long as the recipient is provided with a copy of the Complete Source.
Methods to enforce the licence will depend on each case. For example, most of the hardware designs are likely to be stored and distributed in the form of design files, i.e. digitally, and doing just about anything with them is going to involve copying, at a minimum, which will require a licence, and therefore allows the licence to impinge. This is just one example involving copyright, but as we said in an answer to another question, there may be more rights the licence rests upon in each case.
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 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 also licensed under CERN OHL, but that is an independent decision of its Licensor.
Questions about software
Q: A CERN OHL licensed design contains a processor running code. What are the implications on the code of using CERN OHL for the hardware?
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 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 under a Free and Open Source licence, e.g. GPL, but that is independent of your choice of licensing for the board as a hardware design.
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?
A: Proprietary blocks readily available in the design tools fall under the definition of "Available Components" and it is therefore not 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?
This case is slightly more complicated than the one for FPGA designs. We did not find good wording to make sure the primitive libraries (e.g. the so-called PDKs) were excluded from the distribution obligations. Not excluding them would make the licences applicable in only an extremely reduced number of cases. In the end we decided to allow the original Licensor to mark some components as "Available Components" so that the PDK case and others can be easily covered.
Q: Is an FPGA bitstream a Product according to the definition of Product in CERN OHL?
A: Yes, a bitstream results from the processing of source files and is therefore a Product, provided that those sources are licensed under the CERN OHL.
Questions about patents
Q: I find the section on patents a bit confusing. Can you explain to me in plain words what you are trying to achieve?
The idea is the following: when I give you a set of design files licensed under CERN OHL, I am promising you that I will not sue you for infringing any of my patents when you use that design for all purposes CERN OHL allows (studying, modifying, making hardware, selling it...). This is meant to reassure you as a Licensee and therefore favour adoption of designs licensed under the CERN OHL. Conversely, if you sue me for patent infringement in that particular design, you will lose all the rights I granted you in the licence. This two-way section on patents is intended to provide for a reassuring environment when it comes to sharing hardware designs.
Questions about practical use of the licence
Q: What are all these suffixes?
In the software domain, there are three generally acknowledged licensing regimes for free and open source software: permissive, weak copyleft and strong copyleft. There are tastes and use cases for each option, and the same happens in hardware. We use the word "reciprocal" instead of "copyleft" because the underlying rights in our case are not restricted to copyright. So, when you use the licence, you need to add a Notice to your designs with one of the three following suffixes: S, L or P:
- CERN-OHL-S is a strongly reciprocal licence. For example, if you release HDL files under CERN-OHL-S and then somebody uses those 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 distributes a bitstream which includes your part does not need to distribute the rest of the design files as well.
- CERN-OHL2-P is a permissive licence. It allows people to take your code, relicense it and use it without any obligation to distribute the sources when they ship a product.
Q: How should I handle Notices?
In general, it is good to keep notices in the design files as simple as possible. For example, in your circuit schematics you can have in each page a little square with a notice inside saying "Copyright XYZ, 2018 Licensed under CERN-OHL-S". In the layout, you could have a similar box in one of the documentation layers. Then, for more involved notices, you can use a NOTICE text file in the top directory of the project. One example of such more involved notices would be one where you specify that you would like the final product to display the Source Location (e.g. a URL) on it or its packaging.
Questions about Termination
Q: What happens to the rights of the Licensees of a Licensor if the rights of the Licensor under this licence are terminated?
A: It's his/her rights as Licensee that terminate. (S)he is still a Licensor, and therefore the rights of downstream Licensees are not affected.
Questions about distribution
Q: Does private distribution of sources or products trigger any obligations in CERN-OHL-S and CERN-OHL-L?
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 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.
Questions on licence compatibility
Q: Is CERN OHL compatible with GPL?
A: No. From the rationale document:
We thought hard about compatibility with other licences. An earlier version of the draft contained a mechanism for options, and a specific option which allowed compatibility with GPLv3. There’s an easy way to allow compatibility, of course: you can insert a clause which explicitly allows relicensing, but this necessarily means that one of the licences will have characteristics which are more forgiving than the other, and users can just pick whichever licence they want. If the original licensor wanted to do this in the first place, they could simply dual license under CERN-OHL and GPLv3. We also found that the mechanism we chose was pretty cumbersome, especially since to make it work, we needed also to add an additional permission to GPLv3. Since we’re essentially asking people to relicense their GPLv3 components anyway (albeit within the mechanism), we felt we should be more explicit about this.