Purpose
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
License Criteria
The following criteria serve as guidelines for the categories on this page.
The license must meet the
Open Source Definition
The license, as applied in practice, must not impose significant restrictions beyond those imposed by the Apache License 2.0.
a. (reviewed: 2019-02-16)
High Level
At a high level this policy separates licenses into three categories.
Category A
: Licenses in Category A may be included in Apache Software Foundation products. They are said to be "Apache-like".
Category B
: Licenses in Category B may be, under certain conditions, included in Apache Software Foundation products. They 'may Be' included.
Category X
: Licenses in Category X may
NOT
be included in Apache Software Foundation products.
Category A: What can we include in an ASF Project?
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.
Handling Public Domain 'licensed' 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:
the work is covered by
the Creative Commons
Public Domain Mark
a suitable dedication (to the public domain) by the authors
clear evidence exists that US copyright for the work
has expired
cannot be claimed.
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.
Category B: What can we
maybe
include in an ASF Project?
You may include the licenses and/or projects described in this section in an Apache Software Foundation product
IF
they meet the specified conditions.
Appropriately Labelled Condition
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.
Binary-only Inclusion Condition
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.
"Weak Copyleft" Licenses
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.
GPL-2.0 with GNU ClasspathException
Depending on the situation, the GPL-2.0 WITH ClasspathException-2.0 may, or may not, affect the licensing of the Apache product. PMCs must review each ClasspathException-2.0 dependency of their products to ensure it does not affect the licensing of their product, and to comply with the licensing of that dependency. To include in a binary distribution, PMCs are recommended to apply two tests:
Confirm the dependency is fully under the ClasspathException-2.0 and that it does not contain GPL-2.0
without
the ClasspathException-2.0; AND
Confirm that the dependency is a separate module from the other works in the product (typically a separate jar file).
Note that most GPL-2.0 WITH ClasspathException-2.0 dependencies are dual-licensed with either CDDL-1.1 or EPL-2.0 and PMCs will likely prefer to depend on those dependencies under the alternate license.
GCC Runtime Library exception
ASF produced binaries may incorporate the GCC Runtime Library per the language of the relevant GCC release's GCC Runtime
Library exception (
2.0
or
3.1
).
PMCs must review that ASF product modules are being combined with the GCC Runtime Library module. If the modules are not being combined,
then the PMC should seek further guidance. Common methods of combination are building the ASF code and GCC Runtime Library into a
machine executable, or combining the two into a single shared library.
Including Creative Commons Attribution content
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.
Unmodified media under the Creative Commons Attribution-Share Alike license
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.
Can I copy code from Stack Overflow and contribute it to an ASF project?
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
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
).
Adding OSGi metadata to weak copyleft binaries
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.
Cobertura reports
You may include Cobertura reports in ASF distributions.
Handling licenses that prevent modification
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 (
- GPL-any/Artistic1, with exceptions).
You may include these header files - XSUB.h, perl.h and EXTERN.h (see:
LEGAL-79
).
Including Doxygen-generated config files
You may use these files as long as you remove the generated comments.
Can Apache projects have external dependencies on Ruby licensed works?
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 search functionality that includes JavaScript under other open source licenses. Can Apache projects include this javadoc?
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.
Can we aggregate jars under the Category A licenses and the weak-copyleft Category B licenses into a single aggregated jar file?
Yes.
For these aggregated jar files, can we modify ancillary files that are under weak-copyleft Category B licenses?
Yes. PMCs must review that the modifications are not changing the purpose of the original jar files (i.e. ancillary purposes). We consider both improvements to MANIFEST.MF files and changing of package names to be suitable ancillary modifications.
Category X: What can we NOT include in an ASF Project?
You may NOT include the following licenses within Apache products:
Not OSD-compliant:
Places restrictions on larger works:
Other concerns:
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.
In 2022 (from the 20220924 release), the most popular use of this license, the JSON Java library,
switched from the JSON license to being in the Public Domain. These newer versions are thus Category A.
They may not be distributed
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.
You may rely on them when they support an optional feature
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:
"Will the majority of users want to use my product without adding the optional components?"
FAQ:
Does it matter what platform an Apache product is created to work with?
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.
Is IP clearance required for library dependencies?
No.
IP clearance
is used to import code bases from outside Apache for future development here.
How should I handle a work when there is a choice of license?
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.
What Are Required Third-party Notices?
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.
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.