[Discuss] Publish OSHW with CC0?

Andrew Katz Andrew.Katz at moorcrofts.com
Wed Nov 5 14:28:49 UTC 2014


Hi Roy


On 5 Nov 2014, at 13:30, Roy Nielsen <amrset at gmail.com<mailto:amrset at gmail.com>> wrote:

Hello,

Maybe it's time for a group of people to go to lawmakers to create copyleft law(s) that balance out the closed nature of patent law.  Or work on changing patent law to have copyleft provisions.

We’ve thought about this extensively, and the big problem is that any mechanism (such as a much-easier-to-obtain patent) which facilitates hardware copyleft, also has the extremely undesirable consequence of making proprietary companies more easily able to lock a huge amount of hardware designs away from the commons. That will immediately increase barriers to entry for all participants enormously. It’s difficult to see what the overall benefit would be.

Copyleft in hardware (especially the designs) is a nice-to-have, but it’s not worth creating much worse problems in an effort to solve it.

I’d also disagree slightly, (and unusually!) with Javier:


On Wed, Nov 5, 2014 at 5:31 AM, Javier Serrano <Javier.Serrano at cern.ch<mailto:Javier.Serrano at cern.ch>> wrote:
On 11/05/2014 01:05 PM, Wouter Tebbens wrote:

> But replicating copyleft in hardware is clearly much harder as Alicia
> says. Copyright based licenses may apply to documentation, design files
> etc, but do not prevent people to reuse that information in
> non-free/-open hardware, as the hardware itself is not protected.

This is exactly the same in free software. I can take ideas from the
source code of emacs and write my own proprietary editor. Because the
task for writing an editor from scratch is not trivial, I will think
twice and probably decide to contribute whatever new feature I want to
emacs itself. The power of copyleft grows with the complexity of the
sources it protects, and is nearly zero for trivial work. The same
happens with hardware. While hardware is definitely different from
software, I think there is a large family of hardware (that manufactured
from copyrightable design files) where this difference is not so big.

There is (at least) one respect in which the non-copyrightability of
hardware leads to an undesirable outcome, and that is our inability to
fully guarantee that, under all circumstances, should the original
designer wish so, recipients of open hardware always get access to the
design files. Copyleft does that for software: if you get the binary you
can always have access to the sources.

This is a subtle but important point. The FSF has been clear that nothing in the GPL compels anyone to release their sources. Of course, if you fail to do so in accordance with the GPL, you are in breach of the underlying copyright and therefore potentially have a copyright infringement claim against you (as well as losing your rights under the GPL for that code in the first place), so the consequences are pretty severe, but you do not HAVE to give up your source code, even though there is a very large incentive to do so. This is apparently (according to Eben Moglen, IIRC) by design, one point being that any other outcome means that a violator can have potential claims from all recipients, rather than just the copyright holder(s). Maybe there’s an argument to say that this should be different in the world of hardware (given that hardware licences have much less opportunity to impinge than copyright licences, so their power should be multiplied by increasing the number of potential claimants, rather than the number of potential bite-points - to be honest I’ve only just thought of this). Note that this argument only holds where the GPL is properly construed as a bare licence. It’s on much shakier ground in civil law jurisdictions, for example.


We did our best in CERN OHL v1.2
using the concept of "Documentation Location Notice", inspired by Eli
Greenbaum's paper on 3D-printing [1], but I am very interested in any
other ways of tackling this important problem, hopefully not involving
patents.

Yes indeed, Javier.

Best


Andrew




More information about the discuss mailing list