In the tech community, we’re all familiar with the concept of open-source software. Many of us use it daily, contribute to it, and understand the nuances of different open-source licenses. The fundamental principle is clear: open-source software has its source code available under a permissive license that allows free reproduction and modification. While some purists may take it to the extreme, and there are various licensing models, most of us agree on the core idea.
But when it comes to open-source hardware, things aren’t always so straightforward. Over the years, I’ve heard countless frustrations from friends about hardware projects that claim to be open-source but don’t fully embrace the spirit of openness. This issue deserves a closer look.
Open-Source Hardware Done Right
To explore this, let’s examine two examples of open-source hardware projects—one of my own and another from the broader community.
My Single 8 home movie cartridge is a fully open-source 3D-printable film cartridge designed for a discontinued format. I’ve made all necessary files available in a GitHub repository under the CERN OHL (CERN Open Hardware License). Anyone can download the file, load it into OpenSCAD, generate an STL file for slicing, or tweak the code to create something entirely new. This is open-source at its best—transparent, accessible, and fully modifiable. To make it even easier, I’ve also pre-generated STL files for each supported ISO value.
Now, consider a more complex project: the Tildagon, the badge from Electromagnetic Field 2024. This project has separate repositories for hardware and software, licensed under the CERN OHL and MIT license, respectively. With these files, anyone can replicate the entire Tildagon or modify any part of it within the terms of the license.
The key difference between these projects is complexity. The Single 8 cartridge is straightforward—one type of file, with no ambiguity. The Tildagon, however, is a multi-file project, detailing different components that come together to form a complete device. The important thing is that everything required to recreate or modify the project is available, clearly documented, and properly licensed. This is how open-source hardware should be presented.
Open-Source Hardware Done Wrong
Now, imagine if I had been the developer of the Tildagon and decided to remove some key files from the repository—perhaps starting with the BOM (Bill of Materials), then the KiCAD files. If I only left the Gerber files and a PNG schematic, I could technically still call it open-source hardware.
Would that be fair, though? Sure, people would still have the legal right to use and modify the files I provided. But without the full set of resources, could I really claim my project was just as open as one where all design files were freely available? Editing raw Gerber files is impractical, and providing only the bare minimum is equivalent to releasing just a compiled binary in software terms. Some of my friends argue that this kind of approach is misleading, and I tend to agree.
Of course, I’m not singling out the Tildagon—this is a broader issue. Over the years, several high-profile commercial projects have done exactly this: presenting themselves as open-source hardware while withholding key design files. Some of these projects are widely known, and I even have one on my workbench right now—maybe you do, too.
If all you care about is the final product, this might not seem like a problem. But when companies stretch the definition of open-source purely for marketing purposes, it’s disingenuous. In my view, either something is fully open-source, or it shouldn’t be labeled as such. There’s nothing wrong with closed-source products, but misleading claims shouldn’t be tolerated.
What Can Be Done?
The CERN OHL offers an important concept here: “Complete Source”. This is defined in Clause 1.8 of the license:
1.8 ‘Complete Source’ means the set of all Source necessary to Make a Product, in the preferred form for making modifications, including necessary installation and interfacing information both for the Product and for any included Available Components. If the format is proprietary, it must also be made available in a format (if the proprietary tool can create it) which is viewable with a tool available to potential licensees and licensed under a license approved by the Free Software Foundation or the Open Source Initiative. Complete Source need not include the Source of any Available Component, provided that You include in the Complete Source sufficient information to enable a recipient to Make or source and use the Available Component to Make the Product.
This clause perfectly encapsulates the necessity of releasing all project files for something to be truly open-source. Open-source isn’t just about copying a design—it’s about modifying and extending it. Without full access to all relevant files, meaningful modification becomes nearly impossible.
As a community, maybe it’s time we start holding projects to a higher standard. Instead of blindly accepting every “open-source” claim at face value, we should investigate how open these projects really are. If we don’t, the term open-source hardware will eventually become meaningless, diluted by flashy commercial products that use the label as nothing more than a marketing gimmick.
So, the question remains: How open do we really want open-source hardware to be?
