The Python 1.6 License Explained

Guido van Rossum guido at beopen.com
Wed Aug 23 18:04:32 EDT 2000


With BeOpen's help, CNRI has prepared a FAQ about the new license
which should answer those questions.  The official URL for the Python
1.6 license FAQ is http://www.python.org/1.6/license_faq.html (soon on
a mirror site near you), but I'm also appending it here.

We expect that we will be able to issue the final 1.6 release very
soon.  We're also working hard on the first beta release of Python
2.0, slated for September 4; the final 2.0 release should be ready in
October.  See http://www.pythonlabs.com/tech/python2.html for
up-to-date 2.0 information.

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

Python 1.6 License FAQ

This FAQ addresses questions concerning the CNRI Open Source License
and its impact on past and future Python releases. The text below has
been approved for posting on the Python website and newsgroup by
CNRI's president, Dr. Robert E. Kahn.

    1.The old Python license from CWI worked well for almost 10
    years. Why a new license for Python 1.6?

      CNRI claims copyright in Python code and documentation from
      releases 1.3 through 1.6 inclusive.  However, for a number of
      technical reasons, CNRI never formally licensed this work for
      Internet download, although it did permit Guido to share the
      results with the Python community. As none of this work was
      published either, there were no CNRI copyright notices placed on
      these Python releases prior to 1.6. A CNRI copyright notice will
      appear on the official release of Python 1.6. The CNRI license
      was created to clarify for all users that CNRI's intent is to
      enable Python extensions to be developed in an extremely open
      form, in the best interests of the Python community.

    2.Why isn't the new CNRI license as short and simple as the CWI
    license? Are there any issues with it?

      A license is a legally binding document, and the CNRI Open
      Source License is-- according to CNRI --as simple as they were
      able to make it at this time while still maintaining a balance
      between the need for access and other use of Python with CNRI's
      rights.

    3.Are you saying that the CWI license did not protect our rights?

      CNRI has held copyright and other rights to the code but never
      codified them into a CNRI-blessed license prior to 1.6. The CNRI
      Open Source License is a binding contract between CNRI and
      Python 1.6's users and, unlike the CWI statement, cannot be
      revoked except for a material breach of its terms.  So this
      provides a licensing certainty to Python users that never really
      existed before.

    4.What is CNRI's position on prior Python releases, e.g. Python
    1.5.2?

      Releases of Python prior to 1.6 were shared with the community
      without a formal license from CNRI.  The CWI Copyright Notice
      and Permissions statement (which was included with Python
      releases prior to 1.6b1), as well as the combined CWI-CNRI
      disclaimer, were required to be included as a condition for
      using the prior Python software. CNRI does not intend to require
      users of prior versions of Python to upgrade to 1.6 unless they
      voluntarily choose to do so.

    5.OK, on to the new license. Is it an Open Source license?

      Yes. The board of the Open Source Initiative certified the CNRI
      Open Source License as being fully Open Source compliant.

    6.Has it been approved by the Python Consortium?

      Yes, the Python Consortium members approved the new CNRI Open
      Source License at a meeting of the Python Consortium on Friday,
      July 21, 2000 in Monterey, California.

    7.Is it compatible with the GNU Public License (GPL)?

      Legal counsel for both CNRI and BeOpen.com believe that it is
      fully compatible with the GPL. However, the Free Software
      Foundation attorney and Richard Stallman believe there may be
      one incompatibility, i.e., the CNRI License specifies a legal
      venue to interpret its License while the GPL is silent on the
      issue of jurisdiction. Resolution of this issue is being
      pursued.

    8.So that means it has a GPL-like "copyleft" provision?

      No. "GPL-compatible" means that code licensed under the terms of
      the CNRI Open Source License may be combined with GPLed
      code. The CNRI license imposes fewer restrictions than does the
      GPL.  There is no "copyleft" provision in the CNRI Open Source
      License.

    9.So it supports proprietary ("closed source") use of Python too?

      Yes, provided you abide by the terms of the CNRI license and
      also include the CWI Copyright Notice and Permissions Statement.

   10.I have some questions about those! First, about the "click to
   accept" business. What if I have a derivative work that has no GUI?

      As the text says, "COPYING, INSTALLING OR OTHERWISE USING THE
      SOFTWARE" also constitutes agreement to the terms of the
      license, so there is no requirement to use the click to accept
      button if that is not appropriate. CNRI prefers to offer the
      software via the Internet by first presenting the License and
      having a prospective user click an Accept button. Others may
      offer it in different forms (e.g.  CD-ROM) and thus clicking the
      Accept button is one means but not the only one.

   11.Virginia is one of the few states to have adopted the Uniform
   Computer Information Transactions Act, and paragraph 7 requires
   that the license be interpreted under Virginia law.  Is the "click
   clause" a way to invoke UCITA?

      CNRI needs a body of law to define what its License means, and,
      since its headquarters are in Virginia, Virginia law is a
      logical choice. The adoption of UCITA in Virginia was not a
      motivating factor. If CNRI didn't require that its License be
      interpreted under Virginia law, then anyone could interpret the
      license under very different laws than the ones under which it
      is intended to be interpreted. In particular in a jurisdiction
      that does not recognize general disclaimers of liability (such
      as in CNRI license's paragraphs 4 and 5).

   12.Suppose I embed Python in an application such that the user
   neither knows nor cares about the existence of Python. Does the
   install process have to inform my app's users about the CNRI
   license anyway?

      No, the license does not specify this. For example, in addition
      to including the License text in the License file of a program
      (or in the installer as well), you could just include a
      reference to it in the Readme file.  There is also no need to
      include the full License text in the program (the License
      provides for an alternative reference using the specified handle
      citation). Usage of the software amounts to license acceptance.

   13.In paragraph 2, does "provided, however, that CNRI's License
   Agreement is retained in Python 1.6 beta 1, alone or in any
   derivative version prepared by Licensee" mean that I can make and
   retain a derivative version of the license instead?

      The above statement applies to derivative versions of Python 1.6
      beta 1. You cannot revise the CNRI License. You must retain the
      CNRI License (or their defined reference to it)
      verbatim. However, you can make derivative works and license
      them as a whole under a different but compatible license.

   14.Since I have to retain the CNRI license in my derivative work,
   doesn't that mean my work must be released under exactly the same
   terms as Python?

      No. Paragraph 1 explicitly names Python 1.6 beta 1 as the only
      software covered by the CNRI license.  Since it doesn't name
      your derivative work, your derivative work is not bound by the
      license (except to the extent that it binds you to meet the
      requirements with respect to your use of Python 1.6). You are,
      of course, free to add your own license distributing your
      derivative work under terms similar to the CNRI Open Source
      License, but you are not required to do so.

      In other words, you cannot change the terms under which CNRI
      licenses Python 1.6, and must retain the CNRI License Agreement
      to make that clear, but you can (via adding your own license)
      set your own terms for your derivative works. Note that there is
      no requirement to distribute the Python source code either, if
      this does not make sense for your application.

   15.Does that include, for example, releasing my derivative work
   under the GPL?

      Yes, but you must retain the CNRI License Agreement in your
      work, and it will continue to apply to the Python 1.6 beta 1
      portion of your work (as is made explicit in paragraph 1 of the
      CNRI License).

   16.With regard to paragraph 3, what does "make available to the
   public" mean? If I embed Python in an application and make it
   available for download on the Internet, does that fit the meaning
   of this clause?

      Making the application generally available for download on the
      Internet would be making it available to the public.

   17.In paragraph 3, what does "indicate in any such work the nature
   of the modifications made to Python 1.6 beta 1" mean? Do you mean I
   must publish a patch? A textual description? If a description, how
   detailed must it be? For example, is "Assorted speedups"
   sufficient? Or "Ported to new architecture"? What if I merely add a
   new Python module, or C extension module? Does that constitute "a
   modification" too? What if I just use the freeze tool to change the
   way the distribution is packaged? Or change the layout of files and
   directories from the way CNRI ships them? Or change some file names
   to match my operating system's restrictions?  What if I merely use
   the documentation, as a basis for a brand new implementation of
   Python?

      This license clause is in discussion right now. CNRI has stated
      that the intent is just to have people provide a very high level
      summary of changes, e.g. includes new features X, Y and Z. There
      is no requirement for a specific level of detail. Work is in
      progress to clarify the intent of this clause so as to be
      clearer as to what the standard is. CNRI has already indicated
      that whatever has been done in the past to indicate changes in
      python releases would be sufficient.

   18.In paragraph 6, is automatic termination of the license upon
   material breach immediate?

      Yes. CNRI preferred to give the users a 60 day period to cure
      any deficiencies, but this was deemed incompatible with the GPL
      and CNRI reluctantly agreed to use the automatic termination
      language instead.

   19.Many licenses allow a 30 to 60 day period during which breaches
   can be corrected.

      Immediate termination is actually required for GPL
      compatibility, as the GPL terminates immediately upon a material
      breach. However, there is little you can do to breach the
      license based on usage of the code, since almost any usage is
      allowed by the license. You can breach it by not including the
      appropriate License information or by misusing CNRI's name and
      logo - to give two examples. As indicated above, CNRI actually
      preferred a 60 day cure period but GPL-compatibility required
      otherwise. In practice, the immediate termination clause is
      likely to have no substantive effect. Since breaches are simple
      to cure, most will have no substantive liability associated with
      them. CNRI can take legal steps to prevent eggregious and
      persistent offenders from relicensing the code, but this is a
      step they will not take cavalierly.

   20.What if people already downloaded a million copies of my
   derivative work before CNRI informs me my license has been
   terminated? What am I supposed to do then? Contact every one of
   them and tell them to download a new copy? I won't even know who
   they are!

      This is really up to the party that chooses to enforce such
      licensing. With the cure period removed for compliance with the
      GPL, CNRI is under no obligation to inform you of a
      termination. If you repair any such breach than you are in
      conformance with the License. Enforcement of the CNRI License is
      up to CNRI. Again, there are very few ways to violate the
      license.

   21.Well, I'm not even sure what "material breach" means. What's an
   example?

      This is a well-defined legal term. Very few examples of breaches
      can be given, because the CNRI license imposes very few
      requirements on you. A clear example is if you violate the
      requirement in paragraph 2 to retain CNRI's License Agreement
      (or their defined reference to it) in derivative works.  So
      simply retain the agreement, and you'll have no problem with
      that. Also, if you don't misuse CNRI's name and logo you'll be
      fine.

   22.OK, I'll retain the License Agreement in my derivative works,
   Does that mean my users and I then enter into this license
   agreement too?

      Yes, with CNRI but not with each other. As explained in
      paragraph 1, the license is between CNRI and whoever is using
      Python 1.6 beta 1.

   23.So you mean that everyone who uses my derivative work is
   entering into a contract with CNRI?

      With respect to the Python 1.6 beta 1 portion of your work,
      yes. This is what assures their right to use the Python 1.6 beta
      1 portion of your work-- which is licensed by CNRI, not by you
      --regardless of whatever other restrictions you may impose in
      your license.

   24.In paragraph 7, is the name "Python" a "CNRI trademark or trade
   name"?

      CNRI has certain trademark rights based on its use of the name
      Python. CNRI has begun discussing an orderly transition of the
      www.python.org site with Guido and the trademark matters will be
      addressed in that context.

   25.Will the license change for Python 2.0?

      BeOpen.com, who is leading future Python development, will make
      that determination at the appropriate time. Throughout the
      licensing process, BeOpen.com will be working to keep things as
      simple and as compatible with existing licenses as
      possible. BeOpen.com will add its copyright notice to Python but
      understands the complexities of licensing and so will work to
      avoid adding any further confusion on any of these issues. This
      is why BeOpen.com and CNRI are working together now to finalize
      a license.

   26.What about the copyrights? Will CNRI assign its copyright on
   Python to BeOpen.com or to Guido? If you say you want to clarify
   the legal status of the code, establishing a single copyright
   holder would go a long way toward achieving that!

      There is no need for a single copyright holder. Most composite
      works involve licensing of rights from parties that hold the
      rights to others that wish to make use of them. CNRI will retain
      copyright to its work on Python. CNRI has also worked to get wet
      signatures for major contributions to Python which assign rights
      to it, and email agreements to use minor contributions, so that
      it can license the bulk of the Python system for the public
      good. CNRI also worked with Guido van Rossum and CWI to clarify
      the legal status with respect to permissions for Python 1.2 and
      earlier versions.

August 23, 2000



More information about the Python-list mailing list