On licenses for [Open] Hardware
OOn licenses for [Open] Hardware
M`arius Mont´on ∗† , Xavier Salazar ‡∗ Dpt. of Microelectronics and Electronics Systems, Universitat Aut`onoma de Barcelona, Spain.Email: [email protected] † Institut d’Estudis Espacials de Catalunya. Barcelona, Spain ‡ Barcelona Supercomputing Center. Barcelona, Spain
Abstract —This document explains the basic concepts relatedto software and hardware licenses, and it summarizes the mostpopular licenses that are currently used for hardware projects.Two case studies of hardware projects at different levels ofabstraction are also presented, together with a discussion oflicense applicability, commercial issues, code protection, andrelated concerns.This paper intends to help the reader understand how torelease open hardware with the most appropriate license, andto answer questions that are of current interest. We have beenmainly motivated by the growing influence of the open RISC-VISA, but trying to address a wider hardware point of view.
Index Terms —Licenses, open-hardware
I. I
NTRODUCTION
Thanks to the success and widespread adoption of manyopen-source projects (Linux, LibreOffice, etc.), the communityand users typically have a good understanding of softwarelicenses. Developers in general have a clear picture of theoverall landscape of software licenses, together with the prosand cons and rights retained and conceded by each type ofsoftware license.On the other hand, when we switch to hardware projects, thelandscape of licenses while being generally and conceptuallysimilar they can vary lightly and the knowledge of developersis scarce [1]–[5]. With the advent with the advent of of opensource Hardware initiatives [6] it is getting more important tobecome familiar with those concepts. Hence, this paper triesto address this challenge by clarifying the basic concepts oflicensing, how they are used for hardware and it applies thisknowledge to two different use cases [7], [8].The paper is structured as follows: Section II introduces anumber of key basic concepts related to licenses. Section IIIis a shortlisting of the most commonly used licenses at themoment, with their main features. Next, Section IV exploresthe two use cases. The article finishes with the conclusions inSection V. II. L
ICENSE BASICS
In order to understand open hardware licensing it is im-portant to know main basic concepts of open source licensingthat have been traditionally used for software as many of thoseconcepts can be later on extrapolated for hardware. Licensesare the legal contract between the Software owner and the users. It usually specifies the permissions granted to the user( the licensee ) and the rights, obligations and limitations of theuser towards the Software. Typically a software license grantsthe licensee to use the software but not to re-distribute or re-sell the software. The level of rights retained by the ownerof the software classifies what type of license to use. Forinstance, Microsoft Windows has a proprietary license thatretains copyright to Microsoft, but gives permission to thelicensee (end-user) to use the software and show the softwareto others. But the same license doesn’t allow users to copy thesoftware (install it on other computers), modify the softwareor re-distribute to others. GNU/Linux, has a license (GPL -General Public License) [9] that allows the end-user to accessthe code, copy the software, modify and re-distribute it (withsome restrictions).First of all, some definitions of common concepts usedin licenses are described below, emphasizing the differencesbetween terms that are often misused:
A. Free and Open
As mentioned before, there are two concepts that are oftenmisunderstood: free and open.
Free means that the licenseegets the Software free-of-charge (i.e. ”gratis”), also known aslibre software, and
Open means that the user gets access tothe source code of the design. Although these two conceptsare quite different, they are usually seen together. B. Proprietary and Open
In contrast to free and open approaches, the code maybe kept proprietary, closed as an industrial or trade secret.In these cases, only software binaries or encrypted code areshared. The use of proprietary software is often regulated bya limited use license that may include non-disclosure clauses,prevent reverse engineering, or add any further protectionmechanisms such as liability clauses. Alternatively softwareor the underlying methodology may also be patent protected,and therefore disclosed. Both cases can become relevant whenassessing their compatibility with open source components
C. Authorship and Ownership
The terms authorship and ownership are also often mixedand misunderstood. The authors are the software development There are examples of Software that is free but not open (i.e. Winrar) andsoftware that is open but not free (i.e. µ C/OS-III) a r X i v : . [ c s . OH ] O c t eam that wrote the code. The owner is typically the institutionthat employed the authors. D. Software disclosure
Each organization has its own procedure for software disclo-sure. The authors are not necessarily responsible for choosingthe license of the codes, but they must follow the rules of theirorganizations depending on the business/academic strategy.Specific terms are usually regulated in the employees’ workingor service contracts.
E. Derivative work
A derivative work is any work that expands or uses previouswork from another author. In the case of software, it iscommonly accepted that any code that uses a library bystatically linking it is a derivative work of that library. Anexception to this definition is if a Software component used isdesigned to be a library and it is licensed ”as is”. In the caseof hardware, a design that uses a module or parts of a modulecan be considered as derivative work of this module.
F. Copyright, Creative Commons and Public Domain
All software is automatically protected by copyright to itsauthor, giving exclusive rights to determine under what termsthe original work may be copied and used by others.An author can give away (”waive”) its copyright rights byoffering these rights to the public domain, giving freedomto people to distribute copies, modify it, or sell it withoutattribution.Creative Commons is a set of licenses intended for thedistribution of documents or content of any type in a copyleftphilosophy [10]. There are variations of the rights left to thelicensee, but basically are all combinations of the following: • CCO means ”no right reserved” enabling waiving thecopyright. • Attribution: Licensee can distribute, modify, remix, sell,etc. but they must always give credit to the originalauthor. • ShareAlike: Same as above, but the license of the deriva-tive work must use the same license. • NoDerivs: Limit the licensee to distributing derivativework. • NonCommercial: The licensee cannot use the work com-mercially.
G. Copyleft/Reciprocal and Permissive
Copyleft is the practice of offering the rights to freelydistribute copies or modified versions of a work with thecondition that the same rights must be preserved in thederivative works. These are often called viral licenses.In contrast, permissive licenses allow the licensees toredistribute derivative works with greater freedom, withoutdemanding that the licensee publish derivative works with thesame license.In the case of hardware, as it is not covered by copyright,it is preferable to use the word reciprocal to express the sameCopyleft concept.
Fig. 1. Degrees of freedom and rights in SW licenses. [11]
H. License compatibility
License compatibility is the capacity of pieces of softwareor hardware (IP blocks) with different licenses to be distributedtogether.Two incompatible licences can contain contradictory state-ments and it can be impossible to legally combine source codefrom different software to create or publish a new software.
I. Patents and open-source
Integrating patent-protected software with free and open-source software is a special case of compatibility. Free soft-ware or open source projects cannot fulfill patent licences thatinclude any kind of per-copy fee. A patent that is royalty-freeis acceptable. III. L
ICENSE TYPES
In this section license needs and types are introduced.
A. Philosophy
Proprietary licenses try to protect a business and a valuecreated by the company or companies and their developers. Forthis reason, this type of licenses maintains the copyright andcontrols in some way the ability of the user to get additionalcopies or re-distribute the Software. Basically, the Softwaresold has a value, and the user must pay for each piece orinstallation. The commercial licenses try to protect this sellingstrategy. The majority of code of this type is sold as ”closed-source”, that is, the customer doesn’t receive a copy of thesource code of the Software bought, but only the binaryfiles that are necessary to run the software. In this way, theselling company has double protection, because the licensedoesn’t allow the customer to modify or copy the softwareand technically the customer without the source code has alimited capacity to do so. The free and open-source software philosophy (also namedFOSS) tends to grant the user the ability to inspect, modify anddistribute the Software. Different degrees of freedom are givento the end-user by different FOSS licenses, as described inSection III-B. A depiction of this concept is shown in Figure 1.Although free and open licenses give the end-users morefreedom than commercial licenses, some of them restrict insome way the options of the end-users to do whatever theywant to the code. For instance, GPL restricts the licensee touse the same type of license in any derived works. There are companies that sell Software in source code form usingproprietary licenses. n terms of commercialization, Open Source codes are inmost cases given “as is”, without warranties, support or main-tenance and they are not business friendly. All responsibility ofthe correct use of the Software relies solely on the user of thelicence. It is therefore possible to retain business value fromopen source technologies by offering services around theminstead of simply selling the resulting software product. Hybridapproaches are also possible, with the choice of dual licencesthat include open source sharing for limited (non-commercial)purposes, but with a proprietary approach for commercial uses.
B. Software licenses
As said, there are several different licenses designed for thedistribution of software. Below the most common ones arepresented.
1) GPL:
General Public License (GPL) refers to the li-censes designed and used by the GNU project [9]. It is a freelicense that gives the end-user the freedom to run, study, shareand modify the software.This license is copyleft, meaning that the derivative workcan be only licensed with the same GPL license.It is the license used by Linux Kernel and the GCC compilerand it is one the most popular software license in FOSSdomain.There exists a variant of the GPL license intended forlibraries, which is called LGPL (GNU Lesser General PublicLicense). This license allows non-GPL code to be linked withlibraries licensed by LGPL.
2) BSD licenses:
BSD (Berkeley Software Distribution)licenses are a set of FOSS licenses less restrictive than GPL[12]. There are multiple forms of this license, but the mostcommon in use is the license known as “3-clause version”.These licenses allow the licensee to use, run, study, share andmodify the software.What this license doesn’t do is to force the publication ofderivative work as FOSS, but it requires that credit is givento the original authors. It means that derivative works can beclosed and commercialized in a “standard way”.
3) MIT:
The MIT (Massachusetts Institute of Technology)license is very similar to BSD license with the same level ofpermission granted to the licensee [13].It is compatible with other free or copyleft licenses andallows to reuse within proprietary software.
4) EUPL:
European Union Public Licence (EUPL) is a newlicense created by the European Commission for FOSS [14].This license is a copyleft type, allowing licensee to modify,redistribute, do derivative work, etc.It is compatible with GPL.
5) Apache License:
The Apache License by the ApacheSoftware Foundation (AFL) is a permissive free open-sourcelicense [15].
C. Summary table
Table I In all of them regulation of rights to copy, distribute,modify, distribute a derivative and protection against patentclaims summarizes what a user can do and don’t for eachlicense introduced in this document.
TABLE IL
ICENSE SUMMARY
License GPL BSD MIT EUPL Apache
Copyright Yes Yes Yes Yes YesDistribute Yes Yes Yes Yes YesModify Yes Yes Yes Yes YesDerivative Yes No No No NoDerivative license GPL Any Any Copyleft AnyPatent grant Yes No No Yes Yes • Copyright: Copyright is retained by original authors • Distribute: Licensee can distribute the source code among others. • Modify: Licensee can modify the source code • Derivative: Derivative work must be shared in source code • Derivative license: Derivative work license type • Patent grant: protect both sides from patent claimsFig. 2. License compatibility diagram. (David A. Wheeler [16] )
D. Compatible licenses with other licenses
Figure 2 shows a diagram with compatibility relationsbetween licenses. An arrow from A to B means that modulesusing licences A and B can be combined and the result has touse the license B.This diagram is useful when using 3rd party modules orsub-projects with a different licenses than that chosen by theoverall project. Hence, if we are licensing our code with aBSD-like license and we are using a module or library thatis licensed with an LGPL license, any resulting project thatintegrates both parts must be licensed with LGPL (there is anarrow from BSD-new to LGPL in Figure 2).
E. Software associations1) Free Software Foundation:
The Free Software Founda-tion (FSF) is a nonprofit with a worldwide mission to promotecomputer user freedom [17].
2) The Open Source Initiative:
The open source initiative(OSI) aims to raise awareness and adoption of open sourcesoftware, and build bridges between open source communitiesof practice [18].
F. Hardware licenses
Hardware can be open-sourced in a similar way to soft-ware.In the case of hardware, the term “open-source” refersto the availability of all files and components necessaries toreplicate the device.The basic hardware unit subject to be licensed is called an IPblock (Intellectual Property block) or IP core. It is the reusablenit of logic, cell, netlist or integrated circuit layout design.The IP block also includes all the documentation necessary tounderstand its design or to use the block.In the case of a PCB board, an open-source hardware releasewill contain the schematic and the layout in a free or standardformat. Hardware files are usually also released in someformat readable to all as PDF. For this different nature of thedevices, there exists a set of licenses designed for hardware.Some projects and associations recommend general open-source licenses that were originally conceived for distributionof software, such as GPL, BSD or MIT. Usually these licensesonly protect the hardware part (named the Documentation),and allow the author to chose what license to use for thesoftware parts (Firmware, other software, etc.).In the case of FPGA-based design, the release would includeall HDL files (Verilog, VHDL, SystemC, etc.) in text format,etc. Although these kind of files can be licensed using softwarelicenses, the use of hardware licenses is recommended as theterminology in hardware licenses fits better for this purpose.For a low-level design (Hard-IP, ASIC designs, FPGA bit-streams, etc.), software licenses are not enough and hardwarelicenses ought be used because of the nature of the files andthe design process itself.The Open Source Hardware Association (OSHWA) hasa definition of Open Hardware in its webpage. See alsoSection III-G1.Below is a short listing of the commonly used open sourcehardware licenses:
1) CERN Open Hardware License:
The CERN Open Hard-ware License (OHL or CERN OHL) was originally written byCERN to publish some of their designs [19]. There are threeregimes for this license: • CERN-OHL-S: strongly reciprocal license. It means thata licensee can use the original code, and any releasesof binary files (e.g. FPGA bitstreams incorporating theoriginal Verilog code) must also provide all the HDL codeand necessary components as well with the same license. • CERN-OHL-W: weakly reciprocal license. Similar toCERN-OHL-S, except that the original project can bepublished without including third-party components (butthese components must be available to anybody, maybeby purchasing them). • CERN-OHL-P: permissive license. This licence givestotal freedom to the licensee, it can be re-licensed withoutredistributing the original code.
2) Solderpad:
The Solderpad Hardware Licence is basedon the Apache 2.0 software license, adjusted to the hardwarecontext. It is a permissive free open-source license [20].
G. Hardware associations1) Open Source Hardware Association:
The Open SourceHardware Association (OSHA) promotes access to all kinds ofhardware and projects to users. It has a certificate program and “electrons are cheap, but atoms are expensive” ARDWARE L ICENSES SUMMARY
License CC0 OHL-S OHL-W OHL-P Solderpad
Copyright No Yes Yes Yes YesDistribute Yes Yes Yes Yes YesModify Yes Yes Yes Yes YesDerivative No Yes Yes No NoDeriv. license Any OHL-S OHL-W Any AnyPatent grant No Yes Yes Yes Yes • Copyright: Copyright is retained by original authors • Distribute: Licensee can distribute the source code among others. • Modify: Licensee can modify the source code • Derivative: Derivative work must be shared in source code • Derivative license: Derivative work license type • Patent grant: protect both sides from patent claims maintains a database of open source hardware projects [21],[22]. Each certificated project has a unique identifier and theproject components (hardware PCBs, manuals, etc.) can showthe OSHW logo (Figure 3).
2) FOSSi foundation:
The Free and Open Source SiliconFoundation (FOSSi) is a organization built to promote andassist free and open digital hardware designs [23]. It maintainsa repository of free hardware IP cores and promotes someprojects.Table II summarizes in the same way as previous table thehardware licenses.
H. Licensing the documentation
Documentation, as a literature work, is different in nature tosoftware or hardware, so a different type of license is required.Here are presented the most used licenses for documentation.
1) GFDL:
GNU Free Documentation License is a copyleftlicense for documentation [24]. Its terms are similar to GPL,because it gives similar rights to the readers to copy, redis-tribute and modify a work, and the derivative work must havethe same license. The original author can mark some parts ofthe text as invariants and the license forbids the licensees tomodify theses parts.Wikipedia uses this license for its articles.
2) Creative Commons:
Anther option is to use a Cre-ative Commons license. Some Open Hardware projects use“Creative Commons Attribution Share-Alike” to license theirdesign files (schematics and layout files) (see Section III-H2).It allows the licensee to sell derivative works. I. Hardware deliverables of IP protectable assets
The deliverables of a typical hardware project can be: thelayout ready to tape-out to a ASIC vendor (e.g. TSMC, XFAB, Arduino and other companion business use this license for hardware filesABLE IIISW / HW
SUMMARY
SW HW
Copyleft GPL alike CERN-OHL-HLesser copyleft: LGPL CERN-OHL-WPermisive: MIT / APACHE / BSC CERN-OHL-P / SolderpadLibrary / code IP blockCompile SynthesisBinary bitstream or GF); the P &R (place and route) project ready to beimported into a ASIC vendor tool (e.g. the GDSII file); theschematic or netlist in some vendor tool format (i.e. Cadence,Mentor). The outcome of a hardware project can also be a setof Gerber files for a PCB layout. For an RTL project, Verilogor VHDL files are the foundation of the project (althoughhigher level languages as SystemVerilog, SystemC or Chiselare getting more importance), but intermediate files as netlist(EDIF format) or final files as bitstreams can also be theoutcomes of the project.
J. Analogy from software to hardware licenses
Regarding compatibility, the chart for open source Softwarecan be extrapolated to the Hardware ones as summarized inTable III. IV. C
ASE STUDY EXAMPLES
In this section we propose two different hardware projectapproaches and study some of the implications related to thechoice of license. The two projects are at different abstractionlevels (the first is RTL only, and the second mixes RTL withgates and ASIC tools). Both projects are speculative and withthe purpose of discussing hypotheses around the differentlicensing choices and their consequences
A. Microprocessor at RTL level
This case study is for a RISC-V microprocessor in Veriloglanguage at RTL (Register-Transfer Level) [6]. The code isintended to be synthesized to FPGA and it uses some vendor-library or primitives, such as embedded memories, and DSPblocks in FPGA. Also, the code has been synthesized to anASIC to test correctness and suitability of the written codeto the technology. The development team as authors hold thecopyright of the entire code, but the ownership is with theirinstitution, and therefore any decision on IP disclosure has tobe consented by institution’s decision makers. There are manycommercialization and licensing options, which we enumerate,from those allowing more freedom to those that are morerestrictive.
1) Public domain:
It can be considered to publish allVerilog files and auxiliary files (simulation scripts, FPGAsynthesis scripts for one specific vendor, etc.) as copyleft witha Creative Commons CC0 license.Once published with this kind of license, the code is nolonger their property, and it is now public. This means thatany other team or developer can get the code or parts of it and use it without restrictions: sell it, use it in a product, etc.A company could get the code, do some changes to preparean ASIC and sell it with any mention to the original authors.
2) Reciprocal:
The code can also be released into a publicrepository using the CERN-OHL-W license. In this case, anydevelopment team will be able to obtain the code, synthesizeit and obtain the same processor as the original, assumingthat they have acquired the same vendor tools, primitivesand libraries. The original team may not be able to useCERN-OHL-S if they use third-party libraries, if they cannotdistributed with their project. If the entire project was designedusing open-source with a license compatible with CERN-OHL-S, the entire project could be licensed with this license.This licensee team can modify the original code and publishit again, but it will be mandatory to use the same license inthe changes and/or new files as a derivatives. This team ororganization can also release and sell the bitstream or a PCBboard with the bitstream programmed in the FPGA and alsohas to provide the original code and his changes. If only partsof the design are taken and used in a design by another team,at least the copyleft parts must keep the same license.
3) Permissive license:
A permissive license, such as theSolderPad license, can also be chosen. Using this license, thelicensee team must publish the original code, but the licenseecan choose not to publish its changes. While is it more difficultto get commercial value using this type of license, it is themost business friendly solution since the licensee has a higherlevel of freedom to use, modify and integrate in their systemswithout compromising the rights of the rest of the components.
4) Non-commercial license:
It is also possible to publishthe project with a license that forbids commercial use, butallows licensee to use, modify, etc. the original project forother purposes (mainly academia). This kind of license is veryrestrictive, because can be seen as “nobody in a company canopen the code” and limits the scope of the project to justacademia.
5) Proprietary license:
It can also be decided to publishonly the bitstream and release some documentation and pub-licity of its design, while keeping the source code unreleased.This would be a classical product with any public release ofthe code.
B. Growing complexity of microprocessors
Microprocessors are becoming more complex systems-on-chip, including heterogeneous architectures with general pur-pose processing units, specialized types of accelerators, mem-ory systems, etc. In such cases, as many different IP blockscan be identified as part of a microprocessor, a more carefullook at the compatibility of licenses is needed and therefore amore similar approach as the one explained in next section.
C. IP Block for ASIC
This case study is for an analog–digital mixed design ASIC.There is a analog part that is designed with classical tools(schematic capture, full-custom layout and P&R, etc.) butsome of parts of the design are designed and parametrizedsing iterative processes using a high-level language as python.The IP has a add-on that is a digital interface to a processorbus (AXI4) written in VHDL without any third party libraries.In this case the development team (original team) that holdsthe copyright of the entire code as authors, are also the ownersof it. Again, there are a number of licensing and publishingoptions, and we briefly discuss each.
1) Public domain:
The original team can publish all filesand license them with a Creative Commons CC0 license.
2) Reciprocal:
In case the original authors want to publishtheir work, it seems reasonable that they publish all designfiles, including schematics, P&R results and other files in-volved in the ASIC synthesis. In this case, since ASIC librariesand toolkits are restricted to many people, the type of licenseis similar that the other study case. In this particular case, ifusing CERN-OHL, the license variant should be CERN-OHL-W, because the ASIC vendor toolkit and standard cell librariesare closed components.For the VHDL code of the bus controller, it can be releasedwith CERN-OHL-S because the original project is not usingany third-party library, hence all code is available for licensees.
3) Permissive license:
If the developers want to allow moreflexible licensing for derivative works, they can choose apermissive license.In this case, all ASIC-related files can be published usingCERN-OHL-W (for the same reason as the HDL case and theuse of proprietary libraries or components) or using SolderPadlicense.For the digital RTL–VHDL part, a SolderPad license is themost suitable.This is usually a good choice for handling complex schemesas it doesn’t compromise compatibility between components.On the other hand, it is possible that the original team easilyloses control of their original development.
4) Non-commercial license:
Again, it is possible to publishthe project with a non-commercial license, although is notrecommended for the reasons exposed in the prior case.
5) Proprietary license:
The original team can chose to sellthe IP has a hard-IP and the post-P&R files as deliverables.In this case, probably the deliverable to protect will be thelast steps of the ASIC design specific to a vendor-tool and afabric technology because the tools and design-kits are underrestrictive NDAs for its exclusive use for academic purposes.V. C
ONCLUSIONS
In this paper we presented the different license types forsoftware and hardware. A introduction to each of the licensesand a brief explanation and comparison for all of them hasbeen exposed. Also, two case studies are explained. Thesetwo use cases work at different levels of abstraction and withdifferent development tools. For each case different licenseoptions are depicted to show the landscape of possibilities andto help engineers to chose the proper license for their projects.When deciding to publish a design following an open-source philosophy, it is important to realize that the main pointshould be to give others the ability to study, re-use or modify (and even sell) the project outcomes. For that reason, it isimportant to publish not only the intermediate or final results(as bitstreams, post-P&R layout or mask layout files), but also,as much as possible, release the higher level source code.A
CKNOWLEDGMENTS
The DRAC project is co-financed by the European UnionRegional Development Fund within the framework of theERDF Operational Program of Catalonia 2014-2020 with agrant of 50% of total cost eligible. We also thank Red-RISCVfor the efforts to promote activities around open hardware.R
EFERENCES[1] J. R. Ackerman, “Toward open source hardware,”
U. Dayton L. Rev. ,vol. 34, p. 183, 2008.[2] E. Greenbaum, “Open source semiconductor core licensing,”
Harv. JL& Tech. , vol. 25, p. 131, 2011.[3] A. Katz, “A survey of open processor core licensing,”
International Freeand Open Source Software Law Review , vol. 10, no. 1, pp. 21–46, 2019.[4] J. Svorc and A. Katz, “Breathe in, breathe out: How open hardwarelicensing can help save the world,”
The Journal of Open Law, Technology& Society , vol. 11, no. 1, pp. 49–56, 2019.[5] M. Luis Felipe R, P. Kauttu, P. P. Laia, W. Jonathan, K. Andrew et al. ,“Open hardware licences: parallels and contrasts: Open science monitorcase study,” European Commission Directorate-General for Researchand Innovation, Tech. Rep., 2019.[6] A. Waterman and K. Asanovi´c, “The RISC-V instruction set manual,volume i: User-level isa,” RISC-V Foundation, Tech. Rep. Version20191213, December 2019.[7] K. Asanovi´c and D. A. Patterson, “Instruction sets should be free: Thecase for risc-v,”
EECS Department, University of California, Berkeley,Tech. Rep. UCB/EECS-2014-146 , 2014.[8] S. Greengard, “Will risc-v revolutionize computing?”