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 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.
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 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.
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 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.
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 this clause?

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

Python 1.6 License FAQ

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

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

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

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

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

Has it been approved by the Python Consortium?

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

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

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

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

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?

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?

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?

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?

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

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?

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

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

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!

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

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?

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

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

Will the license change for Python 2.0?

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!