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

[Guido van Rossum]

[MAL]
> > > Is the license on 2.0 going to look the same ? I mean we now
> > > already have two seperate licenses and if BeOpen adds another
> > > two or three paragraphs will end up with a license two pages
> > > long.

[GvR]
> > Good question.  We can't really keep the license the same because the
> > old license is very specific to CNRI.  I would personally be in favor
> > of using the BSD license for 2.0.

[MAL}
> If that's possible, I don't think we have to argue about the
> 1.6 license text at all ;-) ... but then: I seriously doubt that
> CNRI is going to let you put 2.0 under a different license text :-( ...

What will happen is that the licenses in effect all get concatenated
in the LICENSE file.  It's a drag.

> > > Some comments on the new version:
> > 
> > > > 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.
> > >
> > > I don't think the latter (retaining the CNRI license alone) is 
> > > possible: you always have to include the CWI license.
> > 
> > Wow.  I hadn't even noticed this!  It seems you can prepare a
> > derivative version of the license.  Well, maybe.
> 
> I think they mean "derivative version of Python 1.6b1", but in
> court, the above wording could cause serious trouble for CNRI

You're right of course, I misunderstood you *and* the license.  Kahn
explains it this way:

[Kahn]
| Ok. I take the point being made. The way english works with ellipsis or 
| anaphoric references is to link back to the last anchor point. In the above 
| case, the last referent is Python 1.6b1.
| 
| Thus, the last phrase refers to a derivative version of Python1.6b1 
| prepared by Licensee. There is no permission given to make a derivative 
| version of the License.

> ... it seems 2.0 can reuse the CWI license after all ;-)

I'm not sure why you think that: 2.0 is a derivative version and is
thus bound by the CNRI license as well as by the license that BeOpen
adds.

> > > > Alternately, in lieu of CNRI's License Agreement, Licensee may
> > > > substitute the following text (omitting the quotes): "Python 1.6, beta
> > > > 1, is made available subject to the terms and conditions in CNRI's
> > > > License Agreement.  This Agreement may be located on the Internet
> > > > using the following unique, persistent identifier (known as a handle):
> > > > 1895.22/1011.  This Agreement may also be obtained from a proxy server
> > > > on the Internet using the URL:http://hdl.handle.net/1895.22/1011".
> > >
> > > Do we really need this in the license text ? It's nice to have
> > > the text available on the Internet, but why add long descriptions
> > > about where to get it from to the license text itself ?
> > 
> > I'm not happy with this either, but CNRI can put anything they like in
> > their license, and they seem very fond of this particular bit of
> > advertising for their handle system.  I've never managed them to
> > convince them that it was unnecessary.
> 
> Oh well... the above paragraph sure looks scary to a casual
> license reader.

But it's really harmless.

> Also I'm not sure about the usefulness of this paragraph since
> the mapping of a URL to a content cannot be considered a
> legal binding. They would at least have to add some crypto
> signature of the license text to make verification of the
> origin possible.

Sure.  Just don't worry about it.  Kahn again:

| They always have the option of using the full text in that case.

So clearly he isn't interested in taking it out.  I'd let it go.

> > > > 3. In the event Licensee prepares a derivative work that is based on
> > > > or incorporates Python 1.6b1or any part thereof, and wants to make the
> > > > derivative work available to the public as provided herein, then
> > > > Licensee hereby agrees to indicate in any such work the nature of the
> > > > modifications made to Python 1.6b1.
> > >
> > > In what way would those indications have to be made ? A patch
> > > or just text describing the new features ?
> > 
> > Just text.  Bob Kahn told me that the list of "what's new" that I
> > always add to a release would be fine.
> 
> Ok, should be made explicit in the license though...

It's hard to specify this precisely -- in fact, the more precise you
specify it the more scary it looks and the more likely they are to be
able to find fault with the details of how you do it.  In this case, I
believe (and so do lawyers) that vague is good!  If you write "ported
to the Macintosh" and that's what you did, they can hardly argue with
you, can they?

> > > What does "make available to the public" mean ? If I embed
> > > Python in an application and make this application available
> > > on the Internet for download would this fit the meaning ?
> > 
> > Yes, that's why he doesn't use the word "publish" -- such an action
> > would not be considered publication in the sense of the copyright law
> > (at least not in the US, and probably not according to the Bern
> > convention) but it is clearly making it available to the public.
> 
> Ouch. That would mean I'd have to describe all additions,
> i.e. the embedding application, in most details in order not to
> breach the terms of the CNRI license.

No, additional modules aren't modifications to CNRI's work.  A change
to the syntax to support curly braces is.

> > > > 4. CNRI is making Python 1.6b1 available to Licensee on an "AS IS"
> > > > basis.  CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
> > > > IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND
> > > > DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
> > > > FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6b1 WILL NOT
> > > > INFRINGE ANY THIRD PARTY RIGHTS.
> > > >
> > > > 5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE
> > > > SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS
> > > > AS A RESULT OF USING, MODIFYING OR DISTRIBUTING PYTHON 1.6b1, OR ANY
> > > > DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.  SOME
> > > > STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY SO THE
> > > > ABOVE DISCLAIMER MAY NOT APPLY TO LICENSEE.
> > >
> > > I would make this "...SOME STATES AND COUNTRIES...". E.g. in
> > > Germany the above text would only be valid after an initial
> > > 6 month period after installation, AFAIK (this period is
> > > called "Gewährleistung"). Licenses from other vendors usually
> > > add some extra license text to limit the liability in this period
> > > to the carrier on which the software was received by the licensee,
> > > e.g. the diskettes or CDs.
> > 
> > I'll mention this to Kahn.

His response:

| Guido, Im not willing to do a study of international law here. If you
| can have the person identify one country other than the US that does
| not allow the above limitation or exclusion of liability and provide a
| copy of the section of their law, ill be happy to change this to read
| ".... SOME STATES OR COUNTRIES MAY NOT ALLOW ...." Otherwise, id just
| leave it alone (i.e. as is) for now.

Please mail this info directly to Kahn@CNRI.Reston.Va.US if you
believe you have the right information.  (You may CC me.)  Personally,
I wouldn't worry.  If the German law says that part of a license is
illegal, it doesn't make it any more or less illegal whether the
license warns you about this fact.

I believe that in the US, as a form of consumer protection, some
states not only disallow general disclaimers, but also require that
licenses containing such disclaimers notify the reader that the
disclaimer is not valid in their state, so that's where the language
comes from.  I don't know about German law.

> > > > 6. This License Agreement will automatically terminate upon a material
> > > > breach of its terms and conditions.
> > >
> > > Immediately ? Other licenses usually include a 30-60 day period
> > > which allows the licensee to take actions. With the above text,
> > > the license will put the Python copy in question into an illegal
> > > state *prior* to having even been identified as conflicting with the
> > > license.
> > 
> > Believe it or not, this is necessary to ensure GPL compatibility!  An
> > earlier draft had 30-60 days.  But the GPL doesn't, so this was deemed
> > incompatible.  There's an easy workaround though: you fix your
> > compliance and download a new copy, which gives you all the same
> > rights again.
> 
> Hmm, but what about the 100.000 copies of the embedding application
> that have already been downloaded -- I would have to force them
> to redownload the application (or even just a demo of it) in
> order to reestablish the lawfulness of the copy action.

It's better not to violate the license.  But do you really think that
they would go after you immediately if you show good intentions to
rectify?

> Not that I want to violate the license in any way, but there
> seem to be quite a few pitfalls in the present text, some of
> which are not clear at all (e.g. the paragraph 3).

I've warned Kahn about this effect of making the license bigger, but
he simply disagrees (and we agree to disagree).  I don't know what
else I could do about it, apart from putting a FAQ about the license
on python.org -- which I intend to do.

> > > > 7. This License Agreement shall be governed by and interpreted in all
> > > > respects by the law of the State of Virginia, excluding conflict of
> > > > law provisions.  Nothing in this License Agreement shall be deemed to
> > > > create any relationship of agency, partnership, or joint venture
> > > > between CNRI and Licensee.  This License Agreement does not grant
> > > > permission to use CNRI trademarks or trade name in a trademark sense
> > > > to endorse or promote products or services of Licensee, or any third
> > > > party.
> > >
> > > Would the name "Python" be considered a trademark in the above
> > > sense ?
> > 
> > No, Python is not a CNRI trademark.
> 
> I think you or BeOpen on behalf of you should consider
> registering the mark before someone else does it. There are
> quite a few "PYTHON" marks registered, yet all refer to non-
> computer business.

Yes, I do intend to do this.

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)