Fewer Restrictions: Updating LumenPnP Licensing
When I started the LumenPnP project in 2020, I selected a common license that seemed right, and continued with development. I chose GNU GPL v3, and the LumenPnP (along with all associated projects) have been fully licensed with it for their entire existence.
GNU GPLv3 is what’s known as a “viral” license, where (roughly speaking) anything it touches is forced into being fully open source as well. What's more, they're required to license it with the same license. That’s actually quite restrictive!
Our licensing should be based on the reasoning behind why the LumenPnP is open source: because it’s a net benefit to users, builders, and the design. Forcing someone else to open the entirety of their project doesn’t accomplish that goal. If anything, it means folks might be hesitant to use what we’ve built. There’s nothing wrong with keeping your source closed if that’s what you’ve chosen, so we shouldn’t be punishing folks for making that decision.
A way to make Opulo hardware more useful for others is switching to a weakly reciprocal format for licensing, instead of strongly reciprocal one. This ensures that any improvements to our source make their way back to us, but we’re not forcing anyone into adopting our open ethos. The design benefits from being open, and users benefit from being able to use it for what they want to build.
Imagine someone who wants to design, build, and distribute a pipetting machine, and wishes to keep their fancy method of fluid control closed source (or even just licensed differently). Using a GPL-licensed LumenPnP as a base platform for the machine is not an option, as it (arguably) would force them to license their fluid control system under GPL as well. With a weakly reciprocal license, the LumenPnP could be modified to support their pipetting application, their IP can remain licensed how they wish, and the LumenPnP project benefits from any improvements made to the original design source.
Also, GNU GPL v3 is written for software. We've been using it to license hardware, documentation, and everything in between. To help remove ambiguity of how the source can be used, we should be separately licensing each part of our repositories with licenses written specifically for their source type.
After a unanimous vote of repository contributors, we've switched to weakly reciprocal licenses! We're currently in the process of updating Opulo repositories. The licenses we have chosen for this are as follows:
Hardware: CERN-OHL-W
For example, if you release HDL files under CERN-OHL-W and then somebody uses those files in their FPGA, when they distribute the bitstream (either putting it online or shipping a product with it) they do not have to make the rest of the HDL design available under CERN-OHL-W as well. (based on source)
Software: MPL v2.0
The MPL's "file-level" copyleft is designed to encourage contributors to share modifications they make to your code, while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions. (source)
Documentation: CC BY-SA 4.0
This license enables reusers to distribute, remix, adapt, and build upon the material in any medium or format, so long as attribution is given to the creator. The license allows for commercial use. If you remix, adapt, or build upon the material, you must license the modified material under identical terms. (source)
I think this shift allows everyone to use the LumenPnP (and other Opulo source) much more freely, while still ensuring that any improvements make it back to the source. This hardware exists to help people, and that's exactly what this change enables.
A tremendous thank you to everyone that has contributed to any Opulo Open Hardware, and continues to push distributed manufacturing forward.
-Stephen Hawes