To license open source hardware, pick a hardware-specific license, put its full text in a LICENSE file at the root of your repository, and release the native design files next to it. CERN Open Hardware Licence version 2 (CERN-OHL-S-2.0, -W-2.0 or -P-2.0) is the usual starting point, and it only works once you have sorted out who owns what in the design.
The part that trips people up is that hardware licenses operate in two layers at once. Copyright covers the files you authored, and a patent clause in the license grants recipients the right to build and sell the physical thing those files describe. Most hardware itself falls outside copyright, so that second layer is doing the heavy lifting.
This is a practical walkthrough, not legal advice. If your design is commercially important or patent-sensitive, have a qualified attorney review the release before you publish.
Table of Contents
- What You Need
- Step-by-Step
- Common Mistakes
- Frequently Asked Questions
- What is the best license for open source hardware?
- Can I use Creative Commons to license a circuit board and its schematics?
- Do I need to open-source the firmware that runs my hardware?
- What attribution must I include when reusing open hardware files?
- Can manufacturers sell products made from an open hardware design?
- Do I need a lawyer to publish an open source hardware project?
- Conclusion: Start With a Clear License Package
What You Need
Five things need to be in place before you publish anything. Missing one of them is the reason most hardware releases confuse the people who find them.
A clear ownership record. Know which parts of the design you made, which came from a colleague, and which came from a reference design, a purchased CAD library, or an existing open source project. You cannot license what you do not own.
The full license text. Download it from the official source, CERN or TAPR, and keep the exact version you used. A paraphrase of a license is not a license.
Native design files. The Open Source Hardware Definition requires the preferred, editable format. Gerber files, drill files, and STLs alone do not qualify, because they are manufacturing outputs rather than the source you designed in.
A public repository. Git works well, and a README plus a LICENSE file at the root is the convention nearly every tool understands.
Notice text. A short block naming the copyright holder, the SPDX identifier, the year, and where the source lives. You will reuse it in the repository, the documentation, and on the board itself.
Step-by-Step
Step 1: Define What You Are Sharing
List every artifact in the project and give each one a license. A typical marine sensor node includes schematic sheets, PCB layout, a bill of materials, enclosure CAD, HDL or firmware source, assembly documentation, and photographs of the finished board.
Decide which of these get the hardware license, which get a software license, and which get a Creative Commons documentation license. Photos of your board and your name are usually not part of the design grant at all, and the OSHWA definition expects you to say so plainly.
How to tell it worked: every file in the repository maps to exactly one license, and a stranger could point at any file and name the license that governs it.
Step 2: Confirm Ownership and Third-Party Rights
Go contributor by contributor. If a colleague drew part of the schematic, get their permission in writing before you license the whole thing under one open license. In a university or funded lab, check whether the grant agreement or the employment contract already assigns the rights to an institution that expects to be named.
Also separate out anything you did not create. Reference designs, symbol libraries, CAD templates, and copied application notes all carry their own terms. Many are fine to reuse but still need to be credited, and some are not licensable at all.
How to tell it worked: you have a written record for every contribution and a separate line for each third-party component in your bill of materials.
Step 3: Choose the Right License
Pick from licenses written for physical things. Software licenses such as GPL or MIT do not address patent rights, which is exactly the gap hardware licensors care about most, and a widely-read distributor article claiming a copyleft software license is fine for a board is misleading.
Here is the short comparison. SPX identifiers are listed because OSHWA certification requires them.
| License and SPDX ID | Copyleft | Express patent grant | Covers firmware | Best for |
|---|---|---|---|---|
| CERN-OHL-S-2.0 (Strongly Reciprocal) | Yes, share-alike on modified hardware | Yes, with termination on litigation | Yes | Community projects that want improvements to flow back |
| CERN-OHL-W-2.0 (Weakly Reciprocal) | Yes, on the design files only | Yes, with termination on litigation | Yes | Most adopters who want freedom without a hard copyleft chain |
| CERN-OHL-P-2.0 (Permissive) | No | Yes, with termination on litigation | Yes | Companies that want adoption over leverage from reciprocity |
| CERN-OHL v1.2 (older) | Varies by variant | Yes | Yes | Reading legacy projects, not new releases |
| TAPR Open Hardware License 1.0 | No, but no patent retaliation clause | Partial, with a patent waiver against originators | No, firmware is a separate grant | Existing TAPR projects |
| Solderpad License 0.51 (Apache 2.0 based) | No | Yes, via the Apache patent grant | Yes | Commercial teams already fluent in Apache terms |
| CC-BY-SA-4.0 | Share-alike on documentation | No | No | Manuals, photos, and written docs only |
| MIT or GPL-3.0 | Varies | GPL-3.0 has one; MIT has none | Yes | Firmware repository only, never the hardware grant |
The decision rule: choose CERN-OHL-S-2.0 if you want any modified board released under the same terms, CERN-OHL-W-2.0 if you want to keep the copyleft confined to design files, and CERN-OHL-P-2.0 if you would rather maximize adoption and let manufacturers keep their changes to themselves. For a first-time licensor, -W-2.0 is a defensible middle.
How to tell it worked: you can name the exact SPDX identifier for every file in the bundle without hesitation.
Step 4: Write the Attribution and Notice Files
The LICENSE file holds the full, verbatim license text. Nothing else belongs in it. A NOTICE file beside it carries your attribution block.
Where each document goes
| File | Purpose | What it must contain |
|---|---|---|
| LICENSE | The grant itself | Full verbatim license text, nothing added or trimmed |
| NOTICE | Attribution and credit | Copyright holder, year, SPDX identifier, source URL, warranty disclaimer |
| README | Orientation | What the project is, which files exist, how to build it, what the license does not cover |
| BILL_OF_MATERIALS | Reproducibility | Every part, its source, and its license if it is not yours |
| HARDWARE.rst or equivalent | The OSHWA documentation criterion | How to obtain the design files at no more than reasonable reproduction cost |
A workable NOTICE block looks like this. Adjust the names, keep the rest:
Project Name — Copyright (c) 2026 Your Name or Organization
SPDX-License-Identifier: CERN-OHL-W-2.0
Design files, documentation, and firmware in this repository are licensed under the CERN Open Hardware Licence v2.0 weakly reciprocal variant.
Documentation and images not covered by that license are released under CC-BY-SA-4.0.
Modified versions must carry a notice stating the changes made and the date.
This work is provided with no warranty. You assume the risk of building it.
People ask on hardware forums whether notices are required in the code. The short answer is that the repository needs them clearly, and any file you modify should carry a change note, even if your chosen variant does not strictly require per-file headers.
How to tell it worked: someone who has never seen your project can find the license text, the copyright holder, and the source location within thirty seconds of landing on the repository.
Step 5: Package the Design Files and Version History
Release the native, editable files: schematic and layout sources in the tool you designed in, the bill of materials, the HDL or firmware source, and the mechanical CAD. Include the manufacturing outputs too, since most people who build your board need them, but never ship them in place of the source.
Tag each release and keep a changelog that says what changed and when. Version history matters here more than in software, because a change in a component can silently change the manufactured result.
How to tell it worked: you can pull any tagged release and rebuild the board from it without asking the author a question.
Step 6: Publish and Maintain the Project
Put the license in the root of the repository so the hosting platform recognizes it, mark the SPDX identifier in your metadata, and describe the project in plain terms. If the board is built, add a visible notice on the silkscreen or enclosure, or a small card with a QR code pointing at the source location.
The OSHWA definition is explicit that attribution has to be accessible to the person using the product, not only to whoever is reading the repository. If someone buys a board and never sees a URL, nobody has been told anything.
Correct errors openly, publish revisions as new tags, and never change the license terms on already-released versions. Licensing is a decision made once, and changing it quietly breaks the trust that made the release worth anything.
How to tell it worked: you can hand someone a physical unit and a link, and they can reach the complete source from what is printed on the board.
Common Mistakes
Using a software license for hardware. GPL, MIT, and Apache say nothing about patents in a way that addresses the hardware question, and MIT in particular carries no patent grant at all. Fix: license the design under CERN OHL or Solderpad, and use a software license only for the firmware.
Omitting attribution. A release with a license but no copyright line, no SPDX identifier, and no source location is technically licensed and practically invisible. Fix: write the NOTICE block and put it in three places, repository, documentation, and the physical artifact.
Licensing material you do not own. Reference designs and CAD libraries carry their own terms, and licensing them as your own is the fastest way to have a project taken down. Fix: build a third-party section in the bill of materials and license only your own work.
Releasing manufacturing files but no source. Gerbers and STLs are outputs. Publishing them alone does not satisfy the OSHWA definition and gives nobody a way to change the design. Fix: always include the native files.
Assuming no license means public domain. It does not. Without a license, default copyright applies and nobody may legally build, modify, or sell your design. Silence is the most restrictive outcome available, not the most generous one.
Shipping a board with no link back. The people who benefit most are often the ones who never find the repository. Fix: silkscreen notice, enclosure label, or a QR code, plus a line in the manual.
Five habits that make the whole job easier. Record contributions as they happen rather than reconstructing them at release time. Keep a third-party register from day one. Read the actual license text instead of a summary of it, because the reciprocity triggers are where surprises live. Version the license, so CERN-OHL-W-2.0 and v1.2 never get confused. And when a design carries real commercial value, get a patent attorney involved before publication, not after.
Frequently Asked Questions
What is the best license for open source hardware?
For most projects, CERN-OHL-W-2.0 is the best default. It applies to design files, firmware, and documentation in one instrument, includes an express patent grant that terminates if a recipient sues you, and confines share-alike to the design files. Choose CERN-OHL-S-2.0 if you want modified boards released under the same terms, and CERN-OHL-P-2.0 if you would rather maximize adoption. Name the exact SPDX identifier in your repository.
Can I use Creative Commons to license a circuit board and its schematics?
Not as a complete hardware grant. Creative Commons licenses are built for creative works and carry no patent grant, so they leave the most-asked hardware question unanswered: does the recipient have the right to build and sell what I designed? Some projects use CC-BY-SA-4.0 for manuals, photographs, and written documentation alongside a hardware license for the design, which is a clean and common split.
Do I need to open-source the firmware that runs my hardware?
Not legally, but the OSHWA definition treats necessary software as part of the design, and a board nobody can reconfigure is only half open. Most projects license firmware with a standard software license such as MIT, GPL-3.0, or LGPL while the design carries CERN OHL. If you use CERN OHL alone, it already covers the firmware, and adding a software license on top is effectively dual licensing that one element.
What attribution must I include when reusing open hardware files?
Three things: keep the copyright notice, state the SPDX identifier of the license the work was released under, and mark any modified version as modified with a notice of what changed. If you sell a product built from someone else’s design, make clear that you manufacture it and that the original designer neither made nor warrants it. The original designer must remain identifiable on the physical product as well as in the files.
Can manufacturers sell products made from an open hardware design?
Yes. All CERN OHL variants permit commercial manufacture, which is the point of the no discrimination against fields of endeavor clause. What differs is whether they must release their modifications. Under CERN-OHL-S-2.0, a modified board must be shared under the same terms. Under CERN-OHL-P-2.0, a manufacturer can keep changes private and sell them. Neither license lets anyone stop you from selling the design.
Do I need a lawyer to publish an open source hardware project?
For a hobby release, a personal build, or a lab instrument with no commercial value, a careful read of the license text and a clear NOTICE file is usually enough. Get a qualified attorney involved when the design is patentable and commercially significant, when your employer or funder may hold rights, when a manufacturer might be interested, or when you plan to dual license. They are also the right person to confirm you can grant patent rights at all.
Conclusion: Start With a Clear License Package
Start with ownership, not with the license. Write down who made each part of the design, separate out everything you did not create, and only then choose a variant. Once that list is honest, the rest is mechanical: the verbatim license text in a LICENSE file, native design files in a public repository, a NOTICE block naming the copyright holder and the SPDX identifier, and a visible link back from the board itself.
Get those four pieces right and your project is genuinely open source hardware in the sense the Open Source Hardware Definition means, and people building on it will know exactly what they may do.
