Message 05934 [Homepage] [Navigation]
Thread: oxenT05933 Message: 2/2 L1 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[ox-en] Re: [ox-en] The Tricky Business of “Copylefting” Hardware

A couple of practical points re chip manufacture; I've been told (by
people who should know, but this is till second hand) two things:

- companies manufacturing hardware will officially avoid using any
designs with any variety of copyleft just because the legal status is so
undefined [there are circumstances in which this is not true - see below]

- in practice many engineers ignore this and cannibalize free designs
without acknowledgement, relying on the difficulty of proving it. End
result is that a large part of the hardware around now is actually based
on free designs, but no-one knows

- current practice in the hardware industry is always to use as many
different varieties of IP law for protection as possible; the tangle is
deliberate, not accidental. They actively don't want a clear-cut situation.

Having said all that, there are examples of free hardware designs in
production under both bsd-style and gpl licences (ie with a nominal
assumption that copyright governs). The most important gpl examples (the
SPARC varieties) are only possible because Sun always relinquished its
right to enforce the other IP rights over the SPARC.

And a more logical point: software has source code and executable code,
with maybe object code in the middle - but no-one pays any attention to
that nowadays as compilers are so efficient. Hardware design may have
more stages, each needing human intervention and ingenuity; it's not so
simple as 'design' versus 'hardware'. A circuit diagram does not
automatically generate a usable mask layout; and each stage may have
different implications wrt 'IP' law.

My own conclusion (which I've never followed through) is that copyleft
equivalents won't be found by looking for an answer for 'hardware' in
general, but by working out separate solutions for separate fields. FPGA
designs are the simplest case, circuit boards intermediate, ICs hardest.
And electronics is different from dress design, or furniture design.

The alternative is to give up on copyleft and go for PD. For a long time
I didn't like this answer. But I'm currently involved with open street
map, and there is a parallel situation there: current license is
CC-BY-SA, which is legally invalid for data (though IMO not at all
socially invalid). Now there is an attempt to create a copyleft
situation using a new license for data with a real mix of legal bases.
IMO this creates a great field for lawyers but weakens the involvement
of the community, and it's noticeable that in informal polls a very
large proportion of contributors are saying they will make their own
data PD in preference. I'm also starting to swing towards PD in this case.


Christian Siefkes wrote:
[For links, see the web version: ]

It’s probably safe to say that the copyleft principle has been essential
for the success of free software. Copyleft means that all versions of a
software or document will remain free, preventing companies from creating
“value-added” versions of free programs and selling them as proprietary,
non-free software. The GNU General Public License (GPL)—the first and most
well-known incorporation of the copyleft principle—is used for about 50–70%
of all free programs, making it more popular than all other free software
licenses together.

At first sight, the situation in the newly emerging field of free and open
hardware might seem similar—here, copyleft licenses such as the GPL and the
Creative Commons Attribution-ShareAlike License (BY-SA) are very popular
too (see below for a more detailed analysis). But actually, the situation
is very different for hardware design, since copyleft relies on copyright,
and hardware is (in most cases) not protected by copyright law.

The Problem: Copyleft Depends on Copyright

In hardware design, the copyleft clauses of the GPL and the CC BY-SA
license thus don’t work in the way you might expect them to work. Anybody
who modifies and spreads the design description is bound by them, but
people and companies using the design to build and distribute actual
hardware are not. Vendors can modify the hardware and sell or distribute
the modified hardware without having to publish their modified design,
since licenses only govern the design descriptions (the instructions on how
to build the hardware), not the hardware itself. Here’s how the FSF puts it
in their GPL FAQ:

    Can I use the GPL to license hardware?

    Any material that can be copyrighted can be licensed under the GPL.
    GPLv3 can also be used to license materials covered by other
    copyright-like laws, such as semiconductor masks. So, as an example,
    you can release a drawing of a hardware design under the GPL. However,
    if someone used that information to create physical hardware, they
    would have no license obligations when distributing or selling that
    device: it falls outside the scope of copyright and thus the GPL

The problem is that copyright governs only the distribution of information,
but not its usage. If somebody has access to information, they can use them
and act upon them in any way they like without violating copyright law.

If a bookseller publishes a book describing how to build a product X, the
bookseller cannot prevent me from using this information to build and sell
X. The book is protected by copyright laws, but the factual information
contained in it is not, and my use of that factual information falls
outside of copyright laws. The GPL relaxes the restrictions of copyright,
giving me more freedom to use copyrighted information than I would usually
have, but of course it cannot deny me the freedoms which I always have,
even with full copyright in force.

A Solution: Patents?

I know of only one license that is specifically targeted at open hardware
and tries to work around this issue by relying not only on copyright, but
also on a mutual patent immunity clause: the TAPR Open Hardware License,
published in May 2007 (Version 1.0). The idea is that the licensor grants
everybody who complies with the terms of the license the right to use any
relevant patents they control. So if you don’t comply (e.g. by not
publishing the “source” for physical products you build based on the
licensed information), you might get sued by the licensor for patent
violation, but if you comply you’re safe.

TAPR has published two versions of the license: the Open Hardware License
(OHL), which emulates standard copyleft (like the GPL or CC BY-SA), and the
TAPR Noncommercial Hardware License (NCL), which additionally prohibits
commercial usage (like the CC BY-NC-SA).

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.

The TAPR licenses will only be really effective if the licensor possesses
relevant patents, or at least if people can’t be entirely sure that (s)he
doesn’t have any such patents. That’s a pretty bad limitation, since
patents are difficult and expensive to get. Most peer projects will be
unable or unwilling to apply for a patent, so the TAPR licenses will hardly
be suitable for them.

Another unrelated problem of the TAPR licenses is that they require you to
distribute the original designs you’ve received from others in addition to
your own modified version—you must distribute both “before” and “after”
versions of any files you’ve modified (§ 4.2 (b)). This might be extremely
impractical for large version histories (think of hundreds or thousands of
versions), and it makes the creation of printed versions of modified
hardware documentation practically impossible. It’s also unclear what’s the
point of this requirement.

Pragmatic Solutions: Just Use Standard Copyleft—Or No Copyleft Altogether

Most open hardware projects seem to care little about the specific issues
of hardware licensing. Most projects aiming for copyleft just apply a
standard license such as the GNU GPL or the Creative Commons BY-SA license,
apparently either not knowing or not caring that is won’t apply to building
hardware (see list of projects below).

Another solution is to forgo copyleft altogether and just use a permissive
license such as the (modified) BSD license. This allows everybody to use
the provided information in any way they like, without having to keep
modifications or improvements open.

There even is a hardware-specific non-copyleft license, the Balloon
Licence. The Balloon Licence is a simple MIT-style license. Since it does
not try to apply any restrictions on the manufacturing of hardware (no
copyleft or non-commercial clause), it doesn’t have the problems of other
open hardware licenses. However, since this license is very similar to the
commonly used MIT and (modified) BSD licenses and doesn’t address any new
issues, there seems to be little reason to choose this special license
instead of one of the standard ones.

What To Do?

As can be seen from the list below, there is a clear tendency of projects
to use standard copyleft (the GPL or the CC BY-SA), protecting the design
information itself but not any physical hardware built on their basis. Does
this mean that projects are willing to live with a limited copyleft, or are
they just unaware of the problem? I’m not so sure…

In any case, no convincing solutions seem to exist. The TAPR license, the
only license that tries the address the problem of extending copyleft to
the hardware itself, never became very popular—almost nobody outside the
TAPR project seems to be using it. And indeed, its reliance on patent law
makes the license very impractical to use for all but the biggest projects.

On the other hand, just using permissive licenses (like the Apache projects
and the BSD family do) doesn’t seem to be an attractive option for the
majority of open hardware projects—most prefer to get at least the partial
copyleft protection that standard licenses such as the GPL and CC BY-SA can
give them.

But, as described above, their copyleft protection is very incomplete in
case of hardware—hardware builders aren’t required to give back their
improvements. In the case of the RONJA project, this difference between
hardware builders not giving back but the project maintainers expecting
them to do so, has already caused tensions that contributed to the downfall
of the project. Whether similar problems will appear in other projects and
weaken the open hardware community, remains to be seen...

                                  * * *

Appendix: Project Listing

The following projects use standard copyleft licenses:

* GPL:

  - Bug Labs, modular open source computer hardware (cf. Bug Labs: License)
  - Elphel, high performance cameras based on free software and hardware
    designs (cf. About Elphel)
  - RepRap, an open source fabber (cf. RepRap GPL Licence)
  - Sun’s OpenSPARC project, publishes free hardware designs for the
    UltraSPARC T1 and T2 processors
  - Free Telephony Project

* CC Attribution-ShareAlike:

  - Arduino (cf. Arduino Hardware) and Freeduino (cf. Freeduino PCB Design
    Files), two variants of a free microcontroller board. They are aware
    that the CC clauses don’t apply to physical production: “You don’t need
    to give attribution on the physical products that you might make with
    these files, as copyright in general, and CC2.5 in particular, do not
    apply to physical objects.”
  - Beagle Board, a free low-cost computer board based on a Texas
    Instruments processor
  - MultiMachine, a low-cost multi-purpose machine that can be built with
    common hand tools
  - Openmoko, open source mobile phones (uses BY-SA for CAD Files and

* GNU Free Documentation License:

  - Ronja, optical data transmission (cf. Ronja Copying)

Projects using a standard share-alike license that prohibits commercial
usage (CC Attribution-Noncommercial-ShareAlike):

* Ronen Kadushin, free furniture designs

Projects supporting various Creative Commons license:

* Open Architecture Network, a repository of architectural designs and
  plans; users can choose any CC license, including public domain (cf. OAN
* Thingiverse, a repository of digital designs for physical objects; users
  choose either standard copyright or a CC license, GPL and public domain
  are also supported (cf. Thingiverse Terms of Services)
* Ponoko, a repository and marketplace for digital fabrication; available
  choices are full copyright and Creative Commons licenses (list of
  CC-licensed designs)

Projects using the TAPR Open Hardware License, a share-alike license
designed specifically for hardware which relies on patent rather than
copyright law:

* TAPR, the community of radio amateurs which developed that license

Projects dual-licensing between TAPR License and standard copyleft:

* Open Graphics Project, open source graphics cards; three license
  alternatives for its hardware descriptions (schematics and artwork): GPL,
  TAPR License, or a commercial proprietary license, cf. OGP FAQ and
  Announcement from 7 April 2009. Of course, dual/triple-licensing with
  TAPR as one of several options makes the special protections of the TAPR
  License void (users can just choose the GPL instead), so this
  multi-licensing model seems somewhat pointless.

Projects using a non-share-alike license specifically developed for
hardware (the Balloon Licence):

* Balloon Project, another circuit board (only parts of the design are
  free, some design files are kept proprietary)

Projects using a standard non-copyleft license (the BSD license):

* Fab Home, another project for building an open source fabber (cf.
  Fab Home: General disclaimer)


* OpenCores, develops computer components for CPUs, memory controllers,
  peripherals, motherboards etc.; uses a mix of GPL or (preferably) LGPL
  and modified BSD license, depending on the preferences of the
  contributors (OpenCores FAQ)

If I have forgotten important projects, add them in a comment and I’ll
update the article. I didn’t try to cover projects that are small or in
early development. Long lists of open hardware projects can be found in the
Wikipedia article on open source hardware, the P2P Foundation’s Product
Hacking page, the Open Innovation Projects site, the GOSH List of Open
Hardware Projects and the GOSH List of Open Hardware Organizations.

Best regards

Contact: projekt

Thread: oxenT05933 Message: 2/2 L1 [In index]
Message 05934 [Homepage] [Navigation]