Introduction Hardware Licensing

Introduction

Some basic legal questions that one may have when engaging with the universe of Hardware and Digital DIY:

• How do I protect my open source hardware from someone else patenting it?
• What options do I have for making my hardware open source and how enforceable are they?
• What Open Source Hardware Licenses (OHLs) are most used and what are their particularities?
• Will a creative commons / copyright / copyleft license on my documents protect my hardware from being patented?
• Can I use this project within another project?
• What happens when I start manufacturing and/or selling this hardware?
• Someone copied my project, what rules apply?

Some important issues:

• electronic design files are not protected by copyright in the USA
• the UK has four different copyright regimes, for different sectors
• only the design may be protected but not the physical objects, so a viral effect as established with copyleft software licenses is not achieved
• few case law to prove the strength of OHLs
• filing a patent is difficult and expensive and takes time (“Relying on patent law instead of copyright law for hardware makes sense, since patent law is made for hardware, while copyright law is made for information. But it’s also a problem, since getting a patent is a difficult and costly process, while getting copyright is free and automatic. “)
• design right, Community Design Regultations (CDR), Registered/Unregistered Community Design (RCD/UCD).

In the context of hackers, makers, designers and DIYers sharing designs of hardware projects, licensing is one of the important legal aspects to consider. Licenses define the rights and obligations people have related to the objects subject to that license.

In this section we develop an overview of how people share hardware designs and what legal aspects come into play. The scope is Digital DIY. While the term (Digital) DIY can be understood as private use, mostly not for selling or distributing the thing to others, in this analysis we will look into those uses as well. After all, people form part of an ecosystem and it makes a difference when one can only buy the thing or its components from one sole vendor or when everyone interested can participate in its manufacture and sale. We will see how licenses affect these different uses very directly.

We can differentiate licenses in various ways. If we look at the rights they convey to the users («licensees») we can distinguish four groups:

• free licenses («free as in freedom»): licenses that assure the right to a) use for any purpose, b) study and adapt, c) copy and share and d) distribute modified versions (and this group can be split into copyleft and permissive free licenses);
• open, but non-free licenses: licenses that allow certain uses, but not all (e.g. non-commercial) and may or may not be modified (non-derivatives);
• closed, proprietary licenses: end-user agreements that permit certain uses but not much more;
• no license, but the work is published in an open repository.

If we look at the legal regimes that are covered, we can distinguish licenses that are based on and convey rights over:

• copyright (most frequent case);
• design rights;
• patents;
• trademarks.

When Richard Stallman[1] in the 1980s devised the GNU General Public License (GPL) he used copyright law's exclusive rights assigned to the author, who subsequently conveys the four freedoms to the users. So effectively he flipped the «all rights reserved» (and called it «all rights reversed»). Additionally he included the so called copyleft condition that derivative works were to be published under the same license (the GPL). This historic license (and its subsequent versions) is still the most used free software license.

While in most areas of knowledge, copyright is the legal regime used as foundation to enable licensing, in the case of hardware this may be problematic. Copyright law gives rights holders control over creative expressions such as text, graphical works, source code, while patent law assigns temporary exclusive control over technical solutions. But where copyrights in most countries come into existence automatically when a work is published or distributed, patents need to be applied for, which requires a serious effort and cost.

Challenges to shared hardware designs

Note that Digital DIY involves blueprints, hardware design files, schematics, software and documentation for which specific licenses are designed. Our focus is on those licenses that are most often used for sharing the hardware design and documentation. Hardware projects have different legal requirements to encourage sharing than other, purely digital projects (software, documentation). That said, software licenses will be discussed as well, as they are the first public licenses that were developed and provide inspiration for other types of licenses. Besides, software is relevant as well as it is present in most Digital DIY projects.

Challenges that we can identify:

• Patents are time consuming, overly costly and complex bureacratic procedures for most people. Moreover they are not automatically assigned as is the case with copyrights. For developers interested in sharing their hardware designs under a public license, patents are therefore – in most cases – not a good option. See Ackermann.
• Copyright only covers the expression, not the technical idea or solution itself. However most often copyright is the main legal framework used to assert rights that are licensed under a public license. Therefore they can - at best – protect the designs, but cannot avoid the privatisation of differently shaped objects that derive from the same design, even if the license was copyleft.
• Copyleft hardware licenses have limited possibilities to be enforced in court. As copyleft is based in copyright, its effect is over the elements that generate copyrights. However the physical object that one makes following the design files and documentation and so on is in principle not protected by copyright. If someone chooses to make a derivative object, a copyleft hardware license will have no direct legal effect on the terms under which the derivate is distributed, i.e. requiring to publish the design files of such derivative is in principle not enforceable. (Katz, 2012) Only in the case that a digital fabrication technology – such as 3D Printing – makes exact copies of a work, it can be argued that this may fall under copyright and therefore copyleft licensing may be a possibility (to be enforceable).
• When sharing hardware designs and in particular when people engage in the manufacturing and distribution of hardware one should be sure no patents (owned by external parties) exist, or appropriate patent licenses should be in place. Discovering patents is however a complex endeavour – so much that some call it a legal mine field, where one often cannot be sure whether a patent exists and potential patent claims can arise later in the process (in particular when a project proves to be successful).
• Patent applications require there is no «prior art» and to be sure there is enough novelty in the patent application. Different countries hold different standards of what is «enough novelty». On the other hand the existence of prior art is considered a practical way to avoid patent registrations. Publishing a technical solution in an open access web portal is called Defensive Publication and aims to create publicly available prior art, thereby at least theoretically preemptying the possibility to acquire patents over that idea. However often enough patent offices don't take sufficient time to study the existing prior art and patents maybe granted. In those cases the public may request to revoke such patent.
• With digital fabrication tools becoming more and more accessible to a growing group of people, the replication of objects, under legal exclusivity or not, becomes radically easier. Patent infringements are increasing and many observers are seeing a second «War against Piracy». Which lessons could we draw from the first war waged by the copyright behemoths? And how is the replication of physical objects different?

Most common hardware licenses

Following is a list of the most common ways to share hardware designs:

• Public licenses based on patents:
  • Defensive Patent Licenses: DPL,
  • The Open Invention Network (OIN) has a defensive patent license arrangement among its licensees around the GNU/Linux ecosystem
• Public licenses based on copyright of the design files:
  • CERN OHL
  • a hardware-specific non-copyleft license, the Balloon Licence. The Balloon Licence is a simple MIT-style license.
• Copyright and contract law:
  • TAPR OHL
• Generic public licenses used in hardware projects:
  • CC BY-SA
  • CC BY
  • CC0
• Labels based in trademarks:
  • OHANDA
• No license information is published, but the work is published in a publicly accessible repository.

Some more recent open hardware licenses are the Open Hardware License by Andrew Katz and the 3D Printing License by Youmagine.

We will briefly discuss each of these options.

TAPR Open Hardware License (TAPR OHL)

Authored by John R. Ackermann on request by the Tucson Amateur Packet Radio Corporation (TAPR), a nonprofit corporation with an international membership base.

Goal: to tie both the documentation, and the product that results from it, to a set of goals that are, as much as feasible, consistent with the four freedoms defined by the Free Software Foundation’s Free Software Definition. At a minimum the license seeks to ensure that both the documentation, and products based on that, comply with two obligations: (1) that they make the documentation which they received under the Open Source Hardware license available to all; and (2) that they likewise make their modifications to that documentation available to all on the same terms as the original work [Ackermann, 2009].

Main headlines:

• Copyrightholder of the license: TAPR (abbreviation fo: Tucson Amateur Packet Radio Corporation)
• First version: 2007
• Home of the license: http://www.tapr.org/OHL
• Basis for protection: based in copyright, patents and any other intellectual property right.
• Protection through: a combination of a license and a «click-wrap» contract: by exercising any rights granted by the license you become a licensee and have to comply with its terms.
• Provides patent immunity for suit from infringement to licensees and all rightfull possessors of the product based on the documentation.
• Type of licence: copyleft, i.e. requires to share modifications under the same licence.
• Applicability: expressly disclaims applicability to software, firmware, or code loaded into programmable devices.
• Disclaimer of warranties and liability.

In most areas, the OHL speaks functionally rather than legally; in other words, it describes what parties must and must not do without specifically describing the intellectual property regime underlying those obligations. Its goal is to enforce desired behavior without the limitations that a more technical approach might create.

CERN Open Hardware License (CERN OHL)

The principal aim for developing this license was to encourage and protect collaborative development of electronics designs done in an open source manner. A secondary goal was to track the actual ambit of dissemination of the designs of its authors – first of all CERN. Another item also on the wish list was a recognition of CERN's status as an Intergovernmental Organization for dispute settlement purposes, [Ayass, Serrano, 2012].

Main headlines:

• Copyrightholder of the license: CERN
• Home: http://www.ohwr.org/projects/cernohl/wiki
• First version: March 2011
• Basis for protection: copyright over the hardware documentation.
• Protection through: a contract that starts when you exercise any right granted to you under the license.
• Applicability: all kinds of hardware documentation (not for software, firmware or code).
• Attribution of author(s)/licensor(s) through copyright and trademark notices.
• Type of licence: copyleft, i.e. requires to share modifications under the same licence.
• Licensees making modified version are required to send a copy of the modified documentation to the original authors – when they have provided a means of contact with the documentation.
• Invites the licensee manufacturer to inform the licensor who has indicated its wish to receive information about the production.
• Disclaimer of warranties and liability.
• Dispute settlement clause which has been drafted with the aim of safeguarding privileges and immunities of Intergovernmental Organizations

The home of the license can be found at CERN's Open Hardware Repository. The latest version to date is version 1.2 (2013).

Creative Commons Licenses

In particular two Creative Commons (CC) licenses are used to publish hardware documentation as Open Source Hardware: The Attribution (CC BY) and the Attribution-ShareAlike license (CC BY-SA). Other CC licenses are sometimes used to achieve similar purposes but with important restrictions. First there are the CC licenses that include a Non-Commercial restriction (NC). NC restrictions render the documentation incompatible with the four freedoms underlying the Open Source Hardware definition, in particular the freedom zero: the right to use it for any purpose.

Second there are the CC licenses that include a Non-Derivative restriction (ND). ND restrictions render the license non-free or closed as users have no right to make and publish modified versions (freedom 1 and freedom 3).

That said, the two core free licenses, CC BY and CC BY-SA, are much used to publish hardware designs and documentation under a free license, making it efectively Open Source Hardware. The main difference between these two licenses lies in the requirements posed to modified versions: the ShareAlike clause adds the requirement to make modified versions of the work available under the same license terms (or a next version of the license). This makes the license effectively copyleft. And despite the possible doubts whether copyleft licensing in the domain of hardware can be effectively imposed, this is still a much used option. The main advantage of either of these two CC licenses lies in the fact that 1) the CC project is wellknown; 2) it applies to any work of authorship and can be used for documentation, software, design – as long as copyright applies.

Main headlines of CC BY and CC BY-SA:

• Copyrightholder of the license: Creative Commons
• Home: http://creativecommons.org/licenses/
• First version: December 2002
• Basis for protection: copyright and similar rights.
• Explicitly excluded are: moral rights, patent and trademark rights and any right to collect royalties.
• Protection through: a contract that starts when you exercise any right granted to you under the license.
• Applicable to all kinds of hardware documentation but also software, firmware or code.
• Attribution: of authors/licensor(s), a copyright notice.
• Type of licence: in the case of CC BY: permissive, i.e. modified works can be published under different licenses/conditions.
• Type of license: in the case of CC BY-SA: copyleft, i.e. requires to share modifications under the same licence.
• The license waives or agrees not to assert any right to forbid licensees from making technical modifications necessary to circumvent «Effective Technological Measures».
• Disclaimer of warranties and liability: licensed material is offered as-is and as-available.

OHANDA

Trademark law is used to label complying hardware with the OHANDA label. It is not a formal license, but indicates that the hardware labeled with it it is published at the OHANDA website under an accepted free license.

OHANDA, the Open Source Hardware and Design Alliance: http://www.ohanda.org/

GNU General Public License (GPL)

The GPL is the oldest and most used free software license (and open source license for that matter). Although it is specifically designed for software, initially to protect the GNU project (often referred to as Linux or GNU/Linux), it is used considerably for non-software projects also.

It's main headlines:

• Copyrightholder of the license: Free Software Foundation, Inc. <http://fsf.org/>
• Home: https://gnu.org/licenses/gpl.html
• First version: 1989 (unification of previous GNU license variants existing since 1985)
• Basis for protection: copyright over creative expressions, including copyright-like laws that apply to other kinds of works, such as semiconductor masks.
• Patents: contributors grant a non-exclusive, worldwide, royalty-free patent license; licensees may not initiate litigation for patent claims.
• Protection through: a license (not contract) that allows anyone to use it, and conveys further rights to people accepting the license conditions.
• Applicable to: software and other kinds of works.
• Acknowledgement of licensor(s) through copyright and trademark notices.
• Type of licence: copyleft, i.e. requires to share modifications under the same licence.
• No right to forbid circumvention of technological measure (i.e. DRM is forbidden)
• Disclaimer of warranties and liability.

MIT License

• Copyrightholder of the license: the authors of the work
• Home: http://opensource.org/licenses/MIT
• First version: 1988
• Basis for protection: copyright over software and associated documentation.
• Protection through: license
• Applicable explicitly to software and associated documentation
• Acknowledgement of licensor(s) through copyright notices.
• Type of licence: permissive.
• Disclaimer of warranties and liability.

Other License

• Copyrightholder of the license:
• Home:
• First version:
• Basis for protection: copyright over creative expressions.
• Protection through:
• Applicable to all kinds of hardware documentation but also software, firmware or code.
• Acknowledgement of licensor(s) through copyright and trademark notices.
• Type of licence:
• Disclaimer of warranties and liability.

No license

In many cases people publish their work in an open access repository but don't publish any licensing information. This may be due to authors being unaware of the importance or simply because they don't know which license to choose. As the author automatically obtains exclusive copyright over copyrightable expression and the author doesn't state under what conditions others may use his/her work, any rights of the public to those works are rather limited. Fair use exceptions maybe used to have at least the right to copy the work for personal, non-commercial use. However if one would like to modify the work and share that back with the community, first the license conditions of the original work should be clarified.

Sometimes the lack of license information is misused, as at first people may get the impression that the work is shared "openly", while the copyrightholder later decides to apply restrictive conditions.

Further aspects to be detailed:

• About the (im)possibility of copyleft hardware-specific

Introductory and learning materials about hardware licensing:

Some useful materials have been published that maybe reused for course materials on these topics.

• Michael Weinberg

Specialised bibliography

• Desai, D and Magliocca, G. Patents. Meet Napster: 3D Printing and the Digitization of Things. (October, 9 2013) Georgetown Law Journal. Retrieved in October 2014 from URL: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2338067
• Margoni, Thomas (2013). Not for Designers . On the Inadequacies of EU Design Law and How to Fix It. JIPITEC 3, page 225. URL: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2361682 Published under the DPPL.
• Ackermann, John R (2009). Toward Open Source Hardware. In: University of Dayton Law Review. Volume 34 number 2.
• Katz, Andrew (2012). Towards a Functional Licence for Open Hardware. In: International Free and Open Source Software Law Review Vol. 4, Issue 1. URL: http://www.ifosslr.org/ifosslr/article/view/69
• Ayass , Myriam and Serrano, Javier (2012). The CERN Open Hardware License.In: International Free and Open Source Software Law Review Vol. 4, N01 (2012). URL: http://www.ifosslr.org/ifosslr/article/view/65

---