A release checklist for open hardware repositories
What to check before you tag a release and send files to the fab.
Independent guide · Not a certification body
Answer a few short questions about what you're releasing and what you want back from people who build on it. The chooser suggests a license, explains it in plain words, and links to a page with the official text.
Your suggestion shows up here as you answer.
A starting point, not legal advice. Read the license text before you publish, and get a lawyer involved when a company, a grant or patents are on the line.
| Ref | Guide | Read |
|---|---|---|
| G01 | What open-source hardware is (and what it isn't) | 5 min |
| G02 | How to publish an open hardware project | 5 min |
| G03 | OSHWA certification explained | 5 min |
| G04 | Choosing an open hardware license | 5 min |
| G05 | How open hardware businesses make money | 5 min |
| G06 | A short history of open hardware | 5 min |
A photo and a promise don't count. Someone you've never met should be able to study the design, change it, build it and sell it. In practice that means four things ship together.
What to check before you tag a release and send files to the fab.
No. This is an independent guide. We don't certify products and we don't speak for any organization. The best-known certification today is run by the Open Source Hardware Association (OSHWA); our certification guide explains how it works.
For firmware and other code, yes, and you should. For schematics, board layouts and CAD files, a hardware license such as CERN-OHL v2 or Solderpad fits better, because it was written with physical products, manufacturing and patents in mind.
No. It narrows the field and explains the trade-offs in plain words. Read the license text before you commit, and talk to a lawyer if a company, a grant or patents are involved.