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.
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.
Very good article about a little-noticed topic! Even on Hackaday the only article with the tags “OHL” and “open source hardware”.
I’m currently trying to choose a suitable license for my granulate extruder project. I’ve been putting this off for a while and am wavering between the Cern OHL and CC-BY. To the Hackaday readers: which license do you prefer?
Creative Commons is really suited just for documentation/artistic work, so for a hardware project the CERN OHL is a better option. Now, which one of the 3 variants of it is up for you to decide.
Thanks! The permissive version is to me the only one that really makes sense in terms of openness. What I am missing is that the Cern license text is only available in English.
While it is easy to claim ownership of a documentation, its hard to say so for a hardware. Each hardware invention is based on previous work.
Releasing hardware documentation under an open license is to me first of all to prevent someone else claiming a patent on the same thing. Does CC cover that as well as the Cern OHL does?
It’s not that it isn’t noticed, more that people are very used to the brick wall associated with these “open” projects, usually as a pretense for corporate marketing. Many, many execs still see keeping everything proprietary as the best way to ensure profits, even if blocking interoperability on that specific thing has no benefit for them, and investors gobble up marketing that lists a bunch of IP, no matter how useless.
This boils down to an issue that all laws face. You can’t take a bad guy, and give him a set of rules which make him into a good guy. People who want to abuse the system WILL find a way. Laws only “keep honest people honest” and maybe limit the damage caused by bad actors. And that’s assuming the laws are being written by the good guys! Which of course is not always the case.
This isn’t just about “bad guys”, it’s about business culture and ultimately capitalistic pressures for performative growth. And you’re right, you can’t just make a standard, it even laws, to prevent this behavior.
The line between good and bad is fractal, laws are polynomial. It is duty of the religion to turn the bad guys into good guys, and the duty of the law to catch the bad guys far off the line and to preserve the freedom to navigate to the good side of the fractal.
Very nicely put!
This is an absurd tale on laws. The point isn’t to turn “bad guys” into “good guys” (whatever that means). It’s to discourage certain behaviors.
Just because you put “WILL” in super serious all caps, doesn’t make it any more true. People who want to break laws might find a way, but that’s a matter of enforcement.
If a democracy isn’t faithfully expressing the will of the people through laws, that indicates malfunction of democracy, not a flaw in the concept of laws.
Absolutism serves the community not at all.
Sounds like something a Sith would say.
Unfortunately absolutism has become a problem in the open source community. In general there has been a growing intolerance to differing opinions.
See Rust vs C for an example.
You’re talking about essentialism, not absolutism. And it is a major problem that has to be approached with education and patience. A 20-something who likes open source and wants a career in foo widgets on average has zero understanding of licensing, copyright law, any other laws, management, and likely teamwork without a clear chain of command.
It takes almost nothing for a bad actor to (even unknowingly) highjack naive ideas to ultimately recreate the worst forms of tribalism and classism while trying (possibly, assuming good faith here, and I am well aware some don’t deserve it) to level the playing field.
We have orgs like the EFF for legal things, but people who do this quickly single them out for not agreeing with their bad practices. We need OSSW/HW ethics orgs to provide the other half of that, good management, how to actually do transparency, etc.
No; I said what I meant.
I agree we have to call an apple an apple. If there are no source files then it’s not open source.
It’s important to mention that we have a clear definition of Open Source Hardware in several languages, with detailed doc and resources, all supported by an active and serious association.
The definition:
https://www.oshwa.org/definition/
Note the point 1 regarding the source files we must provide, it’s very clear to me:
There’s a decent discussion happening about exactly this in the GOSH forums right now https://forum.openhardware.science/t/veganism-as-a-way-to-appreciate-open-source-definitions/6689/7?u=hikinghack
Interesting to note Julian Stirling’s definitions about how truly open source hardware should be made with open source tools:
“[quote=”julianstirling, post:7, topic:6689”]
My two cents is that doing open source hardware properly is hard. To me, in an ideal world you should:
Have all your original design files openly available
Use an open source license that allows reuse, modification, sale, etc
Do the design in open source software
Have complete assembly instructions
Have complete usage instructions
Do the design work and project management openly so others can understand the design process and contribute
Many other things that don’t immediately spring to mind but I’ll be annoyed I didn’t say as soon as I post this
[/quote]
Well, yeah. Gerber’s aren’t source. They’re object code or intermediate representation.
At least gerber files can be reverse engineered fairly easily. Pre-compiled firmware binaries without source code are more annoying to deal with.
Does releasing schematic and board layout as Altium files count as Open? How about Eagle files now that Autodesk has turned that into a proprietary/creepy software-as-subscription thing? Are application-specific design files required at all, or is a PNG of a properly annotated, hand-drawn schematic acceptable?
How about a BOM without vendor part numbers? If I buy mechanicals from 4UConnector (5k to 20k minimum order quantities and up to 12 weeks lead time), am I obliged to spec a drop-in equivalent you can get in small quantities at Digikey?
Process knowledge can be critical but isn’t universally transferrable: WS2812s are easy to overheat and sensitive to moisture — popped lenses are especially common. If you send design files for a 10×10 array to an assembly house you might see a 10% to 20% failure rate (per component, not per board). Whose responsibility is it to dial in your process?
Where do you draw the line between a 74LVC245, an ATmega328P, an expensive Molex connector, an Ethernet jack made by a vendor who only schedules production in blocks of 5000, and a custom LCD from a manufacturer who requires 3-year contracts?
Hardware is notoriously hard, straight replication isn’t trivial, and redefining a process introduces all sorts of complications. If I make boards 100 at a time using $75k of equipment and custom fixtures, to what degree am I obliged to develop a DIY friendly process for single boards?
To what degree is it acceptable to say, “if you don’t want to duplicate my process, you’ll need to do the work of modifying it to your preferences”?
The FOSS community understands that code written in C for DOS3.1 won’t run if you feed it to a MicroPython interpreter running on an RP2040. They don’t consider that the fault of the person who wrote the C code, or question whether that code can truly be called Open.
Very good points. It’s funny how perspectives are different when you are thinking about the opposite end of the spectrum- closed source.
Many times in my career, I’ve pondered about the value of the IP that I, or the companies that I’ve worked for, owned…
on one hand there have been relatively minor details (design details, process details, etc) that would be super valuable to competition if they wanted to reproduce our product. Ie, something I wanted to protect…
Other times, I’ve had a stack of relatively unorganized designs and build definition, that combined with some tribal knowledge, refined processes, and skilled labor, turn into some impressive end products/device… for these large pieces of IP, I feel that if someone got their hands on it, my opinion would be “good luck”.
To summarize, I think it’s interesting that when you are trying to be closed source, you might try to conceal the smallest of details, aka you can’t even look at my notebook… but when consuming open sourced information, people might push to the extremes of openness AND convenience, aka “you better give me design source in a way that would allow me to most conveniently manipulate said designs”
Sorry, this was pretty ramble heavy… I had a long week haha
I may be missing the point here, but supply the source and if people are interested they’ll make the changes and release them.
As to all the “difficulties” you mentioned, you understand them so put it in the Readme so people come prepared. Also thank you for the information. I’m a new (old) open hardware geek and didn’t know about these challenges. I have had to modify a project or two due to a lack of component selection, but nothing as complicated as mentioned.
I think the oshw community is here to learn from each other, even if it’s just something like board layout on a project we’ll never be able to make.
OSHWA is also a good reference for this type of thing https://www.oshwa.org/faq/
Thanks! I don’t understand how the OSHWA certification program isn’t front and center in this conversation. This is the reason the certification exists.
Yeah it’s so annoying when a project that uses a microcontroller only has the hex or bin file available and no source code. If the MCU is no longer available the project becomes a lot harder. Well, technically it’s open hardware and not open firmware.
As for design files like cad or 2D drawings, I can often replicate my own, with some added customisations thrown in the mix. But the more it’s from your range of skills, the harder it gets to reproduce.
in some sense this is just academic, i guess it’s right that the article zeroes in on basically bragging rights.
in my mind it depends a lot on what you’re trying to use it for. if you want to produce a clone to sell, you will want everything, right? like in principle you would like to even see what vendors and providers they are using behind the scenes, because that is a relevant part of the design. if they made a product, surely they had to iterate some based on the specific pcb fabrication house they used and so on, and it’d be nice to just have everything they did 100% down to what negotiations they did to get such a great deal on shipping.
if you want to produce a one-off just to get you jump started on your own derivative work, maybe a conceptual schematic or even just a parts list is really all you want. maybe you wouldn’t be able to use their board layout or box/case design anyways.
personally i’m a lot more likely to simply want to use the product. so i like documentation that is enough to interface with it or debug kernel drivers or so on. schematics showing how the gpios route to the peripherals are really handy. a lot of times, i’m just as happy to have a stable interface to a closed source driver as a real open source stack.
so yeah you guessed it i’m here to say how much i hate raspberry pi. they get all this positive press from being ‘open source’ but they aren’t! the bottom of each of their drivers is a closed source blob that has severe engineering mistakes baked into it, and a markedly unstable interface as they flail about rudderlessly trying to improve on those mistakes. it’s the worst possible world, from my perspective. you can accomplish an awful lot within those limitations but if you want something open source, if you want to get to the bottom of an infelicity or hack in a novel feature, you’re screwed so much worse than any other product i’ve used in years. even the most locked down phone bootloader uses standardized interfaces these days.
You can just to an info dump. Ideally give an apology and don’t strip the history (e.g. stop putting things you are embarrassed about other than code and design quality n your projects in the first place).
Great article Jenny. I’m a big fan of the CERN licenses for OSHW. My real passion is when you see projects that don’t just share the project files, but those files are created and editable in a free and opensource toolchain. Your example of supplying your film cartridge projects files which are created in OpenSCAD is perfect.. someone can get the source and the exact tool the source was created in. Chefs kiss!
It comes down to how strictly you adhere to the word ‘open’. I’ve seen so called open source software projects that only ran on windows, or open source cad files that were for a paid cad package. So either one I can’t use without spending $ or extra time on the closed product needed to use the ‘open’ product.
That bit is interesting. I see the purpose – to prevent a bad actor trying to hide the source in an absurdly obscure proprietary format – but there’s lots of closed source software which is perfectly fine to use and is the standard. E.G. If you want to share design source files, an AI is much more widely used than Inkscape or whatever the OS option is. There’s probably more examples in hardware design.
I can see valid points on both sides. It’s annoying seeing projects that require expensive laser cutting or cnc equipment that I know I don’t have so I cant replicate said project (obviously some simple things can be replicated by hand but I’m talking about projects that take advantage of specific benefits of those tools).
On the other hand, as a maker I’m going to want to use the tools I have and not artificially limit myself just because some stranger online may not have access to them. It’s irritating to see someone complaining about something I put a lot of work into and giving away for free just because I didn’t do it exactly the way they wanted. At the very least though I do provide source files instead of just output/pre-compiled files. My intention is for people to improve on my projects and that’s not practical if I only hand over a black box/blob.
I’m sure there’s a middle ground to consider where you try to use as many free easily available tools as possible and only use paid software and/or uncommon tools where necessary.
This reminds me of my favorite case of open source abuse: Shelter 2.0.
It required something like 52 sheets of plywood and a $50k CNC router.
For something that was supposed to help people in the third world…
Hardware hacking at the verilog level a possibility?
Well-funded government hackers a threat?
Syntax-checking translations into machine code no longer advisable because
nefarious machine code decoding can result in software control to malware?
can these hardware hackers be defeated with dissimilar hardware platforms?
There’s a big struggle (for me) between (wanting to) open sourcing projects, and attempting to make some money with the things you make. I really like to open source the the things I make, but I’m quite sure that within one or two years they start making some money, some chinese will make copies and start selling them for prices it’s not possible to compete with.
Sometimes I think of releasing the full design (source code, KiCad project, mechanical CAD) only to people who bought the product, but that probably won’t help. Then some easterner just buys one item after a few years and then starts mass producing. It would also make you dependent on the fairness of the people who have bought your product.
I prefer full open source, but I think the solution to this is actually very simple. If you open source, you open source everything (code, schematic, CAD…which includes all the project files from say KiCAD, Blender, etc). If you think you want to commercialize some of your project at some point, you release only the schematic, BOM, and binary (you can add the source code if you feel like it, maybe even at a later date…will depend heavily on what kind of product it is). I think that even for a commercial product, it is fair to expect the schematic for repair-ability (commercial products worked like that for decades). I know a lot of people (including this article) wants the PCB sources to make changes. The way I feel about it is: if you don’t have the skill to duplicate the PCB from pictures, or make your own layout, what makes you think you are going to have the skill to modify an existing design? (thinking more along the lines of designs with controlled impedance traces, length-matches bus traces etc) – if your only intent is to freeload, open source is not for you. Of course you can always release the whole lot at a later date if you change your mind (however, many times this becomes difficult as you would not have all the project details fresh in your mind as you package up the lot).
This will make it clear where you stand w.r.t. your intent to commercialize, or if you are donating the whole shebang to society. That allows you to release your project for people to copy for themselves (and still allow you to commercialize one that is slightly better), and if someone else takes the design (without breaking any copyright of course) and makes a better one in some or other way, or package it differently, then I see it as perfectly fair for them to commercialize that effort. Of course if they have only the binary, there would not be any further functional changes that they can make…only the original functionality that you released, but packaged differently.
Trying to make ideas proprietary is what is wrong with our societies (hiding ideas and knowledge slows down our progress and advancement as a society). It is the specific implementation that we should protect…i.e. your version of the idea, which is where all your effort went into. This is at the core of capitalism…”the best one wins”, not “the one with the idea wins”.
Don’t forget it can takes lots of iterations to get it right. With PCBs that can become quite costly. And the time to develop it isnt free too.
I think people should be gratefull with whatever files are shared. After all they get it for free. Im assuming non derived work here. If it is derived you should comply with that license.
I’m evaluating this topic myself right now. I want to open source the product I’m building for individuals to evaluate it for trust (it’s a security related product) and build it themselves from scratch if they don’t trust my manufacturing, but as a company, I have to pay rent and keep the lights on, so don’t want to just enable a low-margin overseas manufacturer to clone it without effort and dump it on Amazon. The problem with the CERN licesnse is that it doesn’t have a “no commercial” clause like the CC license does.
I’ve run into more than a few widgets (I don’t know what else to call something that deliberately blurs the line between a project and a product) where they try pretty hard to make it appear that they’re releasing the complete source but, upon trying to actually build it, there’s some missing piece (e.g. packages or docker images which presumably exist in an internal repo but which do not exist in any public repo I can find, or there’s everything to run buildroot except the BSP which turns out to be something that could legally be distributed but was not included and while the input files needed to generate the BSP are there it turns out that only the premium subscription version of the FPGA vendor’s toolchain will generate the BSP from those inputs, etc…)
I guess I feel like even with the Complete Source there may be intermediate files that ought to be distributed as well (because there are many other things you can modify or extend without needing to regenerate certain intermediate artifacts, and when the tools to generate them cost thousands of dollars a year it’s sort of obnoxious to omit them). It sounds like this situation is covered in spirit (but maybe not by the letter) in the clause about exporting into a format which open source tools can work with.
It’s not always easy to tell whether any given instance of an omission of this sort is the product of forgetfulness, ignorance, or a cynical ploy to dress a product up as an open source project without actually enabling others to extend it. sigh
To reproduce a circuit, it’s useful to know which components are used. More interesting to me are the design choices made. I’d love to see more design documents and test results for open source projects. For example, it’s not too uncommon to test a dozen components before settling on a specific component. This information is valuable as everyone who wants to use similar components can learn from it.
I started to add all the issues and fixes in Github for others to be able to see the reasons for our choices. (View closed issues here: https://github.com/Smoothieware/Smoothieboard2/issues )
Typically, I try to also add the process of testing and revision as well.
This is IMHO more valuable to the public than just simply being able to “clone” the work (which they are also freely able to do).
It’s like comments in the code, when they’re at their best.
I would hate to think of criticizing someone who shares a design but doesn’t provide the files you might like. For a hardware software device, a dimensioned drawing, a schematic with component values and source code provides a complete solution to create the device. If you have to layout the PCB, thats on the builder. If they give it to you great, if not dont look a gift horse in the mouth.
I like the Mike Stone’s comment, and the thread on ‘absolutism’ is worth a re-read.
As someone with engineering tools at my fingertips, if I have the schematic, whether it be in png or pdf or whatever, that is well annotated, then I do not need anything else. So, at least to my evil little engineering mind, it is ‘open source’. If the schematic has only reference designators, then a BoM is, obviously, required for the documentation to be considered ‘open’.
A word about the projects I have seen that would meet the ‘absolutist’ definition of OSH. They suck. I’ve yet to see one that made it past more than 50% of my DRC script. Thus, I can only advise to take the schematic, in whatever form, and build the PCB and other physical interfaces to your spec. Ignore all of their other debris that allows the creator to declare an absolutist OSH.
An open source hardware project does not need to be good, cheap, use tools you have, use the coding language you like, or anything else. In order to be open source it just needs to have enough info for you to build one yourself (even if it is not “easy” for you. Most times it is more like “ I built this thing for myself and if you want one, here is how I did it”. Who are we to impose rules on people giving you something for nothing? I hate these “rules”, just be glad someone is sharing their work with you.