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

Sun Dec 2 00:04:28 EST 2007

> 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.

The original is also there, an open office document.
Same name but a .odt extension.
For those who want to fiddle with the original.

> 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.

Masks aren't silicon, though. I probably should have put them in,
but they don't actually protect silicon.

>> 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.

Nothing to do with hardware, but showing how the GNU-GPL expands control
from the original source into the various other areas in the diagram.

> 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).

Sorry. getting sloppy with my language. I meant simply that some mechanism
is needed to require the source be made available some how, via some
channel, for an asic. Our high end chips cost something like $12. Adding
$2 a pop for a source disk would be fatal when your trying to sell million
chip contracts.

I don't have a problem with some sort of web based broadcast or some
similar channel that has little overhead. Just guarantee it doesn't get
abused.

> 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.

Well, it depends on where you start. GPL is consistent. If you look at the
set diagram, if you were to use a plain Public Domain style license, every
boundary you cross would be a potential one-way door.  Make a derivitive?
You can take it into ALl Rights Reserved. Distribute a binary? You can
prevent reverse engineering.  Patent your software? You can prevent anyone
else from coding up your functionality. Tivo-ize your hardware? You
prevent anything other than your derivatives from running on your
hardware.

The GNU-GPL effectively prohibits these one-way transactions, and does so
with regard to *every* field on the diagram. Doesn't matter what boundary
you cross, if you take GNU-GPL code into that area, you must make your
source code available under the GNU-GPL license. End of story.

Various other factions have declared that certain areas should be allowed
as one-way trap doors. CC-SA doesn't have a source code requirement,
meaning if you distribute a binary, you can use it as a way to avoid
having to distribute your source code. (CC discourages using SA for
software, but there are various "source" files even for multimedia
projects.)

Some folks vehemently oppose anti-tivo or anti-DRM clauses. That's their
choice. But what it means on that diagram is that there is a one-way door
that people can take the source code and prevent the community from
following.

Some argue that its better to allow proprietary forks in these areas,
because it encourages companies like Tivo to use Linux, or it encourages
companies like DRM-Downloads to use debian works. And folks argue that the
existence of these works benefit users.

The thing is these works don't actually benefit the *contributers*, the
poeple who actually contribute their time and effort to create code.
GNU-GPL is all about protecting the contributers, making sure that their
contributions, and any derivative or modification thereof, are always
available to them via the GNU-GPL.

Users don't give a rats behind that some contributers created some new
thing, and some third party made a proprietary fork. Contributers do.

And I think that Open Hardware should protect the contributers first,
users second. The GNU-GPL has the same priority protecting the
contributers, the community that maintains the code, first and foremost.

Obviously, users would benefit greatly if some company like Microsoft
could make proprietary forks of Linux. Suddenly all this new software
would be available, windows would be much more reliable, and maybe Vista
would be secure.

But that would mean that all the *contributers* would be left out in the
cold. These contributers who actually donated their time and energy ended
up having their work taken from them, turned into a proprietary fork, and
made into some derivative that competes against the community that created
it.

Users will be thrilled by the new functionality available to them.
Contributers will be less than thrilled seeing their works taken into
proprietary forks and competeing against the public version.

I think the Open Hardware license should protect the *contributers* first
and foremost, and if that means the *users* don't get the benefit that
comes from proprietary forks that compete against the community verison,
so be it.

So, I'd favor a strong copyleft. Something similar in approach to the
GNU-GPL, something that allows people to take the work into the different
fields in the set diagram, but puts two-way doors in place to prevent any
arena from being a proprietary advantage.

> 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
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 01 Dec 2007 14:47:08 -0600
> From: Terry Hancock <hancock at anansispaceworks.com>
> Subject: Re: [ohf-licenses] ohf-licenses Digest, Vol 1, Issue 1
> To: ohf-licenses at openhardwarefoundation.org
> Message-ID: <4751C84C.3030500 at anansispaceworks.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Terry Hancock wrote:
>> 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.
>
> Okay, this time, for real. :-)
>
> Cheers,
> Terry
>
>
> --
> Terry Hancock (hancock at AnansiSpaceworks.com)
> Anansi Spaceworks http://www.AnansiSpaceworks.com
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenHardwareConundrum_Diagram.svg
> Type: image/svg+xml
> Size: 16058 bytes
> Desc: not available
> Url :
> http://mail.openhardwarefoundation.org/pipermail/ohf-licenses_openhardwarefoundation.org/attachments/20071201/2853d9f7/attachment.bin
>
> ------------------------------
>
> _______________________________________________
> ohf-licenses mailing list
> ohf-licenses at openhardwarefoundation.org
> http://mail.openhardwarefoundation.org/mailman/listinfo/ohf-licenses_openhardwarefoundation.org
>
>
> End of ohf-licenses Digest, Vol 2, Issue 2
> ******************************************
>

-- 