[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hardware license



Walter Landry <wlandry@ucsd.edu> wrote:
> Thomas Uwe Gruettmueller <sloyment@gmx.net> wrote:
> > On Monday 02 December 2002 21:04, Walter Landry wrote:
> > > Rich Walker <rw@shadow.org.uk> wrote:
> > > > http://www.opencores.org/OIPC/OHGPL.shtml.

> > >
> > > The OpenIPCore license is a more of a copyleft, so you'll
> > > probably be happier with it.  Looking through the license, it
> > > looks mostly ok.
> > 
> > There are some points about it that strike me. Maybe I'm 
> > completely wrong about it... 
> > 
> >  1. This license is only a draft. Is it a good idea to use it
> >     already? Future versions could be incompatible with it.

It seems to have been through a discussion period. I am happy when it
has been through this one, as long as my IP guy is happy with it. 

> >  2. Is this license GPL compatible? In the future, digital
> >     devices will propably use the GPLed F-CPU, so this might be
> >     a big problem, then. 
> 
> I don't think that it is GPL compatible.

I need this to be clarified, as it's a fundamental point. If a piece of
hardware is placed under an OHGPL license, and someone wants to use a
piece of GPL'd hardware or software, how are the licenses incompatible?
For example: 
    can't cut-and-paste design chunks from one to the other
    can't connect outputs of one to inputs of the other
    can't drive OHGPL hardware from GPL code

> 
> >  3. AFAIK, the copyleft in the GPL is not strong enough to
> >     prevent that a chip that has been built from a GPLed design
> >     is bought by a non-licensee, and resold, soldered into a
> >     non-free circuit. This is like creating a non-free artwork 
> >     out of Debian CDs, but far more severe. I am not sure if
> >     there is a possible strategy about this at all, and what the
> >     OHGPL is doing about this.
> 
> It is basically impossible to do what you want. 

Actually, it's silly to. This would be like (for example) BlueTie
forbidding system vendors from providing a purchased boxed set of
BlueTie GNU/Linux Deluxe with a built system. Kind of defeats the point
of making the boxed set in the first place. The thing you want to
prevent is them shipping the system without letting the customer know
that it's using BlueTie v 145.22.woody or whatever. Both licenses do
this, but the OHGPL is a little more appropriate to generating
things-that-are-physical. 

> When you sell a
> person a physical thing, they automatically gain certain rights.  They
> are free to do modify the thing however they want and then resell it.
> This is part of the basic consumer guarantees that you get when you
> buy something (at least in 49 states in the US).
> 
> >  4. I can't find the phrase that allows distribution of a
> >     modified version. 
> 
> Oops.  You're right.  You can fix this by changing paragraph 2 from 
> 
>   2. You may copy, distribute and/or implement ...
> 
> to
> 
>   2. You may copy, modify, distribute and/or implement ...

okay.

> 
> >  5. Paragraph 3, which forbids selling but allows a fee OTOH,
> >     seems to be against the wording of DFSG 1. Is there a
> >     license that has been classified DFSG-free which uses a
> >     similar wording?
> 
> This is fine.  There are other licenses that don't allow selling the
> software per se.  The DFSG only requires the ability to sell it as
> part of an aggregate software distribution.  It does make it GPL
> incompatible, though.

I thought DFSG-1 was to prevent the "You must pay us $0.01 if you sell a
copy of this"; Certainly, I think, 3 is compatible with DFSG-1.

> 
> Regards,
> Walter Landry
> wlandry@ucsd.edu
> 
> 
> 
> 



Reply to: