Open source hardware is a physical device whose complete design — schematics, CAD files, PCB layout, and bill of materials — is published publicly so anyone can study it, change it, build it, and sell what they build. If you have ever wanted to rewire a controller board, swap a sensor, or keep a project alive after its manufacturer has moved on, that idea is the whole point of the field.
For marine makers, this matters in a specific way. A sailing robot or an autonomous underwater vehicle that depends on a sealed, undocumented controller becomes a paperweight the day a chip on it is discontinued. Open designs stay buildable, repairable and improvable by the next person, and they are the reason small ocean-monitoring projects can exist at all.
I will walk through what the term actually covers, what a project should hand you, how the licenses work, and how to tell a genuinely open design from one that is only marketed as open.
Table of Contents
- What Is Open Source Hardware?
- How Open Source Hardware Differs from Open Source Software
- What Should an Open Hardware Project Release?
- How Do Open Hardware Licenses Work?
- What Is the Difference Between Open and Open Source?
- How Is Open Hardware Used in Marine Robotics?
- What Should Beginners Look for in an Open Hardware Project?
- Frequently Asked Questions
- Is open source hardware actually free?
- Can you sell hardware you build from an open source design?
- What is the difference between open source hardware and open source software?
- Why do some open hardware projects release gerber files instead of CAD files?
- Do you have to open source the firmware too?
- What license should a maker choose for an open hardware project?
- Conclusion
What Is Open Source Hardware?
Open source hardware, usually shortened to OSH or OSHW, is any device, machine or mechanical assembly released under an open license together with the design files needed to reproduce it. The Open Source Hardware Association (OSHWA) defines it as hardware whose design is made publicly available so that anyone can study, modify, distribute, make and sell it.
The word that trips people up is design. A PDF of a schematic is not a design. Neither is a set of gerber files. The design is the editable file you open in your CAD tool, plus the schematic, plus the parts list that tells you what to buy, plus whatever the board needs to actually run. That is the equivalent of source code in software, and without it you cannot change the design — you can only copy what someone else already decided.
What makes a project open source hardware
- Public design files: the editable originals, not a printout.
- Permission to modify: you can change it for your own needs without asking anyone.
- Permission to redistribute: you can pass the files on, modified or not.
- Permission to sell: you can build and sell physical copies commercially.
- An open license: the terms are written down and apply generally, not to one product.
- Associated software handled honestly: firmware is either released under an open license or its interfaces are fully documented.
Those six points are the plain-language version of the twelve-criterion OSHW Definition 1.0, published in 2012 after the Open Source Hardware Association and the Open Source Initiative agreed that hardware could use the same four freedoms software had always claimed.
There is also a term you will run into, open documentation, which is much weaker. It means someone published manuals, service guides or exploded diagrams for a product that stays closed. Useful, and it has saved me from guessing at a proprietary connector once. But you still cannot change the design, and that is the difference that matters.
One more correction before going further, because it causes more arguments than anything else in the field: open source hardware is not free. The files are free to use, modify and sell. The components, the board fabrication, the assembly and the shipping are not. Free as in speech, not as in beer, and the joke lands harder once you have seen a small fab quote for a marine controller enclosure.
For a short history: the idea was framed as open hardware back in the late 1990s, TAPR published one of the first hardware licenses in 2007, CERN released its own license in 2011, OSHWA formed in 2012, and the RISC-V instruction set opened chip design in 2015. The most recent shift is the Open Source Technology Readiness Levels framework, which borrows NASA’s maturity ladder so projects can describe how far along a design actually is.
How Open Source Hardware Differs from Open Source Software

With software, copying the source is perfect and free. With hardware, copying the source is the easy part, and it is the only part that is free. Everything after that costs money, which is why the comparison between the two is a comparison of workflows rather than a comparison of principles.
Where a programmer can fork a repository in a second and a server can rebuild it a thousand times for almost nothing, a hardware maker has to order parts, wait for boards, solder, and test. That gap is exactly why hardware designers feel obliged to document far more than programmers do, and why hardware projects that skip documentation tend to be the ones nobody can reproduce.
What counts as source, file by file
| File | What it is | Can you change the design with it? |
|---|---|---|
| Schematic (editable) | The circuit diagram as a source file | Yes — this is real source |
| CAD / mechanical model | Parametric 3D model of the enclosure or mechanism | Yes — real source |
| PCB layout source | Board layout in the EDA tool’s native format | Yes — real source |
| Gerber files | Fabrication output for one specific board | No — you can only copy it |
| Bill of materials | Part numbers, values, references | Partly — you can swap parts, not the topology |
| HDL source code | Verilog or VHDL for FPGA and ASIC designs | Yes — the chip’s source |
| Firmware | Code running on the microcontroller | Yes, if released under an open license |
| PDF schematic | A drawing of a finished board | No |
The rule of thumb is simple: if you could hand the file to a fabricator and have them produce the same object, but you could not hand it to an engineer and have them change the design, then you have manufacturing output rather than source.
Firmware sits awkwardly between the two worlds, and it is worth being clear about it. If a project releases the hardware but keeps its firmware closed, you own a board you cannot reprogram. Some definitions accept that as long as the firmware’s interface is fully documented, because at least you can write something that talks to the board — but most makers find that only halfway useful.
What Should an Open Hardware Project Release?
Ask for these, in roughly this order, and you will know within ten minutes whether a project is genuinely open or just friendly advertising.
- Native CAD and schematic sources in the format the designer actually used, not a converted or exported version.
- PCB layout source files in the EDA tool’s own format, so the board can be edited rather than merely reproduced.
- A bill of materials with real part numbers, including the passives that trips people up.
- Fabrication outputs — gerbers, drill files, pick-and-place data, drill drawings — so someone can order boards without the source.
- 3D models and mechanical drawings for any enclosure, mast mount, hull flange or actuator bracket.
- Firmware source and the toolchain version it was built with.
- Build instructions that a stranger could follow, including which assembly or firmware-flash steps are optional.
- Test procedures — what to measure and what a healthy reading looks like once the board is assembled.
- Version information and a changelog showing board revisions and what changed between them.
- A clear license file, named on the project page, with the license text in the repository.
- Documentation covering interfaces, pinouts, limits and known issues.
Nobody expects a hobby project to ship all eleven perfectly. The ones that survive contact with a real build are the ones that release the first six and are honest about the rest.
How Do Open Hardware Licenses Work?

An open hardware license is copyright applied to a physical design. The four freedoms carry over unchanged — study, modify, redistribute, sell — and what differs is the wording, because a derivative of a circuit board is a different object than a derivative of a program.
The licenses you will actually meet
- CERN-OHL — the most widely used hardware license. Strong copyleft: if you modify the design and distribute it, your modified version must stay open under the same terms.
- CERN-OHL-S — the strong variant, which also reaches the design’s use in a larger system.
- CERN-OHL-P — the permissive variant, where a modified design may be released under different terms, as long as attribution is kept.
- TAPR Open Hardware License — the older community license, permissive in spirit and popular with electronics projects that predate CERN’s.
- Solderpad — a permissive license built on Apache-style terms, popular in the FPGA and small-board world.
- Creative Commons — used for documentation and mechanical designs, and sometimes paired with a hardware license for the rest of the project.
Copyleft versus permissive is the decision most projects agonize over. Copyleft keeps improvements flowing back to the commons and is the right instinct for instruments that a research community depends on. Permissive lowers the barrier for a company that wants to build your board commercially, which is sometimes the only way it gets built at all. There is no universally correct answer, only a trade between protecting the commons and getting hardware into the water.
One thing an open license does not do is hand you the maker’s name or logo. Trademark is separate from copyright, so a derivative must attribute the original design and must not imply the original designer built, sold or endorsed your version. If a project has no stated license, treat it as closed — silence is not permission.
What Is the Difference Between Open and Open Source?
Open hardware means the design is publicly accessible. Open source hardware adds the legal permission to inspect, modify and redistribute it under stated terms. The gap between those two is the whole game: a vendor can publish CAD files with all rights reserved, and every file is technically there while none of the freedoms are.
Apply the same test to documentation. A free service manual is open documentation. A design you may change is open source.
How Is Open Hardware Used in Marine Robotics?
Marine work punishes closed hardware harder than almost any other field, because salt water, sunlight and constant motion destroy components on a schedule you do not control. An undocumented controller in that environment is a single-point failure for the entire vehicle.
Open designs change the economics in a few concrete ways.
Sailing robots and small autonomous surface vessels. Controller boards for wind, rudder and sail actuators are the sort of part that a handful of groups would otherwise each build from scratch. Sharing one open design means a better PID loop implemented once gets inherited by everyone. If you are tuning those loops, what is PID control in simple terms is the useful background, and open hardware is what lets you run that logic on a board you can actually re-flash.
Telemetry and lighting. Night runs, strobes, beacons and telemetry links are mostly a matter of current draw, weatherproof enclosures and a power budget. Open power boards mean you can size a solar panel against a real load profile instead of a vendor’s estimate. Our guide to what lights a small unmanned boat needs covers the sizing side.
Environmental and marine sensors. Water temperature, salinity, dissolved oxygen, wave and motion sensing, GPS and AIS receivers — this is where open hardware is most productive. A published design lets a lab reproduce another lab’s sensor, lets a field unit be repaired locally, and lets you swap in a different sensor without designing a new board around it.
Buoy platforms and swarm systems. When you need twenty identical units, a shared design is not a nicety, it is the only way it is affordable. Divergence between units also becomes a documented problem rather than a mystery, because every change is in the revision history.
Repairs and longevity. The underrated benefit is a boat ten years old with a published board revision you can still order parts for, or redesign around. Field projects outlive their funding, their vendor and often their original team.
None of this means open marine hardware is easy. Salt water gets into connectors, coatings fail at the wrong moment, and a part rated for a lab bench turns out not to be rated for a wet deck — the engineering is hard either way. Open design just makes the failures fixable.
What Should Beginners Look for in an Open Hardware Project?
Before you order parts, work through this list. It is short, and it will save you a lot of time.
- Documentation depth. Are there build instructions a stranger could follow, or only a parts photo and a wishful README?
- File formats. Native CAD and schematic sources, or just gerbers and PDFs? This is the single most common disappointment in the field.
- A named license. CERN-OHL, TAPR, Solderpad, or nothing at all. Nothing at all means assume closed.
- Reproducibility. Has a third party actually built it and written down what happened?
- Revision history. A changelog and dated board versions show the design is maintained rather than abandoned at version 1.0.
- Component availability. Check that the parts on the bill of materials are current, with datasheets you can reach. A design depending on three discontinued parts is a paperweight even if fully open.
- Safety notes. Voltage, current, waterproofing, pressure and battery limits stated plainly, not buried.
- Community activity. An active forum or chat means troubleshooting help exists. Support is a community benefit, not a warranty.
- Certification or published criteria. OSHWA certification exists as a check that the release meets the definition, and it is a useful signal, not a guarantee of quality.
Watch for the forking trap too. Forking a design is trivial; merging two divergent hardware versions back together is very hard, because the boards, the firmware and the documentation all have to agree. Projects that keep a single canonical board with documented revisions tend to be far more useful than a sprawl of near-identical forks.
And if your interest is turning this into work rather than a weekend build, what marine robotics jobs need is worth a read, because open design practice is one of the more useful skills on that list.
Frequently Asked Questions
Is open source hardware actually free?
The design is free. The objects are not. Schematics, CAD files, firmware and documentation can be downloaded and used at no cost, and you can build as many copies as you like. Components, PCB fabrication, assembly, enclosures, certification and shipping all cost money, and for a low-volume marine controller those physical costs usually dominate. That is why a project can be fully open source and still charge a sensible amount for a built board.
Can you sell hardware you build from an open source design?
Yes, under the standard open hardware licenses. The four freedoms explicitly include making and selling, and both CERN-OHL and the TAPR license permit commercial use. Two conditions usually come with it: you must attribute the original designer, and you must not imply that the original designer built, sold or endorsed your version. Trademarks and logos are not covered by the license.
What is the difference between open source hardware and open source software?
The principles are identical, the workflow is not. Software source can be copied and rebuilt for effectively no cost, so copying is frictionless. Hardware source is only a set of files; building from it requires parts, fabrication and assembly, every time. That single difference is why hardware projects need far better documentation, why the format of the released files matters, and why hardware tends to evolve through small revisions rather than fast rewrites.
Why do some open hardware projects release gerber files instead of CAD files?
Gerbers are what a fabricator needs to make boards, so projects release them, and sometimes stop there. But gerbers are manufacturing output, not source. You can send them to a fab and get the same board, yet you cannot change a trace, move a connector or swap a footprint. A genuinely open release includes the native CAD and PCB layout files as well, which is the version you need for modification.
Do you have to open source the firmware too?
Not strictly under every definition. The OSHW definition accepts either firmware released under an open license, or firmware whose interfaces are documented well enough for you to write your own. In practice, most makers want the source. A board with closed firmware can be replaced in hardware, but not reprogrammed, and reprogramming is usually cheaper than redesigning.
What license should a maker choose for an open hardware project?
CERN-OHL is the common default and a safe choice: strong copyleft, widely understood, and accepted by the Open Source Initiative and OSHWA. Choose CERN-OHL-P or the TAPR license if you want modifications to be able to stay closed, which lowers the barrier for a commercial manufacturer. Whichever you pick, publish the full text with the files and make sure it is not tied to one product.
Conclusion
Open source hardware is hardware whose editable design files — schematics, CAD, PCB layout, bill of materials and usually firmware — are published under an open license, so anyone can study, modify, build and sell it. The design is free; the components and fabrication are not.
Your first action is small and takes ten minutes. Pick one project you care about, download its files, and read the license before anything else. If there is no license, stop there. If the only files are gerbers and a PDF, you are looking at manufacturing output, not source. And if the files check out, build one unmodified first — that is the fastest way to find out whether the documentation is as good as it claims to be.


