(obsolete) The main arguments for and against re-doing SqueakL
Last updated at 9:28 pm UTC on 22 March 2017
(obsolete) Licensing Discussion in 2004 Very obsolete; the Squeak licensing 'issue' was solved and Squeak is not properly accepted as open source and is a member project of the Software Freedom Conservancy
The Opening Question: Can we gain acceptance from the Open Source Initiative by getting Apple to release their part of Squeak under a better license?
From: Lex Spoon Sent: Sunday, January 04, 2004 2:55 PM
There has been a lot of discussion about Squeak licensing, and most proposals require that Apple re-release the part of Squeak it owned under a better license. How about we go ahead and do that step, so that further steps may be enabled? Is there any reason not to?
If this does not happen, then a large portion of Squeak will remain under Squeak-L and thus will be rejected by the Open Source Initiative. That status will be unable to be changed until at least the Apple portions of Squeak are entirely replaced, and it puts extra question on the portions of Squeak written at Disney.
I grow increasingly frustrated that Squeak is not included in open source distributions due to the situation with OSI. OSI will likely never be convinced by arguments about the spirit of the license, and without OSI's support, we are likely to continue to have trouble with
other groups such as Debian.
It should be a no brainer for a lawyer to release one of their open source projects using the standard Apple open source license. And even if they say no, it will be good to know the situation.
IMHO, we should not even bother asking for something even more open such as MIT-L, unless it is a verbal conversation and it can be preceded by some probing. We surely want to present a simple no-brainer proposal to the Apple lawyers, and APSL is fine.
For reference on previous discussion, these two pages have a lot of info and links:
Squeak-L
"A proposed license policy changehttp://swiki.squeakfoundation.org/squeakfoundation/103
One Answer: No, let's not try: Apple won't deal and we can work around OSI
From: Cees de Groot Sent: Tuesday, January 06, 2004 4:09 AM
I have asked for [getting different license] about a year ago and got a clear and resounding 'No' as an answer from Apple.
The only way this is going to move forward is if SqC steps in and juggle their contacts at Apple, and judging by past experience I don't feel that this is going to happen any time soon. And even then you are still left with a legal mess (unlike the current situation, which is entirely clear and acceptable to lots of parties) with respect to non-Apple contributions done under the SqL. I can imagine getting Apple around, but Disney? Forget it. Just forget about it.
You work around [trouble with Debian because of lack of OSI support]. I can install daemontools, djbdns, qmail under Debian by apt-getting an installer script, which fetches, patches, compiles, and installs qmail from original sources for me (these products have restrictions on redistribution which make them non-DFSG compliant, for entirely different reasons than Squeak but with completely the same result: non-inclusion). These packages aren't included in Debian, but I could not care less as long as some simple steps are all that's needed.
Personally, I think that any time spent talking about the SqueakL is time lost. If you really want to include Squeak in Debian, for example, make that fetch/install script, wrap up a .deb for it, and submit it to Debian. I give you a 90% chance it will be accepted, and a 0.1% chance that you will ever get Squeak under a different license.
Lex restates the argument in favor of a new license restated
From: Lex Spoon Sent: Tuesday, January 06, 2004 3:32 PM
Cees, shouldn't we at least ask? I agree that we don't want to spend lots of time on this, compared to spending time on Squeak itself. HOWEVER. A better license means:
- more people will be willing to help out
- more companies will feel secure using Squeak
- I will personally save time from maintaining a separate Debian apt repository :) I've already wasted more time on that than on licensing discussions.
I would like to not only save my own time, but save time from everyone else who has to read a custom license and decide whether their liability to Apple is acceptable. And while I am certainly very happy to see Squeak "just" be an experimental testbed for new development technology, I'd be even happier if more companies can feel safe to use it. Squeak is already an excellent dev platform despite being primarily experimental, and I'd hate to see people using something else because of license concerns.
Heck, if nothing else, it would be very nice to be in a herd on this. If Squeak were APSL, then we'd be in company with a lot of other software. Right now, Squeak-L must be evaluated individually, and we may get left aside as the legal basis of open source does slowly get established over the next several years.
.. I didn't realize [that Cees had asked Apple and that they said no]. Who did you ask? What exactly did you ask for? [Later, Cees answered: 'I asked the product manager for open source at Apple, I asked whether they would consider either relicensing under APSL or adapting SqueakL, the answer to the first was a resounding 'no', and the answer to the second was that they were not going to change the indemnification clause because "there's just not enough value to justify the effort required to validate that"'.] If it is hopeless then of course we should give up.
In fact, Alan offered to [work with Apple].
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-August/065042.html
It didn't happen, because there was a lot of subsequent discussion. But perhaps the offer is still open.... ?
Also, Apple still presents Squeak for download on their web site:
http://www.apple.com/downloads/macosx/development_tools/squeak.html
They list the license as "freeware".
This doesn't sound so hopeless as you make it out. Apple seems to have intended Squeak to be released as an open source project; they have a license all hammered out already, so it seems reasonable that they'd be willing to apply this license to Squeak as well.
..
I have been assuming that all the main contributors would be willing to re-release under any open source license you name. We can then strip out any code whose authors we cannot track down, and voila !! APSL Squeak. It is not even clear that we need Disney involved, since all updates from SqC-at-Disney were posted externally and since Disney doesn't seem to care.
On the other hand, the original Squeak release is unambiguously owned by Apple, except for the parts that come from Smalltalk-80. Thus without Apple's help, it is quite hard to move forward.
And this situation, while acceptable to lots of parties, is unacceptable to many others. Isn't that a bad situation for an open source project?
..
Why [shouldn't we expect to be able to deal with Disney]? Here's Alan's take on that situation: Alan Kay on the Squeak License
It's not clear that we need a statement from Disney, and it's also not clear that they'd be unwilling to give it. Companies love to be seen as benefactors of the community.
.. Yes, you can apt-get squeak [from Debian] if you edit your sources.list. It's a pain, however, and not all Debian users are willing to do this.
And anyway, Debian is mainly a sign that there is a problem. While I personally feel comfortable using Squeak for myself, I don't want to be putting legal pressure on others. I also don't want the rug to go out from underneath us when someone notices the license is not OSI certified.
.. I don't want to spend much time on licensing. However, the current situation is fairly bad. Talk all you want about fuzzy law, but the export clause at least seems relatively clear cut. Talk all you want about the symbols on paper maybe not being meaningful, but I'd rather not be sending around symbols on paper that make people nervous. While I don't want to spend lots of time on this, it seems we might as well try. We can ask the parties what they think, before giving up.
If we don't get a better license, then it is okay. At worst, we can all do as Alan suggests and hold out for whatever Squeak begets in 5-15 years from now, and simply abandon ship. Is 5-15 years short enough that we can just wait? I guess it depends on your point of view. Heck, it might even be sooner, who knows? And even the current situation is perfectly fine for Squeak-as-testbed; it's only those goofy people who want Squeak-as-platform that need to worry much about this, and even they can often convince themselves that there is no problem.
However, it would be helpful for the future of Squeak to have an unambiguously open source license. If Apple goes along, we can make this happen. If they don't, I am unsure what happens, but it is at least much more difficult.
Old objections to relicensing, restated
From: Andrew C. Greenberg Sent: Wednesday, January 07, 2004 1:11 AM
[Responding to Lex's original query] Licenses again. I find myself rethinking this issue from time to time, and imagine I will continue to do so, but this time, as I read the reiterated plaint of the "I want it in Debian" movement, the phrase above actually struck me – intellectually – like fingernails on a chalkboard.
Why? Why does this matter? For years, GPL has been hostile to monolithic images, this has been pointed out to FSF, who responded, albeit politely (sometimes), that they could not care less. Squeak has prospered for years now without modifying the license, even once, and
really hasn't shown any serious indicia of harm at any level. The only measurable harm from Squeak-L that I perceive is the vast waste of energy and time we have spent debating the issue.
..I can tell you this for sure: no change of license for a mature project is EVER a "no brainer."
When we last considered [making a proposal to Apple such as APSL], I suggested that we try to reach consensus on a license, and there is none. To be sure, Apple's consent, while necessary, is not sufficient. Unless nearly every contributor signs on to the change, it just doesn't matter what any segment of us considers to be fine.
Source Forge doesn't treat Squeak as Open Source
From: Bert Freudenberg Sent: Tuesday, January 06, 2004 3:57 PM
Did anybody read the nice warning that was put up on squeak.sf.net ['NOTE: This project IS NOT licensed under an Open Source license. Please read the special notice regarding this project'] recently? We may want to start looking for a different place to put the VM code.
[One side discussion on Cees setting up a VM server. A whole set of side discussions occurs about reports of SF rejecting Squeak code or not and whether its really a licensing issue or a SF funding issue.]
Lex attempts to address all concerns about going forward with re-Licensing
From: Lex Spoon Sent: Wednesday, January 07, 2004 2:36 PM
Before answering specific points, let me just remind everyone that this is a simple proposal that takes low effort, that seems likely to work, and that can move a large distance towards getting rid of Squeak's legal problems. While it is true that we can survive without the change, that is no reason not to do something easy to improve the situation. And while it is true that many people are satisfied with Squeak-L, please allow those others of us who are not to, er, spend our time as we see fit. :)
..
goran.krampe@bluefish.se wrote: .. [about what the problems were] The problems are real, as far as I know. I would love to be convinced that this is just OSI and Debian being extremely nitpicky, but so far it seems they are simply being more observant than most.
As it stands, Squeak is only available to certain countries of the world, and it incurs a hefty liability on anyone who merely distributes Squeak. These are things that will bother both open source zealots, and also companies with conservative legal staff.
It seems to be fine for hobbyists and researchers, however, as well as for commercial uses such as web servers that don't involve actually distributing Squeak itself.
"Gary Fisher" wrote: .. 'license negotiations are never trivial' [and will be harder now that Squeak is 'potentially, commercially viable.'? On the other hand, that is also why we should do it as early as possible. Over time Squeak's profile will increase even more. Further, IP law is likely to become more and more established and important over time; it would be extremely nice to be in a herd instead of having a
one-off license. Note that APSL has a versioning provision; any updates that Apple makes to APSL will also apply to Squeak, if Squeak is under APSL.
This negotiation has all the markings of being as trivial as they come. Apple has already agreed to open source Squeak, and further their PR right now includes a commitment to open source software. It would be somewhat embarrassing to them if it became known they were impeding their own open source project.
Andrew C. Greenberg [asked why does Debian's rejection matter?] Because Debian has rejected Squeak on legal issues. This is different from OSI's rejection or FSF's indifference. Debian has decided that the liability of distributing Squeak is too high. Please consider that carefully: some people have decided, after careful consideration of Squeak-L, that they are scared of merely sending around copies of
Squeak. I see no reason that other groups will not decide the same thing: that is a scary looking indemnification clause.
Andrew C. Greenberg [doubted that we had consensus on a license] Everyone seems to be satisfied with APSL....
goran.krampe@bluefish.se [proposed 'to continue with defining Squeak in terms of packages and their proper licenses, continue Squat, meet halfway and then be able to produce images by combining packages and then, simply by choosing packages under MIT or other OSI licenses gradually getting a Squeak that gives us all the possibilities we want.'?]
I really like this strategy in general, and it will succeed for us even if Apple says no. I'd like us to at least ask, however. If Apple says yes, it would save us a lot of clean room rewriting.
Doubts that indemnification clause is a real issue
From: Cees de Groot Sent: Wednesday, January 07, 2004 7:23 PM
[The Apple license] didn't bother Disney, and talk about conservative legal staff... It doesn't bother me, either - first of all, I don't export to funny countries anyway; second, if I create a derivative work and redistribute it, I think it is completely normal that unhappy people first sue me. Furthermore, it is a simple matter of an appropriate license if I want to cover that ('you are licensed to use this software only if you agree to indemnify and hold harmless Apple...'). Finally, I could not imagine in any way that this clause would actually be invoked - every time you do business you need to assess risks; the chance that this clause would cost me money, in my eyes, is so remote that I simply do not care about it.
I can imagine Debian being unhappy about [the indemnification] clause - after all, they're not in the business of taking risks and making money out of that. Every company is, and I think that most companies will decide that this clause isn't worth the trouble (and in fact, a number of companies have decided that already - large ones, small ones).
How important is OSI really
From: Cees de Groot Sent: Wednesday, January 07, 2004 4:33 AM
[Why does not being OSI matter? ] Marketing. That's the only reason. And it's a valid reason – inclusion into the 'open source family' would increase Squeak's visibility and the stamp of approval by e.g. OSI would lower the barrier of entry for companies (now, I run three companies that all are happy campers with Squeak because I as a director read the license and found it ok, but that's why I put this under marketing: you'll land on the 'shortlist' quicker if you're OSI-approved and someone is looking for open source tools/environments).
Now, is marketing a valid-enough reason to create a legal mess? Last year, I thought 'yes'. I reconsidered, and I now think 'no'.
From: danielv Sent: Thursday, January 08, 2004 11:29 AM
Whether [the Squeak-L] is tenable or not depends on whether your requirements for licensing freedom are your own particular standards at a particular time (I am willing to take this risk for this venture) or whether what you wish for Squeak is that it become as free as other shared software. To the extent that we value that goal, we cannot define our own standards, and we cannot each evaluate the license according to our particular needs at a particular time.
There are accepted standards in this area, because people have been doing this for a long time. That's what OSI/DFSG/FSF "Free software"() are all about. These standards are not arbitrary or detached from practice - they are written by people that actually share software widely. If we view Squeak as something whose value lies in being shared, that's the standard we should aim for, whether we think it will be easy or not.
From: Andrew C. Greenberg Sent: Friday, January 09, 2004 10:52 AM
I take no ideological position on licensing freedom. ... I am commenting on the legal consequences of foolish and legally unsuccessful efforts to "relicense" the project.
I believe it is entirely unnecessary – and frankly, it is simply raised primarily by people who ARE too ideological to enjoy freedoms they actually have, that they would risk killing the project to make a misguided political point. There is simply nothing actually constraining about Squeak-L, certainly nothing that practically stopped the project from being successful, other than the fact that some people are funky about nuances that have little to do with real freedom. Again, however, that is not the issue.
My view is this:
First, we must reach a consensus what shape the ultimate license should take. Only then does it make ANY SENSE AT ALL to consider what we should be doing.
Then, we should undertake to relicense the entire project under that license. If it is not possible, we should undertake to either suck it up and work forward, or to rebuild a "free" Squeak if people really care enough to do so.
I ask again, is there broad consensus what license we should use in place of Squeak-L? If so, what is it. Let us draft the revised license in final form and then, only then, consider what it is we should do.
