(obsolete) Dual Licensing
Last updated at 9:35 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
(obsolete) Dual Licensing
SqueakL+MIT
From: Cees de Groot Sent: Wednesday, January 07, 2004 4:33 AM
However, I do agree, empathically, with for example Goran's strong suggestion to dual-License works under SqueakL+MIT. In that way, we will build up a body of code over the years that is 'real Open Source', and maybe in a couple of years the remaining bits will look small enough to make the jump and re-write it all.
Dual license for new code considered harmful
From: Lothar Schenk Sent: Wednesday, January 07, 2004 12:00 PM
I think dual-Licensing of original new contributions will create still more of a mess than we have now, because more code will be released under legally dubious terms. I think the only clean way of releasing original new code (not modifications of existing code) to be open source would be to release them under a non-Squeak-L license, which might be MIT, if authors don't care about independent commercial use by others.
Moreover, I think that re-releasing modifications of existing code that is already under Squeak-L with a dual license, Squeak-L and MIT, might not work legally, because I think this would be considered to be sublicensing from the Squeak-L point of view, and if I understand this correctly, the Squeak-L terms do not allow sublicenses to be less restrictive than the original Squeak-L license (at least as regards Apple's rights and Apple's rights is all the Squeak-L is about, anyway).
Is too
From: Cees de Groot January 7, 2004, 7:26 PM,
I don't think you [Lothar] understand dual licensing. If I release code under SqueakL+MIT, it means that the licensee can choose under what terms he/she wants to use my code (or, of course, choose that neither license is appropriate and not use my code). That is very clear, very common, and very appropriate behavior in this case. There is nothing legally dubious about it
Is not
From: Andrew C. Greenberg Sent: Wednesday, January 07, 2004 11:22 PM
It certainly IS legally dubious, to wit: if the licensor does not have the right to license the underlying work under BOTH licenses. That is the problem. If we had the right to dual license our code without violation of Squeak-L, then we could simply license it under MIT as well.
Remember we are talking new code only
From: goran krampe Sent: Thursday, January 08, 2004 3:10 AM
[Not having the right to license your code under multiple licenses]is NOT "the problem" for NEW code.
[We can ] separate the issues here - either you create a modified work based on code under Squeak-L and then of course you must abide to the rules of Squeak-L - dual licensing under MIT is then not possible. Dual licensing under a different license would be possible though, but probably not overly useful.
But if you create an original work of your own - like say brand new classes for displaying SVG or something - then of course you can dual license it ..
Do the simplest possible thing
From: Lothar Schenk Sent: Thursday, January 08, 2004 5:58 AM
[Goran had asked by it would be cleaner to release new code under a non-Squeak-L license only.] Simple. Don't introduce unnecessary complications if you don't have to. The same reason why superfluous code tends to make software buggier without adding functionality.
The only purpose of Apple's Squeak-L is to protect certain Apple rights in relation to the original code contributions owned by Apple and any modifications thereof. It makes no sense to apply it to non-Apple code. If you own original new code and want it to be free, release it under MIT or something similar that suits you. Why would you need to involve Apple in it?
Why involve Apple in licensing new code?
From: Lothar Schenk Sent: Thursday, January 08, 2004 6:13 AM
[Responding to Cees de Groot's defense of dual licensing] The MIT license gives me effectively the same rights as those of the original owner, provided I retain the copyright notice and the warranty disclaimer.
What possible reason would I, as a potential licensee, have to choose the more restrictive Squeak-L license over the more liberal (and more readily understandable) MIT license?
What possible benefit do you see in a dual license arrangement for non-Apple code?
So we can have one license that covers all
From: goran krampe Sent: Thursday, January 08, 2004 6:16 AM
The analogy [of superfluous code] doesn't hold. In dual licensing I offer you the choice of two licenses - not the union or the sum. Use the one you like. If it is available under MIT, then you don't even know if I am releasing my code under a different license to someone else.
For instance - I might even have sold a special license of my HttpView2 code to a company. Not that I have, but I could have. And I am free to do it in the future. :)
It does make sense [to apply Squeak-L license to non-Apple code] if the code is to be used together with other code that is available under SqueakL. Because this means you have all that code under a single license - SqueakL. Otherwise you will have parts under MIT, and other parts under SqueakL - and then it gets complicated. MIT being a very mild source of complication - but that is beside the point - multiple licenses mixed together gets complicated per definition. :)
So I reiterate - if it is my code and I release it to you and/or the rest of the world under MIT - then that is all you need to know. I could be quadruple-Licencing it to other people, but that doesn't affect you.
.. Again, [the argument for dual licensing of new code] has to do with the fact that we wanted the base Squeak code to be under a single license. And since we can't get rid of SqueakL it was decided that we should stick to it for all additions into it. But since code written for Squeak can also be used in other contexts dual licensing with MIT opened up a maximum of freedom.
In recent days we have though agreed to also let MIT code into the base (IIRC) so today you can use "only MIT" too. Te principle still holds though.
Need to have unambiguous ownership
From: Andrew C. Greenberg Sent: Thursday, January 08, 2004 7:47 AM
Were you my client, I would advise strongly against [dual licensing of new code]. It is a recipe for confusion and later contentious dispute. Sure, if code is "pure," in the sense of having no derivation whatsoever from the existing image, no problem. But how will we later take any significant block of code and actually know what license applies, and to what portions of it?
Dual-Licensing some of the code will not clarify the issue, nor will it solve the problem, if there is any problem at all. ..
From: Andrew C. Greenberg January 08, 2004 8:01 AM
Plural licensing will not save squeak, it will kill it.. Turn the image into a muck of licenses, and you will in the future spend all of your time license-Lawyering instead of coding, and no serious business will consider using the code, ever. When I have time, I will (once more) write in greater detail why this is so. In my view, this would be among the most foolish things we as a community could do. There is a place for dual licensing, but it has nothing to do with image code.
If the license is untenable (and there is serious reason to doubt whether it is is untenable), there are really only two practical solutions:
1) begin rebuilding Squeak – start with the VM. Use Squeak to bootstrap a brand new, free VM. Test by running Squeak on it. Build a new system. Have lawyers crawl all over it to assure cleanliness.
2) negotiate with Apple
all this still begs the question – can we reach unanimous consent on a new license?
Redux
From: goran krampe Sent: Thursday, January 08, 2004 8:19 AM
Why are you [Andrew] comparing dual/plural licensing (=offering code X under multiple licenses for the licensee to choose from) with mixed licensing (=having code in base Squeak under multiple different licenses)?
I/we are fully aware of the dangers of mixed licensing - and that is the prime reason for us telling everyone for the last few years to release their candidate additions to base Squeak under either only Squeak-L or better dually under Squeak-L and MIT. .. it was you [Andrew] that brought about that policy in the first place
Doug tries to make peace
From: Doug Way Sent: Friday, January 09, 2004 5:05 PM
I agree with most of Andrew's points in his other message (namely, that it is probably not practical to re-License Squeak at this moment), but it's pretty clear to me here that he has misinterpreted what Goran said about dual licensing.
I believe Andrew is saying above that we don't want a "multiply-Licensed Squeak release". (Correct me if I'm wrong.) That is, a Squeak image/release which has different sections under different licenses. For example, the kernel licensed under Squeak-L, the networking code licensed under BSD (and not Squeak-L), UI code licensed under only APSL, a web browser licensed under only LGPL, etc. Goran and most of us agree that this would be a bad thing.
However, Goran was saying that we should encourage "dual licensing" of new (non-derivative) additions to the Squeak release, which is an entirely different thing. For example, someone could write a new web browser from scratch and dual license it under Squeak-L and MIT (which is the only recommended dual license), so that someone using the browser could pick either license. This means that if we decide to incorporate this new browser into the Squeak image/release, we can treat it as being licensed under Squeak-L, so that the entire image/release is still licensed under Squeak-L, avoiding the problem above. So in other words, with "dual licensing of new packages" we can avoid the problem of a "mulitply-Licensed Squeak release".
But with the dual-Licensed web browser we also have the option of making it part of a MIT-only Squeak image/release, if we ever build such a thing from the ground up, which is a real possibility with the splitting up of the image into packages and the work on Squat. This would be our OSI-Debian-etc-compliant version of Squeak.
So, if you have a problem with something, please be more specific about whether it's with the "multiply-Licensed Squeak release", or "dual licensing of new packages", or both.
We are currently keeping track of which portions of the Squeak release are licensed under Squeak-L versus SqueakL+MIT, via the SqueakMap catalog. So we are not going to lose track of which source code is under which license.
[Regarding Andrews request to agree on the alternate license first]. . . I realize that one issue is that, with the dual-Licensing recommendation above, we have somewhat arbitrarily chosen MIT as the alternate license here. My impression is that for most of the Squeak community, MIT does have broad support as a OSI-Debian-FSF-etc-compliant license, with only
one possible exception: It lacks the "changes to the base must be posted publicly" clause which Squeak-L has. I know that some like this clause and others don't... it seems like a nice idea in many ways, but may be difficult to enforce, and it is certainly less complicated to leave it out. But anyway, no one seems to be in favor of a more
restrictive GPL-Like license. I don't think there's been too much stuff released under SqueakL+MIT yet, so in theory we could decide on something other than MIT to replace
SqueakL. But the current tentative "replacement" for SqueakL is MIT, for all practical purposes. If the replacement ever happens. :-)
P.S. We (the Guides) did decide to allow MIT-only licensed code to be part of the base Squeak release, if there are no alternatives. This was for the SmaCC compiler which is licensed only under MIT, and has been added to 3.7alpha (and tracked via SqueakMap). So we have consciously broken the rule for avoiding a "multiply-Licensed Squeak release" to
some extent, but this will likely be the only other license allowed in the release.
Not sure it will all work out
From: Andrew C. Greenberg Sent: Friday, January 09, 2004 7:01 PM
Two parties disputing what licenses apply to what software, whether works by persons having access to code are derivative or not, and whether one or another license controls the right to the software? Look to SCO for an example.
I tried, so far as I can, to explain that the one, clear and fundamental question that will make Squeak useful for a particular purpose is whether it is CLEAR or not what one can do with it. Where the distributed image has code licensed under a plurality of licenses,
and the possibility of disputes over whether works are or are not derivative in an open source community, having competing or plural licensing is a recipe for failure.
EVERY CORPORATE COUNSEL looks to its IP lawyers for clear and unequivocal advice before moving forward with a project. As soon as the answer gets complicated, the answer is already decided – let's do something else. More finished film projects in the can have DIED because of last-minute clearance issues. Likewise books and likewise code.
Folks, we need to keep this simple, as simple as we can possibly make it – but no simpler.
I recommend one plan:
a) seek consensus as to the form of a license;
b) seek to get unianimous consensus of stakeholders on the license; and
c) convert
alternatively, just deal with Squeak-L, or where we cannot use code otherwise because the code is subject to too-Limiting licenses such as GPL or LGPL, dual licensed third party code for plug-ins and the like.
Andrew summarizes his position on Dual Licensing: Disjunctive Dual Licencing
From: Of Andrew C. Greenberg Sent: Saturday, January 10, 2004 12:38 PM
1. On Squeak-Map acceptance of dual-licensed code drawn from Squeak.
It seems to have been suggested that I have left the community with ambiguous and/or waffled views concerning a licensing question. I hope with this posting to, at least, clarify what is my position. As to:
Whether the community should continue the practice of reproducing or distributing Squeak-developed code (whether in-image or extracted from an image) under a disjunctive dual license including Squeak-L?
It is legally problematic. It is possibly very dangerous. It can come back to hurt us.
If that is too lawyerly, please consider this lay statement.
Don't do it any more. Fix it. Stop. Please.
That is my position. It is not my view as to whether or not the liberalizing of Squeak-L would be a good thing. To be clear, I LIKE BPL – heck, if there were no liability issues that can be avoided with disclaimers of warranty, I would like public domain dedication for free software. When I say "don't do it," I am not stating whether I think it would or would not be a good thing – I am commenting about whether it might legally compromise the product or the community.
Note please, it is not my opinion that every circumstance where this is done will immediately yield a paralyzing lawsuit bankrupting every reader of this e-mail. I am stating that the general practice could never be approved by a lawyer – and a policy requiring case-by-case analysis would be impractical and error-prone. Licensing is necessarily a conservative business – the idea of EVERY contract is to minimize to the extent practicable the possibility of mistake or confusion. We lawyers write in gobbledegook because we write not so we can be easily understood, but rather so that we cannot be misunderstood.
Under the present practice, I believe that a lawyer being asked by an individual, "can I make this out of squeak and do ____" would probably review this and other practices and respond – "it depends on many things, any conclusive opinion would require a tremendously expensive analysis – try Ruby or Python instead – I can answer your question for those products." In my view, that would be a bad thing.
There is a way to liberalize licensing of the product – this is not it. It can't be done this way.
Once again, I strongly recommend the following:
Stop. Fix it. Don't do it any more. Please.
2. On other situations I have discussed in the past.
I have in the past been asked whether a GPL'd or LGPL'd product could be distributed with Squeak. Each case required a careful analysis, and in some cases the answer was alternatively, "No," "Yes, if we can talk the owner into a dual license," or "Maybe, but it is risky." These were done case-by-case, and the decisions made by SqC and others would be made under a totality of circumstances in view of all of the relevant factors. Very useful code was not incorporated in the past,and very useful code was.
An example of this would be code entire written by others outside of Squeak and hence can not at all be infected by Squeak-L. The code runs without modification in Squeak. We have no doubt as to the pedigree or origin of the code. The code is broadly licensed under a very liberal license that permits others to relicense the code under a more restrictive license without consultation.
In such a case, it is possible that such code could be distributed in the image under Squeak-L (possibly a more limited conjunctive license), or outside the image under a dual license with the understanding that once incorporated into the image, the code becomes Squeak-L (the more liberal disjunctive arm of the license is only for uses where the code is NOT used with squeak). In many such cases, we may be able to
distribute the code without problem.
This is a narrow hypothetical, and the devil is in the details. For example, assume that to make it run in Squeak, you must first load the changeset, make "minor" modifications, and then extract the modified code for use with Squeak. Could this code be extracted and dual licensed? The devil is in the details. The safest way would be to have the original unmodified code distributed by itself, together with
a Squeak-L only changeset embodying the modifications.
Even this hypothetical is dramatically narrower than the more general circumstance under which SqF seems presently to be operating.
3. On my general inability to spend more time than I have with Squeak this month.
I am simply not able to offer more time than I have. Notwithstanding the suggestion that I do not carefully enough read these threads, or that I somehow should spend more time more carefully detailing the bases for these conclusions, I still don't have more time than I have. Sorry, but that's the way it is when you have a 70 witness, 10 week
trial (involving, by the way, FAR SIMPLER IP issues) looming in your near future.
CONCLUSION
Stop it. Fix it. Don't do it any more. Please.
Hypotheticals and two causes of action
Andrew C. Greenberg January 12, 2004 5:40 PM
[Goran wondered if Andrew thinks “that the following scenario is also "legally problematic": I (or a company) write an application in Squeak (no base modifications) and then license that application to someone else under a license of my/the company's choosing.
Because as I interpret you the problem here is not the distinction about modifications to the base but rather that ANYTHING I produce inside Squeak is (or at least can be considered to be) a modified work. And that means, given the language of the license:
"You may distribute and sublicense such Modified Software only under
the terms of a valid, binding license that makes no representations
or warranties on behalf of Apple, and is no less protective of Apple
and Apple's rights than this License."
...that say using MIT is out of the question. Because it is probably not "no less protective of Apple and Apple's rights than this License". So, is this an at least somewhat correct interpretation of the situation? ]
The answer is simple: it depends. This is the answer to almost any legal hypothetical, because the facts can always be twisted to yield different results. Like it or not, that's the way it is in such matters. Every company that deals with a Source code license faces the same problems. Always.
Your analysis has some legal difficulties, confusing the contract language "Modified Software" with the Copyright notion of "derivative work," since a cause of action might arise, severally, in contract or copyright infringement – but I'll skip over the hypertechnical issues to say that, at the bottom line, you are close to right:
The fundamental difficulty (which is also the fundamental attraction to "free software" ideologues) with viral open source licenses, is that it is difficult in most every case to avoid licensing any related code under any license other than the original license. Squeak-L is quasi-viral, but viral enough so that you always have a problem whenever you make a derivative work, or a work that a potential plaintiff might call a derivative work.
In the last round of "what license next," there was a part of our community that did not like BPL and related licenses, in part, because they were non-viral.
Yes, if you work on or in Squeak-L code, you may be barred from licensing it under anything other than Squeak-L, at least if you want to be safe from legal ambiguity. That is my point – the image code MUST be free from such ambiguity. This point was made, with clarity, even in the quotation of mine you love to recite, which notes that code to license it.
For SqF, the question is this: how to maintain a codebase with a clear and consistent, and legally defensible license? This is an open source project, and we can never be certain whether a submission by a random person infringes a copyright or patent, or was copies from SCO sources or otherwise. But if it was built in Squeak, we can be fairly confident that it will not violate Squeak-L to license it under Squeak-L. If it was built in Squeak, we cannot be certain without substantially more and detailed analysis, both of a proposed alternative license and the particular code itself, whether it may otherwise be licensed.
There simply isn't enough money in our group to defend a serious lawsuit from anybody – we need to keep our code as copyright and license clean as possible. Period. We should take a prophylactic view of these things, in my view, to preserve the ability to go forward and not have the entire project brought to a screeching halt because of a self-inflicted wound that we didn't need to take. Seriously, really, absolutely, don't misundertand me.
Bijan Parsia January 12, 2004 7:21 PM: Indeed, if I've been following this exchange correctly, then Squeak isn't a useful development environment for many cross dialect projects (any that aren't Squeak-L compatible!). That seems sad. I wouldn't be surprised if it applied to, oh, Active Essays developed in Squeak (even, perhaps, if compiled to some other format like Flash or SVG). Ouch.
This doesn't seem to be the intent of Squeak-L, i.e., to make it the case that mere use of Squeak as a development environment contaminated one's code.
Might I suggest we table this for the moment, at least until Andrew gets to a more relaxed, post-trial-like time? If the situation is as I understand it, then I think there's good reason to get behind a more liberal, indeed, extremely weak, license, if at all possible, but most of us are already "in the lurch" such that a few weeks or months seems unlikely to make a huge difference.
I'll add that it seems to me that this is part of the general issue of monolithic images. Open source licenses don't seem to have been developed with them in mind, so it's perhaps no surprise that they have unexpected effects.
What's currently not Squeak L
Doug Way January 13, 2004 12:23 AM: Note that the SmaCC compiler is the only part of the current image/release which is not Squeak-L licensed (it is MIT only). Also, it was developed outside of Squeak.. a VisualWorks project originally, I believe.
Regarding dual-licensed code, it looks like there are only three Packages in the base image/release like this at the moment... SUnit, SqueakMap and SMPackageLoader.
SUnit was brought in from an external cross-dialect Smalltalk project, so it seems to be a reasonable example of a dual license. It was already released under a different license (public domain, it appears), and Squeak-L was added when it was incorporated into Squeak.
SqueakMap & SMPackageLoader were both developed in Squeak, and have the SqueakL+MIT license applied as per the current practice. If it is truly invalid to claim the additional MIT license on these packages, we could consider abandoning this particular practice... it would be easy enough for the authors to release future versions under Squeak-L only.
With SmaCC it might be more difficult to get the authors to release it under Squeak-L... but because it was developed outside of Squeak, perhaps this is not as big an issue? Although I can understand the argument for keeping everything in the base image/release as Squeak-L.
No Relicensing
Doug Way January 13, 2004: I should mention that currently, after discussing with some SqC members, we (the Guides) will not be approaching Disney about the possibility of re-licensing. Disney is not a software/computer company like Apple, and has no motivation to play nice with the open source community, so the chances of them allowing a re-licensing without a big incentive are pretty much zero. (Unless something changes, and they have an incentive.)
So, that kind of rules out re-licensing the whole image at the moment. But re-licensing the original Apple Squeak release (by having Alan & co. talk to Apple) and building something up from that could be a possibility. But that is much more of a "do-over". In theory, Craig's Squat project could be based on something like this. And of course the community would have to agree on what exactly the replacement license would be.
So, it seems like there are only a few options, if as you said a clean-room re-implementation is not practically feasible:
1. Live with Squeak-L, which is mostly fine except for non-acceptance from some groups such as OSI and Debian.
2. Re-license the original Apple Squeak release and build up something up new from that. (A major effort.) Starting over with Slate is a more extreme version of this.
3. Try some trickery with sublicensing to get around the Squeak-L clauses which are problematic for OSI/Debian/etc. Andrew, do you have any thoughts on whether this is possible? Squeak-L says a sublicense must be "no less protective of Apple and Apple's rights than this License". If we crafted a sublicense SqueakSub-L which was acceptable to OSI and Debian, and got a written agreement from Apple (with the help of some luminaries if need be) that it was indeed an acceptable sublicense of Squeak-L, would that work? Or is investigating sublicensing pointless?
Andrew C. Greenberg January 13, 2004 [Is investigating sublicensing pointless?] It would be a decent beginning, and would overcome the key hurdle. Best practice would be to get signoff from all subsequent contributors, including Disney, but we must work with the art of the possible., and the language of Squeak-L (apparently hardwired to Apple) gives us an opportunity to exploit Disney's lack of diligence (they COULD have, but did not, change the license to be protective of both Disney and Apple). The question is what new license would we adopt? Can we reach a consensus with which all or everybody
Doug Way January 15, 2004
Andrew had agreed with Doug: “If we crafted a sublicense SqueakSub-L which was acceptable to OSI and Debian, and got a written agreement from Apple .. that it was indeed an acceptable sublicense of Squeak-L, would that work?” by saying “It would be a decent beginning, and would overcome the key hurdle. Best practice would be to get signoff from all subsequent contributors, including Disney, but we must work with the art of the possible., and the language of Squeak-L (apparently hardwired to Apple) gives us an opportunity to exploit Disney's lack of diligence (they COULD have, but did not, change the license to be protective of both Disney and Apple).
Yes! The advantage here is that we wouldn't need to approach anyone except Apple. It's probably worth a try, anyway, and if it solves the issue with OSI/Debian/etc acceptance, that would be a significant accomplishment.
I vaguely recall that Daniel Vainsenscher had talked to a lawyer who was pessimistic about sublicensing, but I don't remember what the exact issue was. It is true though that we potentially have some pull with Apple, as opposed to certain other copyright holders (required for a re-licensing effort), which might make sublicensing work.
Could it be that OSI or Debian would not recognize a sublicense as a valid license to consider for compliance, since the original Squeak-L license might still be in effect? I'm fuzzy on exactly how sublicenses work.
[Responding to “The question is what new license we would adopt? Can we reach a consensus with which all or everybody should agree?”
I'm hoping we could reach some sort of consensus. :-) I think the only real issue in the community is whether the license should be quasi-viral (as Squeak-L is) or non-viral.
It may be that Apple's restrictions on what is "no less protective of Apple and Apple's rights" will limit our choices anyway.
As an extreme example, I don't think that Apple could give a written agreement that the MIT license is a valid sublicense of Squeak-L, even with a lot of prodding from Alan & co., since it seems patently false that the MIT license is "no less protective of Apple and Apple's rights" than Squeak-L. But I could be wrong. BSD/BPL might have a slightly better chance.
On the other extreme, we could create a customized SqueakSub-L by making the minimal number of tweaks to Squeak-L so that it complies with OSI/Debian/FSF. This would mean tweaking the wording in the indemnification clause, tweaking or perhaps removing the export clause, and probably removing the font clause. Also, we'd probably want to replace all references to "Apple" with something else like "copyright holder". A better name than SqueakSub-L might be SqueakOpen-L, or SqueakFree-L. I'd think it would be relatively easy to get Apple to agree to something like this being a valid sublicense of Squeak-L, especially with extra prodding.
Other possibilities might include APSL, which it seems they would probably agree to.
I'd probably lean toward trying some sort of SqueakOpen-L... it might be easier to get consensus on sticking with the status quo regarding the quasi-viral aspect. A minor downside to something like SqueakOpen-L is that it is not as well-known as something like BSD or APSL. But I don't consider that a huge problem... lots of other open source languages/environments have their own custom licenses, such as Python. Among the non-viral licenses I probably like BSD/BPL the most.
Goran Krampe January 16, 2004 3:29 AM
Btw, now that we are digging around anyway - some thoughts about Debian and distribution:
- Is University of Illinois aware of that they are covered by the
indemnification clause?
- I discovered Debian has a few so called "install packages". The package "xanime-modules" has been mentioned as an example. When installed it simply downloads and installs binaries from another distributor than Debian. The user experience stays the same. Tada!
So we could actually write such an install package for Squeak that downloads from University of Illinois (or some other entity) and installs Squeak. And this package can be under GPL and be in "proper Debian". Thus Debian isn't distributing Squeak - just a script.
Now if University of Illinois "wakes up" and don't want to distribute Squeak anymore (due to indemnification clause) - then perhaps it is high time to create a proper SqF that is a legal body that can do the distribution. If someone sues, so what? SqF wouldn't have any money anyway. Or?
Andrew C. Greenberg January 13, 2004: [Regarding the possibility of “sublicensing to get around the Squeak-L clauses which are problematic for OSI/Debian/etc.”] The question isn't whether it is reasonable, but rather whether there is any part of the code that was possibly derived. Surely Kent's part of SUnit can be licensed however he wants, but the subsequent code developed in Squeak is probably licensable only in Squeak-L. Likewise, SM and SMPL.
If SmaCC is unchanged from the original code, I agree that a dual license is possible. To the extent there is any Squeak-specific modifications, there are two approaches: (1) to single license the whole under a conjunctive (not disjunctive) Squeak-L with the additional notice or other provisions of MIT; or (2) to distribute SmaCC under MIT, and a separately developed changeset to make it work in Squeak under Squeak-L. (2) is probably the most straightforward approach.
Andrew C. Greenberg January 13, 2004: What I am saying is that in certain cases, the practice of accepting in-Squeak-developed code for dual licensing and distribution is a very dangerous practice, and that we should stop it and fix it.
...
Code that is not covered by the viral aspect of Squeak-L may be licensed in any way. But you are presuming that this is so, and for code developed in Squeak, there is simply no practice way to do that.
...
Code not developed in Squeak can be [s]o distributed [with a dual license]. Code written in Squeak cannot be safely so distributed absent affirmative proof that the code was independently developed. You are not capable of maintaining a clean room for all Squeak code, nor do we have any team of individuals capable of executing code development under a clean room.
...
[Regarding that idea “that dual licensing with Squeak-L/MIT could be a problem”] You have heard it MANY times now. You don't like that I have so stated, but that is what I am saying. Don't do it any more. Stop. Fix it. Please.
...
[What does BPL refer to?] Berkeley Public License. The code under which most of FreeBSD is distributed. Ultra-liberal, like MIT.
...
I wouldn't use Squeak to build non-Squeak-L code.
I disagree that it is particularly problematic for Squeak or at all "a sad day." I suggest that those who would like to license code more liberally get with the program, suggested elsewhere by Doug, and contemplate how we might relicense the code base entirely, rather than engaging in the generally useless artifact of a dual license (which is ENTIRELY a legal sleight of hand).
Note that ANY dual-licensed code, because disjunctive, can be taken by ANY individual and relicensed under just one of the two. Where code is practically used only in Squeak, it makes no difference at all.
... [Reinforcing his previous comment “There simply isn't enough money in our group to defend a serious lawsuit from anybody – we need to keep our code as copyright and license clean as possible.] The COMMUNITY cannot afford to redistribute code other than in Squeak-L for the reasons previously stated, but individuals may opt to take such risks as they determine to be appropriate
[Does this “mean that SmaCC must be thrown out”] SmaCC was not developed in Squeak, isn't that right? To the extent there are deltas, we can parse those out from the central code-base, and separately license the changesets, the "pure" code in dual, and the impure code in Squeak-L. However, it is unclear that much is gained, since a Squeak-made fork of SmaCC can be taken by any individual and made purely Squeak-L just by that person opting for the Squeak-L prong.
[Are you saying, “that no packages that we want to distribute as the official Squeak can have any other license than Squeak-L and ONLY Squeak-L”?] ...Certainly some packages could be so distributed. As a practical matter, however, this class of packages does not include code developed inside of Squeak.
[Does, this mean “that SqueakMap itself for example is a problem”?] Any person could take SqueakMap tomorrow, change a comment, and relicense it under Squeak-L. The danger is, if it IS derived, for the poor saps who opt for the MIT prong for use outside of Squeak.
Goran Kramp: But again - I am talking about code developed in Squeak. I am a Squeaker. This is squeak-dev. I code in Squeak. And given code developed in Squeak - that is what you are saying. So code developed by us in Squeak and meant for base Squeak (private packages are up to the authors of course) can ONLY be released under Squeak-L. Period.
A little question regarding SM: Are you also opposing SM to list packages that are NOT in official Squeak and that are under other licenses? I have always viewed SM as a catalog - so what I am wondering-is there in some way that SM can be viewed as the distributor of those packages?
Hmmm, I assume SM2 can obviously be considered to be the distributor (since it allows uploads and also has a cache). Damn, this is really making an ugly turn. Ok, what is your advice on that?
...
I was more considering companies and individuals that are interested in making proprietary products written in Squeak. AFAICT that goes out the window. Or? That was after all one of the key points of Squeak-L that has been touted all along. Now it looks like it was a mirage.
Andrew - I think I understand all now - both the misunderstandings etc. You may of course prove me wrong. But... could you please elaborate just a teeny bit more about how I can release something under Squeak-L which doesn't even mention my name and mentions Apple quite a lot? I mean - wouldn't it be better if we at least produced a sublicense for us to use in which we can replace the name "Apple" etc appropriately?
It seems so "strange" to "release something under Squeak-L". I know this was also what bugged John Brant with SmaCC etc.
Joshua 'Schwa' Gargus: Andrew, Can you comment on the difference between the notion of "derived work" that is apparently part of copyright law (and whatever viral implications it might have), and the explicitly viral aspects of the Squeak License (i.e.: section 2 of the SqueakL, talking about "Modified Software")?
I seem to recall you saying at some point that these are two separate issues. Is this the source of our problem here? Let me elaborate. The SqueakL explicitly says that its viral aspects are only invoked when the "Modified Software" modifies 1. existing class objects or their relationships 2. the VM
So, a naive reader (me) might think that "as long as I publish changes that I make to existing classes, I can release the rest of my code under whatever license I want."
However, you have made it clear that this is not so, IIRC because some other provisions of copyright law take effect. Could you explain this? Why wouldn't this line of thinking also apply to a commercial Smalltalk? For example, if you write some code in commercial Smalltalk X, would you not then be required to release the code under the same license as your development environment? This seems absurd, and if it were the case, I would expect that no lawyer anywhere would ever advise their client that it is OK to develop code in any Smalltalk.
Is there something specific about the interaction between copyright law and the SqueakL that makes this scenario not work for code written in Squeak, but OK for code written in Commercial Smalltalk X?
I am confused.
One more example... [Regarding Andrew’s comment that “SqueakMap itself for example is a problem...the danger is, if it IS derived, for the poor saps who opt for the MIT prong for use outside of Squeak.]
Can you please define "derived" in this context? Is it based on the wording of section 2 of the SqueakL, or some other aspect of copyright law?
Jimmie Houchin: A couple quick comments. As regarding settling on a license. I, like Andrew, prefer the BSD License. http://www.opensource.org/licenses/bsd-license.php It is small. It is as free as the MIT license. It allows business to cover their legal backsides with a small no-endorsement clause. It is a very well known and well understood license. Apple is a consumer of BSD licensed software and consequently should understand what that means.
For these as well as others reasons I think the BSD license is possibly the best license for Squeak and to approach Apple for.
If Alan approaches Steve (Apple), another possibility is a complete transferal of copyright. What if we had a SqueakFoundation, legally incorporated with a board Apple respects, to which Apple could sell/transfer their "ownership/copyrights" of Squeak to? We could easily offer the same consideration that Apple gave Xerox for the rights it acquired to develop Squeak. Wasn't that $1? I'll write the check now. :)
This would relieve Apple of any and all legal responsibility and liability concerning Squeak. (Naive opinion from non-attorney with the possibility of correction. :) From that position it would be easy enough to redo the license to a BSD or Squeak Community License or some such. From that position we could approach Disney, et al. and either they re-license or assign their copyrights. Or worst case, we excise their code into a future-forward version of Squeak.
Separate from the above. I am not clear on Andrew's statements regarding licensing of new code. I understand if I am writing in Squeak (environment) my code, I am not in a clean room. However, if I don't modify anything in that environment by writ[ing] separate classes/code to perform my tasks. I would think I could establish the license at my discretion without regard to SqL.
But from my understanding of Andrew, that is not the case. Yes my code may be a user or consumer of Squeak code. But if I am not inheriting from other code... thought... I can't write classes without inheriting from SqL code (Object...) and thusly that would viral mine? Oh boy. Is that correct? That is a saddening thought. If that is the case it seems important to approach Apple or put effort into Squat, Slate, or even Smalltalk/X, etc...
Doug Way January 15, 2004: Currently, re-licensing Squeak, or seeking a transferal of copyright for all of Squeak (which is probably more difficult than re-licensing), is not really an option at the moment, for the reasons I mentioned in my email from two days ago: http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-January/072335.html To the other Guides and SqC, please correct me if I'm wrong in my above assessment. For now, regarding re-licensing, we're basically letting sleeping dogs lie as Alan said.
However, sublicensing, which is a different animal from re-licensing, is still a possibility to help us gain acceptance from the open source community. See my other discussion with Andrew on this.
January 15, 2004 Jimmie Houchin: [Regarding Doug Way’s opinion that “re-licensing Squeak... is not really an option at the moment”] ... I find allowing Disney to dissuade approaching Apple disappointing. I know Disney is not a software company. But Disney has released much (if not all) of their Java code as open source under the Apache license.
So Disney is not ignorant of open source or the advantages of open source. Neither Apple nor Disney really have anything to fear or lose from releasing Squeak. It can also be said that neither have much to gain. That is true. But both invested in Squeak without motives of explicit monetary gains from Squeak itself. Rather if both signed over to a Squeak Foundation, they could potentially free themselves from liability.
The question would still remain. If Apple was generous and acceded our request to either transfer copyrights or re-license under BSD or such, would Squeak's position be improved? Would we be better off, even if Disney did nothing? Would we be in a better position to talk to Disney? I think so. It would demonstrate another large multi-billion$$$ company thought this was a good thing to do.
What position would this put us in to create a Squeak base free from Disney if necessary?
[Regarding Alan’s comment] Letting sleeping dogs lies sounds fine. But the license does affect the community and peoples choosing the use of Squeak. I am trying to build/create a business. I don't want a sleeping dog to bite me in the behind. And if the SqL is as viral as I think Andrew is leading me/us to believe. It won't require one of the sleeping dogs to enforce the viral nature and require (or attempt to require) someone to release code that was never meant to be public. Unless I am mistaken, and I hope I am. That places business in a very tenuous position.
[Regarding sublicensing], Sublicensing is nice and can make better appearances. But can we sublicense away the viral nature? I don't know that we can do that.
Not trying to wake dogs, stir up a hornet’s nest or such. Like Göran seeking understanding. I do need to understand my business position and if Squeak is truly viable for business.
Goran Krampe January 16, 2004 [Regarding Doug Way’s opinion that “re-licensing Squeak... is not really an option at the moment”], I am not sure that it isn't a viable option. But Andrew can probably shed light on that. My naive reasoning:
It seems to me that Apple and Disney have no practical way of changing Squeak-L into something "more proprietary". Apple could do it for version 1.13 (or whichever was the last Apple version, circa 350 classes) - but hey, what would that give them? For a later version they need to be in agreement with Disney I assume, and many of us contributors.
Disney would have to be in agreement with Apple AND all of us contributors to do anything with their stuff. And ripping out the Apple core and all contributions seems pretty hard to do. So... if they simply transferred ownership to a proper SqF - wouldn't that actually be somewhat of a relief for them?
