On Friday, December 27, 2002, at 02:18 PM, Nevin Pratt wrote:

> But as suggested, I think we could tighten the GLORP LGPL license by 
> explicitly defining the terms "library" and "calling code" to be more 
> Smalltalk-centric, thus eliminating some element of doubt about the 
> usability of the license.

I disagree.  I have now reviewed the LGPL again, and it is still my 
conclusion that LGPL is wholly inappropriate for working with Squeak 
code, apart from plugins and FFI code.  This is not, of course, a legal 
opinion as to particular issues, which would require the review of a 
particularly library, particular Squeak code using it and a particular 
dispute -- it is merely a generalized concern based upon a detailed 
legal understanding of software licensing issues.  I am not inclined to 
gainsay Nevin's suggestion above until I have seen his "revised" LGPL, 
which would not, in fact, be an LGPL at all as I read it -- my comments 
are, necessarily, based on the LGPL as it presently exists.  I think it 
is simply unworkable for Squeak code by its own terms.

By its own terms, it is really meaningful only in the context of 
statically and dynamically linked libraries.  Its provisions are 
carefully tied to this model of an "application program" and a 
"library," and make little sense outside of the context.  Efforts to 
distinguish between distribution of changesets as opposed to images 
fail, because images (particularly when distributed with the .source 
and .changes files), contain portions of the "library" for any 
meaningful or operative definition of the library, and hence tie into 
the operative provisions of the definition of a "work based upon" the 
"library."  In other words, the  formerly distributable image has now 
become LGPL'd.  Limitations in LGPL make no meaningful sense in the 
Squeak environment -- API's may no longer be modified except under 
particularized limitations.  There is no clear notion of "object code" 
in Smalltalk to construe that term as used in LGPL.  In short, 
virtually every operative provision raised far too many interesting 
questions about their application to a Squeak program using code that 
was LGPL'd, however introduced into an image.

Mind you, we run into nasty interactions between Squeak-L and LGPL as 
well, to the extent that LGPL code is changed to incorporate or using 
Squeak-L and LGPL code both.  But this is permitted only where the 
combined code is licensed under a license that is "no less protective" 
of the chain of distributor's rights than is Squeak-L.  As the license 
now stands, this is not true of LGPL.  I think this is a  nasty 
limitation of the Squeak-L, and one we should undertake to eliminate in 
time, but as things now stand, it DOES stand in the way of much 
mixed-license coding.

I am unimpressed with the response earlier in this colloquy, that 
"changeset" distribution obviates my previously stated objections to 
the xGPL licenses -- that LGPL and GPL do not translate reasonably or 
credibly into Smalltalk monolithic image models.  Even if the effort to 
reduce an image to its "source" changesets might be credible for 
licensing and distribution purposes (although requiring at the outset 
an extraordinary suspension of disbelief: though NOBODY programs by 
operating on changesets unless they have to -- virtually EVERYONE codes 
in the browser), this is simply an effort to finesse the Smalltalk 
image concept -- not to distinguish it.  The license STILL doesn't work 
with images.

Nevin, after my examination, I respectfully remain of the view that 
both GPL and LGPL are carefully tuned to a world of application 
programs and libraries, DLL's or their equivalents and operating 
systems.  They work for their own purposes, but something different is 
required for real Smalltalk coders.   Squeak, gratefully for some of us 
and apparently for others a problem, doesn't ordinarily live in that 
universe.  Our code is ALL open source and all available, from the top 
down.  A few exceptions, the VM itself, which is an application, its 
collection of primitives, which can call to external libraries and more 
recently the FFI stuff, appeal to this more orthodox model of 
system-building, and thus can be credibly used with LGPL (but not GPL 
unless we want to GPL the entire VM) code.  As I read the GPL, this 
problem is not inherent in the license, but rather derives from RMS' 
interpretation, which he believes would preclude calling to a dynamic 
GPL library from a non-GPL application.  New versions of GPL are 
intended by RMS to "fix" the problem -- which means that GPL's present 
"ambiguity" will ultimately become inherent.

Perhaps we shouldn't be speaking in generalities, but rather describing 
in particularities what conduct in which Nevin believes Smalltalk 
coders should not be permitted to engage.  Then we can "back out" to 
the ad hoc license he ultimately desires (whether it be LGPL, Squeak-L, 
BPL or GLORP-L).   Then we can examine the merits of the license at the 
same time.  Without really knowing what Nevin wants to permit or 
prohibit, it is impossible to say whether a particular license does 
what he desires, or hurts others alter on.

Using LGPL for this purpose is like using a sledgehammer to crack an 
egg.  Although it may "feel good" to use an FSF license, it is simply 
the wrong tool.  Indeed, reliance upon the LGPL to avoid the problems 
of the GPL is disfavored by FSF as well, which renamed the license as 
it tried to diminish its use as a midway between GPL and BPL or public 
domain approaches.

Don't do this folks --  besides being legally unstable, it is also bad 
karma.  As I see it, Squeak code should be free as we can make it.  
Here, I use the term "free" not as does RMS, but rather "free" as in 
"free from limitations on the programmer."

That said, let me suggest that, as we start thinking in terms of a 4.0 
release, we REALLY MUST consider relicensing Squeak so it is OSI 
compatible.  It is time to eliminate the Apple fonts, and with it the 
silly Apple provisions.  It is time also to get rid of some of the 
archaic provisions no longer necessary, and get Apple and the chain of 
developers to sign off on the changes -- Apple should mellow out in 
view of their concessions on the APSL, on which they now base Darwin, 
so this should be politically possible.  Alternatively, it might be 
time to start a FreeSqueak movement to recode the vestiges of the 
original, if only to get the system over the hump and credibly 
relicensed.  In any case, neither GPL nor LGPL have anything to offer 
to inform this debate, I believe -- certainly not as they are presently 
crafted.