Skip to main content

Open Source Initiative and Open Source Hardware Logo

Last updated: 1st September 2021.

An introduction to open source licensing for hardware and software projects.

In this article we take a look at open source licensing basics, different types of project materials, licence compliance and best practice. The aim being to summarise the key points that should be considered, rather than providing any sort of detailed exploration — nor indeed to recommend any particular licences and instead aiming to better equip the reader to make their own decisions.

Note that intellectual property (IP) is used as shorthand for source code and hardware designs.

Basics

Before selecting a licence to use with a project, it is important to consider a few key factors which may affect that choice.

Your rights

If you’re working on a company project you should probably get sign-off from your line manager or if you have one, the Open Source Program Office (OSPO), before publishing company IP under an open source licence. Even if you’re working on something in your spare time this may also be covered by company policy and it’s worth checking your employment contract. Where sign-off is required for spare time projects this will often be provided, with checks just to ensure that staff don’t work on things which might directly compete with company products or infringe upon IP.

Whether developing something as an individual or on behalf of an employer, if this based on or otherwise builds upon third party IP — for example, other open source code — there may be additional considerations and it is likely that there will be some obligations, such as a requirement to attribute the author(s). More on this later.

Your intent

You may be happy for others to do as they please with your work and require no more than attribution — to be credited. On the other hand you may wish that anything which is derived from your project also be published under the same terms. In the case of the former, “permissive” type licensing would be most appropriate, whereas in the latter, “reciprocal” would be more effective.

Companies will have clear objectives and a rationale for open sourcing their IP. For example, with a device SDK the goal is likely to get as many engineers as possible integrating this into products, hence removing potential barriers to adoption will be important. Whereas with a product that is open source, it may be desirable to ensure that a better funded competitor doesn’t simply clone this and execute faster, without sharing their improvements. This is something of a generalisation, but here permissive and reciprocal licensing respectively would seem like the best fit.

This is not to say that those who develop open source products — as opposed to components and SDKs etc. — always choose reciprocal licensing; permissive licensing is equally popular with many different types of projects and a chosen philosophy can play a big part here.

If you would like to preclude third parties from using a project for financial gain or prevent them from publishing modified versions, open source is not appropriate; you cannot have an open source project which disallows commercial use or modifications. There are licences with these clauses, e.g. Creative Commons NonCommercial (NC) and No Derivatives (ND) variants, but these fail the Open Source Definition and projects which employ such licences cannot be called open source.

Software

Open Source Initiative Logo

Here we’ll use software to mean firmware also, since from a creative works perspective and how this is compiled or assembled, it is much the same. Of course, a firmware package can sometimes include an FPGA bitstream, but “gateware” is something that we’ll cover separately.

There are many different licences available for use with open source software and in the main these differ in terms of whether they:

  • Are permissive or reciprocal (latter a.k.a. “copyleft”)
  • Include patent provisions
  • Have been approved by the Open Source Initiative (OSI)
  • Are aligned with a particular project or foundation

Permissive vs. reciprocal was covered briefly earlier and it should be noted that this is a spectrum where there are both weak and strong reciprocal licences. Popular permissive software licences include BSD and MIT, while popular reciprocal licences include GPL and LPGL.

Particular attention to detail must be paid when using reciprocal licences, since for example if you were to link third party GPL code with your own, the latter would be regarded as being derivative. However, if the third party code used the LGPL (Lesser GPL), it may not and could be that you can use any licence, instead of having to publish your code under the same reciprocal licence. This is somewhat simplified and there is more to consider, e.g. whether using dynamic or static linking.

Open source licences are primarily concerned with granting copyright, but some may also include a patent license grant, which will provide additional peace of mind, in giving assurance that the author(s) will not pursue patent licensing dues as a result of use. The Apache License is a popular example that includes such patent provisions.

Not all valid open source licences have gone through the OSI approval process, but inclusion in the Open Source Initiative list can be seen as a mark of quality. That said, the list is fairly large, licence proliferation isn’t helpful and it’s questionable whether some of these licences needed to be created in the first place. As a general rule it’s best to use a more mainstream licence wherever possible.

Many licenses are associated with a particular open source project or foundation. For example, the BSD family of permissive licences were originally used with the BSD version of Unix. Similarly the reciprocal GPL was originally used with programs released as part of the GNU Project. These, along with notably Apache and MIT, have gone on to be used by a great many other projects, while some have seen little use outside of the project which they were originally drafted for.

When contributing to an existing open source project you generally have to make contributions under the same licence. Where a project is hosted by an open source foundation, there may be a policy which states that a particular licence must be used with all new projects. Equally, companies may have their own policy for original work which is to be published under an open source licence.

Hardware

OSHW Logo

Here we’ll use hardware to mean PCB and mechanical designs, which are somewhat different to software in that such designs may be cloned without the act of copying files; for example, a circuit design could be studied and re-entered into a PCB tool, without having access to the original files. Hence reciprocal licensing is trickier with hardware, since licences such as the GPL and AGPL are copyright licences — and if files haven’t been copied, copyright doesn’t come into the equation.

Furthermore, with software we have source code, whereas the design artefacts associated with PCB and mechanical designs will include the original design tool files, plus things such as Gerber and DXF etc. file exports. Hence the language used by open source software licences, which talk about source code, object files and linking, isn’t a great fit for hardware.

In the early days of open source hardware it was typical to use a Creative Commons licence with designs, such as CC BY or CC BY-SA, with just attribution required or with the addition of “SA”, the licensee to share alike. Hence permissive and reciprocal respectively. That is, reciprocal with the aforementioned caveats (works as long as your original files are used). However, this family of licences were originally created for use with works such as articles and photography, whereas there are now licences which have been drafted specifically for use with open source hardware.

CERN Logo

The CERN Open Hardware Licence (OHL) as of v2 is available in three variants: strongly-reciprocal, weakly-reciprocal and permissive. As such this caters for most requirements, has been drafted by a team of open source legal experts and subject to thorough review.

Another licence worthy of note is the Solderpad Hardware License, which is provided as a “wraparound” which extends the Apache 2.0 License in order to explicitly cover various forms of hardware IP. This might be an attractive option where a project has hardware and software/firmware parts, with the Apache 2.0 License being selected for the latter.

Other licences include those such as the TAPR Open Hardware License, which was originally drafted by TAPR for use with their own projects, but is available for use by anyone.

Gateware

Gateware - FPGA designs sit somewhere between software and hardware

Wikimedia Commons, CC BY 3.0.

FPGA designs sit somewhere between software and hardware, in that they start out like software and are developed using a text-based language such as Verilog or VHDL, but are synthesized and then instantiated in hardware. So which type to use? An open source software licence could be used with FPGA projects, but an open source hardware licence may be a better fit.

Another consideration with open source FPGA projects is that they can have to use proprietary IP blocks which were provided with vendor tools, perhaps also with files generated by a wizard or similar and where the vendor claims copyright. In such cases additional care must be taken.

Finally, designs that are to be implemented in ASIC could further complicate matters, as this will involve additional layers of intellectual property, e.g. a Process Design Kit (PDK) supplied by the fab, which may have very restrictive terms. Further to which, licence interaction and compatibility in such scenarios, notably where reciprocal licensed IP is involved, is less well understood. That said, those designing ASICs with open source IP cores will likely have OSPO/legal counsel support.

Compatibility

Licence compatibility is something which must be considered when combining works, e.g. original code with one or more third party open source or proprietary codebases. This is not something we will cover here in detail, but suffice to say that it should be possible to work out what is and what is not permitted, together with any resulting obligations, by studying the respective licences. While paying particular attention to what a licence regards as a derivative work and the implications.

Within companies the OSPO and/or legal counsel can also assist, which may be necessary in more complex or nuanced cases, where what is permitted and when certain obligations are triggered, may be more difficult to ascertain.

Best practice

There are various best practices which can be incorporated into development cycles, which will make it easier for engineering teams and those downstream to manage IP rights and obligations, and compliance activities. These range from simply using standard licence identifiers in file headers, to implementing compliance standards and setting up an Open Source Program Office.

SPDX

SPDX Logo

The Software Package Data Exchange (SPDX) is “an open standard for communicating software bill of material information, including components, licenses, copyrights, and security references. SPDX reduces redundant work by providing a common format for companies and communities to share important data, thereby streamlining and improving compliance.”

SPDX operates as a Linux Foundation project and maintains specifications for the standard, together with a licence list that includes short identifiers which may be used in file headers. These may then be used by not only other engineers, but parsed by tooling which automates the task of producing a software bill of materials as an aid to compliance efforts.

For example, asserting that a file is provided under the MIT License, is as simple as including:

SPDX-License-Identifier: MIT

This would be placed alongside the copyright statement in the header. See the website for further details, e.g. using more than one licence, and indicating that specific or later versions may be used.

Compliance

OpenChain Logo

Governance within anything but small organisations will typically require a more holistic approach, with well thought out policy and process put in place to support the use of, and contributing to, open source. Thankfully, there are initiatives to support such wider governance and compliance efforts, such as OpenChain, which is also hosted as a Linux Foundation project and has been ratified as International Standard, ISO 5230. Along with numerous other resources also, such as the Creating an Open Source Program Office guide, and even events that are dedicated to the topic.

Certification

Open Source Hardware Association (OSHW) Logo

The Open Source Hardware Association (OSHWA) operate a certification programme which “provides an easy and straightforward way for producers to indicate that their products meet a uniform and well-defined standard for open-source compliance.” Details of the certification process, together with a register of certified projects, can be found on their website.

Final remarks

If you’re new to open source or perhaps haven’t previously had much involvement with the licensing side of things, this may at first seem a little daunting, but it needn’t be. With existing open source projects — and proprietary for that matter — it comes down to what rights the licence has conferred upon you, together with any obligations. Similarly, when publishing under an open source licence, it is a question of your or your employer’s intent, and what rights and obligations you or they wish to confer upon licensees.

Andrew Back

Disclaimer: nothing in this article constitutes legal advice.

Open source (hardware and software!) advocate, Treasurer and Director of the Free and Open Source Silicon Foundation, organiser of Wuthering Bytes technology festival and founder of the Open Source Hardware User Group.
DesignSpark Electrical Logolinkedin