A Survey of Open Processor Core Licensing

Andrew Katz,a

(a) Partner, Moorcrofts LLP

DOI: 10.5033/ifosslr.v10i1.130

Abstract

In the Spring of 2018, Western Digital Corporation commissioned Andrew Katz of Moorcrofts LLP to prepare a survey of open processor core licensing.  This is an edited version of that report.

Keywords

Law; information technology; Free and Open Source Software; open hardware licensing; processor cores

Foreword by Alan Tse, Western Digital Corporation:

Western Digital’s relationship with open source has evolved significantly over the last decade. When I first joined Western Digital, our main focus was on open source compliance. That is because in 2009 we were one of the first major companies sued for our open source use. As a result, the main goal for the next few years was to prevent any litigation happening again and we viewed open source with some trepidation. Over time our view shifted as we had to learn about the importance of the open source community and how to be a good participant in that community. And over the years, we have increased our participation – not to avoid litigation, but because our own business interests have started to align. Over the years we have made multiple contributions to the Linux kernel and other open source projects and we have released internal tools that we thought others could use. Now that it has been almost a decade since that first lawsuit, we would like to think that we have learnt a bit more about the open source community and we are proud to say we are a part of that community.

In deciding our licensing strategy for our core release, we engaged Andrew Katz to help us understand the community norms for open source hardware. Owing to his involvement in the drafting of two open source hardware licences, we believed he was at the forefront of Legal scholarship on this issue. His report that follows was instrumental as we balanced our goals of community growth and protection in a space with unique constraints. It’s unique because open source hardware is a capital-intensive field quite different from software and the fact that the established open source licences were written without open source hardware in mind.  We are happy to release this research to the community and hope this research and our journey serves as a beacon to our peers to join use in the open source hardware community.

Introduction

1. 1.To identify major open hardware communities using a combination of research and pre-existing knowledge of various open hardware activities that Andrew Katz has been involved in including both specific projects and umbrella organisations. 

2. 2.To undertake research of those organisations and schedule and carry out a range of telephone interviews with identified leading individuals in the field. Given the relatively short time available to undertake the research, a total of eight individuals were identified, of whom six were able to agree to an interview within the time available for the first version of this report. A further two individuals arranged to be interviewed on a date after the original date of submission of the report to Western Digital, and their responses have been taken in to account in the updated version. No one who was approached declined to take part in the research, and all were very open and candid. We are grateful for their time and interest in the project. We also requested further input from the interviewees about community development and involvement, based on the answers to the first round of questions, and two individuals responded comprehensively by email. Their responses were taken into account in the report. 

3. 3.To review the projects listed on LibreCores and OpenCores.org, and the list researched by Mohammad Shahrad4 and updated as a result of further desktop research and responses from interviewees. 

4. 4.The results of the research were compiled into this report. 

5. 5.In order to facilitate candour on the part of the interviewees, the interviewees were told that their names would not be linked to specific comments they made in a manner similar to the Chatham House Rule. Subsequently, the individuals kindly consented to their names being released. 

6. 6.To avoid bias in answers provided, the interviewees were told the research was being undertaken on behalf of a major US digital hardware manufacturer, but no further information was provided about the research sponsor.  The identity of the sponsor was released to the interviewees some months later when they were asked if they were prepared to waive anonymity. 

Open Source Hardware and Licensing

Summary

Copyleft (reciprocal) licences:

• •Creative Commons Attribution, Share-Alike (CC-BY-SA) 

• •GNU General Public License (GPL) 

• •Hardware-Specific Licenses: TAPR OHL, CERN OHL8 

Permissive Licences

• •Free BSD license (BSD-2-Clause)9 

• •MIT license (MIT) 

• •Creative Commons Attribution (CC-BY-3.0)10 
• •Hardware-Specific License: Solderpad Hardware Licence11 

Given that the above licences are specifically referenced by OSHWA we can make the reasonable assumption that they meet the OSHWA definition. OSHWA does not (at the time of writing) have a process for approving licences. It can be assumed that licences (such as Apache) which are approved by the OSI would also meet the OSHWA criteria.

Licences that were identified during the course of this survey as applying to various open source hardware projects are:

Table 1: Open Source Software Licences

Table 2: Open Content Licences

Table 3: Hardware Specific Licences

Table 4: Licences which are not compliant with OSHWA/ODI criteria

Note that both the Solderpad licence and the CERN OHL are in the process of revision. Version 2 of the Solderpad licence remains very similar to the Apache licence it is based on, but has been amended so that is now expressed to be a ‘wraparound’ of the Apache licence, rather than expressed as a different license. The advantages are that it is much easier for a practitioner familiar with Apache 2.0 to immediately see what the differences are between Solderpad and Apache 2.0.

As of January 2019, the CERN OHL is in the process of being modified significantly to produce version 2. Under current proposals this will be published in three variants: a permissive version which has an Apache-like effect, and two reciprocal versions – lesser and strong (strong reciprocal being the default for those who have already published hardware designs under current versions of the CERN-OHL with the ability to select a later version).  Care has been taken to consult with developers of FPGAs and ASICs to try to meet their concerns, particularly around the use of proprietary tools and libraries that are all but unavoidable in practice, while retaining the copyleft nature of the reciprocal versions of the licence.

Desktop Analysis of Licence Adoption

The OSHWA Surveys

GitHub Search

The OpenPiton Survey19

Of particular interest is that, when the projects are listed in order of the date of last active contribution, it is clear that the more recent projects are more heavily weighted towards permissive, rather than copyleft licensing. There is a total of 28 processor core products listed. There is a gap between October 2015 and February 2017, and if we take the projects that have been active since February 2017 (of which there are 15), 5 of them are copyleft. For projects prior to this date (of which there are 13), 12 are copyleft.

To summarise: recently active projects are split 33% copyleft, 67% permissive, as against the non-active projects, which are 92% copyleft, 8% permissive. This indicates a clear shift to permissive licensing for currently active projects.

 

Fig. 1: Summary of licences chosen for recently active projects, data from the OpenPiton Survey

 

Fig. 2: Summary of licences chosen for non-active projects, data from the OpenPiton Survey

OpenCores and LibreCores

Two websites, opencores.org and librecores.org, host core designs and related materials such as tools and interfaces (‘interfaces’ are materials for other components which would typically appear on silicon alongside a core, such as UARTs and memory controllers).  Opencores is run by a commercial entity, a situation which led to dissatisfaction from members of the FOSSi foundation regarding how Opencores operated, and their subsequent creation of Librecores as an alternative. Librecores has fewer projects, but they tend to be more active than Opencores (possibly because they have had less time to become obsolete).

There is a total of 1190 entries on the Opencores website, including software, toolchains, utilities and interfaces, as well as cores, of which 30 are marked verified. The Librecores site contains 90 entries but does not have any form of verification mechanism. We examined 24 entries in the Opencores website which are marked as ‘verified’ and 40 entries on Librecores. We selected entries which most clearly relate directly to cores and interfaces, details of which are contained in appendices 3 and 4. There is also a thriving ecosystem of associated software tools, test suites and build and utility scripts, analysis of which is outside the scope of this report. Whilst we have undertaken a statistical analysis of this data, it is important to note that should be interpreted in the light of the following constraints:

(1) there is no easy way to weight each entry in terms of how pervasive and active the project is, so a barely-functional and rarely-adopted project would rank the same as a more mature and active one;

(2) there are significant projects which are not represented on either database;

(3) the selection of entries is largely subjective, and whilst the intention is to select projects which instantiate hardware (as opposed to toolchain or utility components), the selection was undertaken by a lawyer and not a microelectronics engineer, so mistakes are inevitable.

Various analyses of the licensing in both Opencores and Librecores for various categories of project are set out on Appendices 3 and 4.

Outcomes of the telephone interviews

Licensing – copyleft vs. permissive

All but one interviewee noted that a permissive model was the most likely to succeed from a commercial perspective. All acknowledged that a particular issue with copyleft licensing was that existing licences, including GPL and LGPL, and even CERN OHL did not provide sufficient certainty as regards boundaries delineating where the copyleft effect occurs. For example, if a component whose design is released under LGPL is combined with another component on the same silicon, does that mean that both components then have to be released under the LGPL? How about if the components are on separate chips? One interviewee specifically referred to the little-understood requirement in LGPL for sufficient interface information to be made available (together with the right to reverse engineer), for the LGPL component to be modified and re-linked to the ‘work’ as a whole. It is not clear how that would work with electronics especially since the works could be combined on static silicon (as masks). One interviewee noted that OpenSPARC (which was licensed under GPLv2) had in the past proved to a successful design (used for devices as diverse as digital cameras and network interfaces), thus demonstrating that GPL-based designs are capable of being commercially successful. There is little publicly available information on OpenSPARC (which is a relatively old project, having been released in 2006), and the interviewee suggested that separate research should be undertaken by locating some of the individuals who had been involved in the project initially, and in particular, the decision to open the technology, and to interview them.

Horizontal and Vertical Boundaries

One interviewee suggested the horizontal boundary problem might be fixed by saying that a weak copyleft licence could be drafted in a manner that the licensor provided an interface definition alongside the code. Provided that any third party complied with the interface definition, their code linking to the original licensor’s code would be free of the reciprocal effect. The next version of the CERN OHL – see above – is likely to adopt an optional mechanism similar to this.

What drives licence choice (copyleft vs. permissive)?

Most interviewees expressed a preference for permissive licensing on the basis that existing copyleft licences left too much uncertainty, and that this uncertainty would inhibit adoption. It would also make it more difficult to deal with companies which provide proprietary libraries as those companies would be uncomfortable having their proprietary library used in a design which covered by copyleft of uncertain scope. One interviewee noted the value in copyleft licensing and noted that the Open Hardware Description licence expressly addressed the scope problems, but that it had not been widely adopted.

When it was suggested in each case that the next version of the CERN OHL would likely incorporate additional optional exceptions which expressly limited the reciprocal effect (as noted above) respondents suggested that this would cause them to potentially reconsider their licensing choices and consider its adoption. However, that there was little point in examining the issue in greater depth until such a licence was more widely accepted in the wild.

It was generally accepted that licence choice was ideological, and that some projects would be more inclined to wish to maximise use of their designs by providing them under a permissive licence while accepting the danger that the designs may become incorporated into proprietary hardware, while others wished to maximise freedom by making them available under a copyleft licence which ensured modifications would be made available under the same licence. However, all parties were all uncomfortable with existing copyleft licences, and regarded the issue, as this stage, as being largely hypothetical.

One interviewee noted that the use of components under copyleft licences in their current state would potentially cause difficulties with fundraising. One interviewee noted that in a due diligence exercise it was not unusual to run a code-scanning tool such as Black Duck against HDL files, although it is not immediately clear what the benefits of such an activity would be and whether Black Duck holds any HDL in its codebase, other than potentially to scan the code for licence texts such as the GPL which are frequently regarded as ‘risky’ by funders.  

‘Selling exceptions to the GPL’

One interviewee provided, as an example, the Leon core provided by Gaisler and based on SuperSPARC that is available both under LGPL/GPL and a proprietary licence. This was simply an illustration of dual licensing and does not suggest any particular motivation on the part of Gaisler for choosing that licensing model.

Open Hardware Communities

The consensus among interviewees was that the lack of open source or low-cost toolchains was an inhibiting factor in the growth of open hardware communities focusing on cores.

It is noteworthy that cores which emulate obsolete or obsolescent designs, primarily of interest to hobbyists, are more likely to be licensed under copyleft licences. For example, the Neo430, OpenMSP430 and T400 and T48 µController cores, examples of cores from selected OpenCores projects which fall into this category, are all licensed under copyleft licences.

Both responses also indicated that, most commonly, projects based on a permissive licence retained the same licence when out- bound licensing (i.e. the licence under which the design is to be licensed to third parties), as for the in-bound contributions.  

In terms of community development, interviewees stressed the importance of evangelism and outreach, and funding community development. One individual also stressed the importance of becoming involved in projects like the FOSSi foundation.

Toolchains

One issue that came up frequently, although detailed discussion is outside the scope of this report, was that open source toolchains are much scarcer in the world of open hardware than they are in software. The extent to which the toolchain will incorporate code of its own into the output, and what the effect of that code is from a legal point of view, is highly problematic: it is a debatable point as regards software but becomes even more so when applied to hardware. Questions arise such as whether a bitstream is in any sense a computer program, and - if so - who ‘runs’ it when the hardware starts up.

Patents

The interviewees generally noted that patents were a potential problem but had no clear suggestions on how to address this challenge. It was noted that members of the RISC-V foundation get the benefit of a cross-licence agreement from the other members, but that non-members, although they are able to use the ISA specification freely, gain no form of explicit patent licence or protection.

One interviewee noted that there was a move towards licences such as Apache 2.0 away from BSD or MIT because of its explicit patent provisions. One noted that the Solderpad licence (an Apache variant) had been adopted by LowRISC and PULPino because it was a relatively simple licence which had been modified specifically for hardware and had Apache-like patent provisions.

Establishing a default licence to use - recommendations

Broadly, licence choice should be limited to one of the more popular licences. Which specific licence is chosen depends depending on business needs for that the relevant project. The most popular software licence choices include the licences of the GPL family, Apache 2.0 and potentially MPL. For hardware, these may roughly correlate with CERN OHL/TAPR, Solderpad or BSD/MIT and Open Hardware Description License. Less well-used licences should be avoided, because they may cause licence incompatibility problems, and it makes project adoption more problematic. It is worth bearing in mind that the lawyers acting for counterparties prefer to work with the text of better-known licences to avoid having to spend expensive time to become familiarised with them. The informal drive towards licence standardisation is a topic which arises at legal licensing conferences quite frequently: the observation goes that the GPL, for all its flaws, is well understood, so tends to lead to a better legal outcome for both parties in contrast to a licence like (for example) the Open Software Licence, which is arguably better drafted, but less well used and understood.

It may be the case that there is, in practice, no choice that can be made, if the project uses, for example, a GPL component at its core which cannot be sufficiently decoupled from the rest of the work. In that case, the whole project would likely have to be released under the relevant version of the GPL.

On the other hand, to maximise freedom, a good choice is the CERN OHL (adopting, where appropriate, one of the reciprocal versions, when v2 is released).

Another option as referred to previously in this paper is to sell proprietary unrestricted licences alongside a given open source licence (assuming the licences of the other components allow this). It is common practice to use a restricted licence (such as GPL or CERN OHL with no exceptions) to enhance the attractiveness of the proprietary option, though while this is common it is frowned upon by the GPL community.  On the other hand, a legitimate reason for dual licensing may be that the licensee wishes to use a GPL-licensed core alongside third-party proprietary components, and therefore has to seek a licence from the licensor of the core which is compatible with those components.

Conclusion

All interviewees believed that the most commercially effective open hardware core designs were those which adopted permissive licences. The prevalence of these licences is borne out by desktop research. The stated various reasons for this are:

• ─that the currently available copyleft open hardware licences are insufficiently clear in their effect to be safely used; 

• ─that the potential benefits of copyleft licensing in core designs are not yet sufficiently clear to show an overwhelming need to shift to a copyleft model; 

• ─that copyleft licensing is certainly interesting and may have a place as the market matures. No interviewee was against copyleft core licensing in principle (although there was consensus that a weak copyleft with clearly defined boundaries was more likely to be commercially successful).27 

Note that even though the interviewees selected were intended to represent a cross section of the core-developing communities, RISC-V was referred to by every interviewee. The emphasis on permissive licensing may therefore be an artefact of the relatively small sample size and a shared familiarity by the interviewees with RISC-V. It may, on the other hand, reflect a reality that RISC-V is the most prominent and widely adopted open ISA currently in use.

About the author

Andrew Katz is a partner at boutique law firm Moorcrofts LLP, based in England's Thames Valley. Andrew specialises in technology law and has a particular interest in open design and development. He can be contacted at andrew.katz@moorcrofts.com

Appendix 1

Interviewees

• •Krste Asanovic, Dept EECS, UC Berkeley. 

• •Andrew Back, Managing Director, AB Open. 

• •Julius Baxter, Director, FOSSi Foundation. 

• •Dr Jeremy Bennett, Chief Executive, Embecosm. 

• •Alex Bradbury, lowRISC CIC. 

• •David May, Professor of Computer Science, Bristol, Founder XMOS, FREng, FRS. 

• •Simon Phipps, Founder, Meshed Insights Ltd. 

• •Dr Davide Rossi, University of Bologna. 

Appendix 2

Taxonomy of Open Source processors from OpenPiton

Appendix 3

OpenCores

Table 6: OpenCores

Appendix 4

Librecores

Table 7: LibreCores

Appendix 5

Analysis

Table 8: Summary Analysis

Table 9: Licence Analysis

Table 10: OpenCore Analysis

Table 11: Librecore Analysis

Table 12: Analysis of Opencores and Librecores

Licence and Attribution

This paper was published in the International Free and Open Source Software Law Review, Volume 10, Issue 1 (December 2018). It originally appeared online at http://www.ifosslr.org.

This article should be cited as follows:

Katz, Andrew (2018) 'A Survey of Open Processor Core Licensing', International Free and Open Source Software Law Review, 10(1), pp 21 – 46
DOI: 10.5033/ifosslr.v10i1.130

Copyright © 2018 Moorcrofts LLP.

This article is licensed under a Creative Commons Attribution 4.0 CC-BY available at

https://creativecommons.org/licenses/by/4.0/

1For more information see <https://github.com/westerndigitalcorporation/swerv>

2Alan Tse is a member of Western Digital’s Legal team and responsible for open source compliance across the company and supporting Western Digital’s open source strategy.  His practice covers product lines both up and down the stack including storage devices firmware, consumer devices, data centre systems, and now even hardware cores.  As a former computer engineer who grew up using open source software and anxiously waiting for the year of the Linux desktop, he has watched the evolution of open source throughout the tech industry and occasionally dabbles in various open source communities.

3The data presented in this paper represents information obtained during that research period, unless explicitly stated otherwise. For example, during discussions with Mohammad Shahrad (see footnotes 4, 19 and 20) we agreed to provide him with an updated of the data he presented in the paper referenced at footnote 4, and since this update was provided as at 29 January 2019, we decided to update the relevant text and appendix of this report accordingly. It does not affect the conclusions. The author thanks Heather Stewart for her invaluable assistance in the updating process.

4Balkind, Joseph, et al. (2016) ‘OpenPiton: An Open Source Manycore Research Framework’,  ASPLOS ‘16, pp 217 – 232. <http://parallel.princeton.edu/papers/openpiton-asplos16.pdf> DOI: 10.1145/2872362.2872414

5For more information see <https://www.oshwa.org/definition/>

6With the interesting distinction that in the preamble, OSHWA states that the design must be publicly available so that anyone can make etc. the design. OSI only requires that the licensing terms enable the licensee to make open source software publicly available, but not that public availability itself is necessary.

7<https://www.oshwa.org/sharing-best-practices/>

8Andrew Katz has been involved in the drafting of CERN OHL <https://www.ohwr.org/documents/294>.

9<https://opensource.org/licenses/BSD-2-Clause>

10<https://creativecommons.org/licenses/by/3.0/>

11Andrew Katz drafted the Solderpad Licence. <http://solderpad.org/licenses/>

12<https://opensource.org/licenses/ISC>

13<https://www.oshwa.org/oshw-community-survey-2012/>

14<https://www.oshwa.org/oshw-community-survey-2013/>

15<https://www.blackducksoftware.com/top-open-source-licenses>

16As of 29 January 2019, this has increased to ‘about 1500’, but the search results are somewhat noisier, so it’s not clear if this is a valid comparison.

17We tried to rerun the search on 29 January, but the results were so much noisier that it’s impossible to make a valid comparison.

18We tried to rerun the search on 29 January, but the results were so much noisier that it’s impossible to make a valid comparison.

19Balkind, Joseph, et al. (2016) ‘OpenPiton: An Open Source Manycore Research Framework’,  ASPLOS ‘16, pp 217 – 232. <http://parallel.princeton.edu/papers/openpiton-asplos16.pdf> DOI: 10.1145/2872362.2872414

20<http://parallel.princeton.edu/openpiton/open_source_processors.php>

21The results in the appendix have been updated to 29 January 2019, and therefore differ slightly from the version of the table provided to WD in the original version of the report. The figures above have been updated accordingly. For comparison, the text in the original report read: “There is a gap between October 2015 and February 2017, and if we take the projects that have been active since February 2017 (of which there are 12), 5 of them are copyleft. For projects prior to this date (of which there are 14), 12 are copyleft.”

22At of January 2019, proposals for CERN OHL v2 take a different approach and have introduced the concept of an ‘Available Component’. Designs do not have to provide the design documentation for components that qualify as ‘Available Components’, which include items like readily available electronic components, provided that enough information about their specification, characteristics and interfaces is available to enable them to be sourced or used in the design. Thus a 555 timer when provided along with its datasheet would quality as an ‘Available Component’.

23Stallman, Richard ‘Selling Exceptions to the GNU GPL’ <https://www.gnu.org/philosophy/selling-exceptions.en.html>

24The results in the appendix have been updated to 29 January 2019, and are not the version of the table provided to WD. The text of the version of the report released to WD  accordingly read “two projects out of 26” in the sentence to which this is a footnote.

25In the sense of ‘liberty’. In other words, the designer’s intention is that the design, in all its incarnations, remains free of constraints on reuse, modification and distribution, and also has the effect of causing other designs combined with it to be equally free, with the overall intention of increasing the commons of free designs.

26Or the newly (January 2019) announced permissive version of the CERN OHL.

27At the time of the original research, some of the interviewees were aware that CERN was in the process of redrafting the CERN OHL to create a new version intended to address the concerns of FPGA and ASIC developers. The approach which was being taken at that stage was by way of application-specific exceptions to the licence. The current approach (as at January 2019) is somewhat different and now allows code libraries, macros, etc. which are provided as part of the toolchain to be included as an ‘Available Component’ - see footnote 22.

28Originally published in Balkind, Joseph, et al. (2016) ‘OpenPiton: An Open Source Manycore Research Framework’,  ASPLOS ‘16, pp 217 – 232. <http://parallel.princeton.edu/papers/openpiton-asplos16.pdf> DOI: 10.1145/2872362.2872414, Table 4, updated at http://parallel.princeton.edu/openpiton/open_source_processors.php