Many things have changed in the hardware licensing landscape since we published our guidelines as a set of best practices for how to share hardware designs efficiently. If you visit them today, you will see that we updated the content under the “Licensing your Designs” section. The biggest change is that we are now describing four different licensable elements of open hardware: hardware, design files, documentation, and software. “Design files” as a separate element is a new addition to that list. This short post explains the rationale for the changes.
Why Change?
One key factor is the increasing use of version 2 of the CERN Open Hardware Licence for sharing hardware designs under any of the three usual regimes: permissive, weakly reciprocal or strongly reciprocal. The CERN OHL v2 is the only license approved by the Open Source Initiative which was drafted with the specificities of hardware in mind. It is also the recommended license to host hardware designs on GitHub and other platforms.
Another important development is the exponential growth of open-source gateware (FPGA or ASIC designs using Hardware Description Languages) fueled by the RISC-V revolution. For those preferring a reciprocal sharing regime, there was no adequate license in this realm, and the use of traditional software licenses quickly showed a number of issues. The reciprocal variants of CERN OHL v2 filled that gap.
Modern hardware licenses all include patent license clauses in their text. They provide reassurance to licensees that any patents held by the licensor covering the hardware design are licensed to them alongside the other rights in the design. The new guidelines reflect this important trend.
Finally, there has been a persistent source of confusion since the early days of open-source hardware licensing, namely the difference between licensing the hardware designs and licensing the resulting hardware.
The New Guidance
The new guidelines provide clarity by separating the hardware itself from hardware designs. You can think of this as the difference between a PCB you are holding in your hand and a KiCad file, or a mechanical device and the schematic for that device. This distinction can become especially important in situations where the designs are eligible for copyright protection, but the hardware itself is not.
The new guidelines also provide a set of best practices to be applied for different types of hardware. The resources on licensing in the OSHWA certification site will be updated shortly to remain compatible with the new guidelines and reflect this shift to a four-pronged approach to licensing, covering:
- the hardware itself,
- the hardware design files,
- the documentation around the hardware, including e.g. user manuals and explanatory materials,
- any software related to or running in that hardware.
Please read the new guidelines and let us know in the forums if anything is unclear or if you have any comments, requests, corrections, etc. Happy sharing!