Open Source Hardware, How Open Do You Want It To Be?

In our wider community we are all familiar with the idea of open source software. Many of us run it as our everyday tools, a lot of us release our work under an open source licence, and we have a pretty good idea of the merits of one such document over another. A piece of open source software has all of its code released under a permissive licence that explicitly allows it to be freely reproduced and modified, and though some people with longer beards take it a little too seriously at times and different flavours of open source work under slightly different rules, by and large we’re all happy with that.

When it comes to open hardware though, is it so clear cut?  I’ve had more than one rant from my friends over the years about pieces of hardware which claim to be open-source but aren’t really, that I think this bears some discussion.

Open Source Hardware As It Should Be Done

To explore this, we’ll need to consider a couple of open source hardware projects, and I’ll start close to home with one of my own. My Single 8 home movie cartridge is a 3D printable film cartridge for a defunct format, and I’ve put everything necessary to create one yourself in a GitHub repository under the CERN OHL. If you download the file and load it into OpenSCAD you can quickly create an STL file for your slicer, or fiddle with the code and make an entirely new object. Open source at its most efficient, and everyone’s happy. I’ve even generated STLs ready to go for each of the supported ISO values.

The beautiful EMF2024 Tildagon. CC-BY-4.0

For the second example project it’s necessary instead of a single OpenSCAD file, to consider a more complex design with multiple files. The Tildagon was the badge at the Electromagnetic Field 2024 hacker camp, and there are repositories for its hardware under the CERN OHL, and its software under an MIT licence. Using the contents of these repositories, you can make your own Tildagon in its entirety, or rework any part of it under the terms of the licence.

Of these, the film cartridge is a simple repository. Whether you download the OpenSCAD file or the STLs, there’s only one type of file and it’s unambiguous what the project comprises. But the Tildagon is much more complex device, that has many different files describing its various parts, all of which come together to make the whole. Everything required is present, and the terms of use for it all are clearly defined. For me, it’s a great example of how a complex open-source hardware project should be presented.

Open Source Hardware As It Shouldn’t Be Done

Now, imagine that instead of the EMF folks, I was the developer of the Tildagon. Imagine that I started taking files away from the repositories. The BOM first perhaps, then the KiCAD files. If I were left with just the Gerbers and the PNG schematic, I’ve in theory provided just enough resources to make a Tildagon, and with an appropriate open-source licence I could call it an open-source hardware project.

But even though I’ve granted people the right to use and modify the files in an open-source manner, can I really claim it’s as open-source as if I had released the full set of resources? Hand-editing the source of a Gerber doesn’t really count, and I agree with a point made by some of those friends I mentioned earlier. Providing as little as possible in that way is the equivalent of releasing a compiled binary, as when the convergence factor with free-as-in-beer approaches one, maybe it’s not open-source hardware after all.

Of course, the astute among you will have gathered by now that this isn’t about the Tildagon, instead I’m using it as a metaphor for something else. Though it’s tempting to do so I am not going to name and shame, but there have been a series of high-profile commercial open source hardware projects over the years that do to a greater or lesser extent just what I have described. I even have one of them on my bench, perhaps you do too. It’s not a problem if all you want is the product, but pushing the limits of open source in this way as an empty marketing ploy is not appropriate. Either something is fully open, or it should not, in my opinion at least, be allowed to describe itself as such. There’s nothing at all wrong with a closed source product, after all.

So. What’s To Be Done?

There’s a key phrase in the CERN OHL that I think is pertinent here; the idea of the “Complete source”. It’s mentioned in clause 1.8 of the text, which goes as follows:

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 licence 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 encapsulates perfectly how the release of all project files should be necessary for a project that wants to be called open-source. It’s important, because open source goes beyond mere ability to copy, and extends into modifying and extending the project. Without those extra files, as with my Tildagon-as-Gerbers example above, this becomes next-to-impossible. Perhaps it’s time as a community to take a slightly harder line with anything less, and instead of welcoming every shiny new toy at face value, probing a little to find out just how deep that open source hardware logo goes.

Otherwise, calling something open source hardware will inevitably lose its meaning. Is this what we want, in exchange for a few flashy commercial projects?

Open source hardware logo on PCB: Altzone, CC BY-SA 3.0.