Open source hardware and the licenses

Usama Abid

For most of us who love developing products and sharing them with the world, the idea of having to license them is usually a distant thought. Often times, we slap a commonly used open source software license on our hardware projects and move on. Sometimes, we add a disclaimer with the creator’s credentials and distribute it. And other times, we don’t even bother and simply put out the results of our hard work somewhere on the internet for the world to discover.

So, why bother with a license at all?  Well, an open source project with no license attached — no matter how remarkable it is — is avoided for use by everyone. For others to use, distribute, and build upon projects the creator must have first given their express permission outlining use of their designs, constituting it as open source. Designs that are free-to-see aren’t considered open source as you’re not literally and legally allowing anyone else to use those designs.

For example, you might design and perfect the most robust ASICs ever — ones that could enhance the exploration capabilities of the next MARS rover. But without an open source license attached, NASA wouldn’t use it because it would be legally restricting (and therefore risky) for them to use it commercially. No license, in practice, means you are abandoning your hard work in the wild instead of owning it and sharing with others. So, it’s a very common but HUGE mistake to not license your publicly available projects under an open source license.

What can a properly defined open source license do for you?

It can certify and give credibility to the original creator. It determines the legitimacy of your contribution by making sure that you, the original developer, are credited for making it in the first place. By defining your open source project under a proper license, you grant other engineers and innovators:

  1. A liberty by law to benefit from it and innovate upon it without requiring further permissions;
  2. The freedom to do so without worrying about copyright infringements or legal penalties.

Commercial or derivative products can be messy if it is built upon “openly available” technologies that have no proper licenses or certification.

Most commonly used (and community endorsed) licenses

All the preferred open source licenses fall under either of two categories:

  1. Permissive Licenses or Copyright (င)
  2. Viral Licenses or Copyleft (၁)

Permissive licenses are ones that allow hardware designers to release a project in the open source so that anyone can explore, use, modify and distribute it in any way they see fit. These are also known as “copyright licenses”. Often, with these licenses, there’s just one condition imposed upon the usage of projects and that is to credit the original creators of the project every time you use it, or if the modified versions are also released for public use. In any case you modify the original project and keep it to yourself, you are not obliged to abide by anything. But who does that, right? The most commonly used permissive licenses (copyright licenses) are:

The permissive/copyright licenses are the catalyst for businesses and industry giants taking an open-source approach, and as a result, they have contributed greatly to the community. These licenses are simple in nature and only expect attribution of credit, and that too, if required. These licenses have enabled businesses to commercialize products without being obliged to publicly expose their entire tech stack and intellectual property.

Viral licenses are ones that allow anyone to use, explore, distribute or modify the projects, but with one huge difference: Any project covered under a viral license compels anyone who uses and modifies the project to publicly contribute and commit all the modifications that they have made to the original project. This way, the original project is not only kept updated, it has evolved. Viral licenses are also more popularly known as “copyleft licenses”.

The most commonly used Viral Licenses are:

These licenses are known as “viral” because once a project is covered under these licenses and gains some momentum, a person or organization any individual or any organization using or depending upon it is legally bound to share their own modification, help maintain the project, and contribute to the updates, the violations of which can result in termination of usage rights to heavy fine and penalties. Linux has become the obvious example for it as it’s covered under the GPL-2.0 — a Viral Copyleft License. But Linux was just too important to ignore. The use of these licenses has discouraged many from benefiting from smaller projects even once in fear of being bound to keep contributing back to it or being forced to expose their IP in case of organizations.

So, which license is the best for your hardware project?

As most of the licenses have been defined with software in mind, taking just one open source license and slapping it onto a hardware project — which is multifaceted and complex — can do more damage. Software licenses have loopholes which make them unable to cover aspects of intellectual property that are specific to hardware. By the definition, any project is only truly open source if every single aspect is publicly available and doesn’t restrict anyone with less access. In this way, software is easy to license because of its text based nature and it is confined to just one medium, i.e. digital files. Software is not physical or tangible, and is only one-dimensional. Most of the libraries, frameworks, or compilers that it can depend on to be Open Source, are also freely available in that domain.

Hardware is difficult to cover under one license because of all the different elements involved: from the schematics and layouts design in any ECAD to the Bill of Materials (BoM), all of which must be in open source. Let’s not forget that open source must also apply to the mechanical structure of the design to the firmware written in any programming language. To cover all of these different mediums under copyright protection, it is best practice to include multiple licenses in your project repository. As CERN Open Hardware LicenseTAPR Open Hardware License or the Open Source Hardware Certification (OSHW) are very good at covering all the electrical and mechanical aspects of hardware, including the ECAD designs and BoM. However, they don’t cover the soft aspects, like firmware, which can be covered fully by other licenses e.g. MIT, GNU etc.

Sparkfun Electronics is the perfect example!

This organization develops open source hardware commercially , and regularly releases their projects under a combination of licenses. Find any Sparkfun project and you’ll see a LICENSE file containing different licenses mentioned distinctively for each category. They often use the OSHW certification for the physical hardware itself as the OSHW logo is printed on the silk screens along with attributions. The ECAD designs along with libraries and footprints are released under the Creative Commons Share-alike 4.0 International while the firmware is covered under the MIT Open-Source License.

Related Posts