Open-source hardware is a physical thing whose design anyone may study, change, make and sell. The design is the part that's open. The board on your desk still costs money, and nobody owes you a free one.
That short version comes from the Open Source Hardware Definition, which the community wrote in 2010 and 2011 and which the Open Source Hardware Association (OSHWA) now hosts. Its statement of principles opens with the line that open source hardware is "hardware whose design is made publicly available," and goes on to list the freedoms that matter: study, modify, distribute, make and sell, for the design and for hardware based on it. You can read the full text on OSHWA's definition page. The current version is 1.0.
The definition is modeled on the Open Source Definition for software, and the ideas carry over well. The hard part is that hardware has more than one kind of "source," and some of it is easy to leave out by accident.
The definition, criterion by criterion
The definition has twelve criteria. Most people only need to remember the first four, because the rest describe what a license may and may not do.
The first criterion is documentation. The hardware has to be released with documentation, including design files, and the design files have to be in the preferred format for making changes. For a circuit board that means the native project from your EDA tool, such as a KiCad project, together with the exported Gerbers and a PDF schematic. For a 3D-printed part it means the CAD source, not only the STL mesh. Deliberately obfuscated files don't count.
Second, scope: the documentation must say which parts of the design are released under the license. A project can be partly open. A robot can have an open chassis and a closed motor controller, as long as the release is honest about which is which.
Third, necessary software. If the hardware needs software to work, such as firmware or a driver, then either that software is released under an open source license, or the interfaces are documented well enough that someone could write their own.
Fourth, derived works: the license has to allow modifications and derived works, and allow the modified design to be made and sold.
The remaining criteria say the license must allow free redistribution, may require attribution, can't discriminate against people, groups or fields of use, must apply to everyone who receives the design, can't be tied to one product, can't restrict other hardware or software that ships alongside, and must be technology neutral. A license that only lets you build the device with one company's tools fails that last test.
What actually has to be published
The criteria translate into a fairly stable list of files. For a typical electronics project:
| Item | What people expect |
|---|---|
| Schematic | Native EDA files plus a PDF anyone can open |
| PCB layout | Native files plus Gerbers and drill files for a fab house |
| Bill of materials | Part numbers, values, quantities and footprints |
| Mechanical parts | Editable CAD (STEP is a good neutral format) |
| Firmware | Source code under an open source software license |
| Instructions | How to assemble, test and use it |
| License | A file in the repository and a note in the design files |
Our guide to publishing an open hardware project goes through each item and how to lay out a repository.
Things that look open but aren't
Plenty of products get called "open" in marketing copy without meeting the definition. A few patterns come up again and again.
Schematic only
A PDF schematic helps repair, and it's better than nothing. But a PDF isn't the preferred form for modification, and without the layout files nobody can make a copy of the board.
Non-commercial licenses
A design published under a license that forbids commercial use fails the "make and sell" freedom. Creative Commons licenses with the NC (non-commercial) clause are the usual example. The design might be freely viewable and fun to remix, but it isn't open-source hardware by this definition.
Open API, closed device
A gadget with a documented API or an SDK is easier to program. The hardware itself is still closed.
Files "available on request"
If people have to email you, sign up or agree to a nondisclosure agreement to get the files, the design isn't publicly available.
No license at all
Posting files without a license feels generous, but in most countries copyright applies automatically, so other people have no clear permission to copy and share them. See choosing a license, or try the license chooser.
Why the design gets the freedom and not the device
Software is copied for nothing. Hardware isn't. Atoms cost money, and so do machines, labor and testing. Open hardware deals with that by opening the information and leaving the economics of manufacturing alone. A company can publish every file for a board and still sell assembled, tested units at a profit, because most buyers would rather pay than build. We cover how that works in practice in open hardware business models.
There's a legal side to this too. Copyright protects drawings, documents and code, but it doesn't cover the functional object a drawing describes. Patents can cover a function, and trademarks cover names and logos. This is why hardware licenses look different from software licenses: they have to say something about making physical products, and the better ones include a patent grant. The definition also notes that open hardware doesn't hand over your trademark. Someone can build your design, but they can't sell it under your brand.
Open-source hardware versus "open hardware"
You'll see both terms. "Open hardware" is the older, looser phrase and has been used since the late 1990s for anything from published specs to free designs. "Open-source hardware" usually means a project that meets the community definition. Some groups also say "free hardware" or "libre hardware," echoing the free software movement. In everyday use the terms overlap, and this site uses them interchangeably, but when someone claims their product is open-source hardware, the twelve criteria above are the fair test.
Certification is optional
Nothing requires you to register a project to call it open-source hardware. If it meets the definition, it is. OSHWA does run a free certification program that lets a project show a logo and a unique ID, which helps buyers and contributors trust the claim. It's run by OSHWA, not by this site; our certification guide explains how it works.
A quick self-check
Before you call a project open-source hardware, ask four questions:
- Could a stranger build a copy from the files I published, without asking me anything?
- Are the files in the format I'd use to change them myself?
- Is there a license that allows modification, manufacture and sale by anyone?
- Have I said clearly which parts, if any, are not covered?
If the answer to all four is yes, you're most of the way there. The rest is good documentation, and that's mostly patience.