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.
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.
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.
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.
What is CNRI's position on prior Python releases, e.g. Python
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.
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.
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.
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.
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.
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.
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.
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).
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
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
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.
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
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.
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).
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
Making the application generally available for download on the
Internet would be making it available to the public.
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.
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.
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 egregious and persistent offenders from
relicensing the code, but this is a step they will not take
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 then 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.
Well, I'm not even sure what "material breach" means. What's an
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.
OK, I'll retain the License Agreement in my derivative works,
Does that mean my users and I then enter into this license agreement
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.
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
In paragraph 7, is the name "Python" a "CNRI trademark or trade
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.
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.
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