Skip to content

Latest commit

 

History

History
138 lines (119 loc) · 7.5 KB

licensing.md

File metadata and controls

138 lines (119 loc) · 7.5 KB
layout title
page
Free and Open Source Silicon Licensing

This text briefly introduces the reader to open source licensing, attempt to explain the FOSSi licensing situation at present, and suggest some further reading. It is far from comprehensive and focuses specifically on licensing FOSSi designs but does its best to capture the current state of play. FOSSi and Hardware Description Languages (HDL) are used interchangeably in this article.

Open source licences are used to enable developers to release their work for use by others under certain terms and conditions. Those terms and conditions vary greatly between the various licences that are available, ranging from licences which permit others to use the work almost as they wish (permissive), to those that put strict requirements on the re-use of the work and ensure that derivative works remain open and free.

Selecting a licence for open source works can be difficult when faced with vast array of those available. Making it particularly tricky is that there are few licences which have been written specifically to address the unique case of FOSSi source code, where designs are synthesised and used in programmable hardware such as FPGAs, or used to create semiconductor mask sets for the manufacture of silicon chips. The overwhelming majority of available licences were written to apply to software and contain concepts and wording which aren’t applicable to HDL designs. That said, the more permissive the licence the fewer technology-specific terms required, making them more suitable for use with HDL source code.

The permissiveness of the licence is a matter for the licensor (the author, copyright owner) and often depends on their position regarding reuse of the design. The more permissive the licence, the less requirements on future users and developers of the IP. Less permissive licences have more restrictions, which generally ensure the derivative works remain as free and open as the original work. These less permissive licences, also known as copyleft licences for how they enforce the work’s openness, vary greatly from weak to strong copyleft and primarily indicate how a derivative work may be licensed - whether it must be entirely released under an equivalently open licence (strong copyleft, reciprocal licences) or not.

As already mentioned, almost all strong copyleft licences have been written to apply to software, and the mechanisms they specify (binary linking, for example) that qualify a derivative work to be released under the same terms and conditions - guaranteeing the IP remain open and free to be reused - are problematic attempting to apply them a HDL design. This article for the Harvard Journal of Law by Eli Greenbaum gives an overview of the problem (summary and comment). In short, in the case of linking, for example, a HDL design compiled for manufacture typically isn’t considered binary object code, and when one HDL design is instantiated in another, it isn’t exactly the same as linking in the software context. There are many other problematic technical issues which emerge. What to do about this is an active area of research and discussion by the interested parties.

One approach put forward by Javier Serrano of CERN goes that in order to leverage the existing pool of mature and tested software licences then some sort of consensus should be reached regarding the translation of software concepts to the hardware context. Ideally, it would be through something released by the stewards of the existing licences dealing the applicability of their existing software licences to HDL designs. It has been commonplace in the past decade to license HDL code under licences such as the GNU GPL and LGPL licences which are copyleft, and the permissive BSD and MIT software licences, with the idea being that the general intention of the licence is invoked. Given the large number of HDL works having adopted a software licence, providing firmer legal ground for them via some translation of the technical concepts used in software licences like the GNU GPL would be beneficial.

Another approach is to adapt existing software licences and replace incompatible software concepts with those applicable to use in semiconductors and reprogrammable logic chips (FPGAs). Licences such as this are the Solderpad licence based on the Apache software license, and the OHDL which is based on the Mozilla public licence. The CERN OHL aims to be the GNU GPL licence for hardware, however its applicability to HDL designs has been raised.

One consideration in this discussion is that copyright applies to the source code files, but not the manufactured hardware such as a silicon die, for example. See "Licensing your Designs" in this OSHWA article. Do the conditions in the licence that are triggered when a derivative work is distributed (what constitutes distribution in this case is also a good question) apply when something is manufactured? Then consider an FPGA containing a bitstream, which could be construed to be more like a software binary.

The case for why copyleft licences for hardware may be hard or impossible to enforce is made by Andrew Katz in this article. He proposes the Solderpad licence to mitigate these issues, and argues that beyond the practical barriers open source hardware impose, wishing to enforce copyleft requirements will eliminate potential collaborators, making an already small ecosystem smaller.

This is an active topic and this article will be updated as it progresses.

Further reading (not all FOSSi/HDL-oriented)

Licences for FOSSi/HDL

Permissive

  • Solderpad - based on the Apache License 2.0, modified to apply to HDL works
  • Modified BSD license - ensures warranty disclaimers are maintained and enables the authors to approve attribution of derived works

Copyleft