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
|