[Python-Dev] Still no new license -- but draft text available

Gary Momarison nobody at phony.org
Fri Aug 4 16:54:47 EDT 2000


Tim, I'm glad to have had a response from you, who I have found (in
reading the last few days of posts) to be a good thinker and writer. 
(I'm new to the newsgroup). I'm sorry you didn't feel qualified
to address my main issue more directly, but I hope the exchange will
help me and others who will need to be involved in composing or
selecting a license in the future.

"Tim Peters" <tim_one at email.msn.com> writes:

> [From the proposed CNRI Open Source License]
> > 2. Subject to the terms and conditions of this License Agreement, CNRI
> > hereby grants Licensee a nonexclusive, royalty-free, world-wide
> > license to reproduce, analyze, test, perform and/or display publicly,
> > prepare derivative works, distribute, and otherwise use Python 1.6b1
> > alone or in any derivative version, provided, however, that CNRI's
> > License Agreement is retained in Python 1.6b1, alone or in any
> > derivative version prepared by Licensee.
> 
...
> 
> Is there *any* OSI-certified and GPL-compatible license that does not rub
> you the wrong way?
>
IIRC, the old MIT license (if one may call it a license) doesn't (on
this point).  The BSD license comes close and could easily be made clear
about it.  The BSD license, if you interpret it literally, doesn't
require one to retain in derivatives the sentence that says you are
pretty much free to do anything with it; just the copyright claim, the
"list", and the disclaimers.  (I would call that an unnatural
interpretation, but that's the meat & potatoes of lawyers and might be a
winner in court, especially since it achieves the results probably
intended by most BSD licensors -- others go for GPL variants.)

It would be simple to fix any of these licenses to be clear about
what terms the licensor requires to be in the licenses of derivatives.

It should be noted that the licensor's original license always covers
his code in derivatives regardless of the existence of any license copy.
The question is whether the derivative is covered by it, especially if
it requires a copy of the license in the derivative and it does not
explicitly permit license changes.

I suspect that the law says you own a share of a derivative (it is
a "joint" or "collective" work in the terms of USC 17) and nobody 
may change the licensing without your explicit permission.

> 
> > That "...provided, however, that CNRI's License Agreement is
> > retained" clause looks deadly to me.  If a derivative work retains
> > that License while also getting some new License which most people
> > would want to apply, then conflicts seem inevitable.
...
> When people asked Guido about stuff like this wrt the CWI license, his
> response was that the inherited license clearly <wink> applied only to the
> inherited part of the combined product, in effect to keep a record of the
> legal history of the software you started with and to prevent CWI from
> getting sued.  But note this from the CNRI license text:

I doubt that such a record of history has much legal standing if all of
the license's terms are not to be considered contractual as a whole.
By what reasoning can one pick and choose terms to be considered
contractual in derivatives (unless it is explicitly stated in the
original license)?

> getting sued.  But note this from the CNRI license text:
> 
>     Licensee [has a] nonexclusive [etc] license to reproduce [etc]
>     and otherwise use Python 1.6b1 alone or in any derivative version
>     [yadda yadda yadda]
> 
> It does *not* say Licensee has a license to do all that stuff with your
> derivative work, it explicitly names Python 1.6b1 as the only thing they're
> getting a license for (and they should!  you most certainly are not getting
> the right to prevent anyone else from using Python 1.6b1, derivative work or
> not).  The CWI license was much muddier on this point to my eyes.

Obviously. It ends with "derivative version prepared by Licensee".

>
...
> Are you a lawyer?  I don't see a justification for much of what goes on in
> Perl either, but then neither am I Perler by training <wink>.  That is, if
> you're not trained in the law, how could anyone satisfy you?  A killer
> argument to a lawyer isn't a Usenet-y argument from first principles, it's
> usually based on a long string of citations into the massive body of case
> law, statutes and precedents that are *their* language of discourse.  I know
> I couldn't tell a good legal argument from a bad one if it bit me on the
> ass.

You underestimate yourself.  Neither of us are lawyers, but that doesn't
mean we can't talk about our understanding of licenses and to try to
help compose ones that are understandable to laymen.  After all, it is
we that sue and get sued, not the lawyers.  Remember that all of these
licenses that some lawyers think are bone-headed were OKed by many other
lawyers in many different situations.  There are many laymen who have
become more knowledgeable about a very specialized topic than even most
specialist lawyers (who have many other things to worry about). I am
not one of them, obviously.

...
> > But I ask this: What does "is retained" mean?  What are the
> > implications?  By what legal theory do licenses "stack"?
> > If the derivative retains the original license which gives me
> > a right, why must I observe some other license which trys to
> > take it away?  I have no way of knowing what code is original
> > and which is not.

I sure wish someone would address these issues, lawyer or not.

...
> 
> We asked RMS to negotiate with CNRI solely to resolve the issue of GPL
> compatibility, and I agree that's got almost nothing to say to people
> interested in proprietary uses.

Unfortunately, all uses of copyrighted material are proprietary uses.  
That's why we're having all this grief.  Otherwise, you could just tell
RMS to go away.  My point was just that RMS's "ruling" on this license
is irrelevant except to the extent that his well-informed but
non-lawyer's opinion influences potential licensors and licensees. You
probably should care about that to popularize Python, but it has nothing 
to do with the validity of the license in court.  RMS's "ruling" won't 
be a factor in court.

You go on to say, basically, that nobody's opinion matters.  That's
probably true regarding the Python license, if CNRI doesn't bother
reading this newsgroup. Likewise, they are unlikely to consider the
opinion of anyone who's reputation they don't respect no matter how
delivered.  But we can hope that these discussions would have some
influence on people who will be dealing with licenses in the future.

In case it wasn't clear: anyone who agrees with my understanding of 
clause 2 should find the GPL incompatible with the Python license.

As a totally separate issue, let me state that some people find that the
following clause of the GPL makes the GPL incompatable with any license
that isn't essentially identical with the GPL, the fanciful words of RMS
and his lawyers notwithstanding.

    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

P.S. I'm sorry if I seemed to imply that I was developing a Python
derivative.  I'm not.  I just find the subject interesting and hope
that more discussion of some issues will result in better-crafted 
licenses in the future.  I'd hate to see everyone just give up
on freer-than-GPL licenses just because they are confusing or
poorly written from a legal/corporate perspective.  Let's hope the 
new Python license is an improvement or at least contains some 
stuff that will lead to improvements.



More information about the Python-list mailing list