How to License your package
Last updated at 3:55 pm UTC on 14 January 2006
[Subsequent to, but I think independently of the intense discussion about the license, Samir raises the question from the point of view of the package developer.]
License application how you want but modifications under Squeak-L
Samir Saidani January 20, 2004: I'm about to release new packages on SqueakMap and these packages need to modify some squeak base classes (hence in Squeak-L) in order to work properly. So if they modify these classes, I guess I have to release all the packages under the Squeak-L, but I don't want, mainly because of the exportation clause.
So I take a look on several packages on SqueakMap, to get a feeling on what is the common usage, and I notice two different strategies:
- People who release their contribution on Squeak base classes (in Squeak-L) in a package different from their main contribution, the> application (in MIT Licence or whatever)
- People who don't distinguish between their contribution to the core of Squeak and their application, and they sometimes choose the MIT License or another one, (eg. StarBrowser, Refactoring Browser...) which seems to me illegal according to the terms of Squeak-L.
NB: I found it quite funny and interesting that license problems force us to clarify our packaging policy... Our problems help us !
That’s the safest way, but may not be completely safe
Goran Krampe I Am Not A Lawyer - the following just reflects what I believe to be true.
According to Squeak-L you only need to publish your base changes according the rules explained in the license - not the whole package.
[Regarding the strategy of not distinguishing between their contribution to the core of Squeak and their application, and choosing a non Squeak-L License for the whole “which seems illegal according to the terms of Squeak-L”] Exactly. This is something that have come more into light recently. Releasing modifications to base classes under MIT is clearly against Squeak-L. AFAICT. They needn't be released under exactly Squeak-L but in practice it is easiest to just pick Squeak-L.
We have been using a dual license (Squeak-L/MIT) for quite a few packages and we all need to revisit that decision. Personally I am moving a few of my packages over to Squeak-L only for the time being. I don't like it - but since we don't have a proper "SqueakSub-L-template" to use yet...
Regarding if you can develop non base modifications (apps) and release those (separately from the image) under MIT has also been discussed and Andrew Greenberg says that his view is that you can't even do that - at least not without doubt. The problem (if I understood him correctly) lies in being sure that your app can not be considered to be a "base modification".
I do want to say that his view might be considered a bit "on the safe side" since he is talking about community code - it sure is a good thing to be paranoid when it comes to that. I am not sure how paranoid you would need to be if you were a company or a private individual.
Not sure Apple Software includes Modified Software
Lothar Schenk: I am not a lawyer, either, so I reserve the right of being wrong with anything I tell you. ;-)
The first distinction I think that needs to be made in the Squeak-L is between what is called there "Apple Software", what is called "Modified Software" and what is not covered there explicitly and what may be called "Third Party Software".
The term "Apple Software" is defined in Paragraph 1 as "the software, documentation and any fonts which you will receive by downloading this software". Of course, calling it "Apple Software" only makes sense in relation to software owned by Apple. This is clearly the case with the original contributions by Apple.
The term "Modified Software" is introduced in Paragraph 2, where it says "You may modify and create derivative works of the Apple Software" and this is then called "Modified Software". A derivative work in copyright law is any work that incorporates pieces of another copyrighted work, for example a screen play based on a novel. It has to be substantially different to be considered a work that's copyrightable by itself. What is substantially different is open to question and lastly determined authoritatively only in a court of law on a case by case basis. I think what the Squeak-L calls a "modification" of the Apple Software is a work that cannot be considered to be substantially different to be called a derivative work.
Now, as to this "Modified Software", which includes, it should be kept in mind, any derivative work, it is said in Paragraph 2 that: "If the Modified Software contains modifications, overwrites, replacements, deletions, additions, or ports to new platforms of: (1) the methods of existing class objects or their existing relationships, or (2) any part of the virtual machine, then for so long as the Modified Software is distributed or sublicensed to others, such modified, overwritten, replaced, deleted, added and ported portions of the Modified Software must be made publicly available ... at no charge under the terms set forth in Exhibit A below.
To me, there are several conclusions from that:
(1) If you make a derivative work and keep it privately to yourself (i.e. do not distribute or sublicense it) you need not make anything of it available, not even the modified portions.
(2) Not all portions of a derivative work need to be made publicly available. Only if your work contains modifications etc. of either the virtual machine, or the methods of existing class objects or their relationships. And only the modified portions need to be made available.
(3) If your work does not modify anything in the existing VM or image, you need not make anything publicly available. It is interesting to note that the terms of Exhibit A, under which you have to release modified portions do not refer to the export clause, indemnification of Apple etc. as does Squeak-L itself.
Note also, that all these clauses refer specifically to "Apple Software" and not "Modified Software".
What I CANNOT tell you, however, is, if "Apple Software" is to be seen as inclusive or exclusive of "Modified Software". I think, Andrew Greenberg could clear this up, for sure.
If it were inclusive, all of these clauses would still pertain to modified portions (but not to your own portions if you chose differently). If it were exclusive, they wouldn't and only Exhibit A would be pertinent.
So, Andrew, if you have the time, can you confirm or reject my understanding of these matters and also clarify the status of "Apple Software" vs. "Modified Software"?
Doubts there is a distinction
Goran Krampe: [Regarding the observation that the terms under which you must release modified portions do not refer to the export clause, indemnification of Apple etc. as does Squeak-L itself.]
This is what I called the "loop hole" on some occasion in the past. But another interpretation is that Exhibit A is additional to the other clauses in Squeak-L. Here is the relevant piece:
"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. You may distribute and sublicense the Fonts only as a part of and for use with Modified Software, and not as a part of or for use with Modified Software that is distributed or sublicensed for a fee or for other valuable consideration. If the Modified Software contains modifications, overwrites, replacements, deletions, additions, or ports to new platforms of: (1) the methods of existing class objects or their existing relationships, or (2) any part of the virtual machine, then for so long as the Modified Software is distributed or sublicensed to others, such modified, overwritten, replaced, deleted, added and ported portions of the Modified Software must be made publicly available, preferably by means of download from a website, at no charge under the terms set forth in Exhibit A below."
I personally read the last line as meaning "under the exact terms in Exhibit A and nothing more or less". But Craig Latta read this as "under the terms set forth in Exhibit A and also of course also 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" - since he thought that the first sentence also refers to those parts in "Modified Software" that constitute the base modifications.
Again, IANAL and can't say which interpretation is the correct one - though I am leaning towards Craig being right.
So much for that loophole! :)
Maybe
Lothar Schenk [Regarding the observation that the terms under which you must release modified portions do not refer to the export clause, indemnification of Apple etc. as does Squeak-L itself.]
Here is how I understand this:
Exhibit A is not an additional clause in the Squeak-L. It is a wording of the (minimal) license under which you must release modified portions of the base software. It is viral in that further modifications of modified portions ("Changed Software") must again be made available (at least) under the license worded in Exhibit A.
If I distribute unmodified portions of the original Apple Software, they would still be covered by the Squeak-L If I distribute modified portions as indicated and required by paragraph 2, then Exhibit A is a preformulated wording of the license I have to use or must include in my own license, if I have additional terms.
[Modified Software] in Exhibit A takes the place of "Apple Software" in Squeak-L, and "Changed Software" in Exhibit A takes the place of "Modified Software" in Squeak-L. In this recursive fashion, Exhibit A repeats the provisions of Paragraph 2 in Squeak-L for the [Modified Software].
Apple's further rights according to the Squeak-L are implicated in Exhibit A by the provision that further modifications of the [Modified Software] must again be licensed under a license which is "no less protective of [the licensors of the Modified Software]" (which might be you or me) "and its licensors" (and this chain will eventually end with Apple). So, any code that has any connection to original Apple code is either under Squeak-L itself (if unmodified) or under Exhibit A, and Apple's rights have to be protected.
If I understand this correctly, then if I were to release any modifications I make solely under the license worded in Exhibit A with no additional clauses, then Apple's rights would automatically be sufficiently protected.
Now, what of those parts of an application which are not modifications of the existing software? I think the question of crucial importance here is if it has to be considered as "derivative work" or not. Because in the case of a derivative work, Paragraph 2 of Squeak-L imposes restrictions on the license I can use, in that said license "makes no representations or warranties on behalf of Apple, and is no less protective of Apple and Apple's rights than this License". If it is not a derivative work (wholly original), you can, of course, do whatever you like. But as Andrew has cautioned, given code similarity, it might not be possible to draw the line between derivative and non-derivative clearly enough in a legal challenge, because of Squeak development practices.
Okay, I await corrections and further insights by those more knowledgeable than me. :)
