ask for APSL? for real this time?
Andrew C. Greenberg
werdna at mucow.com
Fri Jan 9 15:43:48 UTC 2004
To be clear. It is my conclusion (a considered view of a seasoned
intellectual property attorney) that plural licensing will kill the
project and make it absolutely impossible to make changes in the
future. Nothing I wrote here undercuts that conclusion. Please, for
G-d's sake, don't do it.
In the real world, you don't want technicians to make legal decisions
regarding the licensing of their code. Whether code is derived or not
is not a trivial issue, and certainly not a trivial issue if litigation
of any kind is implicated in a business decision. Having dual
licensing will yield little or no advantage, and may give rise to
later-insurmountable problems that could be resolved now if we
On Jan 8, 2004, at 8:11 AM, goran.krampe at bluefish.se wrote:
> "Andrew C. Greenberg" <werdna at mucow.com> wrote:
>> Were you my client, I would advise strongly against it. It is a
>> for confusion and later contentious dispute. Sure, if code is
>> in the sense of having no derivation whatsoever from the existing=20
>> image, no problem.
> Eh... that was what I said. Why are you then first advising strongly
> against it, and then saying "no problem"? I am confused. I thought we
> were in clear agreement earlier that dual licensing (MIT/SqueakL) for
> contributions (not modifications) to base Squeak was appropriate since
> we (at least earlier) had agreed that we wanted all base Squeak under
> ONE license.
>> But how will we later take any significant block of=20=
>> code and actually know what license applies, and to what portions
> For these added base package it is clear: SM tells you the license.
>> Dual-licensing some of the code will not clarify the issue, nor will
>> solve the problem, if there is any problem at all.
> Lost me again. Earlier you argued very strongly for keeping base Squeak
> under a single license - SqueakL - and now you argue that doing that
> through dual licensing is the wrong way.
>> It would be far,=20
>> far more sensible to start from scratch and rebuild a new Smalltalk.
>> The fact that nobody has bothered has much to do with the fact that
>> license isn't really a problem.
> There are at least 3 efforts ongoing that I know of:
> - Slate (though not motivated by license issues - it is a new
> "Smalltalk" implementation under MIT)
> - Squat (Craigs from-the-ground-up project with the license issue as a
> base ingredience AFAICT)
> - TFNR/partitioning-the-image (The community's effort of defining the
> image in clear packages)
>> Best solution is to involve Apple with a plan, AFTER WE OURSELVES
>> A CONSENSUS what plan to undertake.
> Personally I have a hard problem seeing how to deal with the other Big
> Player. And I am still to be convinced that the work done there is not
> regards, Göran
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2361 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040109/0c346895/smime.bin
More information about the Squeak-dev