This policy provides licensing guidance to Apache Software Foundation projects. It identifies the acceptable licenses for inclusion of third-party Open Source components in Apache Software Foundation products.
Projects can submit licensing questions to the Legal Affairs Committee JIRA space.
The following criteria serve as guidelines for the categories on this page.
a. (reviewed: 2019-02-16)
At a high level this policy separates licenses into three categories.
For inclusion in an Apache Software Foundation product, we consider the following licenses to be similar in terms to the Apache License 2.0:
Many of these licenses have specific attribution terms that the project needs to adhered to, often by adding them to the NOTICE file. Ensure you are doing this when including these works.
You can include works in the public domain (or covered by a license treated similarly) within Apache products. You must provide attribution (in a similar fashion to the Category A list).
A work should be treated as being in the public domain when one of the following applies:
Licenses that we treat as similar to public domain:
Note that whether a work falls in the public domain may be a difficult subject. Determining whether the copyright in a work has expired may be non-trivial and may vary between jurisdictions. Raise the topic on legal-discuss@ or via a JIRA issue if you have doubt over whether a work falls in the public domain.
You may include the licenses and/or projects described in this section in an Apache Software Foundation product IF they meet the specified conditions.
In all Category B cases our users should not be surprised at their inclusion in our products. If we attach an appropriate and prominent label to the distribution, users are less likely to be unaware of restrictions significantly different from those of the Apache License. An appropriate and prominent label is a label the user will read while learning about the distribution - for example in a README, and it should identify the third-party product and its licensing, and provide a url to the its homepage. Please also comply with any attribution/notice requirements in the specific license in question.
Any Category B licensed works may be included in binary-only form in Apache Software Foundation convenience binaries. Do not include Category B licensed works in source releases.
Each license in this section requires some degree of reciprocity. This may require additional action to minimize the chance that a user of an Apache product will create a derivative work of a differently-licensed portion of an Apache product without being aware of the applicable requirements.
You may include software under the following licenses in binary form within an Apache product if you label the inclusion appropriately (see above):
By including only the object/binary form, there is less exposed surface area of the third-party work from which someone might derive a work. This addresses the second guiding principle of this policy.
For small amounts of source code that the ASF product directly consumes at runtime, and for which that source is unmodified and unlikely to be changed anyway (say, by virtue of being specified by a standard), you may include appropriately labeled source code. An example of this is the web-facesconfig_1_0.dtd, whose inclusion is mandated by the JSR 127: JavaServer Faces specification.
Works under the Creative Commons Attribution (CC-BY) licenses (2.5, 3.0, and 4.0) contain terms related to "Effective Technological Measures", which may come as a surprise to users. Thus you should label them appropriately and only include them in binary form.
You may include unmodified media under the Creative Commons Attribution-Share Alike 2.5, Creative Commons Attribution-Share Alike 3.0 and Creative Commons Attribution-Share Alike 4.0 license in Apache products, subject to the licenses attribution clauses which may require LICENSE/NOTICE/README changes. For any other type of CC-SA licensed work, contact the Legal PMC.
Note that media is intended to mean binary visual/video/audio elements used in our documentation. It is not intended to mean inclusion in our source code.
No, not without contacting the original author and getting permission from them to use the code in an Apache project under the Apache License 2.0.
Doug Lea's concurrent library is public domain, but contains some Sun files which are not public domain. You may include this library in ASF products much like the resources in the 'weak copyleft' list above. "It may be included in binary form within an Apache product if the inclusion is appropriately labeled". If using the source, remove the files Sun licensed to Doug and treat as Category A (or get the files from Harmony).
You can insert OSGi metadata into 'Category B' licensed jars, provided that you include a note that this has occurred in the prominent labeling for the jar.
You may include Cobertura reports in ASF distributions.
There are licenses that give broad rights for redistribution of unmodified copies. Such licenses are not open source, but they do satisfy the second and third guiding principles above.
Apache projects must not include material under such licenses in version control or in released source packages. It is however acceptable for a build process to automatically download such non-software materials like fonts and standardized data and include them in the resulting binaries. Such use makes it clear that these dependencies are not a part of the open source code of the project.
You may use material under the following licenses, as described above:
Many languages have developed ecosystems of associated tools that aid in the building of artifacts for distribution. While such tools may not always be made available under an otherwise compatible license, we have approved specific tools for inclusion in Apache distributions when they are used for that specific purpose.
Note that the tool must not affect the licensing of the project source code. We also expect that our use of the tooling to build our source code is its typical use.
To date, we have approved the following tools for such use:
Developing Perl bindings which link compiled C code to create dynamically loaded XS modules requires including header files licensed under the Perl license (http://dev.perl.org/licenses/ - GPL-any/Artistic1, with exceptions).
You may include these header files - XSUB.h, perl.h and EXTERN.h (see: LEGAL-79).
You may use these files as long as you remove the generated comments.
A project written primarily and obviously in Ruby can have a dependency either on Matz's Ruby Interpreter (MRI),
or on any Gem which is licensed under the Ruby license.
Of course Gems written under other licenses (such as MIT) may also be OK, depending on the license.
Also note that the Ruby license is listed on the 'Category B' Weak Copyleft list above for binary usage (for example JRuby).
From Java 9 onwards, Javadoc can include JavaScript under MIT, MIT OR GPL-3.0, or GPL-2.0 WITH ClasspathException-2.0. Apache binary releases (including Maven javadoc jars) and Apache websites may include this for their javadoc. It must not be included in source releases.
You may NOT include the following licenses within Apache products:
Details of 'other concerns':
Facebook BSD+Patents license
The Facebook BSD+Patents license includes a specification of a PATENTS file that
passes along risk to downstream consumers of our software imbalanced
in favor of the licensor, not the licensee, thereby violating our Apache
legal policy of being a universal donor.
The terms of Facebook BSD+Patents license are not a subset of those found in the ALv2, and they cannot be sublicensed as ALv2.
NPL
The Netscape Public License is the original license for Mozilla containing
amendments that are specific to Netscape. These
amendments allow "Netscape" (now part of AOL) 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").
Nonsensical licenses
These licenses while amusing to their creators are legally problematic. They often include subjective Field of use restrictions e.g. “Don’t be evil” with no definition of the arbiter for that subjective restriction. In some cases they may not even grant sufficient rights to conform to the OSI open source definition. Since we do not wish to surprise our downstream consumers we forbid the use of such licenses.
JSON license
As of 2016-11-03 the JSON license was moved to the 'Category X' license list. Prior to this, use of
the JSON Java library was allowed. See Debian's page for a
list of alternatives.
Apache projects may not distribute Category X licensed components, in source or binary form; in ASF source code or in convenience binaries. As with the previous question on platforms, you can rely on the component if its license terms do not affect the Apache product's licensing. For example, using a GPL'ed tool during the build is okay, but including GPL'ed source code is not.
Apache projects can rely on components under prohibited licenses if the component is only needed for optional features. When doing so, a project shall provide the user with instructions on how to obtain and install the non-included work. Optional means that the component is not required for standard use of the product or for the product to achieve a desirable level of quality. The question to ask yourself in this situation is:
It does not matter, unless the terms for that platform affect the Apache product's licensing. For example, creating a product that runs on Windows or Java, uses a web service such as Google Services or Yahoo Search, or is a plugin for a product such as JBoss or JIRA is fine, whereas creating a Linux kernel module is not fine because the Apache product itself would have to be licensed under something other than the Apache License, version 2.0.
Note that this does not mean you can redistribute the platform code itself. That of course depends on the licensing of said code. If you have any doubts as to whether the licensing of the platform would affect the Apache code, check the legal-discuss@ archives to see if it has come up before, and if not email legal-discuss@ to find out.
No.
IP clearance is used to import code bases from outside Apache for future development here.
When including that work's licensing, state which license you are using and include only the license that you have chosen. Prefer Category A to Category B to Category X. You don't need to modify the work itself if, for example, it mentions the various licensing options in the source headers.
When a release contains third party works, the licenses covering those works may ask that you inform consumers in certain specific fashions. These third party notices vary from license to license. Apache releases should contain a copy of each license, usually contained in the LICENSE document. For many licenses this is a sufficient notice. Some licenses require some additional notice. In many cases, you can include this notice within the dependent artifact.
A required third-party notice is any third party notice which the above cases don't cover.
See Bundling Other ASF Products for a note on required notices when a release contains another Apache product.