The license does the legal work in an open hardware release. Without one, people can look at your files but have no clear right to copy, change or manufacture them.
This guide compares the licenses you're most likely to meet. The license chooser on our homepage asks the same questions in a shorter form, and the license comparison page has links to every official text. Nothing here is legal advice. If your employer, a grant or patents are involved, have a lawyer read the license before you publish.
Why hardware needs its own licenses
Software licenses work because copyright covers code. Hardware is messier. Copyright covers your schematic drawings, your PCB artwork, your CAD files and your manual, but it usually doesn't cover the physical object those files describe or the idea behind the circuit. A functional device may be covered by patents instead, and the name on the box by trademarks.
Early open hardware projects often used software licenses like the GPL, or Creative Commons licenses. Arduino, for example, published its board reference designs under CC BY-SA. These work for sharing files. They don't say much about manufacturing products, about patents, or about the moment a design file turns into a board you can hold. Hardware licenses were written to fill those gaps.
The main question: what should people owe you?
Open licenses split into two families.
Reciprocal licenses, sometimes called copyleft or share-alike, require anyone who distributes a modified version to release it under the same license. Your design stays open, and so do improvements to it.
Permissive licenses let people do almost anything, including making closed products from your design, as long as they keep your copyright and license notices.
Neither family is better. Reciprocal licenses suit projects that want to grow a commons, where you'd be unhappy to see a competitor ship a closed version of your work. Permissive licenses suit projects that want the widest possible adoption, including inside commercial products, such as reference designs, IP cores and standards.
The CERN Open Hardware Licence, version 2
CERN, the European particle physics lab, wrote the first CERN-OHL in 2011 for its own open hardware repository. Version 2, published in 2020, split the license into three variants that share the same structure. All three cover hardware design source, handle the making and distribution of physical products, and include an express patent license from contributors. All three are approved by the Open Source Initiative.
CERN-OHL-S v2 (strongly reciprocal)
If someone makes and distributes a product or modified design based on yours, they have to make the complete source available under CERN-OHL-S, including the parts they added. There are exceptions for "available components," standard parts like off-the-shelf chips that anyone can buy and that come with enough interface information to use. This is the right pick when you want everything built on your work to stay open.
CERN-OHL-W v2 (weakly reciprocal)
Changes to your design have to stay open, but people can combine it with their own closed designs without opening those. It was written with IP cores and modules in mind, where a company might want to drop your open block into a larger chip or board. Think of it as roughly the hardware counterpart of the LGPL.
CERN-OHL-P v2 (permissive)
People may use and modify the design for any purpose and release their versions under any terms, as long as notices are kept. It keeps the hardware-specific definitions and the patent license from the other variants, which is its main advantage over a software license like MIT.
The variant names come with an SPDX identifier (CERN-OHL-S-2.0, CERN-OHL-W-2.0, CERN-OHL-P-2.0). CERN also recommends naming a "source location," a URL where the design can be found, and putting it on the product where practical. A line on the PCB silkscreen does the job.
Solderpad Hardware License
The Solderpad Hardware License is a permissive license built on the Apache License 2.0. Rather than rewriting Apache, it wraps it with definitions that extend it to hardware and design rights. The current version is 2.1, and stewardship moved to the FOSSi Foundation in 2020.
Because it inherits Apache's text, Solderpad is familiar to corporate legal departments, and it includes Apache's patent grant along with the clause that ends that grant for anyone who sues over patents in the work. That combination has made it popular for open processor cores and chip IP. If your design is digital logic that companies will build into silicon, and you want them to do so freely, Solderpad is a strong choice. CERN-OHL-P is the obvious alternative.
TAPR Open Hardware License
The TAPR OHL was published in 2007 by TAPR, a nonprofit amateur radio organization, and was among the first licenses written specifically for hardware. It's reciprocal: modified documentation has to stay under the TAPR OHL, and it includes a promise not to sue over patents covering products made from the design. It also asks people distributing modified documentation to email it to earlier licensors who provided an address.
You'll still see the TAPR OHL on older projects. It hasn't been updated since version 1.0 and wasn't submitted to the Open Source Initiative. For new strongly reciprocal projects, CERN-OHL-S v2 has more legal review and more users behind it. If you're modifying a project that already uses the TAPR OHL, keep using it.
Creative Commons for documentation
Creative Commons licenses are made for creative works, and they suit the manuals, guides, photos and illustrations that come with hardware. Two fit open hardware:
- CC BY-SA 4.0 (Attribution-ShareAlike): adaptations have to carry the same license. A natural match for a reciprocal hardware license.
- CC BY 4.0 (Attribution): reuse with credit only. A natural match for a permissive hardware license.
Avoid the NC (non-commercial) and ND (no derivatives) variants. They fail the open source hardware definition, and OSHWA certification won't accept them.
For the design files themselves, a hardware license is usually the better tool, because Creative Commons licenses don't deal with manufacturing or patents.
Firmware and software
Code that runs on your hardware, or on a computer talking to it, should use a regular open source software license: GPL-3.0 or GPL-2.0 for reciprocal, Apache-2.0 or MIT for permissive. Match the spirit of your hardware choice if you can. A strongly reciprocal board with permissively licensed firmware is fine, but say clearly in the README which license covers which folder.
How the options compare
| License | Family | Patent terms | Best for |
|---|---|---|---|
| CERN-OHL-S v2 | Strongly reciprocal | Express patent license | Keeping every derivative open |
| CERN-OHL-W v2 | Weakly reciprocal | Express patent license | Modules and IP blocks used next to closed parts |
| CERN-OHL-P v2 | Permissive | Express patent license | Wide adoption, hardware-specific terms |
| Solderpad 2.1 | Permissive | Apache 2.0 patent grant | Chip IP and processor cores |
| TAPR OHL 1.0 | Reciprocal | Non-assertion promise | Projects that already use it |
| CC BY-SA 4.0 | Share-alike | None | Documentation for reciprocal projects |
| CC BY 4.0 | Attribution | None | Documentation for permissive projects |
Once you've chosen
If you're building on someone else's open design, its license usually decides for you. Otherwise, put the full license text in the repository, add an SPDX identifier line to source files, put a notice in the design files, and mention the license in the README. Our publishing guide shows where each piece goes.