This page is a container serving as a basis for communication during the drafting process of the next version of CERN OHL. It hosts or points to all the information needed to review our effort. If you would like to help us, it would be great if you found time to go through all this material. You can then send your feedback to us, either using the forum or writing to us directly. The drafting team is currently composed of Myriam Ayass, Andrew Katz and Javier Serrano. If you need an account in ohwr.org (e.g. for submitting issues) or in forums.ohwr.org, please ask Javier directly. Thank you very much in advance for your help.
Our current choice is to split the licence in three:
A strongly reciprocal licence called CERN-OHL-S (see
A weakly reciprocal licence called CERN-OHL-L (see
A permissive licence called CERN-OHL-P (see
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
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
document. There is also a video
webm) of a
talk which Andrew Katz delivered in FOSDEM 2019, which can be a gentle
introduction you might want to watch before diving into the materials.
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 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-OHL-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: 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
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
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
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. This is tricky because copyright law (which is the mechanism used
by most software licences to impose obligations on licensees) does not
apply to hardware production and distribution. In drafting CERN-OHL-S,
we have made a special effort to achieve this effect by relying solely
on existing and applicable rights, and we believe the licence will
fulfil this part of its purpose in a large number of cases. Read on to
learn how CERN-OHL-S provides two mechanisms for a recipient of
hardware to get hold of design documents:
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. Once the
licensee exercises any rights under the licence, the whole licence text
applies, including obligations at production and distribution time. 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. It is important for a licensor to understand how the licence
is intended to work and what can and cannot be achieved for a particular
design in a particular context. No licence gives licensors 100%
reassurance of what will happen in court one day, and the CERN OHL is
not an exception in that
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:
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.
If you are not the original designer, you can also take the design and modify it (therefore becoming a Licensee), adding a Notice for the display of the Source Location before distributing the resulting modified design (therefore becoming a Licensor).
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
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.
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).
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
Q: Are non-open binary software blobs allowed to run in hardware licensed under CERN OHL?
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?
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
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?
Because of the way primitive libraries (e.g. the so-called
PDKs and standard
cell libraries) are
distributed in the ASIC design world, things are actually quite
different from the FPGA case. Wording in CERN-OHL-S does not exclude
these primitive libraries from the distribution obligations. Not
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
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
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?
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.
so the top level must be CERN-OHL-S in order to comply with both licences.
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: 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
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
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-S compatible with GPL?
A: No. To explain why, let's take the case of an FPGA design. If any block is GPL in that design, all other blocks have to be released under GPL. Same for CERN-OHL-S: one core as CERN-OHL-S would force a distribution of all other cores, along with the top-level design, under that licence. So it's easy to see how a GPL core and a CERN-OHL-S core in the same design would create a problem. This is a well-known issue in the software world, and the reason why people try to avoid the proliferation of different, incompatible, strong copyleft licences.
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. 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.
The rationale document explains all this with other words:
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.
Q: More specifically, I would like to use a GPL2-licensed core 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.