cypherpunk license: PLEASE STEAL ME (Re: GPL & commercial software, the critical distinction) (fwd)

Forwarded message:

> Date: Tue, 29 Sep 1998 01:53:23 +0100
> From: Adam Back <aba@dcs.ex.ac.uk>
> Subject: cypherpunk license: PLEASE STEAL ME (Re: GPL & commercial software, the critical distinction)

> OK, but it would seem to me that to interpret GPL in this way is in
> violation of the spirit (and probably legal intent if interpreted by a
> lawyer).

Actualy this situation is specificaly addressed in the LGPL in regards
header files and how they are the gray area in all this and probably
indefensible in a court (it says this in the LGPL go look...www.gnu.org).
As programmers this is what we want after all, the API to be described so we
can replace those proprietary libraries and programs if we desire.

Actualy you missed the obvious way to distribute commercial code and the
(L)GPL will protect your propietary work....

In both licenses it is very specific in noting that a L/GPL'ed work that is
subsumed in another causes that work to become L/GPL'ed by default. It
further notes that there is NO implication that the use of commercial
code/libraries in a L/GPL'ed work can be construed to L/GPL that proprietary
code.

How I do jobs for my customers is that I develop my programs and libraries I
want to protect via copyright and then distribute them with a set of scripts
and makefiles that during install build the end product. So the end user can
enjoy the privileges of the L/GPL'ed code (ie can fix bugs and relink the
libraries to their hearts content) and I protect my work. The catch is to
make sure the makefiles and scripts are L/GPL'ed. You could even include gcc
or egc on the distribution medium and use it to compile the resultant
without worrying about your commercial code being subsumed. It is quite
commen today for commercial houses to use gcc/egc to develop and distribute
fully commercial code, the catch is that none of the end resultant code can
come from L/GPL'ed sources.

This harks back to my comment earlier today about the GNU/cash system being
a perfect medium for the implimentation of crypto/e$ protocols. The catch is
that you have to be willing to give up your claims to the stubs that must be
placed in the L/GPL'ed product. If you can get away with using named pipes
as buffers and T's then it becomes reasonably trivial to create a situation
where one can inject non-L/GPL'ed code into the stream without the
functional code so injected falling under the L/GPL.


    ____________________________________________________________________

                            The seeker is a finder.

                                     Ancient Persian Proverb

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Jim Choate writes:
> > OK, but it would seem to me that to interpret GPL in this way is in
> > violation of the spirit (and probably legal intent if interpreted by a
> > lawyer).
> 
> Actualy this situation is specificaly addressed in the LGPL in regards
> header files and how they are the gray area in all this and probably
> indefensible in a court (it says this in the LGPL go look...www.gnu.org).

Yes, I know, I have read LGPL a few times, and it does include the
sorts of exceptions you describe.  But I said GPL, and GPL is the
license which I was suggesting causes problems.  As I said, LGPL is
sort of useable.

> Actualy you missed the obvious way to distribute commercial code and the
> (L)GPL will protect your propietary work....
> 
> In both licenses it is very specific in noting that a L/GPL'ed work that is
> subsumed in another causes that work to become L/GPL'ed by default. 

Right, this is the major sticking point for commercial people I find.

> It further notes that there is NO implication that the use of
> commercial code/libraries in a L/GPL'ed work can be construed to
> L/GPL that proprietary code.

Yes, but the more interesting, less restrictive case is where they
really want to modify the code.  cf the example I gave of say adding
pgp5 compatibility to pgp26ui.

I think that if you modify to any significant extent a GPL peice of
software, and try to sell it you could run into problems.  Your legal
bill for trying to work out how bad it is will be expensive.  If the
company is not that bothered about adding crypto, they are going to
see the implications in lawyer hours alone, and give up before they
start.

> How I do jobs for my customers is that I develop my programs and
> libraries I want to protect via copyright and then distribute them
> with a set of scripts and makefiles that during install build the
> end product.

If you want to be creative, you could do what you want to it ignoring
the license, then provide a binary patch from their binary to your
binary.  Or whatever.  Commercial lawyers are cautious animals though,
so because you could theoretically hack around things does not mean
that some company's lawyer is going to recommend that they do it.

Simpler, rather than hack around, and have the additional hurdle to
crypto deployment of many lawyer hours spent wrangling over
implications of GPL and hacks around it, is to discourage use of GPL
for crypto libraries, and software.

> So the end user can enjoy the privileges of the L/GPL'ed code (ie
> can fix bugs and relink the libraries to their hearts content) 

That aspect of LGPL (availability of source) is useful to the extent
that it encourages people to make source of the crypto parts
available.

> It is quite commen today for commercial houses to use gcc/egc to
> develop and distribute fully commercial code, the catch is that none
> of the end resultant code can come from L/GPL'ed sources.

Use of GNU development tools is a different, and more straight forward
issue than using GNU licensed code.

> [hack around GPL problems using pipes]

The point remains: the simplest and best thing to do about licenses if
you are more concerned about crypto deployment than source
availability is not to use GPL, and probably to avoid LGPL also.

Use BSD, use PD, either is better than GPL for the purpose.

Adam