I very strongly disagree with the statement on SqueakMap that reads:
Licenses/LGPL - GNU Lesser General Public License. Only suitable for plugins.
I believe this statement was derived from a post by Andrew C. Greenberg, wherein he stated:
"I am an IP and Patent lawyer. After a careful analysis, and extensive discussions with FSF and RMS on the subject matter, it is my present view that GPL is unsuitable for use with a monolithic object image system unless all code of that system is to be GPL'd. While LGPL can be made to work for things like plugins, GPL simply is "too viral" to work in an open community such as ours."
Notice that Andrew's statement was primarily about GPL code, with only a somewhat passing comment about LGPL. As to the use of LGPL for external libraries (like those found on SqueakMap), Andrew later said:
"LGPL, as opposed to GPL, is non-viral to calling programs. It is usable for plugins and attached libraries, particularly if dual-licensed with Squeak-L. I wouldn't use it to distribute Smalltalk code...I have not given any thought to LGPL Smalltalk code distributed outside the image. Let me consider this."
The key phrase here is Andrew's admission that "I have not given any thought to LGPL Smalltalk code distributed outside the image".
GLORP is licensed as LGPL. GLORP began life as an Object People project, and for various political reasons will probably remain LGPL. However, I can categorically state that many within Cincom have plans to eventually "officially" support GLORP as the preferred O/R mapping framework for VisualWorks. In other words, there are plans for GLORP to see an active life as a supported part of a major commercial Smalltalk implementation. And this, in and of itself, goes directly against the SqueakMap statement that LGPL is "only suitable for plugins".
GLORP also has an attorney retained to investigate such issues. At some point an "official" opinion might be solicited from that attorney (with, of course, his usual fees to investigate the issue sufficiently to render an "official" opinion). However, for now, it isn't considered to be a high enough priority. Thus, for now, a simpler approach to quelch all uncertainties might be to get an "official" opinion rendered directly by the FSF concerning LGPL (just as it appears Andrew did for GPL), since they are the creators of the LGPL license. At some point (hopefully soon) I plan on attempting to do just that.
But in any case, it certainly *is* the current opinion of many that LGPL is certainly good for more than "just VM plugins". I am one of those people. I strongly disagree with the statement on SqueakMap that states it that way (though I personally completely agree with Andrew's statement about GPL code).
Nevin
(This message has been sent to the Squeak list, and CC'd to Andrew C. Greenberg)
On Sunday, December 22, 2002, at 06:31 PM, Nevin Pratt wrote:
The key phrase here is Andrew's admission that "I have not given any thought to LGPL Smalltalk code distributed outside the image".
Don't read too much into it. While it is true that I haven't carefully opined, this is not because I am optimistic about obtaining a different result -- this is simply because nobody has seriously insisted on LGPL for any meaningful Squeak asset. I doubt that LGPL would work effectively with a monolithic image in practice, but I am game to look at the question if there is serious interest.
GLORP also has an attorney retained to investigate such issues. At some point an "official" opinion might be solicited from that attorney (with, of course, his usual fees to investigate the issue sufficiently to render an "official" opinion). However, for now, it isn't considered to be a high enough priority. Thus, for now, a simpler approach to quelch all uncertainties might be to get an "official" opinion rendered directly by the FSF concerning LGPL (just as it appears Andrew did for GPL), since they are the creators of the LGPL license.
FSF has been remarkably hostile to Squeak and Squeak-L, and has no interest in catering to monolithic images. Indeed, FSF is hostile to use of LGPL for the most part. Their view is that the world should be GPL'd.
At some point (hopefully soon) I plan on attempting to do just that.
The culture of Squeak is a bit "freer" than LGPL. We are used to freely manipulating code in the image, refactoring, subclassing, copying and so forth, without being concerned about compliance with licenses. The Squeak-L makes it possible to do just about anything, and all is well -- the resulting image can be used commercially for many purposes, and for just about any non-commercial purpose. This is not the case for LGPL code -- and any code infected thereby. The practical application of LGPL for plugins is that folks don't tend to freely reuse plugin code in apps as widely -- don't get the idea that we Squeakers widely sanction LGPL for plugins, its just that there have been a few applications that couldn't be made available any other way (however, virtually ALWAYS with respect to any code that got into the image, we have gotten, at least, a Squeak-L/LGPL dual license).
Be certain to ask the right questions. The issues are complex. What is the LGPL status of subclasses of the LGPL code? of various patterns that do not use inheritance?
All of a sudden, commercial uses of Squeak will require complex compliance memoranda by attorneys, depending on the specific classes used and not used.
But in any case, it certainly *is* the current opinion of many that LGPL is certainly good for more than "just VM plugins". I am one of those people. I strongly disagree with the statement on SqueakMap that states it that way (though I personally completely agree with Andrew's statement about GPL code).
Many? How many is that? How many have seriously considered LGPL in monolithic images for widely distributed open source Smalltalks?
Andrew C. Greenberg wrote:
But in any case, it certainly *is* the current opinion of many that LGPL is certainly good for more than "just VM plugins". I am one of those people. I strongly disagree with the statement on SqueakMap that states it that way (though I personally completely agree with Andrew's statement about GPL code).
Many? How many is that? How many have seriously considered LGPL in monolithic images for widely distributed open source Smalltalks?
It wouldn't be appropriate to name specific names within a public forum, however suffice it to say that I'm not aware of a single prominent "Camp Smalltalk" person who believes LGPL is a problem. You can google Camp Smalltalk discussions and see some of it yourself.
There are likewise a number of prominent Cincom folks who don't think it is a problem. Pick a Cincomer, then google on GLORP plus their name, and you can see for yourself.
And this doesn't even mention private conversations about the topic.
Nevin
Andrew Said:
Be certain to ask the right questions. The issues are complex. What is the LGPL status of subclasses of the LGPL code? of various patterns that do not use inheritance?
All of a sudden, commercial uses of Squeak will require complex compliance memoranda by attorneys, depending on the specific classes used and not used.
GPL code CAN be used for commercial purposes, you just have to provide the SOURCE with the application. It's not rocket science to read the license and understand it. As a legal doc, it's durn clear as to what it involves.
In the 50s and 60s, it was a VERY common practice to give the source with a purchased app. It was even common with UNIX source for SYS-V.
Personally, I like the GPL because it forces people to 'play fair'. My hard work won't be locked away, and I won't see anything from it ( improvements, upgrades, etc ). Plus any fixes made will make it back into the community.
That said, I am not a 100% GPL fanatic. Personally, I think Alladin GS has the best of both worlds. A commercial release, and after a year or so, the old code is released under the GPL ( which makes maintenance, and mods for specific uses easier ).
It's a license, use it or don't. No one is forcing you. But in certain situations, I think it is VERY useful and important.
-Daniel
Daniel Joyce wrote:
Andrew Said:
Be certain to ask the right questions. The issues are complex. What is the LGPL status of subclasses of the LGPL code? of various patterns that do not use inheritance?
All of a sudden, commercial uses of Squeak will require complex compliance memoranda by attorneys, depending on the specific classes used and not used.
GPL code CAN be used for commercial purposes, you just have to provide the SOURCE with the application.
True. But what constitutes "application source" is muddy with Smalltalk. I believe that is Andrew's point. Because of that, I personally wouldn't touch GPL code for a Smalltalk image, if it were my decision.
However, note that I am talking about LGPL rather than GPL (specifically in the context of GLORP having an LGPL license), and LGPL has a more liberal license than GPL.
Nevin
I also believe the SqueakMap statement to be entirely proper that SqueakL is the only allowable license for code in the base image. For the base image code, LGPL is entirely inappropriate, let alone the stricter GPL.
But the separately installable stuff on SqueakMap is an entirely different thing, in my own worthless opinion, and for that code I still maintain the LGPL is not a problem.
Nevin
True. But what constitutes "application source" is muddy with Smalltalk. I believe that is Andrew's point. Because of that, I personally wouldn't touch GPL code for a Smalltalk image, if it were my decision.
However, note that I am talking about LGPL rather than GPL (specifically in the context of GLORP having an LGPL license), and LGPL has a more liberal license than GPL.
Nevin
I would say the changesets that impliment said code.
A LGPL library can call Kernel functions on a NON-GPL OS. That does not require that the source of the OS has to be released too. ( Gnu C libs on Solaris )
Likewise, LGPL classes can call code in non-Gpl classes, that does not require the source to those non- LGPL classes be released either.
Likewise, a propietary library can call functions in LGPL libraries too w/o being LGPL.
So non-LGPL classes can call GPL classes.
The only REAL muddy place I see is the case where someone subclasses a LGPL class. Would the subclass fall under the LGPL too, or since it's still just calling a LGPL class, and so technically is not a LGPL class too.
-Daniel
Daniel Joyce wrote:
True. But what constitutes "application source" is muddy with Smalltalk. I believe that is Andrew's point. Because of that, I personally wouldn't touch GPL code for a Smalltalk image, if it were my decision.
However, note that I am talking about LGPL rather than GPL (specifically in the context of GLORP having an LGPL license), and LGPL has a more liberal license than GPL.
Nevin
I would say the changesets that impliment said code.
A LGPL library can call Kernel functions on a NON-GPL OS. That does not require that the source of the OS has to be released too. ( Gnu C libs on Solaris )
Likewise, LGPL classes can call code in non-Gpl classes, that does not require the source to those non- LGPL classes be released either.
Likewise, a propietary library can call functions in LGPL libraries too w/o being LGPL.
So non-LGPL classes can call GPL classes.
The only REAL muddy place I see is the case where someone subclasses a LGPL class. Would the subclass fall under the LGPL too, or since it's still just calling a LGPL class, and so technically is not a LGPL class too.
What about the case where someone adds a method to an LGPL'ed class? This method is part of their package and it's only called by their package. All it is doing is making calls to parts of the LGPL'ed class. We do this all the time in Smalltalk... the method is logically part of another package but attached to the LGPL'ed class. Does that mean that method has to be LGPL'ed? Does the whole package?
Julian
-Daniel
Julian Fitzell wrote:
What about the case where someone adds a method to an LGPL'ed class? This method is part of their package and it's only called by their package. All it is doing is making calls to parts of the LGPL'ed class. We do this all the time in Smalltalk... the method is logically part of another package but attached to the LGPL'ed class. Does that mean that method has to be LGPL'ed? Does the whole package?
Julian
Objective-C has exactly the same issue, and there doesn't seem to be any confusion with it and LGPL.
In Objective-C, an external library is roughly analagous to a Smalltalk change set.
Now as an example, a "proprietary" library can add methods to classes in an existing LGPL library without needing the source code of the LGPL library to do it. And the reverse is also possible-- an LPGL library can add methods to classes in a proprietary library without needing source code to the proprietary library to do it.
And there doesn't seem to be any issues as long as they are in separate libraries (i.e., separate change sets for Smalltalk).
Nevin
On Monday, December 23, 2002, at 02:13 PM, Nevin Pratt wrote:
Julian Fitzell wrote:
What about the case where someone adds a method to an LGPL'ed class? This method is part of their package and it's only called by their package. All it is doing is making calls to parts of the LGPL'ed class. We do this all the time in Smalltalk... the method is logically part of another package but attached to the LGPL'ed class. Does that mean that method has to be LGPL'ed? Does the whole >> package?
Julian
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.
In Objective-C, an external library is roughly analagous to a Smalltalk change set.
Rough analogies are a dangerous way to proceed when we are discussing legal consequences of software development. Ultimately, the mode of distribution of the initial source of viral code is not meaningful or useful in analyzing the difficulties of the LGPL in Squeak. Loading the code into a monolithic image, we now have a mix of code in that image, and the question is how much of the image becomes virally infected thereby.
This is the fundamental difference between Objective-C code and Smalltalk with respect to licensing.
Now as an example, a "proprietary" library can add methods to classes in an existing LGPL library without needing the source code of the LGPL library to do it. And the reverse is also possible-- an LPGL library can add methods to classes in a proprietary library without needing source code to the proprietary library to do it.
There are no libraries in Smalltalk. There are images of objects.
And there doesn't seem to be any issues as long as they are in separate libraries (i.e., separate change sets for Smalltalk).
Nothing in smalltalk lives in change sets. Smalltalk code aren't maintained as change sets -- changesets are simple memorializations of changes within an image.
Andrew C. Greenberg wrote:
In Objective-C, an external library is roughly analagous to a Smalltalk change set.
Rough analogies are a dangerous way to proceed when we are discussing legal consequences of software development.
Granted. And a very good point.
Ultimately, the mode of distribution of the initial source of viral code is not meaningful or useful in analyzing the difficulties of the LGPL in Squeak. Loading the code into a monolithic image, we now have a mix of code in that image, and the question is how much of the image becomes virally infected thereby.
This is the fundamental difference between Objective-C code and Smalltalk with respect to licensing.
Don't agree. While I agree that the monolithic image blurs the distinction between development time and runtime (because it's *all* runtime with Smalltalk), during runtime the concept of the "object space" from the point of view of the executing program is identical between Objective-C and Smalltalk, and their respective capabilities are very close to being identical.
What I perceive to be your interpretation of GPL and LGPL is that for Smalltalk image-based code, there is no difference between those two licenses. I could be mistaken, but that is the impression that I get that you are saying. And, that's what I don't agree with. There is a difference between those two licenses for Smalltalk image-based code. No, I don't believe I can accurately illucidate the boundaries and differences between those two licenses for Smalltalk image-based code, but I firmly believe those two licenses have differences for Smalltalk image-based code (for that matter, not every Smalltalk implementation is image-based: ObjectStudio and SmallScript being notable exceptions).
And I also feel that you are correct in raising the flags that you have raised. But I feel that your interpretation that there is no difference between those two licenses for Smalltalk image-based code to be an overreaction, and inaccurate. Of course, I could also be misunderstanding what you are saying, too.
In regards to the FSF clearing up the confusion, probably a simple question of "what is the difference between GPL and LGPL licenses in regards to Smalltalk image-based code" would suffice. I'm inclined to think that their position for GPL will be that the entire image would need to be GPL'd. But their position for LGPL will be something a bit less restrictive, whatever that happens to be. And it is that difference that would indicate the boundaries.
Nevin
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?
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.
- Stephen
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.
Andrew C. Greenberg wrote:
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.
Andrew,
Sounds like all we need is a suitably precise Smalltalk-centric definition of "library" and "calling code"?
For LGPL (like GLORP in particular), perhaps we can "modify" the LGPL license by explicitly defining what those two terms mean.
So, for LGPL, what would you consider to be good candidate definitions for those two terms?
Nevin
Maybe I've just missed it, but it seems to me before we get into putting a new license together we need to better define the goal in doing so. Looking back at this thread in the archives it all seems to have started with Nevin noting that he didn't care for the description accompanying the LGPL license on SqueakMap. Now we seem to be on a discussion of either creating a new license or somehow forking the LGPL. Why? What goal are we trying to meet that isn't already met by the Squeak license or the LGPL?
Ken
Ken Causey wrote:
Maybe I've just missed it, but it seems to me before we get into putting a new license together we need to better define the goal in doing so. Looking back at this thread in the archives it all seems to have started with Nevin noting that he didn't care for the description accompanying the LGPL license on SqueakMap. Now we seem to be on a discussion of either creating a new license or somehow forking the LGPL. Why?
The issue is that for GLORP, for various political reasons, we are stuck with LGPL for the time being.
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.
Nevin
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.
Hey all!
For performance reasons, I am using Squeak 2.8 on my Audiovox Maestro Pocket PC. I am having a problem resolving file paths, I think. When it starts up it cannot find the source file, even though it is definitely there. It also gives me an error "For some reason, this file cannot be read" when I try to examine any file in the File List window. The path to my operating directory is '\Storage Card\squeak' which is where I put everything including the VM.
The TinySqueak image doesn't have this problem (it's based on Squeak v3.0). Is this a known problem with v2.8 and Windows CE? I'm digging into this now, and if I can figure it out, I'll be sure to let you all know. Just in case someone already knows, where should I look to fix this?
Thanks,
-Carl
1. Google for sqfixes. 2. Click the SqFixes link. 3. Click the link to show all messages, rather than the most recent ones only. 4. Do a find in the page for WinCE. Repeat until you find a changeset called "WinCE DOSFileDiredctory fix."
I can do this later, but that's how to find it... I can't do it at this moment.
Regards, Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/ "one has a moral responsibility to disobey unjust laws" :: m. l. king jr.
From: "Aaron J Reichow" reic0024@d.umn.edu
- Google for sqfixes.
- Click the SqFixes link.
- Click the link to show all messages, rather than the most recent ones
only. 4. Do a find in the page for WinCE. Repeat until you find a changeset called "WinCE DOSFileDiredctory fix."
I can do this later, but that's how to find it... I can't do it at this moment.
Thanks Aaron! That did the trick! Here's a path to the message including the patch:
http://squeak.cs.uiuc.edu/mail/squeak/msg08862.html
-Carl
I would recommend dual-licensing the disjunction of Squeak-L (for use with Squeak) and LGPL. Nothing else comes close to avoiding the traumatic problems your approach presents. I can't prevent you from licensing the software as you prefer -- that is your choice. If you want it to be useful with Squeak, and modified and incorporated into Squeak, however, without violating license or culture -- or worse-- this is the only solution I presently see. Until now, nobody has refused the dual license approach (even RMS bought into that for Perl). I will look again at LGPL when I can find some time. In the meanwhile, I disagree that "all we need" is to modify LGPL with "suitably precise" new definitions. The last thing the world requires is another ad-hoc open source license.
On Friday, December 27, 2002, at 09:57 AM, Nevin Pratt wrote:
Andrew C. Greenberg wrote:
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.
Andrew,
Sounds like all we need is a suitably precise Smalltalk-centric definition of "library" and "calling code"?
For LGPL (like GLORP in particular), perhaps we can "modify" the LGPL license by explicitly defining what those two terms mean.
So, for LGPL, what would you consider to be good candidate definitions for those two terms?
Nevin
Andrew C. Greenberg wrote:
I would recommend dual-licensing the disjunction of Squeak-L (for use with Squeak) and LGPL.
I agree. However, with GLORP, for various political reasons, we are stuck with LGPL for the time being. So, your suggestion is not an option right now for GLORP.
Nevin
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.
- Stephen
So let's write our own licenses then....
A MIT style license, and a GPL-ish license that takes these issues into account for SmallTalk code.
-Daniel
On Thursday, December 26, 2002, at 08:44 PM, Daniel Joyce wrote:
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.
- Stephen
So let's write our own licenses then....
A MIT style license, and a GPL-ish license that takes these issues into account for SmallTalk code.
Well, we do have Squeak-L...
Daniel Joyce wrote:
I would say the changesets that impliment said code.
A LGPL library can call Kernel functions on a NON-GPL OS. That does not require that the source of the OS has to be released too. ( Gnu C libs on Solaris )
Likewise, LGPL classes can call code in non-Gpl classes, that does not require the source to those non- LGPL classes be released either.
Likewise, a propietary library can call functions in LGPL libraries too w/o being LGPL.
So non-LGPL classes can call GPL classes.
The only REAL muddy place I see is the case where someone subclasses a LGPL class. Would the subclass fall under the LGPL too, or since it's still just calling a LGPL class, and so technically is not a LGPL class too.
-Daniel
There's more muddy places than that. What about moving a portion of such code out of one change set into another? The second change set will now contain some LGPL code-- does the entire second change set now need to be LGPL'd? Probably.
And I don't think this covers all the issues either.
In short, I think Andrew is entirely correct in raising flags.
But none-the-less, I think the statement on SqueakMap that LGPL is only good for VM plugins is a bit overreaching, and an overreaction. Thus, I still strongly disagree with what it says.
Nevin
squeak-dev@lists.squeakfoundation.org
-
Aaron J Reichow -
Andrew C. Greenberg -
Carl Gundel -
Daniel Joyce -
Julian Fitzell -
Ken Causey -
Nevin Pratt -
Stephen Pair