ask for APSL? for real this time?
Andrew C. Greenberg
werdna at mucow.com
Sat Jan 10 00:22:26 UTC 2004
On Jan 9, 2004, at 11:30 AM, goran.krampe at bluefish.se wrote:
>> In the real world, you don't want technicians to make legal decisions
>> regarding the licensing of their code.
>
> This is the "open source" world where both companies AND individuals
> are
> authors.
Of course. I presume that the open source world likewise lives in the
real world. I am counsel, pro bono and for pay, for many open source
projects, and my comments are directed to all players.
> When an individual is the author, typically making something in his
> spare time, he will simply have to do as best he or she can. This isn't
> the corporate world Andrew, we are simply forced to make these
> decisions
> ourselves.
Nonsense -- nobody needs to make any decisions at all. We can do much
better. We can avoid ENTIRELY any chance that an individual is
infecting the community's project with invalidly licensed code by
insisting upon licensing standards. Squeak-L has done quite well for
years in precisely this manner.
> I am the author of *my* code and I bloody well *will* decide how I
> license it.
Of course, and that's fair enough. it would be my recommendation to
the community, however, that code you offer to the community under a
different license not be incorporated into a general release.
>> Whether code is derived or not
>> is not a trivial issue, and certainly not a trivial issue if
>> litigation
>
> I would seriously hope that if I write an app in Squeak without
> touching
> the existing classes - just using them, then that app is clearly
> *according to Squeak-L* not a derived work of Squeak itself. If that is
> not so then PLEASE tell us, because I assume many of us would like to
> know that.
It is not necessarily so. You have been told.
>> 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
>> responded promptly.
>
> I think this is the last time I will ever bother to respond to you
> Andrew because I am so fed up with trying to discuss something with you
> when you only respond to pieces that you pick at your leisure, or
> simply
> not bother to respond at all.
As i wrote seperately, I am sorry you feel so troubled about my
advices. I have written legions about these issues in the past, and I
do tend to condense my comments to a shorthand these days, particularly
now when i have so very little time. It is absolutely true that I
don't have a great deal of time to respond in depth to each new
request. As I have noted, please at least understand it comes from a
mutual love of Squeak -- I want to SOLVE our licensing problem, and am
very fearful that your proposed path will exacerbate the issue.
Can we, at least, first see if we can come to consensus as to what
license, if any, to which we might shift if at all? That is to say, is
there any license for which EVERY person who's initials appear in the
code can either:
1) firmly adopt; or at least
2) agree to consent to shift the code over
which also might have at least a reasonable shot of getting consent
once we bring it to the appropriate level at the several corporate
sponsors? If not, I would strongly recommend just dealing with
Squeak-L, and alas, shunning any non-conforming code from general
distribution.
For my part, I can be talked into almost anything that is not
monolithic image incompatible. While I like the safe and quasi-viral
aspects of Squeak-L, I would not oppose a BPL-like license. I am not a
partisan of APSL, but I do consider that Apple would be far more likely
to consent to APSL than to BPL. I understand that Cees believes he has
fathomed this issue, but I sincerely believe that a concerted approach
after proper preparation, supported by the illuminati (Alan and cabal)
and directed to executives well above the "manager" position, further
supported by competent counsel to negotiate issues properly, would fare
much better.
I don't believe that Apple would seriously consider any inquiry that
would be impractical, or lead to any litigation downside for them. Nor
would they treat us seriously if we don't treat our own community
seriously enough. No kidding, but language along the lines of goran's
intemperate language earlier is not likely to help the matter at all.
Once the code is BPL'd or APSL'd, we can move forward with much greater
ease.
So, once again, is there a consensus among actual and legitimate
stakeholders, whose code is presently distributed in the core image and
necessary modules, as to what license they might accept in lieu of
Squeak-L?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2361 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040109/dad5dd4c/smime.bin
More information about the Squeak-dev
mailing list
|