“Open source” carries real ethical weight among engineers and tinkerers. It signals a commitment to transparency, collaborative improvement, and user sovereignty. But the movement has matured, and a distinct fork has appeared in its philosophy: open source software on one side, open source hardware on the other. We habitually lump them together under a single banner of shared digital ideals. That’s a mistake. The differences aren’t superficial. They’re rooted in the physics of atoms versus bits, in the economics of fabrication versus distribution, and in the legal frameworks that govern each. My aim here is to dissect these two paradigms with the precision they deserve.
The Core of the Fork: Information Versus Instantiation
At the most basic level, the distinction comes down to the nature of the product. Open source software is a set of instructions—source code—that can be copied, modified, and distributed at essentially zero marginal cost. A developer in Mumbai forks a repository hosted in Berlin, compiles it, and runs the binary in seconds. The whole lifecycle, from source to executable, is pure information manipulation. The license—usually a GPL, MIT, or Apache variant—governs the copying and modification of that information. Sharing costs nothing beyond a network connection.
Open source hardware deals with a design specification that must become a physical object. A schematic, a board layout file, a mechanical CAD model—that’s the “source code” of hardware. But the output isn’t an executable. It’s a tangible artifact: a PCB, a machined bracket, an injection-molded enclosure. This instantiation step introduces non-trivial costs and dependencies. Licenses like CERN OHL or TAPR have to account for that gap. They can’t just govern copying a file. They have to, in some way, address the fabrication and distribution of the physical object the file describes. That’s the first great schism.
Licensing Logic: Copyright and Its Limitations
Software licenses lean heavily on copyright law. Copyright automatically attaches to a creative work the moment it’s fixed in a tangible medium—like writing a line of Python. When I release software under the GPL, I’m wielding my copyright to grant permissions. I’m saying: “You may copy, modify, and distribute this work, provided you pass on these same freedoms.” The legal mechanism is well-tested. A whole generation of lawyers and hackers has worked through the implications.
Hardware licenses operate in a murkier legal landscape. The design files for a circuit board—the schematic and Gerber files—may be protected by copyright as a graphic or literary work. The CERN Open Hardware Licence version 2 explicitly relies on that. But the physical hardware itself, the assembled PCB with components soldered on, generally isn’t protected by copyright. It’s a functional article, and its protection falls under patent law, not copyright. That means a pure copyleft approach—where the freedom of the design is legally mandated to propagate to the physical object—is legally fragile. The licensor can’t easily impose conditions on a third party who builds and sells the board without using the original design files, maybe by recreating it from a netlist. The OSHW community has thus developed a social contract, a set of community norms that often carry more weight than the legal text itself. The Open Source Hardware Association’s logo is a declaration of intent as much as a legal marker.
The Copyleft Challenge in Atoms
In software, a strong copyleft license like the AGPL creates a “viral” effect. Link your code to AGPL code and offer a network service, and you must release your code. This chain of obligation is sustained through copying and modification—both copyright-restricted activities. In hardware, the chain breaks at fabrication. When I buy an open source hardware device, I don’t “execute a license” at the moment of use. The physical object is mine. My right to use, resell, or reverse-engineer it is largely unrestricted by copyright. That’s a profound philosophical difference. The freedom of open source software is a freedom of information actively maintained by a legal chain. The freedom of open source hardware is a freedom of design publication that hopes to influence behavior in the physical space, primarily through transparency and the promise of collaboration.
The Economics of Forking
A software fork is a strategic action. When maintainers make a decision the community dislikes, a fork can be created, developed, and released as a complete, usable alternative—often in weeks. The barrier is competence and time. For hardware, a fork is a financial commitment. Modifying a PCB layout is one thing. Fabricating a prototype, assembling it, and testing it is another. A single prototype run with components and stencils can cost hundreds of dollars. Scaling to a production run requires thousands more, plus inventory management and certification testing if the product must meet FCC or CE standards. This economic gravity means hardware forks are rare and tend to be less radical. They often show up as minor derivative boards—a “remix” with a different sensor or a smaller form factor—rather than a fundamental re-architecture. The community’s relationship with a hardware project is therefore more conservative and deeply tied to the original designer’s ongoing stewardship.
Toolchain Dependencies and Sovereignty
An open source software project can, in its purest form, be self-hosted. The compiler (GCC), the build system (Make), the editor (Emacs)—all can be open source. The whole toolchain can be free. The GNU project fought for that and largely achieved it. An open source hardware design, however, often stands on a proprietary foundation. The EDA tool used to draw the schematic and layout the board—Altium Designer, OrCAD, or even KiCad, which is a beacon of freedom—is just the start. The components themselves, the microcontrollers and sensors, are proprietary silicon. Their full datasheets may require a non-disclosure agreement. The firmware on a microcontroller might be compiled with a proprietary compiler. The FPGA fabric is configured with proprietary bitstream generation tools from Xilinx or Intel. This creates a hierarchy of openness. A board may be “open source” because its schematics and layout are published under a permissive license, but the silicon it hosts is a black box. The user’s sovereignty is limited to the board’s interconnects, not its core computation. A true open source hardware engineer must navigate these layers, constantly making pragmatic trade-offs between ideal freedom and functional capability.
Firmware: The Bridge Between Worlds
Firmware is the liminal space where OSS and OSHW collide. An open source hardware board is a paperweight without firmware. If the firmware is a proprietary binary blob, the device isn’t meaningfully open, regardless of the PCB design files being public. The community’s ability to fix bugs, add features, or audit security is nullified. That’s why the most respected open source hardware projects, from Arduino to the Precursor mobile device, place immense emphasis on the openness of their firmware and bootloader. They understand that the hardware is a platform for running software, and if the software is locked down, the hardware is effectively a closed appliance. The OSHW definition from the Open Source Hardware Association recognizes this, stating that the software necessary for the hardware to function properly should be released under an OSI-approved license. This requirement acknowledges that the boundary between the two is permeable and that a principled stance on hardware must encompass its embedded code.
Verification and Trust: From Checksums to X-Rays
Verifying a piece of open source software is a deterministic process. I download the source code, audit it, compile it with a trusted compiler, and verify that the resulting binary matches the distributed binary through a reproducible build. That gives me a chain of trust from human-readable code to machine-executable instructions. For hardware, no such direct chain exists. I can inspect the published Gerber files and compare them to the physical board in my hand. I can test continuity with a multimeter. But I can’t easily verify that the microcontroller on the board is the exact part specified and not a cheaper, compromised clone. I can’t verify—without destructive analysis—that the PCB has the correct layer stackup and impedance control. Trust in open source hardware is ultimately trust in the distributor and the manufacturing supply chain. The design files are a promise. The physical object is a delivery. The gap between them can only be bridged by destructive testing, X-ray imaging, or, most commonly, by the reputation of the entity commissioning the fabrication.
A Principled Conclusion
The distinction between open source software and open source hardware isn’t about one being “better” than the other. It’s about understanding the terrain you’re operating on. OSS fights for freedom in a space of pure logic and near-zero duplication costs, where copyright is a sharp and effective instrument. OSHW fights for transparency and user rights in a space of physical supply chains, capital-intensive fabrication, and a legal system that was never designed for it. The open hardware engineer must be a systems thinker, comfortable with the messy compromises of proprietary silicon and the social enforcement of norms where legal enforcement fails. The open source software developer can, in theory, achieve a level of purity and self-contained sovereignty that the hardware designer can only asymptotically approach.
As we advocate for the right to repair, study, modify, and share the devices around us, we must be precise in our language and principled in our demands. Recognizing the deep, structural difference between opening code and opening a machine is the first step toward building a world where both are done with integrity.
Frequently Asked Questions
- Why can’t a hardware license simply enforce copyleft on the physical product like the GPL does for software?
- Copyright law, the mechanism behind the GPL, doesn’t typically cover functional physical objects. A PCB is a functional article, not a creative work of authorship. The legal chain of obligation that forces the release of modified source code in software breaks down when an object is manufactured from a design file, especially if the manufacturer doesn’t directly copy the file but re-creates the design.
- If a piece of hardware is “open source,” does that automatically mean it respects my freedom?
- Not entirely. The design files for the PCB might be open, but the device may still contain proprietary chips, require proprietary firmware, or be encumbered by patents. True freedom of the device depends on the openness of its entire stack: from the hardware design files to the firmware, the FPGA bitstreams, and the toolchains required to modify them.
- What is the primary economic barrier that prevents more open source hardware forks?
- The cost of instantiation. Forking a software project costs time and compute cycles. Forking a hardware project means not only redesigning the board but also paying for prototype fabrication, component procurement, assembly, testing, and potentially expensive regulatory certification. This capital requirement creates a high barrier that naturally centralizes development around a few well-resourced entities.