cddl-sca

Common Development & Distribution License (CDDL) and the Sun Contributor Agreement (SCA)

CDDL FAQ on opensolaris.org
CDDL background
Redline diffs (pdf) between MPL v1.1 & CDDL v1.0
Free and Open Source Licensing at Sun (pdf)
Sun Contributor Agreement Information
Sun Contributor Agreement (pdf)

Common Development and Distribution License
Description and High-Level Summary of Changes

Executive Summary

We have carefully reviewed the existing OSI approved licenses and found none of them to meet our needs, and thus have reluctantly drafted a new open source license based on the Mozilla Public License, version 1.1 (“MPL”). We do appreciate the issue of license proliferation, however, and have worked hard to make the Common Development and Distribution License (“CDDL”) as reusable as possible. Additionally, we have attempted to address the problems we perceived in existing open source licenses that led us to conclude that reusing those existing licenses was impractical.

We chose to use the MPL as a base, since it already had a number of attributes we were looking for in a license:

  • Requirement that the source of modifications be made available; this helps encourage code reuse and a vibrant community.
  • Requirement that the source of modifications be shared under the open source license; this helps encourage that open source remains open source.
  • Ability to distribute executables under a different license; this gives businesses more flexibility in licensing their derived works.
  • A “files based” definition of modifications and covered software; this makes it easy to combine code with code distributed under different licenses.
  • Explicit patent license; this makes it easier for businesses to use the software without concerns over patent rights.
  • Provision for termination of rights in response to patent claims (i.e. “patent peace” provision); this helps discourage patent litigation amongst the community, which we felt to be A Good Thing.

The MPL came closest to meeting our needs. We felt that it had a number of issues, though, which prevented us from simply using that license or one of its variants.

Once we embarked down the path of creating a new license, we focused on certain high level goals. We wished to create a license that was simpler, less burdensome for contributors, clear and consistent in the use of terms and language, and that was as reusable and general as possible. In addition, we made a number of specific improvements, a few of which are highlighted here.

  • Fixed the “Effect of New Versions” problem. We added an option to make Covered Software available under a specific version of the license, rather than allowing the use of future license versions. This change was made to make the license more reusable by others: it addresses the concern that the license steward could change the terms of the license in ways that are not compatible with a community’s (and the Initial Developer’s) values and objectives.
  • Focused the “patent peace” provisions to cover only software released under this license. We felt that this would make the license more acceptable to a diverse community of contributors, whether large or small. We strengthened the the penalties of the remaining provision, however, since we do believe that “patent peace” has an important role to play in open source licenses.
  • Simplified many of the Required Notices (or in a few cases, removed the requirement) since they seemed overly specific and burdensome.
  • Clarified the definition of Modifications, to make it easier for readers to understand what is covered by the license and what is not.

A more detailed list of changes made to create the CDDL license along with the associated rationale can be found here.

Common Development and Distribution License (CDDL)
Description and Rationale

Executive Summary

We have carefully reviewed the existing OSI approved licenses and found none of them to meet our needs, and thus have reluctantly drafted a new open source license based on the Mozilla Public License, version 1.1 (“MPL”). We do appreciate the issue of license proliferation, however, and have worked hard to make the Common Development and Distribution License (“CDDL”) as reusable as possible. Additionally, we have attempted to address the problems we perceived in existing open source licenses that led us to conclude that reusing those existing licenses was impractical.

We chose to use the MPL as a base, since it already had a number of attributes we were looking for in a license:

  • Requirement that the source of modifications be made available; this helps encourage code reuse and a vibrant community.
  • Requirement that the source of modifications be shared under the open source license; this helps encourage that open source remains open source.
  • Ability to distribute executables under a different license; this gives businesses more flexibility in licensing their derived works.
  • A “files based” definition of modifications and covered software; this makes it easy to combine code with code distributed under different licenses.
  • Explicit patent license; this makes it easier for businesses to use the software without concerns over patent rights.
  • Provision for termination of rights in response to patent claims (i.e. “patent peace” provision); this helps discourage patent litigation amongst the community, which we felt to be A Good Thing.

The MPL came closest to meeting our needs. We felt that it had a number of issues, though, which prevented us from simply using that license or one of its variants.

Once we embarked down the path of creating a new license, we focused on certain high level goals. We wished to create a license that was simpler, less burdensome for contributors, clear and consistent in the use of terms and language, and that was as reusable and general as possible. In addition, we made a number of specific improvements, a few of which are highlighted here.

  • Fixed the “Effect of New Versions” problem. We added an option to make Covered Software available under a specific version of the license, rather than allowing the use of future license versions. This change was made to make the license more reusable by others: it addresses the concern that the license steward could change the terms of the license in ways that are not compatible with a community’s (and the Initial Developer’s) values and objectives.
  • Focused the “patent peace” provisions to cover only software released under this license. We felt that this would make the license more acceptable to a diverse community of contributors, whether large or small. We strengthened the the penalties of the remaining provision, however, since we believe that patent peace has an important role to play in open source licenses.
  • Simplified many of the Required Notices (or in a few cases, removed the requirement) since they seemed overly specific and burdensome.
  • Clarified the definition of Modifications, to make it easier for readers to understand what is covered by the license and what is not.

General Changes made throughout the license

What follows is a detailed description of changes from the MPL. Terms defined in the CDDL are used whenever possible; these are indicated with capital letters. All section references are to the CDDL unless otherwise indicated.

We made a number of general changes, which are propagated throughout the license. These include:

  • Changed use of the term “Code” to “Software”. This was done to ensure that it was clear that this license can be used for both Source Code and Executables, not simply Source Code.
  • Eliminated the definition of “Commercial Use”. This term was thought to be misleading, since software may be distributed for both commercial and non-commercial purposes, and we didn’t want anyone to see the definition and conclude that the license makes a distinction between commercial and non-commercial use. Since this definition was only used in one place (2.2(c)), we simply eliminated the definition, and embedded the descriptive text in the place where the definition had been used.
  • Wherever software distribution is mentioned, added the phrase “or otherwise makes available” to cover passive types of distribution, such as with ASPs.
  • Eliminated the definition of “Electronic Distribution Mechanism”; this was no longer necessary, since we simplified the requirements around how Source Code is to be made available.
  • Clarified wording related to the file-based approach to Modifications and Covered Software. We wanted to make it very clear to the community what is covered and what is not.
  • Added option of making Covered Software available under a specific version of the license, rather than allowing the use of future license versions. This change was made to make the license more reusable by others.
  • Eliminated Exhibit A, in order to simplify the process of contributing software under the license.

Specific Changes

Sections that have not changed (except for numbering) are not listed.

Name: changed to a generic name to allow (and encourage) use of the license by groups other than Sun.

Removed 1.0.1 of the MPL (Commercial Use), as mentioned under “General Changes.”

1.1. Contributor: Clarified that an individual can be a Contributor.

1.2. Contributor Version: Added an “if any” clause, to clarify that the Contributor Version may be derived from the Original Software without any prior Modifications by other Contributors. Also changed “Code” to “Software,” as mentioned under General Changes.

1.3. Covered Software: Clarified wording regarding file-based approach to Modifications and Covered Software, as mentioned under General Changes.

Section 1.4 of the MPL (Electronic Distribution Mechanism) was deleted; it is no longer needed due to simplified language regarding how source code for modifications must be made available. See 3.1 (Availability of Source Code).

1.4. Executable: Changed “Code” to “Software”, as mentioned under “General Changes.”

1.5. Initial Developer: Exhibit A notice has been removed, so the definition of Initial Developer had to change as a result. The new definition is based on the individual or entity that initially releases the Original Software.

1.6. Larger Work: Changed “Code” to “Software,” as mentioned under “General Changes.”

1.9. Modifications: Clarification of files-based approach, as mentioned in “General Changes.” Specifically, removed “substance or structure of” phrase to avoid confusion, because it suggests that the definition of Modifications might go beyond modified files to something more.

Changed “Code” to “Software,” as mentioned under “General Changes.”

Added 1.9(c), which takes into account the common practice of contributing new source files to an open source distribution.

1.10. Original Software: Removed Exhibit A references, and extended to cover both Source Code and Executables. Also changed “Code” to “Software,” as mentioned under “General Changes.”

1.12. Source Code: Simplified the definition; the details regarding scripts, interface definition files, etc., didn’t seem necessary and are not specified in other common licenses (e.g., CPL and OSL).

1.13. You: Since Section 4.2 (6.2 in the MPL) has been changed to allow the Initial Developer for a particular project to specify use of a specific version of the License (excluding future versions of the License), the “future versions” clause was removed here.

2. License Grants: Changed title to make it clear that the license grant is for Executables as well as Source Code. In the MPL, it was unclear whether the license grant covered Executables.

2.1. Initial Developer Grant: Clarified language to make sure that those using the license grant to modify and redistribute software under this license would also be bound to make the Source Code available. Moved “subject to third party intellectual property claims” so that the structure of the license grant in 2.1 was the same as in 2.2.

2.1(a). Changed “Code” to “Software,” as mentioned under “General Changes.”

2.1(b). Changed “Code” to “Software,” as mentioned under “General Changes.”

2.1(c). Added “otherwise makes available” as mentioned in General Changes. Changed “Code” to “Software,” as mentioned under “General Changes.”

2.1(d). The “separate from the Original Code” clause is ambiguous, and was felt by some to be inconsistent with other aspects of the license grant and definitions that specify “portions thereof”. In order to avoid confusion, we chose to simply eliminate this clause. Also changed “Code” to “Software,” as mentioned under “General Changes.”

2.2. Contributor Grant: As in 2.1.

2.2(a) As in 2.1(a).

2.2(c) Removed “Commercial Use”. Replaced with “distributes or otherwise makes available”; this matches the wording in 2.1(c). See “General Changes” for a more detailed explanation.

2.2(d) As in 2.1(d).

3. Distribution Obligations: This section was substantially reorganized, including some simplifications and deletions. See below for details.

3.1. Availability of Source Code: This section is based on Sections 3.1 and 3.2 of the MPL. We tried to merge the various obligations about Source Code into one section for clarity. Aside from rewording due to the restructuring of the section, the primary change is to the requirements around Source Code availability. Since access to Source Code is a critical requirement for any open source community, we felt that it was important to make it easy for community members to get access to the Source Code in a usable form. The MPL requires that those making (and distributing) Modifications need only make the source for those Modifications available, which might result in the need to assemble the source changes from a number of different contributors to get a source base that matches a particular distribution. Instead, we chose to require that anyone distributing Covered Software under this license make the Source Code available for all Covered Software they are distributing (rather than just the Source Code for their Modifications). Note that if someone is just distributing a component of the Covered Software, only the Source Code for that component needs to be made available.

In addition, the specific mechanism and timing requirements for making Source Code available and references to “Electronic Distribution Mechanisms” were removed and replaced with notions of “reasonable” and “medium customarily used for software exchange.”

We also removed the reference to the “future version of the License” since Section 4.2 of CDDL (Effect of New Versions) is different from Section 6.2 of MPL (Effect of New Versions). See “General Changes” for a more detailed explanation.

3.2. Modifications: This section is based on Sections 3.1 and 3.4(c) of the MPL. The required notices in the MPL regarding third party claims and patents (formerly in MPL Section 3.4(a) and 3.4(b)) have been eliminated; they seemed overly burdensome and likely to prevent wider acceptance of the license by by the community. Additionally, none of the other major open source licenses (e.g., GPL, BSD, CPL, OSL) require such disclosures.

3.3. Required Notices: This section is based on Sections 3.3 and 3.5 of the MPL, though the form by which a Contributor identifies Modifications is no longer specified. References to Exhibit A were also removed. This was done because the requirements of the MPL seemed overly specific and burdensome; even the Mozilla community doesn’t seem to consistently adhere to this practice. Since failure to follow requirements of the license can have significant legal repercussions, it seemed best to be pragmatic and leave the details of how notice is provided to the community and its developers. We note that our requirement is similar to that of other open source licenses (e.g., CPL, OSL).

A requirement that you “may not remove or alter any copyright, patent or trademark notice contained within …” was also added; this matches similar language in the OSL.

3.4. Application of Additional Terms: This section is from the next to last sentence of MPL Section 3.1 (“Application of License”) combined with the latter half of MPL Section 3.5 (“Required Notices”.) We merged these two sections as part of the overall reorganization of Section 3, in an attempt to simplify and group things more coherently. We also added “Covered Software” to clarify that the obligations related to the Source Code of the Covered Software. Also fixed a typo present in the MPL.

3.5. Distribution of Executable Versions: This section is from MPL Section 3.6 (“Distribution of Executable Versions”.) We removed the redundancies related to the required notices. Also, “Code” was replaced with “Software” (as mentioned under General Changes), and the reference to MPL Section 3.2 and its specific required notices was also removed.

3.6. Larger Works: Replaced “Code” with “Software,” as mentioned in “General Changes.”

Sections 4 and 5 of the MPL (“Inability to Comply Due to Statute or Regulation” and “Application of this License”) were seen as unnecessary or redundant, and have been removed from the CDDL.

4.1. New Versions (of the License): Added concept of a license steward, in order to make the license reusable by others.

4.2. Effect of New Versions: The MPL’s option of allowing Contributors to use new versions of a license, while often quite useful (as it makes it easy to improve the license without relicensing all covered code), can cause problems when the Initial Developer is not also the license steward because the license steward could change the terms of the license in ways that are not compatible with the community’s (and the Initial Developer’s) values and objectives.

The approach we have taken is from the GPL; the CDDL allows an Initial Developer to decide whether they wish to license their Original Software solely under a specific license version, or allow the use of a later version of the same license as well. This ensures that other communities can use the license.

4.3. Modified Versions: Retitled this subsection (in MPL, Section 6.3 was called “Derivative Works”) to clarify that this is about modifications to the license, not the code. Also simplified the requirements. While we do not want to contribute to a proliferation of open source licenses, we want other businesses and communities to be able to use this license as the basis for future licenses if industry or business needs warrant.

5. Disclaimer of Warranty: Replaced “Code” with “Software,” as mentioned in “General Changes.”

6.1. Removed the sublicense statement, since it was redundant with a similar statement in 6.4.

6.2. Changed trigger from initiation of litigation to assertion of a patent infringement claim, for clarity. Also, created an inline definition of Participant Software to account for the fact that the claim might be against either a Contributor Version or against the Original Software and used this definition throughout the section. Clarified a potential ambiguity by adding “directly or indirectly” on line 6 in the first sentence, so that if your rights from this license are terminated due to your assertion of a patent infringement claim, you cannot reacquire those same rights indirectly. Removed the royalty provision, which was seen as confusing and unnecessary. Broadened the penalty to terminate rights from any Contributor (and the Initial Developer), not just the Participant.

We removed MPL’s 8.2(b), which revoked license rights if patent claims are made against any product of a Participant, not just code released under this license. We’re trying to build a community of diverse contributors, large and small, including commercial contributors, and felt that this section would be a hindrance to commercial adoption. However, we believe that “patent peace” has an important role to play in open source licenses, which is why we have strengthened the provisions in 6.2(a) and 6.3.

Removed MPL’s 8.3, since this no longer made sense after removal of the royalty provision in 6.2.

6.3. As in 6.2(a), clarified a potential ambiguity so that if your rights from this license are terminated due to assertion of a patent infringement claim, you cannot reacquire those same rights from a distributor. Removed the parenthetical “(excluding distributors and resellers)”, which was seen as confusing and unnecessary.

7. LIMITATION OF LIABILITY: Changed “Code” to “Software,” as mentioned in “General Changes.” Also added “lost profits” as a clarification to protect Contributors and other licensees.

8. U.S. GOVERNMENT END USERS: Updated to reflect the current U.S. Government regulations and to avoid any ambiguity regarding the application of any other regulations. Also changed “Code” to “Software,” as mentioned under “General Changes.”

9. MISCELLANEOUS: To make the license more general, we removed the requirement that the License be governed by California law provisions, and we removed the restriction that litigation be subject to the jurisdiction of the Federal Courts of the Northern District of California. Rather, choice of law, venue and jurisdiction can now be specified in a notice in the Original Software. Added last sentence to clarify the party responsible for complying with export control obligations.

Deleted Section 13 of the MPL because it was confusing and unnecessary.

Exhibit A from the MPL was removed, since 3.3 no longer requires a specific format for the notice of modifications.

Sun Contributor Agreement

Sun Microsystems, Inc. Contributor Agreement

These terms apply to your contribution of materials to a product or project owned or managed by us (‘project’), and set out the intellectual property rights you grant to us (Sun Microsystems, Inc.) in the contributed materials. If this contribution is on behalf of a company, the term ‘you’ will also mean the company you identify below. If you agree to be bound by these terms, fill in the information requested below and provide your signature.

Read this agreement carefully before signing.

1. The term ‘contribution’ means any source code, object code, patch, tool, sample, graphic, specification, manual, documentation, or any other material posted or submitted by you to a project.

2. With respect to any worldwide copyrights, or copyright applications and registrations, in your contribution:

  • you hereby assign to us joint ownership, and to the extent that such assignment is or becomes invalid, ineffective or unenforceable, you hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under those copyrights. This includes, at our option, the right to sublicense these same rights to third parties through multiple levels of sublicensees or other licensing arrangements;
  • you agree that each of us can do all things in relation to your contribution as if each of us were the sole owners, and if one of us makes a derivative work of your contribution, the one who makes the derivative work (or has it made) will be the sole owner of that derivative work;
  • you agree that you will not assert any moral rights in your contribution against us, our licensees or transferees;
  • you agree that we may register a copyright in your contribution and exercise all ownership rights associated with it; and
  • you agree that neither of us has any duty to consult with, obtain the consent of, pay or render an accounting to the other for any use or distribution of your contribution.

3. With respect to any patents you own, or that you can license without payment to any third party, you hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free license to:

  • make, have made, use, sell, offer to sell, import, and otherwise transfer your contribution in whole or in part, alone or in combination with or included in any product, work or materials arising out of the project to which your contribution was submitted, and
  • at our option, to sublicense these same rights to third parties through multiple levels of sublicensees or other licensing arrangements.

4. Except as set out above, you keep all right, title, and interest in your contribution. The rights that you grant to us under these terms are effective on the date you first submitted a contribution to us, even if your submission took place before the date you sign these terms. Any contribution we make available under any license will also be made available under a suitable FSF (Free Software Foundation) or OSI (Open Source Initiative) approved license.

5. With respect to your contribution, you represent that:

  • it is an original work and that you can legally grant the rights set out in these terms;
  • it does not to the best of your knowledge violate any third party’s copyrights, trademarks, patents, or other intellectual property rights; and
  • you are authorized to sign this contract on behalf of your company (if identified below).

6. These terms will be governed by the laws of the State of California and applicable U.S. Federal law. Any choice of law rules will not apply.

If available, please list your username(s) and the name of the project(s) (or project website(s)) for which you would like to contribute materials.

Your username:
Project name (or project website):
Your username:
Project name (or project website):

Your contact information (Please print clearly):

Your name:
Your company’s name (if applicable):
Mailing address:
Telephone, Fax and Email:
Your signature:
Date:

To deliver these terms to us, scan and email, or fax a signed copy to us using the email address or fax number set out on the appropriate project website.

Sun Contributor Agreement – version 1.5
This document is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License
http://creativecommons.org/licenses/by-sa/3.0/

Sun Contributor Agreement

About the agreement

Following the lead of other open source projects, the OpenSolaris project requires contributors to jointly assign their copyright on contributed code. The Sun Contributor Agreement (SCA) gives Sun and the contributor joint copyright interests in the code: the contributor retains copyrights while also granting those rights to Sun as the open source project sponsor.

The SCA is applicable to all products and projects owned or managed by Sun: signing it once means you can contribute code to any Sun-sponsored open source project.

The SCA does not change the rights or responsibilities of the OpenSolaris community under the Common Development and Distribution License (CDDL). By executing the SCA, contributors protect the OpenSolaris code base, enable alternative licensing models, and protect the flexibility to adapt the project to the changing demands of the community. In order for the SCA to be effective, the OpenSolaris project must obtain an assignment for all contributions. Please review the SCA for a complete understanding of its terms and conditions. By contributing source code or other material to OpenSolaris you represent that you have a SCA with Sun for such contributions. If this representation is not true, you hereby license your contributions as Materials under the OpenSolaris Terms of Use. In order to track contributors, you understand that your full name and username will be posted on a public URL of authorized contributors.

Instructions for submitting the agreement

  • Register on opensolaris.org (you need to specify your username on the agreement).
  • Download and print out the Sun Contributor Agreement.
  • Sign the agreement.
  • Send the signed agreement to Sun:
    • as a facsimile: FAX your signed agreement to +1 650-745-3307
    • as a digital image: Scan or photograph your signed agreement and email it to contrib-faxes AT sun DOT com. (Your scan or photograph should be of the complete page and at least 3 megapixels/180 dpi.)

Confirmation of your submission

  • You will receive a reference number confirming that the agreement has been received.
  • Please provide this reference number when making contributions to the OpenSolaris project.

Questions

  • If you have questions, please send email to website-admin AT opensolaris DOT org.