How To Apply the CPAL To Your Product
hideDisclaimer: This is a layperson's view of this license. This is not Socialtext's official position on the meaning of terms of the license. If this document contains errors or disagrees with the license, the license should be considered the correct and definitive source for answers. In any case, this is not legal advice. Get advice from your own lawyer.
Introduction
The Common Public Attribution License 1.0, which we'll call the CPAL, is an Open Source license put together by Socialtext, Inc., to meet the needs of a wide variety of product developers, especially in the Web 2.0, and Enterprise 2.0, world. It is based upon existing Open Source licenses, including the Mozilla Public License 2.0 (the "MPL") used for the very successful Firefox product, with tweaks to address common business concerns. It was approved by the Open Software Initiative (the OSI) in July 2007 as an OSI certified Open Source license.
This document is a developer's view of how to apply the CPAL to your product. That is, it is a guide for software developers who want to release their product under the CPAL license. It is assumed that you have the legal right to license your code under the CPAL. This would be the case, for example, if you wrote the entire program yourself without any restrictions from other parties. If you are modifying code from someone else you may not have those rights. Check with your lawyer to be sure.
It is worthwhile to read through the CPAL carefully to understand its terms. It is the license itself that controls what you are allowing and not allowing others to do, and the requirements that you place upon them and yourself. Here we will only go through the main terms that involve action on your part.
First, we will go through the license examining those parts and listing what you should do. After that we will go through a fictitious product and look at sample text that you can provide to meet the needs of the license.
Details of the License parts requiring action by you
The first part of the license, Section 1, consists of definitions of terms. Like many legal documents, capitalized words may have special meaning defined here. We will use those terms in this document, too, and you can look to Section 1 for definitions.
Section 2 describes the rights that you and others are granting to others through the license. As in most of the license, there are two main cases to deal with: The Initial Developer who grants the rights to the initial release of the product, and Contributors who grant rights to Modifications to that original code.
Section 3 gets into things you and others have to do. First, you (and anybody else distributing the Source Code) must include a copy of the license with every copy of the Source Code you distribute. (Section 3.1) Note that making the Original Code or Modifications available as an application over a network is considered distribution. (This is something added by the CPAL to the MPL through Section 15.)
If anyone else distributes the product as an executable (i.e., not as source code), they must make their Modifications available in Source Code form on either the same media as an Executable version (if that isn't already Source Code, for example as with a scripting language like Perl if left in the original, programmer-friendly form) or via an accepted Electronic Distribution Mechanism to anyone to whom they make an Executable version available. (Section 3.2) This Electronic Distribution Mechanism must be kept available for a specified minimum amount of time. It is considered to be making the Executable version available through distribution if an individual or legal entity makes their Modifications available to others than themselves as an application over a network. (See Sections 1.12 and 15.) This means that someone else may not make modifications to your product and then provide a service to third-parties using that modified code without also making their modifications available to those users as Source Code.
In the case of a web-based product, a good practice may be for you, the Initial Developer, to provide as part of the UI a mechanism that you are happy with for obtaining the Source Code. Others could then hopefully easily use a similar mechanism for Source Code distribution. This could be, for example, by you providing a link labeled "Get Source Code" on an "About this product" page displayed by the product during operation. That link would point to your download page. Other parties who modify the code could then just change that link to point to their download page, or add a companion link to just their Modifications.
In Section 3.3, the CPAL requires that Modifications include a file documenting the changes made and the date of the change. In this file the modifier must include a prominent statement that the Modification is derived, directly or indirectly, from Original Code provided by the Initial Developer. Also, the modifier must include the name of the Initial Developer in the Source Code and in any notice in an Executable version or related documentation in which the modifier describes the origin or ownership of the Covered Code.
To make this Section 3.3 requirement easier to follow (and less likely to be inadvertently missed), you should provide an initial version of this contents of this file, the Initial Developer name in the Source Code, and notification in any Executable versions and related documentation that you produce. The contents of this "changes" file may be part of a file named "LEGAL" which is required specifically by the CPAL or it may be a separate file.
When making contributions, if you know that a license from someone else is required to exercise the rights you are giving, you must include a text file along with the Source Code titled "LEGAL". (Section 3.4.a) In this file you must describe the claim of that someone else and who they are in sufficient detail so that a recipient will know whom to contact to obtain a license. If you find out about this need for a license after you make the modifications available to others, you must update the "LEGAL" file for copies you make available from then on as well as take other reasonable steps to notify people who already received copies.
Even if you don't know of any claims to list in the "LEGAL" file, you may want to provide the file and include a section for listing these claims, leaving it with "None known at present."
If your modifications include APIs that need patent licenses to implement, you must also disclose that in the "LEGAL" file. (Section 3.4.b) Again, even if you don't have APIs that need patent licenses, you may want to leave space for the list in the "LEGAL" file.
According to Section 3.5, the original licensor must duplicate the notice in Exhibit A (with blanks appropriately filled in -- see below) in each file of the Source Code. For those files that can't have comments or notices (such as some structured data files) you must include the notice along with those files in such a way that the user would likely find it when looking for it, such as in an appropriate directory. If you contribute modifications to a file, you may add your name as a Contributor to these notices.
You must duplicate the license in any documentation for the Source Code where you describe recipients' rights or ownership rights relating to the Covered Code. (Section 3.5)
Distribution of Executable versions must include a notice stating that source code is available under terms of the license and describing how it may be obtained. This notice must be conspicuously included in any notice in the Executable version, related documentation, or collateral in which you describe the recipients' rights related to the Covered Code. (Section 3.6)
If for any legal reason it is impossible to comply with any of the terms of the license, you must describe those limitations and the code they affect in the LEGAL file. (Section 4) This must be in easy to understand language.
The Original Developer may include in the Exhibit B of the copy of the license provided with the product an attribution requirement. (Section 14.a) This requirement (described in more detail below) may give the situations in which the attribution must be provided, as well as details of what that attribution consists of. There are limits on what that requirement may call for by itself, though if a modifier of the code adds their own attribution information the Original Developer's information must be no less prominent. The limits include a statement that if there is no graphic user interface to access the code the Original Developer cannot require modifiers to add one and the attribution requirement would not apply.
You should list trademarks, service marks, and tradename ownerships if possible, so they are clear. (Section 14.a)
A checklist
Before shipping a product under the CPAL for the first time, you may want to go through the above list to make sure that you have done all of the things required. Here is a shorter checklist of the most common things to be done:
- Include a copy of the license with Source Code.
- Duplicate the license in any documentation for the Source Code where you describe recipients' rights or ownership rights relating to the Covered Code.
- Conspicuously include a notice stating that source code is available under terms of the license and describing how it may be obtained in Executable versions, related documentation, and collateral in which you describe the recipients' rights related to the Covered Code.
- Provide a mechanism for obtaining the Source Code as part of the UI.
- Provide an initial version of the file with changes listed.
- Provide an initial "LEGAL" file with details of additional licenses required for rights and APIs.
- Provide a list of trademarks, service marks, and tradename ownerships.
- Fill in Exhibit A in your copy of the license if appropriate and duplicate the notice in each file of the Source Code with all the blanks filled in.
- Fill in Exhibit B in your copy of the license.
Filling in the Exhibits
The "official" copy of the CPAL that you find on the OSI web site or in some of the Socialtext information about the CPAL has many "fill in the blanks" phrases and some optional terms in Exhibit A and Exhibit B. The "copy" of the license that you include with your product should have only the Exhibit B customizations completed (the Exhibit A customizations are done in each file to which they are copied and would not be in the main copy if those customizations differed from file to file). Therefore, the CPAL that comes with different products may not have identical text -- they may differ in those two exhibits. (This is explained a bit in Section 6.3 where it says that a license can still be called the CPAL if the Exhibits are filled out.)
Exhibit A
The "Exhibit A" text that is put in each source file is the way that users find out the licensing and other information about the contents of that file. The text is usually in the form of comments appropriate to the computer language of the file. This is where the copyright holder says "these are the licensing terms". This is accomplished by the statement that the contents of the file are subject to a particular license. This text also sets out some of the "genealogy" of the contents of the file.
The Exhibit A text that you put in the file starts after the opening quotation mark (before "The contents of…" and goes until the close quotation mark ("…License."). Note that many copies of the CPAL were produced by a word processor and use characters for quotation marks that are not in the 96 ASCII characters supported by all editors. Using them may cause incorrect display with browsers or other display methods looking for different encoding, such as UTF-8. You may want to replace those characters with a quotation mark character (ASCII character decimal 34) to be clean. Exhibit A includes multiple quotation marks.
The first blank to fill in is an indication of where the reader may obtain a copy of the License. This is in Exhibit A which must be reproduced (with the blanks filled in) in each of the source files. The license itself is not included in each source file and probably appears only once as part of the bundle of files that makes up the Source Code. This blank helps the reader find a copy of the License in the event that the source file is separated from the other files.
Fill in the "copy of the License" blank with a permanent URL that gives access to a copy of the CPAL. Normally this would be a copy with Exhibit B filled out -- that is, a copy specific to this product. If such a permanent URL is not possible, you could have the URL of a copy of the CPAL without the blanks filled out, but then the contents of a filled in Exhibit B would need to be in the file along with the contents of the filled in Exhibit A. Instead of, or in addition to, a URL, you could put some other commonly accepted way to obtain a copy of the license, such as by giving a permanent postal address.
The "Original Code" blank describes the computer software covered by this particular license when first applied to the code (that is, before additional Modifications). This may be the name of the product or some other reasonable description. While you may have many files, each with Exhibit A text, more than one may have come from a common project, which would be listed here. This is a form of attribution and a way of showing the genealogy of the code.
To see some examples of "Original Code" from a filled out Exhibit A for an MPL product, you can look at the Mozilla Firefox product (such as when installed on your machine or at http://mxr.mozilla.org/mozilla1.8/mozilla/source/) which has these, among others, as the Original Code for various files: "Mozilla Communicator client code, released March 31, 1998", "Mozilla SVG project", "mozilla.org code", and "Mozilla Communicator client code".
The next two blanks are the "Original Developer" and the "Initial Developer of the Original Code". The "Initial Developer" is the one who has the right to license the code and is often the author of the Original Code. "Original Developer" is a term used for Attribution (Section 14). It is the entity that "organized the development of the Original Code". That is, it is the entity requiring the attribution for promotional value to help justify releasing the code under this license. The Original Developer is often the Initial Developer who authored, or owns rights to, the Original Code, but there are times when some or all of the code was authored by others but only the Original Developer is involved in the attribution requirements. For example, Socialtext authored most of the Socialtext wiki product and is both the Original Developer and the Initial Developer. Software Garden authored most of the initial SocialCalc code, so is listed as an Initial Developer (along with Socialtext with authored a small amount of the Original Code), but only Socialtext, which is funding ongoing development and sponsoring the release under CPAL, is listed as the Original Developer.
In the Mozilla project, the Initial Developer is often Netscape Corporation, though some files that came from other Original Code have other Initial Developers.
If the Original Developer is the same as the Initial Developer, just state that "The Original Developer is the Initial Developer" and then fill in the blank for Initial Developer.
The "genealogy" of the code, listing who wrote what, is important for more than one reason. In the Open Source world, attribution for artistic, fairness, and moral reasons is important. Also important is a history for legal reasons to determine a clear chain of granting of rights. A lawyer for a potential user of the code may only have the information in the Source Code to determine if the granting of rights is "clean" enough to give comfort for Okaying the use of that code. As has been shown in the lawsuit between SCO and IBM, ascertaining the history of a particular piece of code can be important years later.
The next set of blanks is for the copyright information. Here you list the entities who wrote the code and who holds the copyrights to that code. If they are all the same as the Initial Developer you can just say "Initial Developer" for who wrote it and who holds the copyright. Alternatively, you can list each entity. In the blank after the "Copyright (c)" you should list the years during which the code was written for copyright purposes (usually the years for each new release of the code) as well as the entity holding the copyright.
For example, Firefox often has something like this: "The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by the Initial Developer are Copyright (C) 1998 the Initial Developer. All Rights Reserved" and "The Original Code is the Mozilla JavaScript Shell project. The Initial Developer of the Original Code is Alex Fritze. Portions created by the Initial Developer are Copyright (C) 2003 the Initial Developer. All Rights Reserved."
The next blank is the "Contributor" section. Each Contributor (entities that create or contribute to the creation of Modifications) should be listed. Sometimes the Initial Developer lists their name here, and sometimes they do not. In any case, make sure the section heading is in the text. By listing your name even though you are the Initial Developer you set the style for filling in this section. Also, some users of the license list the actual person who made the contributions (as names and/or email addresses). Again, it is helpful to have a trail of all contributors and a way of contacting those individuals and/or companies.
For example, in Firefox again, "The Original Code is mozilla.org code. The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by the Initial Developer are Copyright (C) 1998 the Initial Developer. All Rights Reserved. Contributor(s): travis@netscape.com."
The next section of Exhibit A is where you, as the Initial Developer, have the option of listing other licenses that the receiver may choose to follow and under which you license the file. For example, parts of the Firefox product may be used under terms of either the MPL or the GPL or the LGPL. Modifiers of the product may choose to only license their modifications under one of those licenses, and this section gives them that ability.
To take advantage of this section, fill in the blanks listing the long and short names of the additional licenses. For example, to "dual license" the file under both the CPAL and the Artistic License 2.0, you would fill in the first blank in this section with "Artistic License 2.0" and other five blanks with "AL2".
If you are only licensing the file under the CPAL you can remove the two paragraphs about alternative licenses.
Exhibit B
The copy of the CPAL that you include with the product should have the Exhibit B information filled out. This is the Attribution Information that applies to the whole product.
As stated in Section 14.a, you may include in Exhibit B a requirement about attribution. This requirement may only include displaying four items (the copyright, phrase, image, and URL, discussed later). The Original Code may actually have more extensive attribution displays, but modifiers may remove those displays as part of modifying the code. The requirement in Exhibit B says that in the least, modified versions of the code must display this listed Attribution Information (if provided -- if an item is not provided then it is not required to be displayed).
The wording of Exhibit B, originating with legal wording designed for products that operate only on an individual's computer, such as a browser or word processor, is oriented around that execution model. That is, it included wording for programs that are "launched" or "run". In that case, attribution information is traditionally displayed in splash screens or initial displays. In many "Web 2.0" and "Enterprise 2.0" products, one sometimes accesses products without initial displays, where the main use starts and ends on a main working display. Many server-based products either run completely for each screen displayed (such as normal CGI scripts) or are started once when the server comes up before any user accesses it. This makes figuring out how to provide attribution that meets the requirements unclear for some products. The CPAL wording for this requirement includes a list of alternative forms (including an "about" display and a dedicated attribution area on user interface screens) to address this uncertainty and a statement that use of such attribution forms by the Original Code means that continued use of that form would be an acceptable way of meeting the requirement.
Therefore, one way of influencing the attribution method would be to use a method you prefer yourself in the Original Code.
The wording of Section 14.a and 14.b limit what the Original Developer may require. Therefore, you can explain in greater detail how you would like the product to behave as part of Exhibit B and those limitations will take care of clearing up any "overreaching" that could be an interpretation of your stated requirements. Modifiers have the option of using different methods of attribution as long as they include at least the items you list and meet the requirements for prominence in Section 14.
The blanks in Exhibit B are as follows:
The Attribution Copyright notice is the notice you want on attribution displays. This may be less than the full list of all copyright claims and is a way to give attribution to the Original Developer and not all of the other "minor" contributors.
The Attribution Phrase (limited to no more than 10 words) lets you have something other than the copyright notice to give attribution, such as explaining who the Original Developer is (a corporate tag line) or as the text for the URL.
The Attribution URL is a URL for learning more about the Original Developer or the Original Code, or for whatever other purpose the Original Developer desires. Instructions for how to display this URL may be included in Exhibit B (such as "as the target of a link when clicking the image or the Attribution Phrase"), but that is only a guide to the modifier. The CPAL does not give guidance on how the URL must be displayed.
The Graphic Image that must be displayed is defined in Exhibit B. This image (in a file) must be provided as part of the Source Code. Good form would be to include in Exhibit B a list of various forms and sizes of acceptable images to meet the different needs of attribution as stated in Section 14 where the CPAL states that it should be consistent in size with other elements of Attribution Information and no less prominent than similar information from other parties, etc. You may also want to provide a URL where other versions are available.
In Exhibit B you also indicate whether or not the display of Attribution Information is required in Larger Works. This is a business decision.
Examples
Here is an example of extra files and Exhibit A and B text when applying the CPAL to a fictitious product:
LEGAL.TXT file example
In this case LEGAL.TXT includes the list of changes and much of the other legal material.
LEGAL INFORMATION This LEGAL.txt file accompanies the "CPAL-DEMO Open" program. It includes notices required by the licenses as well as general legal notices. ========================================= COPYRIGHT AND ATTRIBUTION NOTICES ========================================= Portions Copyright (C) 2006, 2007 CPAL Developers, Inc. All Rights Reserved. image:cpaldev-logo.gif "CPAL-Dev, provider of popular attribution formatters" http://www.cpal-dev.com ========================================= SOURCE CODE AVAILABILITY NOTICE ========================================= The source code for this product is available from: http://www.cpal-dev.com/cpaldemoopen ========================================= GENERAL LEGAL NOTICES ========================================= CPAL-Dev is a trademark of CPAL Developers, Inc. ========================================= SOURCE CODE LICENSE ========================================= Except as explicitly indicated in the file itself, the contents of all files that make up this product are subject to the Common Public Attribution License Version 1.0 (the "License"; alternatively, the "CPAL"); you may not use the files except in compliance with the License. You may obtain a copy of the License at http://www.cpal-dev.com/cpaldemoopen/license. The License is based on the Mozilla Public License Version 1.1 but Sections 14 and 15 have been added to cover use of software over a computer network and provide for limited attribution for the Original Developer. In addition, Exhibit A has been modified to be consistent with Exhibit B. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. ========================================= LEGAL NOTICES REQUIRED BY THE LICENSE ========================================= CHANGES MADE TO THE COVERED CODE (see CPAL Section 3.3): 2007-07-30, "Joe Commoner" <joec@cpal-dev.com>: Original Code based on CPAL-Demo 3.2 product. Licensing notices added to all applicable files and proprietary ZY-compression code removed. ---- (Documentation of future changes as the result of Modifications, including the date of change, will go here in this LEGAL.txt file. This documentation may be summaries of changes with the more detailed descriptions included in the actual modified files as appropriate.) ========================================= THIRD PARTY CLAIMS ========================================= (See CPAL Section 3.4(a)): None known at present. [End of LEGAL.txt]
Displaying the contents of this file in response to the user clicking a button or a link labeled "Legal" in a common place for such things on a major page of the product may be one way of providing a variety of forms of notice as required by the CPAL in places such as Section 3.6. You could have that display automatically replace the "image:" line with the image itself and make the URLs in to links.
Exhibit A example
Here is an example of the filled in Exhibit A text for this fictitious product:
*** BEGIN LICENSE INFORMATION *** The contents of this file are subject to the Common Public Attribution License Version 1.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.cpal-dev.com/cpaldemoopen/license. The License is based on the Mozilla Public License Version 1.1 but Sections 14 and 15 have been added to cover use of software over a computer network and provide for limited attribution for the Original Developer. In addition, Exhibit A has been modified to be consistent with Exhibit B. Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. The Original Code is the CPAL-DEMO Open program. The Initial Developer of the Original Code is CPAL Developers, Inc. The Original Developer is the Initial Developer. All portions of the code written by CPAL Developers, Inc., are: Copyright (C) 2006, 2007 CPAL Developers, Inc. All Rights Reserved. Contributor(s): *** END LICENSE INFORMATION ***
Exhibit B examples
Here are two versions of the filled in Exhibit B. The first just simply provides the requested information with no guidance:
EXHIBIT B. Attribution Information Attribution Copyright Notice: Copyright (C) 2006, 2007 CPAL Developers, Inc. Attribution Phrase (not exceeding 10 words): CPAL-Dev, provider of popular attribution formatters Attribution URL: http://www.cpal-dev.com Graphic Image provided in the Covered Code as file: cpaldev-logo.gif Display of Attribution Information is required in Larger Works which are defined in the CPAL as a work which combines Covered Code or portions thereof with code not governed by the terms of the CPAL.
Here is a version of Exhibit B with more extensive information:
EXHIBIT B. Attribution Information Subject to the limitations and other requirements in Section 14 of the License, the Original Developer requires You to display the following Attribution Information: Attribution Copyright Notice: Copyright (C) 2006, 2007 CPAL Developers, Inc. Attribution Phrase (not exceeding 10 words): CPAL-Dev, provider of popular attribution formatters Attribution URL: http://www.cpal-dev.com Graphic Image as provided in the Covered Code as file: cpaldev-logo.gif, with alternatives listed on http://www.cpal-dev.com/cpaldemoopen/license. This display should be, at a minimum, the Graphic Image displayed in the upper right corner of all "Edit Mode" pages, with that image linked to the Attribution URL and with an "ALT/Hover" text of the Attribution Phrase, and the Attribution Copyright Notice displayed in the footer of the page. Display of Attribution Information is required in Larger Works which are defined in the CPAL as a work which combines Covered Code or portions thereof with code not governed by the terms of the CPAL.
Remember that this document is not legal advice. You should clear what you are doing with your own legal counsel who may interpret the CPAL differently.
