ask for APSL? for real this time?
Andrew C. Greenberg
werdna at mucow.com
Mon Jan 12 22:39:55 UTC 2004
On Jan 12, 2004, at 4:14 AM, goran.krampe at bluefish.se wrote:
> Hi Andrew and all!
> Since you still haven't responded regarding the quote I will for now
> conclude that it probably is for reasons unknown to me (what do I know)
> and I have instead selected a single question to ask you in hope for a
Goran, I'm not sure why you are being so beligerent. While I never
considered the "quote" you so frequently refer to as contrary to my
present position, I intended the quoted portion below missive to be the
detailed response you were seeking, placing your expansive reading of
my prior remarks in a clearer context, hopefully so we can find a basis
for mutual understanding. In particular, it was intended to answer
your specific question.
> Regarding the quote: It simply seems to me that you have changed your
> mind regarding what can be considered a modified work - and that is the
> source for the change in attitude towards dual licensing of
I don't agree that I have changed my mind, but it doesn't matter. As
to the practice you now thing was based upon my advices, this is my
Don't do it any more. Stop. Fix it. Please.
> "Andrew C. Greenberg" <werdna at mucow.com> wrote:
>> 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
>> 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.
> Reading this and also further down in your posting you wrote:
> "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."
> ...leading me to wondering if you then think that the following
> 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
> 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
> 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
> "no less protective of Apple and Apple's rights than this License".
> So Andrew, is this an at least somewhat correct interpretation of the
> siuation? :)
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
stuck in the image is likely Squeak-L, regardless how the author wants
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. My advice concerning the present
practice is this:
Don't do it any more. Stop. Fix it. Please.
Certainly don't continue it in my name.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2361 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040112/90748522/smime.bin
More information about the Squeak-dev