LGPL and SqueakMap

Andrew C. Greenberg werdna at mucow.com
Thu Dec 26 17:58:41 UTC 2002


On Thursday, December 26, 2002, at 09:55 AM, Stephen Pair wrote:

> Andrew Greenberg wrote:
>
>>> Objective-C has exactly the same issue, and there doesn't seem to be
>>> any confusion with it and LGPL.
>>
>> Fundamental differences between Objective-C code and Smalltalk is the
>> presence of the monolithic image.
>
> But that issue is a non issue if you don't use images to distribute 
> your
> Smalltalk code, correct?

This depends on your definition of a "non issue." :-)  From a legal 
perspective, this is a mire -- a disaster waiting to happen.  I believe 
that widespread, and particularly casual, mixed licensing will kill 
Squeak -- that's my concern.  I do not believe that I exaggerate.   I 
believe, by the way, that as others have written, the present status of 
Squeak is tenuous enough as is, and that until we have resolved that 
issue, consensus to permit mixed licensing will be bad for the 
community.  This has been my legal conclusion for some time, which I 
have revisited periodically.  In the interest of full disclosure, I do 
share Alan's ideological opposition to actually highly restrictive 
licenses that are denominated as "free" -- but this isn't the point 
about which I am concerned.

Stephen recognizes that substantial difficulties will arise from 
distribution of mixed images, and cleverly, but probably incorrectly, 
considers that the non-distribution of code through a monolithic image 
may solve the problem.  First, RMS has taken the position that, except 
for certain precise exceptions, where a mixture of components and 
subsequent distribution would violate LGPL, the independent 
distribution of components for assembly likewise violates.  Even if he 
is incorrect (and this is legally controvertible, as are many of the 
non-textual "positions" RMS has taken), it is error to presume that 
common "uses" of Smalltalk images, once cojoined with mixed code, does 
not violate a license, or even if it doesn't violate a license 
restriction, that the conduct, because not expressly permitted, would 
not violate the Copyright Act.  Moreover, we do not concern ourselves 
only with satisfying LGPL, but must also concern ourselves with 
satisfying Squeak-L or other license.  It is precisely here, where a 
piece of code formerly Squeak-L'd calls or is called by a piece of code 
presently LGPL'd, that we must worry about violations.  (N.B.: I am no 
passionate fan of Squeak-L either -- but it is far less restrictive 
than GPL and is also less restrictive than LGPL).
Ordinary use of software generally constitutes "reproduction" within 
the meaning of the Copyright Act.  Modern sharing of software through 
networks or by other means constiutes "distribution."  Absent an 
express license, any conduct along these lines invades the exclusive 
rights under U.S. law, at least, of section 106.

Ambiguity or uncertainty as to what can be done with code is the enemy 
here -- that the most common and desired uses are possible areas for 
legal dispute.  Given that we conceive of ourselves as cutting edge and 
evolving into the next universe of possibilities, to adopt any 
restrictions of any kind is a nightmare.  Limitations on how we 
"distribute" our code is a bar to ongoing development, and will create 
deep and bad karma at the end of the day.

>> There are no libraries in Smalltalk.  There are images of objects.
>
> I suppose that depends on how you define a library.  If a library is
> nothing more than some unit of code that can be used by other units of
> code, then sure, Smalltalk does have libraries.
>
> The LGPL defines "library" as such:
>
>  A "library" means a collection of software functions and/or data
> prepared so as to be conveniently linked with application programs
> (which use some of those functions and data) to form executables.
>
> But the LGPL's use of the term would imply that they were intending to
> apply it to C libraries.  I would liken change sets to libraries, and
> images to executables if I were attempting to apply the LGPL to
> Smalltalk code.  But given that the LGPL was not written with Smalltalk
> code in mind, I wouldn't consider using it.  I would either: a) attempt
> to generalize the wording of the LGPL, or b) write an entirely new
> license that accomplishes what I am after.
>
> What would be useful (I think) is a license that talks in terms of
> general concepts such as units of software code, direct translation of
> that code into alternate forms (i.e. machine code), re-use by other
> units of code, re-distribution in source and/or translated form, etc.

Both GPL and LGPL live in the world of Unix/Windows, comprising shared 
libraries and calling code.  Neither translate without analogy to our 
application.  There will always be doubt.  This is the problem.




More information about the Squeak-dev mailing list