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

Thu Aug 3 08:14:55 EDT 2000

Guido van Rossum wrote:
>
> [...]
>
> > > > 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.

If you interpret the above wording in the sense of "preparing
a derivative version of the License Agreement", BeOpen (or
anyone else) could just remove the CNRI License text. I
understand that this is not intended (that's why I put the smiley
there ;-).

> [...] 
>
> > > > > 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?

True.

> > > > 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.

Ok, thanks for clarifying this.

(I guess the "vague is good" argument fits here as well.)

> > > > > 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 at 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.

I haven't found an English version of the German law text,
but this is the title of the law which handles German
business conditions:

"Gesetz zur Regelung des Rechts der Allgemeinen Geschäftsbedingungen
AGBG) - Act Governing Standard Business Conditions"

The relevant paragraph is no. 11 (10).

I'm not a lawyer, but from what I know:
terms generally excluding liability are invalid; liability
may be limited during the first 6 months after license
agreement and excluded after this initial period.

Anyway, you're right in that the notice about the paragraph
not necessarily applying to the licensee only has informational
character and that it doesn't do any harm otherwise.

> > > > > 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?

I don't intend to violate the license, but customers of 
an application embedding Python will have to agree to the
Python license to be able to legally use the Python engine
embedded in the application -- that is: if the application
unintensionally fails to meet the CNRI license terms
then the application as a whole would immediately become
unusable by the customer.

Now just think of an eCommerce application which produces
some $100k USD revenue each day... such a customer wouldn't
like these license terms at all :-(

BTW, I think that section 6. can be removed altogether, if
it doesn't include any reference to such a 30-60 day period:
the permissions set forth in a license are only valid in case
the license terms are adhered to whether it includes such
a section or not.

> > 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.

Good (or bad ? :-()

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/