[ohf-licenses] ohf-licenses Digest, Vol 1, Issue 1

[Terry Hancock]

Greg London wrote:
> I've been pondering this a bit more. It occurred to me that
> the problem can be fairly nicely boiled down into a simple
> set diagram consisting of just three circles or three sets.
> 
> I drew it up and posted it on my home page here:
> http://www.greglondon.com/openhw/OpenHardwareConundrum.pdf

The transparency didn't work too well. I'm attaching an SVG of just the
Venn diagram. Which will also be easier to edit. It's an Inkscape SVG, BTW.

> It's a one page PDF, licensed BY-SA, so feel free to pass
> it around. I think it explains fairly simply what something
> like GNU-GPL does and explains why it is likely insufficient
> for an open hardware community where the contributers have
> some expectation of their contributions remaining open.
> 
> The Achilles heal is that once you convert Verilog to silicon,
> it is no longer a copyright-derivative, therefore GNU-GPL no
> longer applies, and therefore no longer protects.

This may actually be an exception, since there is a "mask right", at
least in the US, which the GPLv3 appears to invoke as a "copyright-like"
right. But in general, I agree.

> The GPL's source code requirement prevents people from
> creating derivatives and keeping them private by distributing
> only an executable.

Right.

> The GPL's anti-tivo clause prevents
> functionality that prohibits only certain derivatives/executables
> from beign executed.

I'm not really sure what this means in the case of a hardware device.

My guess is that it is toothless, because there's no way to "Tivoize" a
hardware design -- if you're going to make the hardware you have the
power to remove any such devices.

The Tivoization problem only makes sense from the point of a software
developer who can't re-create the hardware. They are stuck with the
hardware as it is, and if it contains some hidden key mechanism, they
can't get at it to change it.

> I think what is needed is a license the protects everything
> exactly as the GNU-GPL does, plus, treats an asic built from
> open hardware source code as a sort of "executable" that
> requires the source code to be made available under the same
> license as the original.

Actually, my investigation into this suggests that this isn't really
what you want, because the burden of distribution could become quite
painful (at least as bad as the old BSD advertising clause).

Consider what happens if you OEM-package a million $2 chips. Such a
requirement will force you to pack a disk with each one, containing the
verilog source. Or to print (a very, very tiny?!) promise to deliver the
source on each chip.

The resulting distribution costs might well *double* the cost of the
chip. If the chips are sold on a roll for automatic assembly, must a
CD-ROM be included for *each* chip. If a user receives an assembly made
of 50 different OH chips, does he get a disk for each one? Or does the
integrator have to copy the files from each upstream disk onto a single
disk for distribution.

I just don't think the GPL language fits the hardware very well, so I
think a new set of rules will be desirable.

Some sort of URL mechanism and/or online registries of open hardware
designs would be better, I think.

OTOH, *requiring* a registry method violates the "dissident" and "desert
island" tests that some advocates (<ahem>, Debian), regard as essential.
So, I'd propose instead that the registry is an optional solution, with
a more GPL-like distribution of source as an option.

Note that for the more extreme opinions out there, NO hard copyleft will
be acceptable, because they will regard ANY hard copyleft as a "use"
restriction -- since it "restricts" behavior outside of what is
considered "copying" for the purposes of copyright law. I personally
think this is bogus, but it is internally consistent.

This is the kind of thinking that leads to the conclusion that CC's
existing "anti-TPM distribution" clause is "non-free", because
"distributing works in TPM form" is a "use" of the work (even though it
clearly interferes with the end users' rights that free licenses are
intended to preserve, IMHO).

I disagree on the basis that ANY form of copying is a "use" (even those
forbidden by copyright law), but that's not what "no use restrictions"
is intended to mean! But this opinion is out there. I just think that NO
hardware copyleft will satisfy these folks, so we should simply ignore
them, and accept the reality.

> Anyway, I figure the best place to start is to try and
> describe the problem as succinctly as possible, which I
> believe the one-page PDF at the above URL takes a decent
> swipe at. Then get agreement that, yes, that describes
> the situation. And then hopefully the solution is a natural
> outcome from there.

Well, I think you did a pretty nice job of that, thanks!

Cheers,
Terry

-- 
Terry Hancock (hancock at AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com