- 👋 Hi, I’m @Surachai-kent
- 👀 I’m interested in ...
- 🌱 I’m currently learning ...
- 💞️ I’m looking to collaborate on ...
- 📫 How to reach me ...
Title: Third-Party Licensing Policy - The Apache Software Foundation Atom: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/?format=atom "ASF legal-discuss Mailing List" Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.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.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
###
Effective Date: N/A (proposed) ### {#effectivedate}
This document represented a proposed ASF policy that was very helpful in guiding the foundation for a number of years.
Please refer to the official version that was derived from this draft and associated feedback.
THE REST OF THIS DOCUMENT IS OF HISTORIC INTEREST ONLY
This policy is primarily intended for Apache committers and PMC members. While it can help users understand what governs the inclusion of third-party works within Apache products, it does not place any requirements on users. The LICENSE file within each product includes and/or references the only applicable licensing terms.
This document defines the Apache Software Foundation's third-party licensing policy, specifying which licenses are acceptable for use with an Apache product, which licenses are not, and how to handle each case. The policy applies to all works developed outside the ASF that are being considered for use with or inclusion within an Apache product.
This policy is divided into the following sections:
- Guiding Principles
- Software License Criteria and Categories
- License Labeling Requirement
- Options for Prohibited Works
- Transition and Exceptions
- Appendix: Definitions and Contact Info
A forthcoming policy will address the detailed procedures for accepting and distributing contributions, including those considered third-party works.
The policies outlined in this document are designed to meet the following guiding principles:
- The ASF must be able to distribute works created within an Apache Project solely under the Apache License.
- The licensing connotation of the Apache brand must be maintained by ensuring all software in an Apache product, including third-party works, is licensed under the Apache License or similar terms and that steps are taken to minimize any practical impact on the user due to any difference in terms.
- Committers must be provided with a clear policy that identifies when a third-party work can be included within an Apache product and that addresses the practical issue of releasing products that depend on other software.
- Users of Apache products must be provided with all licensing terms applicable to any part of the product and must be given prominent notice when any of those terms include restrictions significantly different from the Apache License.
The following criteria serve to fulfill the first two guiding principles of this policy, as described above.
- The license must meet the Open Source Definition.
- The license must not place restrictions on the distribution of independent works that simply use or contain the covered work.
- The license must not place restrictions on the distribution of larger works, other than to require that the covered component still complies with the conditions of its license.
In addition to these requirements, if the license requires any degree of reciprocity, the ASF distribution must be prominently labeled to indicate the inclusion of software under reciprocal terms.
The lists below declare which licenses are authorized and which licenses are excluded from applying to any part of a product distributed by an ASF PMC. Categorized lists of licenses are used in this policy to address the third guiding principle of this policy.
Even optional works must adhere to this policy if they are included as part of the Apache product. See Options for Prohibited Works for more details on what can be done with an excluded license, including issues related to optional add-ons and system requirements.
NOTE: Licenses not appearing on these lists must be explicitly approved by the ASF Legal Affairs officer prior to distribution. License approval requests may be sent to the legal-discuss mailing list.
NOTE: Some licenses listed below do not include version numbers, in which case the specific version referred to is the one posted on the OSI site.
Third-party works, in both source and binary form, may be included within Apache products when made available under the following licenses:
Each license in this category requires some degree of reciprocity; therefore, additional action must be taken in order to minimize the chance that a user of an Apache product will create a derivative work of a reciprocally-licensed portion of an Apache product without being aware of the applicable requirements.
The first action that must be taken is that software under the following licenses may only be included within an Apache product if the inclusion is appropriately labeled:
For small amounts of source that is directly consumed by the ASF product at runtime in source form, and for which that source is unlikely to be changed anyway (say, by virtue of being specified by a standard), this action is sufficient. An example of this is the web-facesconfig_1_0.dtd, whose inclusion is mandated by the JSR 127: JavaServer Faces specification.
Code that is more substantial, more volatile, or not directly consumed at runtime in source form may only be distributed in binary form.
By including only the object/binary form, there is less exposed surface area of the third-party work from which a work might be derived; this addresses the second guiding principle of this policy. By attaching a prominent label to the distribution and requiring an explicit action by the user to get the reciprocally-licensed source, users are less likely to be unaware of restrictions significantly different from those of the Apache License; this addresses the fourth guiding principle of this policy.
Although the source must not be included in Apache products, the NOTICE file, which is required to be included in each ASF distribution, must point to the source form of the included binary (more on that in the forthcoming "Receiving and Releasing Contributions" document).
Note that works written in a scripting language without a binary form cannot be included in any ASF product under one of these licenses (see Transition and Exceptions). In addition, C-based projects may have difficulty using works under these licenses since they would have to deal with platform-specific binaries, rather than just distributing source that can be built on most any platform.
The following licenses must not apply to any software within an Apache product, whether in source or binary form. See Options for Prohibited Works for applicability to system requirements or optional works distributed elsewhere.
- BCL*
- Special exceptions to the GNU GPL (e.g. GNU Classpath)*
- GNU GPL
- GNU LGPL*
- NPL 1.0 and NPL 1.1*
- QPL
- Sleepycat License
* see discussion of this in Transition and Exceptions
This policy allows some terms within included licenses that go beyond the restrictions of the Apache License (see License Criteria). Such allowance attempts to provide an appropriate compromise between the advantages of efficiency and familiarity achieved by reusing other open source works within Apache products and the need to continue to meet the licensing expectations of users of Apache-branded products. However, following the fourth guiding principle of this policy, this compromise requires extra effort to ensure our users understand what they are getting.
The forthcoming policy on "Receiving and Releasing Contributions" will describe how we keep users informed through the inclusion of all applicable license files and notices inside a distribution. This labeling policy takes the extra step of alerting users of key licensing characteristics using a few easily visible labels on the download site and within the distribution itself.
The License Labeling Requirement goes into effect three months after the effective date of this policy. This gives PMCs time to determine which labels apply to their releases and to insert the appropriate provided labels into their distribution and download pages. To minimize the effort required of PMCs by this labeling policy, the VP of Legal Affairs will provide a table mapping licenses to labels and a kit to make the effort of updating the download page comparable to that of adding an ApacheCon logo to a project's web site.
To help users quickly identify important characteristics of the collection of licenses that apply to an Apache product, a product-specific set of labels with a corresponding set of definitions will be included in all ASF download pages and third-party license indexes within ASF distributions. The download pages will also include a graphic representation of each label. The Creative Commons licenses use a similar system to identify the key characteristics of each individual license; however, this system uses labels to identify characteristics of a set of licenses that apply to a specific product.
Below are the three label categories, reflecting three concerns our users may have about third-party licenses. Each category has two possible states or "labels". The graphic version of each label is not yet available. [Editorial Note: please volunteer (see contact info) if you would like to design them.]
- Single-License: All works included within the product are licensed to Apache users under the Apache License (v.2+).
- Multi-Licensed: While all code developed at the ASF is licensed under the Apache License, one or more third-party works are licensed under other terms. These terms may or may not include various attribution requirements, patent grants, termination clauses, and reciprocity requirements. However, all licenses covering any part of an Apache product meet the ASF's third-party licensing criteria.
- Source Included: The source distribution for the Apache product includes the complete source for the entire product, including all third-party works.
- Source Available: The source distribution for the Apache product does not include the source for some third-party works, but such source is available online, as noted in the product's NOTICE file.
- No Reciprocity Required: No part of the Apache product requires distribution of derivative works to be made available under the same license as the original work.
- Reciprocity Required by some Components: Some included third-party works are licensed under terms that require distribution of derivative works to be made available under the same license as the original work. See the Apache product's LICENSE file to find the applicable third-party licenses.
The purpose of this part of the policy is to support the third-guiding principle of this policy by offering options for PMCs interested in third-party works that cannot be included in an ASF product due to their license.
One of the guiding principles behind this policy is to maintain the value and connotation of the Apache brand; therefore, some licenses are excluded from applying to any part of an Apache product. However, there are two categories of software on which this policy places no licensing restrictions: system requirements (works used by the product) and optional add-ons (works that use the product).
If a PMC wishes to build a product that takes a core dependency on some third-party work that is only available under an excluded license, the PMC might consider whether the work can be used as a system requirement, rather than an internal part of the product. The drawback to this approach is that every new system requirement narrows the potential user base for the product. Each PMC is solely responsible for choosing an appropriate set of system requirements for its products; however, the following guidelines are recommended:
- Clearly label each product's system requirements and their licenses on the main product page.
- Consider the project's implicit/explicit charter and intention of the board resolution that created the project when determining how the system requirements will affect the users.
- Provide a means, when practical, for users to substitute an alternative implementation for system requirements only available under excluded licenses (especially non-OSD licenses).
If a PMC wishes to allow optional add-ons to enhance the functionality of the standard Apache product, the following options are available:
- For add-ons under authorized licenses, the add-on could be distributed inside the product (see forthcoming policy on "Receiving and Releasing Contributions" for details on how and where to do this).
- For add-ons under excluded licenses, the PMC may provide a link/reference on the product web site or within product documentation to some other web site that hosts such add-ons (e.g. a SF.net project or some third-party site dedicated to distributing add-ons for the Apache product) as long as it is made clear to users that the host site is not part of the Apache product nor endorsed by the ASF.
- For add-ons under excluded licenses, the PMC may include a feature within the product that allows the user to obtain third-party add-ons if the feature also alerts the user of the associated license and makes clear to users that the host site is not part of the Apache product nor endorsed by the ASF.
The following scenarios provide more detail of what may and may not be done with prohibited works (defined as third-party works licensed under an excluded license).
- YOU MUST NOT include any portion of a prohibited work within the Apache product, whether or not that work is considered required or optional.
- YOU MAY include code within the Apache product necessary to achieve compatibility with a prohibited work through the use of API calls, "bridge code", or protocols, provided that the compatibility code was contributed under a CLA. However, any such code used for compatibility with a third-party work that is licensed under terms that violate criterion #2 ("must not place restrictions on the distribution of independent works that simply use or contain the covered work."), such as the GPL, requires review and explicit approval of both the PMC chair and the Legal Affairs officer. This review will ensure that the Apache product takes only the necessary steps to achieve compatibility.
- YOU MAY ALSO include a feature within an Apache product that allows the user to explicitly choose to download an optional third-party add-on, as long as that feature also alerts the user of the associated license.
- YOU MUST NOT distribute a prohibited work from an apache.org server.
- YOU MAY reference a prohibited work (e.g. with text or hyperlinks) from an apache.org web page or identify the work as a system requirement for the proper operation of the Apache product.
- YOU MUST NOT modify, assemble, or release a prohibited work as an action of an ASF PMC.
- YOU MAY independently develop, assemble, or release software under an excluded license as an individual who happens to be an ASF committer/PMC member, but only when such action is not identified as being associated with or sponsored by the ASF.
- YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of a prohibited work.
- YOU MAY include within an Apache product a documented, non-default, build option to allow users to explicitly insert a prohibited work into a single binary package with the Apache product code.
- YOU MAY ALSO include within an Apache product a documented, non-default, build option to allow users to explicitly choose to validate, retrieve, or configure any system requirement for an Apache product, provided that such option is not likely to be confused with the standard product build and that any resulting retrieval of a prohibited work is accompanied by a clear identification of its associated license.
The purpose of this section is to describe the schedule by which PMCs are expected to transition through full compliance with this policy. In addition, a special rule for incubating projects is established and possible authorized exceptions are discussed.
All prohibited works that are currently included in builds or releases must be removed from future versions by the earlier of:
- one year from the effective date of this policy, or
- the second major release of any ASF product.
In addition, as of the effective date of this policy, new prohibited works must not be added to any project build or distribution.
For the following cases only, the application of the General Rule described above will be reevaluated in six months from the effective date of this policy:
- exclusion of the NPL 1.0 and 1.1 licenses
- prohibition of the application of Category B licenses (for binary only) to JavaScript, XML, and other works lacking a binary form
Since projects undergoing incubation are not officially endorsed by the ASF and are given an allowance to work out any remaining legal issues, a relaxed rule applies to these projects. The intent of this rule is to allow existing open source projects already including prohibited works to start incubation and then work to remove the prohibited works from the product.
In lieu of the General Rule above, the following rules apply to projects undergoing incubation:
- Initial code for newly incubating projects may be covered by an excluded license, as long as the license is confirmed not to place licensing restrictions on code developed for the project under CLA contributions. Either the V.P. of the Incubator Project or Legal Affairs V.P must make this determination.
- After the initial code contribution, future additions to the incubating project must not include works under an excluded license.
- Incubating projects must not distribute an official product release that includes works covered by an excluded license.
Should PMCs start implementing the License Labeling Requirement before prohibited works have been removed from their releases (whether major or minor releases), a special label will be needed for each label category that some third-party license violates. (e.g. "Transitional Exception: One or more works is not available under an open source license", with an associated image label having a big red "X" over the typical label category image plus product-specific text describing the work, the issue, and the expected date of compliance.)
The Binary Code License falls far short of the Open Source Definition, thereby violating the first criterion for license approval. All BCL-licensed works currently included in ASF products must be removed before the earlier of one year or two major releases (see the General Rule above). PMCs with BCL-licensed works are encouraged to use this time to request copyright owners of such works to consider also licensing under an authorized license (Category A or Category B), such as the CDDL. Another option for some products may be to move the BCL-licensed work to a system requirement that is not included in the product.
The NPL is simply the MPL (which is allowed under Category B) plus amendments that are specific to Netscape. Unfortunately, these amendments allow "Netscape" (now part of Time Warner) to avoid the reciprocity requirement that all other licensees must adhere to. This disqualifies the license from meeting Open Source Definition #5 ("No Discrimination Against Persons or Groups"). While this is a clear violation of the first license criterion, it is unlikely to be a significant practical concern for users of Apache products that include an NPL binary. Therefore, the NPL is currently listed as an excluded license, but this exclusion will be reevaluated in six months.
The current license policy only allows source files to be included under a Category A license, not a Category B license (binary only). Therefore, XML and text files covered by a Category B license cannot be included in an Apache product. Whether this places a significant burden on PMCs will be reevaluated in six months.
As AJAX-related functionality becomes more popular, there may be a demand for JavaScript libraries, which are only available in source form. The current license policy allows such code to be included when covered by a Category A license (authorized for source and binary), but not a Category B license (binary only). Whether there is an overwhelming need for such Category B-licensed JavaScript libraries to be included in the product will be reevaluated in six months.
The LGPL v2.1 is ineligible from being a Category B license (a category that includes the MPL, CPL, EPL, and CDDL) primarily due to the restrictions it places on larger works, violating the third license criterion. Therefore, LGPL v2.1-licensed works must not be included in Apache products, although they may be listed as system requirements or distributed elsewhere as optional works.
Some copyright holders have licensed their works under the GPL with special exceptions. Although these exceptions may appear to be addressing the restrictions disallowed by the ASF's first and second license criteria, the exceptions may only apply to software not "derived from or based on" the covered work. The references terms defined in the GPL that include works that "use" or "contain" the work. Therefore, software under these exceptions is generally not allowed for inclusion within an Apache product. PMCs may, however, choose to allow such works to be system requirements of an Apache product, provided a review by the ASF Legal Affairs officer and PMC chair determine no part of the product is copied from or derived from the GPL/exception-licensed work other than what is strictly required to achieve compatibility. See details for inclusions within the product that are related to excluded licenses.
<a name="define"><h3>Definitions</h3></a>
<dl>
<di><a name="define-binary"> </a>
<dt><u>binary</u></dt>
<dd>a form of the work not typically used for making modifications, including executables, object code, and Java class files</dd>
</di>
<br />
<di><a name="define-largerwork"> </a>
<dt><u>larger work</u></dt>
<dd>a work which combines the third-party work or portions thereof with code not governed by the terms of the third-party work's license (borrowed from the MPL/CDDL definition)</dd>
</di>
<br />
<di><a name="define-nonreciprocal"> </a>
<dt><u>nonreciprocal</u></dt>
<dd>allowing distribution of modifications and derivative works to be licensed under any terms that do not cause the distributor
to violate the original license</dd>
</di>
<br />
<di><a name="define-prohibitedwork"> </a>
<dt><u>prohibited work</u></dt>
<dd>a third-party work only available under an excluded (Category X) license</dd>
</di>
<br />
<di><a name="define-reciprocal"> </a>
<dt><u>reciprocal</u></dt>
<dd>requiring that the distribution of modifications or derivative works be made available under the same license as the original work</dd>
</di>
<br />
<di><a name="define-source"> </a>
<dt><u>source</u></dt>
<dd>the preferred form of the work for making modifications <i>(borrowed from the GPL's definition)</i></dd>
</di>
<br />
<di><a name="define-thirdpartywork"> </a>
<dt><u>third-party work</u></dt>
<dd>any work that has not been contributed to the ASF under a Contributor License Agreement</dd>
</di>
<br />
<di><a name="define-thirdpartylicense"> </a>
<dt><u>third-party license</u></dt>
<dd>the license applying to a third-party work</dd>
</di>
</dl>
For questions or feedback on this policy, please send mail to the legal-discuss mailing list.