This article is cross-posted from Open Electronics.
It’s always tricky when you create something: a complex project, a commercial product, or just a hack. Then you must decide what license to use to release it to the public.
The discussion regarding licensing open electronics or hardware in general has been going on for years, and many points of view have been shared across the community. Countless e-mail exchanges, forum posts and – more importantly – countless project experiences are available to learn from.
Definitions: Are you sure you want to make Open Hardware?
First thing to do is to understand what you’re talking about. Two incredible resources to understand what open hardware (or, better, open source hardware) really is, you should really give a read to this page (open-source hardware definition and statement principles) containing the Open Source Hardware Definition according to OSHWA. The OSHWA (stands for Open Source Hardware Association) is just one, maybe the most important one, of the global players that are looking into the Open Source Hardware movement with a perspective of standardization, momentum building and association.
OSHWA blog and website also hosts a great wrap up of the history behind the OSHW movement: give it a read to have some real context of what we are talking about and from where this discussion comes from. Thanks Catarina Mota for this amazing wrap up.
Licenses are the means to present your projects
Before thinking about the licenses, it’s even more important for you to understand a couple of specific and important aspects of open source hardware. First of all, the license (or at least, the approach to licensing) that you are going to use is an important mean to tell others – right from the start –what they are able to do with your project, designs and invention. A license tells the other how they could use it both from an amateurial and learning point of view or even for commercial purposes to be embedded and integrated into something more complex.
In general, by applying an open source license to a piece of work you state that you’re open to see this being part of the other’s work and, in some ways, you acknowledged that you borrowed a lot from the open community (as we always do) for inspiration and information.
A complex matter
Licensing is a complex matter, the use of the right license is therefore an important way of stating how others can and should use your work. By explicitly applying an open-source license to your hardware design files and the accompanying pieces of information, you make it clear that others can copy and modify them. When licensing your project, keep in mind that someone who makes a derivative of your hardware will probably also want to build on your software, instructions, and other documentation: therefore you shouldn’t only license just the hardware design files but also these other elements of your project.
Another very important consideration, is eminently resumed in an informative (very useful and must read) page again from the Open Source Hardware Association. This post, in fact, recaps about best practices to use and some other key aspects. OSHWA says:
Note that copyright (on which most licenses are based) doesn’t apply to hardware itself, only to the design files for it – and, then, only to the elements which constitute “original works of authorship” (in U.S. law) and not the underlying functionality or ideas. Therefore, it’s not entirely clear exactly which legal protections are or aren’t afforded by the use of a copyright-based license for hardware design files – but they’re still important as a way of making clear the ways in which you want others to use your designs.
That’s exactly the situation we are in: it’s not entirely clear (at least in US-legal framework, that is usually the most important framework when dealing with copyright law and, in 99% of the cases, a key market segment for your products) what you can actually copyright when you talk about hardware. Where’s the limit between an “original works of authorship” and an “underlying functionality” or “idea”? In fact, in a rather general and quite frequent misinterpretation of licenses, people think that using open licensing is actually contrarian to advocating author rights (copyright) on pieces of work: that’s not really the case. In fact when you apply a license on something, you be aware that you can do that as you’re the creator and, therefore, owner of the so called “copy rights” on that piece of authorship. In few words: it’s likely not possible to copyright a wrench since the underlying principle about how the wrench works is considered public domain as a common physical principle.
Despite you’re not going to be able to answer some specific questions about this aspect if not in a legal court, it might be useful to stress out that this problem may mostly worry the ones that are looking for closed source hardware. In fact, while you choose to use an open license on a piece of hardware, designs and work, you’re supposed to be less worried if some parts of your work are not actually “copyrightable” (and therefore they end up being simply of public domain).
Something interesting to add at this point is that in open source software (a realm that is almost ten years more mature than open source hardware) a relevant tendency has appeared lately: people often simply don’t apply any specific license to their works just because they don’t think about licensing as interesting or important, they just release their works in the public domain (implicitly or not). In February this year a scientific paper by Clark Asay, Assistant Professor at Penn State University Dickinson School of Law (and brother of the Open Source influencer Matt Asay), suggested that software should be released into the public domain to solve most of the conflicting license issues that sometimes prevent the use of Free and Open Source Software in commercial projects.
An outstanding problem here, is that even releasing a project under public domain is clumsy and complex from a legal perspective and a proper license for this may not be 100% available. In February, commenting Asay’s proposition, Glyn Moody (a true reference in open source) commented saying:
It is very hard to place works in the public domain — the Creative Commons CC0 is perhaps the most thoroughly worked-out tool for doing so. As Asay notes, we need legislation to formalize and facilitate this move, and to address issues such as liability.
Despite this tendency to public domain is quite interesting from an analyst perspective (in fact that led me to think a lot about the process of componentization and commoditization that software is undergoing these days), underestimating the importance of licensing and leave it unclear it’s rather not to be suggested from the point of view of the developer. It’s way better for you as a developer and owner of the creative rights on your invention, to take a conscious decision based on the right information sources and choose a proper license for your work. Don’t forget that at least, the license you choose, will be the business card of your project, it’s public face and it’s first contact interface.
As per the software world, the most dividing, complex choice in licensing hardware is about choosing a Copyleft license or not. As you might know, the copyleft clause – formidably created once by Richard Stallman, guru and creator of the Free (as in speech) Software movement – has been at the very core of a decade long debate between Free Software advocate and Open Source software thinkers.
The GPL, in fact one of the most used licenses in free software history, actually sports a copyleft clause that basically forces adopter of the piece of work that is GPL licensed, to adopt the same (or a compatible) license themselves in their derivative works. Despite Richard’s will it’s clear in my mind as in that of many others, and despite we could share the principle of creating a virtuous cycle between you and the adopter of your works that will ultimately led to more Free Software (or hardware), this clause has been going through a large spectrum of feelings from the community.
At the end of the day, more permissive licenses such as the Apache Software License or BSDappeared and consolidated. Within time, permissive licensing (that not including copyleft clauses) gained some significant traction and share of minds in the software community.
As said before, lately, seems that most of the licenses adopted by devs are permissive and, in most cases, public domain or not specified, and this should actually make us think about the willingness of people to release completely available projects when their work is based on a significant amount of open materials.
Apart from copyleft, another important permission that you might not give to the adopters of your works, is that of using your licensed work for commercial purposes. The most famous licensing approach that explicitly and easily covers commercial exploitation is the Creative Commons License, that with the well know Non-commercial clause extension in fact prohibits to the adopter to make commercial exploitation of your works.
By the way, after having debated open licenses as an alternative to the closed approach, it’s very important to add some reality in the picture: hardware is very different from software and closing it may be much more difficult. In fact in the software realm, many potential strategies for protecting your code may be applied: the most obvious is distributing executable, with obfuscated code. Clearly enough this is not something you can do with hardware as your hardware projects will always be possibly subject to re-engineering.
That’s why if you make hardware today you should really consider to adopt open licenses and build community oriented and long term business models around your open product (that’s another story that we will soon cover on the blog).
Get inspired by others
A further activity that you could do to choose a proper license as your way to consciously share with the community is seeing what other projects (that are part of this community) are doing.
Projects that inspire you (or even inspired you to start your project), great product or companies may serve as an interesting starting point. Especially, projects that share a similar value proposition, business model and market or mission could be extremely useful to understand the implications of a license.
In fact, as you know licensing a product, may imply several consequences especially regarding the actual use that people will make of your inventions and the derivative works that are created: license shapes the community in some ways.
For example, if you are addressing the makers movement, a good choice could be to adopt CC-BY-SA, as Arduino does with its hardware designs implying that all the Arduino ecosystem will stay Free and Open.
On the other hand, the openPicus team – targeting a slightly different customer segment – mostly made of OEMs, System Integrators and companies that look for enabling intelligent connected functionalities to their products – allows for the technology to be embedded in final, boxed,commercial and event certified products with more ease, by adopting a CC-BY (no copyleft clause) license.
If your mission is to change the world, instead, you could opt for the relevant and conscious choice of GPL licensing as Open Source Ecology did. In a passage of OSE wiki, there’s a relevant explanation that I think everyone should read to really understand what the role of licensing is after all, in open source hardware and what limits are implicit in using community developed licenses in a very complex legal framework.
Most machines and processes are protected by patent, not licensing, laws. The designs of hardware are protected under copyright, and are therefore protected under copyleft, but the actual hardware is not. A corporation can copy the hardware and commercialize it without OSE attribution or continuation of the right to copy the hardware and we have no legal recourse. In fact, at that point, in countries with a first-to-file and not a first-to-invent patenting regime they could even patent our work and prevent us from doing any further work on the project.
GPL and copyleft licensing doesn’t function operationally for hardware, but its better than nothing or an overly-expensive patent. A corporation can simply sell a piece of OSE hardware without attribution or open documentation because GPL only protects the publishing and copying of DESIGNS. However, a GNU public license can ensure that people are:
free to use the designs for any purpose (including commercial),
free to change the designs to suit your needs,
free to share the designs with your friends and neighbors, and
free to share the changes you make.
Because the GPL is infectious (or viral, the license continues down any modifications or forks) these protections last for the entire life of the core design!
Another interesting case is that of CERN and it’s definitely something you should look into, if you’re doing open hardware as part of research programs or in the academia in general. It’s good to know that the CERN has, within time, developed its own open source hardware license, the famous CERN Open Hardware Licence. CERN OHL was developed to be used on the Open Hardware Repository, a huge open hardware repo used within the CERN to develop open hardware products and encourage reuse and external contributions. Go here for more detail.
It’s about being conscious of the philosophy and mission
When thinking about licensing, you should therefore approach the topic as a key moment for you to understand the ecosystem you’re entering when you do open source hardware and open source design.
It’s a moment for you to grow as a creative creator, as a design professional or as a hacker: Know the story of this movement and consciously choose a licensing approach that is in line with your philosophy, mission, and with the plans you’ve for your inventions and products.
In the end, refer to your inspirers and gurus and don’t mind to drop an email if needed, people doing open source has often open minds and hearts and will surely be enthusiast to give you a hand in the most important choice in the life of your project.
Author Simone Cicero is a blogger at meedabyte.com, strategist, and speaker. Simone is also a long-time Open Source advocate and Open Source Electronics editor. Follow him on twitter at @meedabyte.