Frequently Asked Questions about the CERN Open Hardware Licence

Frequently Asked Questions about the CERN Open Hardware Licence

Frequently Asked Questions about CERN OHL v2

Special section for COVID-19 developers

We are going to include this section here temporarily to help people who are developing hardware for fighting COVID-19. After the crisis, we will dispatch these questions to the relevant sections:

Q: Why should I use a licence?

A: If you put your files out there, be it on github, ohwr.org, gitlab.com or anywhere else, copyright law applies by default. Unless you explicitly give permission to, people will not have the right to copy them, modify them, publish the modifications, make hardware based on the design files, commercialise it, etc. You give this permission through a licence. There are ready-made licences you can use for this purpose.

Q: Why should I use the CERN Open Hardware Licence v2?

A: Because it is the newest Open Hardware Licence, it incorporates the latest thinking of many experts on what makes an Open Hardware licence good and it acknowledges, through the use of three variants, the different sharing schemes you might want to use in your project. See this other FAQ entry for other reasons, in particular if you are considering or already used a non-hardware licence.

Q: How do I license my material in practice?

A: After you have decided which variant of the licence you would like to use, go to the licence page and see the user guide corresponding to that variant.

Q: My project includes hardware and software. How do I make sure the whole product is distributed together and stays open source?

A: A quick clarification first: we use the word "firmware" sometimes for software which is permanently stored in a ROM or flash memory in a product. All our discussion about software applies fully to firmware because firmware is software. We do not use the word "firmware" when we discuss the design of Field-Programmable Gate Arrays (FPGA) or Application-Specific Integrated Circuits (ASICs) using Hardware Description Languages (HDL). For those cases, we use the word "gateware".

The CERN OHL v2 was designed to fill a gap in the licensing scene. It allows hardware designers to efficiently share hardware designs. It also works very well with gateware. Those are the natural domains for CERN OHL use. In addition, we made sure during its drafting that it could also be used for software. Having said that, there are already very good licences for Free and Open Source Software (FOSS), so chances are your software base is already using one of those, or you prefer to use a well-established software licence for any other reason.

If you are trying to pick a good FOSS licence for the software part of your project, here are our recommendations:

GPL3-or-later if you want a strongly-reciprocal software licence.
LGPL3-or-later or MPL2 if you want a weakly-reciprocal software licence.
Apache 2 if you want a permissive licence.

Now, if you have gone through the discussion material on CERN OHL v2, you may have come across the concept of "Available Components" and you may be wondering if software is a component of your hardware design. The answer is "no, it isn't". Software is not a component of the hardware design, the same way that the orange juice you pour into a bottle is not a component of the bottle design. So all the discussion about "Available Components" does not apply here. The software and hardware parts of a project have independent licensing regimes.

So, how can you, as a licensor, make sure that software and hardware design files travel together, under open-source licences, as people modify them and ship products based on the them? There are two things you can do:

License your software under a strongly-reciprocal licence such as GPL3, which ensures that improvements are fed back to the community when products are distributed. You can also use a weakly-reciprocal licence such as LGPL3 if you want to allow people to combine your software with proprietary (non-open-source) developments. It would, of course, be helpful if the source code of the software part of your product were provided in the Source Location of the hardware design, or through a link available in it.
In addition, you may, to give recipients additional comfort, have your product certified under the Open Source Hardware Association (OSHWA) certification program, which stipulates that the hardware part of a project should be licensed under an Open Hardware licence and the software part should be licensed under a Free and Open Source Software licence. Others will still be able to take your hardware, use proprietary software in it instead of the software you provided, and ship the result as a product, but they will not be able to use the version of the OSHWA certification logo that incorporates your certification ID.

Q: We are designing a ventilator within our company. We plan to include our company logo in a PCB silk screen. What happens to the logo if other people build and distribute the ventilator? What if they build and distribute a version of the ventilator for which they modified the design files?

A: If you publish a design including a silk screen for the PCB, then you may want to consider excluding your logo if you don’t want it reproduced, or, if you do, but only on a non-modified version of the circuit board, then you can include two versions of the silk screen, one with your logo, and one without (of course, remember that even if someone makes a non-modified PCB, they may do so badly, and in a way which reflects badly on you). The version without the logo is the version you should provide under the CERN-OHL together with the rest of the design files.

You may then want to consider a separate licence for use of the logo. You can grant this on a case-by-case basis, or have a general policy. This is a common approach in the world of Open Source, especially so far as certification is concerned: for example, the Open Source Hardware Association only permits the use of their logo on certified hardware. You may like to consider your own certification programme, by which you license the use of the term “<your company> Certified” to those manufacturers complying with your certification programme. Each of the CERN-OHL variants contains a section prohibiting licensees from using the name of CERN or the Licensor to suggest any implication of endorsement or involvement with the project, but if you include your logo in a silk screen print which you license under CERN-OHL, you will confuse licensees by providing a potential conflict with this section.

Note also that in many jurisdictions, failing to provide appropriate quality control over anyone who is permitted to use your name or logo may have adverse legal consequences. If you do want to license the use of the your logo to others, please do not try to do so under the CERN-OHL, and do take appropriate legal advice.

CERN OHL v2 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, W 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-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 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 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 licences. What does this mean in practice? If I release a design for which I hold patents under, say, CC-BY-SA, and you take it and use it, e.g. to build hardware and commercialise it, I can sue you for patent infringement. The CERN OHL v2 contains a patent licence, i.e. a promise of the licensor to all potential licensees that they can use the design without fear of being sued for patent infringement in that design by the licensor. The CERN OHL v2 also contains a patent retaliation clause: licensees who sue the licensor for patent infringement automatically lose their rights under the licence.

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). PCB design is also often done using proprietary tools. 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. We sent a request for endorsement to FSF and are awaiting their answer. In the meantime, CERN OHL v2 was approved by OSI and is now listed as a preferential option for licensing hardware in choosealicense.com.

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.

Q: I am a user of CERN OHL version 1.2. What are the main changes introduced by this new version?

A: Version 2 of the CERN OHL improves on version 1.2 in various respects:

The new version comes in three variants: strongly reciprocal, weakly reciprocal and permissive. Reciprocal licences stipulate that changes to a design must be fed back to the community, for everybody to benefit from them. Permissive licences do not impose this condition. In this way, CERN OHL v2 caters for the different collaborative models currently used in Open Source Hardware projects.
In the reciprocal variants, it is very important to clarify the scope of reciprocal obligations. By introducing the concepts of "Available Component" and "External Material", plus the already-existing concept of "Product", the new version makes a special effort to clarify what sources should be shared in both the -S and -W variants.
CERN OHL version 1.2 included a patent licence, i.e. a promise by the licensor that (s)he will not sue a licensee for patent infringement as regards the design licensed under CERN OHL. Version 2 adds a reciprocal clause for this patent licence: if a licensee sues a licensor for patent infringement, (s)he loses all the rights granted by the licence.
In licence 1.2 we did not make a special effort to cater for Hardware Description Language (HDL) development as used in Field Programmable Gate Array (FPGA) and Application-Specific Integrated Circuit (ASIC) design. As we became convinced that there was no appropriate reciprocal licensing regime for HDL, we made sure that CERN-OHL-S and CERN-OHL-W can provide a good solution for FPGA and ASIC designers with a reciprocal mindset.
Version 2 makes a special effort to maximise the chances that the recipient of a physical product will get access to the design files for that product. It does this by granting the licensor the possibility of embedding a URL or another reference in the object itself, and establishing that downstream licensees should respect that notice and update it as applicable if the design is changed.
The new version provides a grace period of 30 days for licensees which infringe in terms. If they come into compliance within 30 days after receiving a notification from the licensor, their rights are reinstated. This is meant to help with cases in which a licensee infringes the terms of the licence inadvertently.

Q: I am using one of variants of CERN OHL v2. What is the licence of the licence text itself?

A: The licence is copyright (c) CERN 2020, and the text of the licence is licensed as a whole under a Creative Commons Attribution-NoDerivatives 4.0 International Licence, (CC BY-ND 4.0), available at https://creativecommons.org/licenses/by-nd/4.0/

As a special exception to that licence, CERN expressly permits faithful translations of the entire licence into any language, and subsequent public display and distribution, provided that the resulting translation (which may include an attribution to the translator) is released under CC BY-ND 4.0 attributing CERN as the copyright holder, and providing a link to the original licence text at https://ohwr.org/cern_ohl_s_v2.txt (for the S variant), https://ohwr.org/cern_ohl_w_v2.txt (for the W variant) or https://ohwr.org/cern_ohl_p_v2.txt (for the P variant). This paragraph (translated appropriately) must be included when copying or translating the licence. If you carry out such a translation, you must make it clear (by at least including this paragraph) that the translation is unofficial and that the original text of the licence in the English language as released by CERN is definitive. You may also extract parts of the licence text (both in the original and in faithful translation) and copy, publicly display and distribute them for the purposes of education, training, providing legal advice, reviewing and critiquing the licence provided that you attribute CERN as above and also provided that such extracted parts do not form part of any document intended to have legal effect.

Q: In the W variant, paragraph 4.1 specifies Licensees should make the Complete Source of a design available when Making and conveying Products based on that design, but later, in paragraph 4.2 the text says that Sources of External Material are not included in that Complete Source. I find that a bit confusing. Is the Complete Source not complete then? Can you explain?

A: First of all, notice all words which are capitalised in the text above are defined in section 1 ("Definitions") of the licence text. During the drafting of the S variant, we needed a concept that would represent all the Sources you need to Make the Product. We chose to call that "Complete Source". The drafting of W took S as a basis, softening the reciprocal obligations where needed. We decided to keep the same definition of "Complete Source" for coherency, and added 4.2 after 4.1, specifying that the Sources for External Material do not need to be distributed when Making and conveying a Product. This means that the Complete Source in 4.1 does not need to include External Material. We understand this can seem a bit fuzzy on first reading, but are confident that reading 4.2 after 4.1 gives a clear picture and leaves no place for misunderstanding. This FAQ entry is just meant to make our drafting intentions explicit (W is definitely meant to be a weakly-reciprocal licence) and to provide some historic justification for our wording choices.

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 respect.

Q: Are there types of hardware that may not lend themselves to the CERN-OHL licences?

A: Copyright protection can apply unevenly to hardware. As a result, the CERN-OHL licences focus on Source and Covered Source. These types of documentation for hardware are much more clearly protected by copyright.

One result of this focus is that the obligations created by the CERN-OHL licences are strongest when someone modifying or building upon the licensed hardware would normally do so by modifying the Source. For example, someone modifying a PCB is likely to start with the source file for the original PCB licensed under the CERN-OHL instead of trying to recreate the file from scratch by examining the PCB itself.

Other types of physical objects are not as reliant on Source for modifications. For example, someone modifying a crowbar might choose to recreate documentation instead of starting with the originally licensed documentation.

While these types of directly modified hardware are edge cases, their limited relationship with their underlying documentation make it less likely that their licensing requirements can be easily enforced. If you are working with these types of hardware it may be better to focus on the CERN-OHL-P licence. That licence removes any ambiguity around the hardware’s rights without attempting to impose unenforceable obligations on downstream users.

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 -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.

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-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 also licensed under CERN OHL, but that is an independent decision of its 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-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 one of the few places 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).

Questions about software

Q: A CERN OHL licensed PCB contains a processor running code. What are the implications on the code of using CERN OHL for the hardware?

A: The CERN OHL licence of the PCB 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-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 as applied to the PCB has no concern with the contents of that flash. You could of course choose to license that code under a Free and Open Source licence, e.g. GPL, or even under the CERN OHL itself, but that is independent of your choice of licensing for the board as a hardware design.

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-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 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-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 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-W and not CERN-OHL-S.

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.

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. Furthermore, 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.

Q: What is wrong with GPL for FPGA design?

A: There is nothing wrong with the GNU General Public License in general, quite the opposite. This is the licence that revolutionised the free software world by introducing the idea of copyleft. Many of the greatest Free and Open Source Software (FOSS) projects have benefited from the sharing facilitated by GPL. GPL was drafted mainly to license software, and as such there are a number of issues when trying to apply it in other domains. Here, we will focus on the two main issues when using GPL for FPGA design:

Terms and their meaning. Version 3 of the GPL has an initial section devoted to definitions, and carefully tries to not rely on undefined terms in later sections. It is however very difficult to stay at that level of abstraction, and the licence becomes more helpful for licensing software when it provides clarification and examples, such as in the definition of “Corresponding Source”. The flip side is that this clarification and examples are meaningless for somebody licensing a non-software project. Terms like “shared libraries” or “dynamically-linked subprograms” do not have a commonly-accepted meaning outside software. When you use a core in your FPGA design, is that like using a library in a software project? This is a very common interpretation, but rests on the subjective judgement of the licensor. The end result is that, for example, the meaning of “Corresponding Source”, a central concept in GPL, is not 100% clear for FPGA designs.
The realities of FPGA design. In software development, it is often the case that the toolchain is FOSS itself, and that you can build a complex application without relying on a single line of proprietary code. In FPGA design, most of the toolchain is proprietary. There are some heroic efforts to come up with FOSS tools, but the vast majority of designers are using the proprietary tools provided by the FPGA vendors themselves. These tools are therefore seen as essential ingredients to the design process and come with a number of proprietary cores the designer can use. One example of such cores could be a DDR4 controller for accessing external RAM, which uses logic in the FPGA to implement a DDR4 interface. Because access to the tools is anyway needed to work with the chips, it is assumed that whoever wants to modify your design will have the tools, and therefore the access to the proprietary cores which come with them. Designers often take this access for granted and instantiate these cores in an otherwise open-source design. If you use GPL, you would in principle (according to the “common sense” interpretation of “Corresponding Source”) need to release the source for these proprietary cores under GPL when you convey the product in non-source form (e.g. when you ship a configured FPGA in a PCB). This is impossible, because these cores are typically “all rights reserved” by the vendor. In order to cope with this difficulty, which reflects the realities of the FPGA design ecosystem, we carved out an exception in CERN-OHL-S-2.0 (the strongly-reciprocal variant of CERN OHL 2.0). Components which are shipped with the tools qualify as “Available Components” and are therefore exempt from the obligation to release their source under the same licence. Any other component in a CERN-OHL-S-2.0 design must be open-source. Because access to proprietary cores comes with the tools and because replacing some of these cores by fully open-source alternatives could sometimes represent a prohibitive amount of work and risk, we thought an S variant of the licence with the carve-out for cores included with the tools makes for a more widely useful strongly-reciprocal licence.

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 trademarks

Q: My company has a trademark logo. We have designed a PCB and want to include the logo in the design files ("Source"). Can we do this?

Yes, you can, but there are good reasons why we suggest you do not. Your logo will likely have two forms of intellectual property. One is the copyright in the design of the logo itself, and the other is trade mark rights in the logo (which may be registered or unregistered). The trade mark rights are an indicator that the PCB design originates from your company. The CERN-OHL family is not intended to license any trade mark rights. You do not want a licensee taking your designs, and then reselling them as originating from you. This could badly affect your brand image, especially if the products provided are of low quality, and it could confuse your customers. Even worse, because you would not be exercising any quality control over the products which your licensee is making using your trade mark, this could be the basis of a challenge to invalidate your mark completely (this is a highly technical area, so you should talk to a trademark lawyer in your country).

Also, from a copyright perspective, if you place your logo design into your design files licensed under CERN-OHL, you are giving your licensees the right to use and adapt your logo artwork. You will probably not want to do this.

To make lawful use of someone else's trademark, especially where it is a logo, you must comply both with trademark law AND copyright law. In each case, you will either need a licence from the holder of the trademark and owner of the relevant copyright, or be covered by a legal exception such as fair use, fair dealing (in the case of copyright), or legitimate descriptive use (in the case of trademarks).

To reduce confusion, we believe that a good approach is to make it clear in the NOTICE file supplied as part of your Source that you are NOT licensing the use of your trademark and logo under CERN-OHL, and other than using your trademark to comply with the obligations to keep trademark notices intact in the Source (See section 3 in each of the variants of CERN-OHL), a licensee is not permitted to do so, unless separately licensed by you, or as otherwise permitted by law. This is also consistent with section 7.2 (CERN-OHL-P) and section 8.2 (CERN-OHL-S and CERN-OHL-W) which say that the name, image or logo of CERN or the Licensor (you!) may not be used except to comply with section 3 or where permitted by law.

If there are circumstances in which you wish to allow the use of your trademark and logo, then we suggest you have a written trademark policy which sets this out clearly. You should write this with the assistance of a trademark lawyer, as you will want to avoid the possibility of granting rights that are too wide, or even potentially allowing your trade mark to be invalidated. You might want to allow trusted manufacturers to use your name and logo, or to allow organisations that are making compatible products to use your name and logo to describe their products as compatible. You may even want to charge companies for the right to use your logo after they have been through your certification programme. This is all possible, and should be dealt with by way of a separate trade mark licence or policy which is unconnected with the CERN-OHL. Again, this is a highly technical legal area, and you should take appropriate legal advice from a qualified professional.

You can always state in your NOTICE file that products made using your Source must bear a shortform URL (for example) pointing to the Source Location, which will also contain the NOTICE file which can itself refer to a trade mark usage policy.

An example of an open hardware trade mark policy which addresses these issues can be found here: https://www.arduino.cc/en/trademark. You can even adapt the Arduino trademark policy for use by your own company, as long as you comply with the applicable CC-BY-SA 3.0 licence applicable to it.

Of course, these principles don't only apply to PCBs, they can apply to any sort of hardware design where it is possible to incorporate a trade mark or logo as part of the design.

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 version 2". 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-W?

A: If you distribute a product privately, and the sources for that 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 (unless you are using the research and development permission in Section 5 of -S and -W: see the next FAQ below).

Q: I want to engage another engineering company to help me with research and development. Can I do that without that company getting the full set of rights to use and distribute my designs under CERN-OHL?

A: Yes. There are two ways you can provide the designs (Covered Source) to the engineering company: either under section 3 (which is the way you would provide the designs to any third party), or under section 5. Section 5 is an additional permission which allows you to convey the Covered Source to an R&D company under restricted terms (which prevent the engineering company from conveying to any third party, or from using the designs for its own purposes). This means that the engineering company won't acquire the rights any other recipient would normally acquire under the CERN-OHL-S or -W. This lets a company perform research and development for you without the results potentially being made available to anyone else, unless you want them to (without section 5, if you tried to prevent the engineering company either from making their own use of the designs, or from conveying them to any third party, this would be a breach of subsection 2.3, as restrictions on licensees). If you do not comply with the provisions of section 5, then the conveyance will be deemed to be under section 3 and the engineering company will receive the right to use, modify and re-distribute the designs themselves, as if they were any other recipient of those designs.

Q: What to do with the 3D models of components that I got from a third party?

A: It is often the case that some of the 3D models in e.g. a PCB design are downloaded from the Internet, for example from the website of the manufacturer. In order to decide whether you can include them in your distribution, and how, we need to look at two dimensions: what is the licensing scheme of the 3D model (proprietary or open-source, and in the latter case, compatible or non-compatible with CERN OHL W or S as applicable) and what licence variant you are using for your design:

If you are using the S variant for your design, all 3D models you use must be licensed under an open-source licence compatible with the S variant, and per the definition of "Compatible Licence" in the text of the S variant (section 1.2). Notice 3D models which are not licensed under a compatible licence will typically not qualify as "Available Components" (section 1.7) in the S variant, unless they are distributed with the design tool (e.g. a PCB design program).
If you are using the W variant of the design, you can distribute the 3D models along with the rest of your design, as part of your Complete Source, provided they are licensed under a licence compatible with the W variant (see 1.2 in the text of the W variant). 3D models not licensed under a compatible licence, can still be referenced in a W design provided they qualify as Available Components (section 1.7). Proprietary and open-source 3D models will typically qualify as long as they are available to anyone (for example by downloading freely from a website).
If you are using the P variant, you can combine your design with any proprietary component, including 3D models, whether they are easily available or not. Your ability to distribute the 3D models with your design will depend exclusively on the licensing of the models.

In any of the three cases above, you can only distribute the 3D models themselves if their licence allows you to do so. If there are 3D models in your design which you are not allowed to distribute, it is good practice to include notes in your documentation stating where you got the models, for your own reference and that of any users of your design, who could then get the models on their own.

The discussion above applies to similar cases as well, such as 2D symbols and footprints.

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 licence 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-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:

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-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.

Questions about CERN OHL v1.2

Q: What are the main differences between v1.2 and v1.1?

A: Version 1.2 is lighter on the users of the licence. Now licensees who modified a design no longer have the obligation to notify the changes to upstream licensors. In addition to that, in order to guarantee that recipients of CERN OHL-licensed hardware get access to the design documents of a specific piece of hardware, version 1.2 includes the notion of Documentation Location. Another difference between the two versions is that Intergovernmental Organizations such as CERN are not singled out regarding their rights anymore. This means that they are as any other licensor or licensee.

Q: What is the motivation for the sentence "However, the Licensor shall not assert his rights under the foregoing proviso unless or until a Product is distributed" in paragraph 3.3?

A: The Licensee receives a right (to modify the Documentation) upon the fulfillment of a condition (to make the Documentation available). Without the sentence above, the obligation for publishing would be enforced as soon as the modification happens, which would make it impossible to fulfill.

Questions about CERN OHL v1.1

Q: We like to publish one of our HW design to the open source. Therefore we are looking for an “open hardware licence” to be used. In this process we found the CERN OHL v1.1 which could be a good choice.
In the “Guide to the CERN OHL v1.1” is pointed out that one should include “Licensed under CERN v1.1” on the silkscreen. To this paragraph I got the following question:

Is this a MUST ? (The prints are already produced and for further productions we do not have much empty space on the board)
What is the legal consequence if this is missing?
Does a licensee necessarily need to add the notice on the silkscreen?

A: The Guide is here to provide guidance and assistance as to how to apply the CERN OHL.
Indeed, space can be an issue. The idea behind this recommendation is to have it known that the hardware one would come across is licensed under CERN OHL. However, under CERN OHL v.1.1, the Documentation must accompany the hardware that is being distributed (article 4.1) and in the Documentation, the licence notice must appear, and must not be removed by licensees (article 3.1).
So to summarise, adding the licence notice is not a requirement, but as licensor, it is one of the best ways to make it known that the hardware is Open (Source) Hardware since it may well get ‘separated’ from the Documentation in its life. The licensee does not have to add the notice on the silkscreen, however if the licensor has put it there, he may not remove it.

Faq