Sublicensing

Daniel Vainsencher danielv at netvision.net.il
Fri Aug 15 20:05:38 UTC 2003



Joshua 'Schwa' Gargus <schwa at cc.gatech.edu> wrote:
> However, my suggested approach is careful to not be less protective of
> Apple's rights, even at the expense of not solving some license problems
> that we'd like to be solved.  It is the same as the old license, except it
> extends the disclaimer of warranty, liability, etc. to parties other than
> Apple.  Of course, IANAL, but I have difficulty seeing how this could be
> construed to be less protective of Apple and Apple's rights.  
> 
> Do you plan to speak with Haim again?  You could ask him about this specific
> case. 
I'm sorry I didn't make this clear before - I asked him that precise
question - can we either somehow remove that limitation or at least make
it more fair. I described the technique used by the CPL, which is
similar to what you advocate (commercial distributors must indemnify
everyone else). His response was that which I conveyed before - any
tricky sublicensing creates a risk of retroactively being found "less
protective" and therefore a copyright infringement.

> Or would Andrew care to weigh in with his opinion?  Also, if we're 
> considering actually paying a lawyer, instead of just milking them for free
> legal advice ;-), why don't we pay Andrew instead?
I believe that if someone decides to pursue this avenue, they should
indeed budget some serious lawyer time, and be willing to accept a
solution that will not be fool-proof. However, I'm becoming somewhat
reluctant about sublicensing from a slightly different POV - I think the
healthy thing to do long term is to secure a codebase which presents
fewer risks by being truly freely licensed. This is not a short term
goal obviously, but it seems better to me than the community engaging in
exploratory licensing.

> > Now, this lawyer is not a copyright/opensource expert, and it is
> > possible we'll find someone more confident about getting smart. But I
> > think we need to start planning on solving this problem by organizing
> > *and by coding*, rather than by PR, lawyers or licensing. I say this
> > quite sadly, because this will not be easy to do :-( OTOH, it could be
> > fun. Anyone care to design a new VM? :-)
> Sounds like at least Anthony Hannan is thinking about it.
Hey, AFAIK, he wants to change everything at once. For the purposes of
this discussion, I want to change as little as possible, for a new
implementation. Of course, if we consider free licensing a important
value when thinking about contributions, we can definitely be more
liberal about other things. For example, Anthonys Squeak parser, which
is freely licensed itself, but generated using an unclearly licensed
SmaCC, could be considered better licensed than Squeaks own... 

> I don't have reams of code in the image, but FWIW, all of my code which as
> made it into the image is hereby licensed under the MIT license.
> 
> Joshua
This is exactly the spirit we'll need, but if we seriously want to move
towards solving this issue, we'll need to be more methodical. Otherwise
open questions remain like, what is the status of code you contribute
tommorow? 

I think some steps should be -
1. To announce, and include in the web documentation, and in the list
information that any code sent to the list is dual licensed by default
under the MIT and SqueakL (as opposed to just SqueakL right now).
2. To make a point of replacing entire mechanisms, rather than
refactoring existing ones. For example, the kind of work KCP does right
now doesn't improve our license status at all. However, a newly
implemented kernel (MIT licensed) could. This makes it quite a bit
harder to keep the system stable, but it isn't impossible.
3. Learn from other projects. Some (Python) have non-profit foundations
that hold copyright for key parts of the system. I don't know what
exactly is appropriate for us, but we should think about it.
4. Search for existing, freely licensed codebases. I know
LittleSmalltalk doesn't compare to Squeak, but parts of it might be able
to replace parts of Squeak (and then filled out by the community).
StrongTalk's code carries a hilarious*, but (unless I'm missing
something) very free license, so maybe we could reuse part of that.
5. To start keeping track of what parts of the code are already
completely free, and which aren't. This isn't that hard - small fixes
don't matter for this, only clean rewrites. This is important so that we
know what still needs to be replaced.

* - Qouting - "You acknowledge that Software is not designed, licensed
or intended for use in the design, construction, operation or
maintenance of any nuclear facility."

Daniel



More information about the Squeak-dev mailing list