An open hardware license is permission, in writing, to study, build, modify, sell and distribute a physical design, provided you pass the design files and documentation along under the same terms. In practice it decides three things: who can build your work, whether their version has to stay open, and what paperwork travels with the thing they build.
That is what open hardware licenses mean in practice for a maker sitting in front of a repository with a board to release and no idea which text to drop in. The license names get debated endlessly, and the actual decisions are only a handful.
The confusion is rarely about the word open. It is about what the paper actually covers, which is why a lot of designers pick a license defensively rather than by intent. Let’s untangle it the way a maker would, with real files and real decisions.
Table of Contents
- What Is an Open Hardware License?
- What Can an Open Hardware License Let You Do?
- What Obligations Does an Open Hardware License Impose?
- Permissive vs Copyleft: Which Terms Fit a Project?
- How Do You Apply a License to a Complete Marine Robot?
- What Must Be Included When You Sell or Manufacture the Design?
- What If a Project Uses Multiple Licenses and Dependencies?
- How to Choose and Document the Right License
- Frequently Asked Questions
- Do I need an open hardware license for the firmware, CAD files, and circuit design separately?
- Can I sell a product made from an open hardware design?
- What files count as the source of an open hardware project?
- Can I change an open hardware design without publishing the modification?
- Can I mix permissive and copyleft components in one marine robot?
- What open hardware licenses mean in practice for a small team or hobby project?
- Conclusion
What Is an Open Hardware License?
Open means the design is published and reproducible, not that it is cheap or free to manufacture. Someone pays for the parts, the fab run and the assembly labour whether or not a license exists.
The license itself is a legal instrument attached to a set of files. It grants rights that copyright law would otherwise reserve to you, and attaches conditions to those rights. What you are actually licensing is a permission to build, plus a set of promises about what the person building has to do in return.
Four different things sit in a hardware project, and they are not covered by one document:
- Design files — schematics, PCB layout, CAD and enclosure models, HDL sources.
- Documentation — manuals, assembly guides, wiring diagrams, calibration sheets.
- Firmware and software — the code on the microcontroller and anything on the host side.
- The physical article — the board or enclosure sitting in the water right now.
Copyright covers the first three. It does not cover the fourth, and that gap is the reason hardware needed its own licenses. Making an object from a licensed design is not a derivative work in the copyright sense.
The Open Source Hardware Association’s definition treats an open source hardware license as one for tangible artifacts — machines, devices and other physical things — that carries no discrimination against persons or groups, no discrimination against fields of endeavor, and no restriction on what anyone may do with the design.
That last clause is where a lot of well-meaning licenses fall apart. A non-commercial clause or a no-derivatives clause violates the definition, which is exactly why Bunnie Huang’s open-source laptop and several hobby projects drew debate when they reached for Creative Commons BY-SA rather than a hardware-specific license.
Why hardware needed its own licenses
Software licenses solved a linking problem. In code, the boundary between your work and someone else’s is visible and has a workable rule: link and you inherit the terms. A physical object has no such boundary.
A clamp made by a print shop sits on your frame, and nobody can say where one design ends and the other begins. That is why hardware licenses lean on the permission grant, on explicit patent language and on a definition of which files count, rather than on any hope that a court will draw a clean line around a derivation.
Getting this distinction right changes what you publish. The license attaches to a file set and a set of promises, not to a board sitting on a bench somewhere, and the four deliverables each need a decision rather than one blanket choice.
What Can an Open Hardware License Let You Do?
A license lets you study the design, reproduce it unmodified, modify it, manufacture it, sell what you manufacture, and distribute the files to anyone, including people who will compete with you. That last permission surprises people. Commercial reuse is not a loophole in these licenses, it is an intended grant.
CERN’s stated rationale is peer review and the freedom to study, modify and manufacture, explicitly including commercial companies.
Then there is the part a hardware license cannot reach.
Rights that stay with you no matter what the license says
Trademark. The name and logo are never licensed. If you publish a design called Proteus Sensor, nobody else may call their board that, but nobody else is stopped from building it or even from selling it under a different name.
Patents. Copyright never touched patents. Most hardware licenses deal with this through an explicit patent grant or a patent retaliation clause, and the two work very differently. CERN OHL includes a patent grant from the licensor and a retaliation clause that revokes that grant if you sue patent holders over the licensed work.
Registered design rights and regulatory approval. An industrial design registration is a separate right, and publishing openly before registering can cost you novelty in some jurisdictions. Safety certification is yours, not the licensee’s.
Warranty and liability. Every one of these licenses disclaims warranty. That disclaimer does not stop someone building your design and blaming you when it fails in the field.
Reading a license for the four things it does not say
Most confusion comes from silence rather than from a clause nobody understood. Check what the text says about firmware, about documentation, about the licensor’s own rights, and about what happens if someone does none of it.
Firmware is the big one, and the answer is consistent across the main hardware licenses: not covered. Read a CERN OHL or Solderpad license without assuming the code on the board falls inside it. If nobody licensed the firmware separately, it is under default copyright, which means nobody can redistribute it.
Documentation is a similar gap in some releases. Schematics may be covered while the assembly guide that makes the design usable is not, which produces an open release nobody can actually build from.
The licensor’s own rights matter too. Copyleft terms differ on whether they bind the original designer to downstream users or only bind downstream users to each other, and that difference decides whether you owe your own contributors anything if they later build on your project.
And the last thing every license is silent on: what happens when somebody ignores the terms. A license with no enforcement mechanism and no termination clause is a request rather than a contract, which is why all the widely used ones include a termination provision.
What Obligations Does an Open Hardware License Impose?
Reciprocity is the core obligation: the design you publish and anything derived from it stays under the same license, so the improvements circulate back. On top of that sit four smaller duties that catch people out.
- Attribution. Credit the original designer, with a link, in reasonable form.
- License notice. Ship a copy of the license text with the files and with the physical product.
- Source availability. Publish the design files, not just the manufacturing output.
- Modified-design marking. Label changes, mark the work as modified, and keep the revision history traceable.
Those duties land differently depending on how the design reaches the world.
| Obligation | Published repository | Distributed kit | Sold or manufactured unit |
|---|---|---|---|
| Notice | LICENSE file plus SPDX tag in metadata | Printed card in the box, and in the repo | Marking on the board or enclosure, plus docs |
| Attribution | Credit line in README and NOTICE | Credit in the assembly guide | Data sheet or product page naming the designer |
| Source availability | Original design files in the repo | Files included on a published link | Offer files with the product or on request |
| Modification marking | Version history and change notes | Notes on any included variant | Mark modifications on the modified part only |
| Reciprocity | Derivatives inherit the license | Derivatives inherit the license | Derivatives inherit the license |
Note the asymmetry in row three. Publishing Gerber files alone is not an open release under any of these licenses. They are manufacturing output, not source. The OSHWA distinction between original design files and auxiliary design files is doing the real work here: schematics in a native format are original; Gerbers are auxiliary.
Source availability also has a timing dimension. Files that sit in a private repo for two years after you start selling boards are technically available and practically useless, which is why the copyleft terms tie the availability obligation to the moment you distribute the work in product form rather than leaving it to good intentions.
Attribution is where most compliance failures actually happen, and almost never at the design level. A manufacturer will happily put a credit in the manual and then drop it when the manual moves online. Put the credit in the repository, in the schematic title block and on the physical item, so removing it takes deliberate work.
Permissive vs Copyleft: Which Terms Fit a Project?
Three families cover almost every real decision, and the difference between them is one question: when someone modifies the design, do they owe anything back?
Permissive licenses owe nothing back. Someone can build your sensor, change the connector, sell it, and keep the changes closed. Copyleft licenses require derived designs to carry the same terms, so the modification travels forward as open.
The five licenses you will actually choose between
| Criterion | CERN-OHL-S-2.0 | CERN-OHL-W-2.0 | CERN-OHL-P-2.0 | TAPR-OHL-1.0 | Solderpad |
|---|---|---|---|---|---|
| Reciprocity | Strongly reciprocal | Weakly reciprocal | Permissive | Reciprocal | Permissive |
| Commercial reuse allowed | Yes | Yes | Yes | Yes | Yes |
| Modifications must stay open | Yes, always | Only if you distribute the modified files | No | Yes | No |
| Patent handling | Patent grant plus retaliation clause | Patent grant plus retaliation clause | Patent grant plus retaliation clause | Patent grant plus retaliation clause | Apache 2.0 patent grant |
| Attribution required | Yes | Yes | Yes | Yes | Yes |
| Covers firmware | No | No | No | No | No |
| SPDX identifier | CERN-OHL-S-2.0 | CERN-OHL-W-2.0 | CERN-OHL-P-2.0 | TAPR-OHL-1.0 | Not listed |
| Typical adopters | Research instruments, interconnects | Designs that want optional reciprocity | Boards that want adoption over control | Legacy boards still in circulation | Boards, modules, shields |
| Best for | A module you want to keep improving in the open | A platform where you want openness without locking builders in | A reference design you want adopted widely | Very little new work today | A part you want a company to build and sell |
CERN OHL v2, released in 2020, is the current version and supersedes the v1.1 and v1.2 advice still circulating in older posts. It exists in the three variants above.
TAPR OHL 1.0 has largely been superseded. Bonvoisin and colleagues record in their 2020 survey of standardisation practices that the TAPR OHL became less popular as licenses with more general utility appeared, specifically CERN OHL and Solderpad. New projects rarely pick it, though plenty of boards still carry it.
Solderpad is derived from Apache 2.0, and that derivation is the reason it wins adoption. Maker teams tend to choose it because it is Apache-derived and their organisation already has legal familiarity with that text, not because of technical merit. The same Apache 2.0 lineage means no retaliation clause.
Three projects, three different answers
A university lab building a one-off instrument for its own use has no adoption problem to solve, so it often picks the term its institution already knows, or the most permissive one. Nothing downstream is harmed either way.
A startup selling an assembled product built on a design they did not invent is in a different position. They need to know whether they can keep their improvements closed, because those improvements are the business. Solderpad or CERN-OHL-P-2.0 answers that cleanly; CERN-OHL-S-2.0 does not, and picking it quietly hands competitors a share of the work.
A group publishing a sensor module they want to keep improving through contribution is the third case. Here CERN-OHL-S-2.0 is the right call, because it guarantees that the fix a stranger submits in year three comes back under the same terms the project started with. That guarantee is the whole reason to accept the reciprocal obligation.
Weak copyleft sits between the two and is chosen for a specific reason: it lets someone build a product privately from your design without publishing anything, but obliges them to open up if they distribute the modified design files themselves. It is a reasonable middle when you want contribution but not surveillance.
Jargon you will meet in the license texts
These terms show up in every discussion and mean less obvious things than they sound like.
- Strongly reciprocal — copyleft that binds every derived design, whether or not the derived design files are distributed. This is CERN-OHL-S-2.0.
- Weakly reciprocal — copyleft that binds only when the modified design files themselves are distributed, so a private manufactured product triggers nothing. This is CERN-OHL-W-2.0.
- Derivative design — hardware licenses define this by reference to modification of the licensed work, not by the physical assembly. Whether a new bracket counts depends on the files it came from.
- Patent retaliation clause — a provision that revokes the licensor’s patent grant if the licensee sues someone else over patents covering the licensed work.
- Original design files — schematics, PCB layout in native format, CAD models and the bill of materials. These are the source.
- Auxiliary design files — Gerbers, drill files, pick-and-place output and panel drawings. Necessary to manufacture, but not the source.
- SPDX identifier — the standardized license ID string, such as CERN-OHL-W-2.0, that automated tooling uses to recognise what terms a file set carries.
- FOSH — free and open source hardware, the term used when talking about designs that satisfy both the freedom requirements and the open hardware definition.
How Do You Apply a License to a Complete Marine Robot?
A complete marine robot is where the layered licensing problem gets real. You have electronics, an enclosure that may be printed or machined, firmware, a host-side control program, documentation, and a pile of bought parts.
What the project license covers
Point the license at the files you produced: schematics, PCB layout in native format, CAD and enclosure models, bill of materials, firmware and gateware if you wrote it, manual, wiring diagrams, calibration data, fabrication assets such as drill files and panel drawings, and the scripts that generate them.
Commit a LICENSE file at the repository root and add the SPDX identifier to the metadata. Anything you did not create stays with whoever did.
What it does not cover
Third-party libraries, KiCad symbols and footprints, 3D-printing models pulled from a print farm, datasheets, and purchased components all carry their own terms. Most are fine to use; the trap is assuming so because they came from a repository. Check each one and record the answer in a dependencies file.
Why field deployment changes the calculus
A board that ends up in salt water is a board somebody will eventually repair in a boat shed, not a clean room. The person doing the repair needs the right to study the design, make a replacement part, and keep working on it without asking permission. If your license forecloses any of that, you have designed a deployment that ends at the first fouled sensor.
The other field-specific issue is longevity. Instruments get deployed longer than anyone planned for, and the team that maintains them may not be the team that built them. Publishing firmware under a permissive software license, keeping the fabrication files in a stable repository, and stating plainly that no warranty is offered all help the next person more than any clever clause in the hardware license.
What Must Be Included When You Sell or Manufacture the Design?
Once money changes hands, the obligations get specific, and the exact duties depend on the license you picked. Under any CERN OHL variant or TAPR OHL, a manufacturer who sells boards based on your design takes on the same obligations you did: keep the license notice and attribution intact, mark modifications, make the source available, and license the derived design under the same terms.
Solderpad changes that picture. A builder under Solderpad is not obliged to open their changes or pass anything on. They still owe attribution and the Apache 2.0 patent grant, and they do not get your trademark.
Two practical habits survive every choice. Mark something physical — silkscreen, an engraved plate, a line in the manual — so the notice travels with the object. And keep product identification or a serial reference so that when the tenth company builds your design, you can tell whose version you are looking at.
For commissioned builds, get the license position in writing before the first board spins. It takes one paragraph and removes the most common dispute in small collaborative projects.
Why the same license behaves differently in different countries
The text is identical everywhere, but the surrounding law is not. Three places where this bites.
Patent retaliation clauses are the clearest example. Whether a clause that revokes a patent grant on the grounds that you sued someone else is enforceable, and what it actually revokes, depends on the patent law it lands in. Enforceability questions around retaliatory patent clauses have been litigated in the United States, and the reasoning does not transfer neatly to jurisdictions with a different patent litigation culture.
Design registration is the second. If you publish a design openly before filing, you can lose the novelty that a registered design right depends on. That is a real consequence in jurisdictions with a short novelty window, and it applies whether or not anyone uses your license.
Copyright scope is the third, and it is the one most people assume is universal. Copyright protects a drawing or a file. It does not protect the object made from it, and how much protection the file gets varies by country. Moral rights also attach differently depending on where you are, which can matter if you modify someone else’s published design and the law in their country gives them a say over how it is presented.
The practical advice is unglamorous. Publish under a well-tested license, keep the file set and the notices complete, and where a specific project has real money or real patent exposure attached to it, take local advice rather than assuming the US reading of the clause travels.
What If a Project Uses Multiple Licenses and Dependencies?
Every serious hardware project mixes licenses, and mixing is normal. The question is whether the obligations are compatible, which usually means checking one thing: does anything in the stack carry a clause that restricts what a recipient may do with what they receive?
Hardware license against hardware license: a design under CERN-OHL-S-2.0 and a module under Solderpad can be combined, and the result stays under the stronger reciprocal term. Mixing an open license with a proprietary or no-derivatives license on the same design is not a combination, it is a contradiction.
Hardware against firmware: the two do not interact. CERN OHL and Solderpad apply to hardware only, and this comes up constantly in forum threads without a clear answer. License your firmware separately, and pick terms that fit what you want from the software.
HDL and IP cores: gateware has no clear linking vector the way object files do in software, so treat VHDL or Verilog sources as their own deliverable with their own license. Vendor IP cores are licensed to you, not to your users, and you generally cannot pass them on.
Documentation: CC BY-SA 4.0 is a reasonable choice for manuals and datasheets because it is unambiguous and widely understood. Just keep it in a separate file so nobody assumes the whole repository is CC.
The habit that prevents most problems: maintain a dependencies file listing every imported asset, its source, its license and its SPDX identifier. It is dull work and it settles arguments in minutes.
How to Choose and Document the Right License
A six-step selection process
- Name the freedom you actually want. Adoption, or control. These pull toward different licenses and you cannot fully have both.
- Identify what you hold. Copyright in the files, any patent application, any design registration, and the trademark. Only the first is usually clear.
- Check the dependencies. Anything already imported constrains your choice before you make it.
- Compare the shortlist. For most makers that is Solderpad, CERN-OHL-P-2.0 or CERN-OHL-W-2.0. Reach CERN-OHL-S-2.0 when the module must stay open to stay useful.
- Test the downstream obligation. Imagine the builder you most want to say yes, and check whether your license lets them do the thing that made them interested.
- Write the choice down in the repository, on the physical product and in a BOM or NOTICE file.
On documentation, three details do most of the work. Name the version, because CERN OHL v2 and v1.x are not interchangeable and older advice is still indexed.
Add the SPDX identifier so your bill of materials tooling resolves it rather than choking. Hardware licenses are still poorly covered by many SBOM tools, and a missing identifier surfaces as an unknown component during an audit. And keep a CHANGELOG, because modified-design marking only works if you can show what changed when.
One more thing worth knowing about the ecosystem: Solderpad moved under FOSSi Foundation stewardship in a recent update. The permissive option makers reach for is actively maintained rather than parked.
If you are weighing the ecosystem as a whole, the practice ranking that shows up most often in practitioner threads runs from most to least permissive: Solderpad, then CERN OHL, then TAPR OHL. Real projects in the wild still cluster around CERN-OHL-P-2.0 and CERN-OHL-S-2.0, with plenty of boards on MIT and a depressing number carrying no license at all.
Frequently Asked Questions
Do I need an open hardware license for the firmware, CAD files, and circuit design separately?
Yes, treat them as three separate deliverables. The hardware license covers schematics, PCB layout, CAD files and documentation. Firmware and host-side software need a software license such as MIT, Apache 2.0 or GPL, because CERN OHL, TAPR OHL and Solderpad all apply to hardware only. Documentation can sit under CC BY-SA 4.0. Keep them in separate files with separate notices so nobody has to guess what covers what.
Can I sell a product made from an open hardware design?
Yes. Every major open hardware license grants the right to manufacture and sell, and CERN states that permission for commercial companies is intentional rather than a gap. Under a copyleft term you must keep the license notice and attribution, mark modifications, publish the source files and license your derived design under the same terms. Under a permissive term such as Solderpad you can keep your changes closed. You never get the original trademark.
What files count as the source of an open hardware project?
Original design files: schematics, PCB layout in a native editable format, CAD and enclosure models, HDL sources, bill of materials and the scripts that generate them. Auxiliary files such as Gerbers, drill files and panel drawings help manufacture the design but are not the source, and publishing only those does not count as an open release. Documentation belongs in the release too, since a schematic nobody can assemble from is not much of a permission.
Can I change an open hardware design without publishing the modification?
Under a permissive license such as Solderpad or CERN-OHL-P-2.0, yes. You can modify it, sell it and keep the changes to yourself. Under CERN-OHL-W-2.0 the duty to publish arises only when you distribute the modified design files. Under CERN-OHL-S-2.0 and TAPR-OHL-1.0 the derived design must be licensed under the same terms, so a modification you publish obliges you to open it. Attribution is still required in every case.
Can I mix permissive and copyleft components in one marine robot?
Usually yes. A module under Solderpad can be combined with one under CERN-OHL-W-2.0, and the combined derivative stays under the reciprocal term. What you cannot do is combine open terms with a no-derivatives or non-commercial clause on the same design, because that contradicts the OSHWA definition of open source hardware. Keep a dependencies file recording the source and license of every imported asset so the combined obligations stay auditable.
What open hardware licenses mean in practice for a small team or hobby project?
In practice it means choosing between adoption and control, then writing the choice down. If you want companies building and selling your board, pick Solderpad or CERN-OHL-P-2.0. If you want your sensor to keep improving as an open standard, pick CERN-OHL-S-2.0. Commit a LICENSE file, add the SPDX identifier, mark the notice on the board and keep a dependency list. That is the whole job for a small team, and it takes an afternoon.
Conclusion
Start before you pick a license: write down who owns the files, which downstream freedom you actually want, what you will distribute and what you imported from someone else. That list narrows the choice to two or three real options, and the rest is attribution, source availability and marking the notice somewhere a person will actually see it.
This describes how these licenses generally work, not how your specific project will be treated. If the money or the patent exposure is real, talk to a lawyer in your jurisdiction.
