Open Hardware Licensing


As mentioned in a recent blog post about the CERN Open
Hardware license, Octopart makes use of many Free and Open Source Software projects
and is interested in the unfolding world of Open Hardware electronics. In this
post we explore the scope of hardware licensing and some of the specific new
licenses that are in use.

Keep in mind that we are not lawyers and are not giving specific legal advice; if you have any corrections or concerns please post in the comments below!

The primary goal of both open source hardware and open source software licensing is to allow users, engineers, and companies to “stand on each other’s shoulders
instead of on each other’s shoes” by protecting their mutual rights to inspect, share, modify, and re-distribute their creations. It has taken decades to harmonize this ideal with legal frameworks and practical economics in the software industry, but with much of the internet and many consumer devices
running on free and open source software (or at least based on open source components), the movement can be considered a success. Sharing hardware is a lot different from software (for one thing copying hardware currently costs a lot more), but that does not prevent electrical engineers from sharing design files and documentation the same way programmers do.

Software licenses are generally enforced under domestic and international
copyright law protecting the textual source code itself, and legal precedent
has supported the validity of this model. Some larger companies controversially choose to pursue software patents covering specific algorithms, codecs, or even business practices, but copyright coupled with an end user license agreement or free/open license is enough protection for most organizations and individuals who are trying to enforce commercial, share-alike, or attribution license terms.
Hardware designs have the potential to cover much more than source code
files, and it is an open question whether copyright will be enough to protect all
parts of any given design or whether patent law or other more creative mechanisms will have to be leveraged as well (most existing open hardware licenses cover any patents rights associated with the design as well as the copyright on any source or design files).

Copyright covers the functional content of source code quite well: for example, if you manually type in
source code read from a textbook with small changes to the indenting, the original copyright will still cover this new representation of the code.
On the other hand, if you sketch the layout of a two sided circuit board (with the solder mask removed) into a board layout tool, you can likely do whatever you like with your new representation of the design, unless there is a patent on the behavior of the circuit itself. Then again, if you tried to do the same thing with a microprocessor, scanning in the etched silicon with an electron microscope, you would run afoul of specific international copyright restrictions on chip mask works. Here is a full breakdown of some of the “layers” that a hardware design might include, and the legal mechanisms used to protect them:

Mechanical Layer:
covering the physical design of a device, including 3D models, design drawings,
CAD files, part lists, and instructions for fabrication and assembly. Potentially
covered under patent law, or even trademark in the case of fashion or form.
With the advent of rapid prototyping tools, interest in licensing machine-readable source files for mechanical designs
is growing, and there have even been recent (failed) attempts at legal action
concerning simple geometric shapes.

Silicon Layer:
wafer masks, netlists, and hardware description language code describing
integrated circuit design. The overhead of IC fabrication and economies of
scale mean that there have been few open source IC projects to date (though
there have been a few), but as costs come down we might see more action in this
space. The line between silicon (“ASIC”) designs and FPGA or CPLD firmware is
blurry and potentially interchangeable for purely digital designs (see below). Mask works (engineering “blueprints”) can be covered under international copyright.

Schematic and Layout Layers:
circuit schematics, netlists, layout, bill of materials, and Gerber files.
In most electronics designs the schematic and final PCB layout are tightly
coupled, but often implemented by different people so the two layers are
considered separately. This is the area where most new licensing attention has
been focused. The individual “representations” or “expressions” (images, text files) of this layer can be
covered under copyright, but the “content” or “idea” (aka, the actual circuit or layout) can not be, and could only be protected by patent. To make things even more complicated, most design tools use their own proprietary binary file formats, which makes sharing and comparing designs at this level difficult.

Firmware Layer:
hardware-specific code such as device drivers, initialization code, linker
scripts, FPGA code, and some libraries. More likely to be distributed in
compiled or binary formats than higher level software. Even in the
desktop/server open source software world this is a gray area, with many
distributions of Linux bundling “binary blob” video drivers. When source is
open it is usually released under existing software licenses and enforced by
copyright law; when closed, regulations like the Digital Millennium Copyright Act
restrict reverse engineering the behavior of firmware. License terms could potentially restrict the use of firmware to particular hardware architectures or devices.

Software Layer:
relatively platform-independent code such as operating systems, interpreters,
and application code. Legal enforcement by copyright, generally released under
existing “FOSS” software licenses with no restriction on hardware.

Documentation:
written manuals, design notes, flowcharts, datasheets, and functional
descriptions. Covered by copyright and often released under either a broad
Creative Commons license or under special-purpose licenses like the Free Documentation License.

Branding:
encompassing trade names, logos, web domains, communities, etc. Legally covered
under trademark law. Almost all open hardware and software licenses at every
level require some form of attribution back to the original creator, which could be thought of as free advertising for the project.

Here is a comparison table of existing hardware licenses which have been
applied to the schematic/layout layer, showing the diversity of approaches to
the problem:

Name

Year

Mechanism

OSHW Definition?

Attribution?

Copyleft?

Commercial?

Notes


CERN OHL 1.1

2011

Patent, Copyright

Yes

Yes

Yes

Yes

Notification and updates to changes.txt required


TAPR 1.0

2007

Patent, Copyright

Yes

Yes

Yes

Yes

Notification, updates to changes.txt, before/after copies, and manufacturing files required


GPLv3

2007

Patent, Copyright

Yes

Yes

Yes

Yes


SGPL

2000

Unspecified

No

Yes

Yes

No

$$$ to manufacture


Chumby HDK

2007

Patent, Copyright

No

No

N/A

No


CreativeCommons 3.0

2007

Copyright

Depends

Opt. (BY)

Opt. (SA)

Opt. (NC)


Balloon

2003

Attribution only

No

Yes

No

Yes

Manufacturing files only, no editable source

And here are some existing hardware projects under these licenses:

  • Multiple CERN projects under the CERN OHL, including White Rabbit and SPEC
  • The RHINO project from the University of Cape Town under the TAPR license
  • The Arduino development board designs under a Creative Commons Attribution Share-Alike license
  • Many OpenCores designs under the LGPL license, including the OpenRISC ASIC
  • The OpenSparc CPU under the GPL license
  • The RepRap and Makerbot 3D printer electronics under the GPL license
  • The Chumby devices under the Chumby HDK
  • Camera computers from Elphel under the GPL license
  • The Open Graphics Project’s OGD1 video card design under TAPR (firmware under GPL)

Personally, I hope to see more open textual file formats for every level of
hardware design and to see open projects grow larger, such that the difference
between copyrighted source materials and the ephemeral “design” of an object
becomes unimportant; for example, the OpenSPARC CPU project is probably safe
from proprietary duplication for the same reason that the Linux, GCC, and
Apache projects are: most of the value is in the testing, community, compatibility, and availability of the specific open implementation. That doesn’t stop anybody
from trying to create compatible proprietary clones to capitalize on the
successes of these projects, but historically the effort has not been worth it.
For a small project like the TV-Be-Gone (which was aggressively duplicated) or
an RSS reader (of which there are many similar open and closed implementations)
reimplementation is easy and copyright does not cover the “idea” of the device/application. Licenses protecting the openness of the
later projects will likely be very difficult, and realistically creators
should just protect their brand with trademarks.

We hope you’ll think about releasing your next Big Hairy Audacious Electronics Project under an open license. We welcome comments below or via email, and will be in person at the Open Hardware Summit in NYC on September 15th. You might also find these background links informative:

Corrections: Version 3 of the GPL does cover patent rights, the CERN license does not require old versions of design files to be bundled with new modifications (thanks Phillip Torrone!), and the RHINO project is actually based out of the University of Cape Town and is under the TAPR license (thanks Javier Serrano!).

I have also posted a more complete spreadsheet of licenses on Google docs.