ask for APSL? for real this time?
Andrew C. Greenberg
werdna at mucow.com
Sat Jan 10 17:38:02 UTC 2004
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
to:
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.
if that is too lawyerly, please consider this lay statement.
Don't do it any more. Fix it. Stop. Please.
That is my position. It is not my view as to whether or not the
liberalizing of Squeak-L would be a good thing. To be clear, I LIKE
BPL -- heck, if there were no liability issues that can be avoided with
disclaimers of warranty, I would like public domain dedication for free
software. When I say "don't do it," I am not stating whether I think
it would or would not be a good thing -- I am commenting about whether
it might legally compromise the product or the community.
Note please, it is not my opinion that every circumstance where this is
done will immediately yield a paralyzing lawsuit bankrupting every
reader of this e-mail. I am stating that the general practice could
never be approved by a lawyer -- and a policy requiring case-by-case
analysis would be impractical and error-prone. Licensing is
necessarily a conservative business -- the idea of EVERY contract is to
minimize to the extent practicable the possibility of mistake or
confusion. We lawyers write in gobbledegook because we write not so we
can be easily understood, but rather so that we cannot be
misunderstood.
Under the present practice, I believe that a lawyer being asked by an
individual, "can I make this out of squeak and do ____" would probably
review this and other practices and respond -- "it depends on many
things, any conclusive opinion would require a tremendously expensive
analysis -- try Ruby or Python instead -- I can answer your question
for those products." In my view, that would be a bad thing.
There is a way to liberalize licensing of the product -- this is not
it. It can't be done this way.
Once again, I strongly recommend the following:
Stop. Fix it. Don't do it any more. Please.
2. On other situations I have discussed in the past.
I have in the past been asked whether a GPL'd or LGPL'd product could
be distributed with Squeak. Each case required a careful analysis, and
in some cases the answer was alternatively, "No," "Yes, if we can talk
the owner into a dual license," or "Maybe, but it is risky." These
were done case-by-case, and the decisions made by SqC and others would
be made under a totality of circumstances in view of all of the
relevant factors. Very useful code was not incorporated in the past,
and very useful code was.
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. The code runs
without modification in Squeak. We have no doubt as to the pedigree or
origin of the code. The code is broadly licensed under a very liberal
license that permits others to relicense the code under a more
restrictive license without consultation.
In such a case, it is possible that such code could be distributed in
the image under Squeak-L (possibly a more limited conjunctive license),
or outside the image under a dual license with the understanding that
once incorporated into the image, the code becomes Squeak-L (the more
liberal disjunctive arm of the license is only for uses where the code
is NOT used with squeak). In many such cases, we may be able to
distribute the code without problem.
This is a narrow hypothetical, and the devil is in the details. For
example, assume that to make it run in Squeak, you must first load the
changeset, make "minor" modifications, and then extract the modified
code for use with Squeak. Could this code be extracted and dual
licensed? The devil is in the details. The safest way would be to
have the original unmodified code distributed by itself, together with
a Squeak-L only changeset embodying the modifications.
Even this hypothetical is dramatically narrower than the more general
circumstance under which SqF seems presently to be operating.
3. On my general inability to spend more time than I have with Squeak
this month.
I am simply not able to offer more time than I have. Notwithstanding
the suggestion that I do not carefully enough read these threads, or
that I somehow should spend more time more carefully detailing the
bases for these conclusions, I still don't have more time than I have.
Sorry, but that's the way it is when you have a 70 witness, 10 week
trial (involving, by the way, FAR SIMPLER IP issues) looming in your
near future.
CONCLUSION
Stop it. Fix it. Don't do it any more. Please.
-------------- 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/20040110/2fca92ef/smime.bin
More information about the Squeak-dev
mailing list
|