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