ApacheCon is Coming 9-12 Sept. 2019 - Las Vegas The Apache Software Foundation
Apache 20th Anniversary Logo

Celebrating 20 years of community-led development "The Apache Way"

Apache Support Logo
ASF 3rd Party License Policy

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.

If they have a licensing question, projects are asked to submit questions to the Legal Affairs Committee JIRA space.

License Criteria

The following criteria serve as guidelines for the categories on this page.

  1. The license must meet the Open Source Definition.a
  2. 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: What can we include in an ASF Project?

For the purposes of being included in an Apache Software Foundation product, the following licenses are considered to be similar in terms to the Apache License 2.0:

Many of these licenses have specific attribution terms that need to be adhered to, often by adding them to the NOTICE file. Ensure you are doing this when including these works.

Handling Public Domain 'licensed' works

Works in the public domain (or covered by a license treated similarly) may be included within Apache products. Attribution is required (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 should be treated 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?

For the purposes of being included in an Apache Software Foundation product, licenses and/or projects described in this section may be included IF specified conditions are met.

Appropriately Labelled Condition

In all Category B cases our users should not be surprised at their inclusion in our products. By attaching 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, its licensing, and a url to the its homepage. Please also ensure to comply with any attribution/notice requirements in the specific license in question.

Binary-only Inclusion Condition

Unless otherwise specified, all Category B licensed works should be included in binary-only form in Apache Software Foundation convenience binaries (and not source code).

"Weak Copyleft" Licenses

Each license in this section requires some degree of reciprocity. This may mean that additional action is warranted in order 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.

Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled (see above):

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.

For small amounts of source that is directly consumed by the ASF product at runtime in source form, and for which that source is unmodified and unlikely to be changed anyway (say, by virtue of being specified by a standard), inclusion of appropriately labeled source is also permitted. An example of this is the web-facesconfig_1_0.dtd, whose inclusion is mandated by the JSR 127: JavaServer Faces specification.

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 their inclusion shall be appropriately labelled and only in binary form.

Unmodified media under the Creative Commons Attribution-Share Alike license

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 licenses may be included 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, please 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 inside our source code.

Doug Lea's concurrent library

Doug Lea's concurrent library is public domain, but contains some Sun files which are not public domain. This may be included in ASF products much like 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

Insertion of OSGi metadata into 'Category B' licensed jars is permitted providing that a note that this has occurred is included in the prominent labeling for the jar.

Cobertura reports

Cobertura reports may be included 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.

Material under the following licenses may be used as described above:

Incuding build tools in ASF products

Many languages have developed an ecosystem 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, specific tools have been OK'ed for inclusion in Apache distributions when used for that specific purpose.

The most important criteria to be included in this category is that such tools are not customarily part of distributions of running code, unless such deliverables include source anyway. Other criteria for inclusion include: having been around for years, being defacto standards in their respective communities, being made available under are under "library" or "lesser" licenses or otherwise containing an exception which ensures that usage of this tool does not affect the license of the code against which it is run.

To date, the following tools have been approved for such usage:

Including Perl licensed header files when creating dynamically loaded XS modules

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).

Including Doxygen-generated config files

As long as the generated comments are removed from the Doxygen-generated files, these files may be used.

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).

Category X: What can we NOT include in an ASF Project?

The following licenses may NOT be included 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 arbiter for that subjective restriction defined. 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.

They may not be distributed

Apache projects may not distribute Category X licensed components, be it in source or binary form; and be it in ASF source code or convenience binaries. As with the previous question on platforms, the component can be relied on if the component's license terms do not affect the Apache product's licensing. For example, using a GPL'ed tool during the build is OK, however including GPL'ed source code is not.

They may be relied upon 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:

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 the platform code itself can be redistributed. That of course will depend on the licensing of said code. Also, if you have any doubts as to whether the licensing of the platform would affect the Apache code, we recommend that you 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 works for which multiple mutually exclusive licenses are available be handled?

When including that work's licensing, state which license is being used 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 consumers are informed 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. For some licenses some additional notice is required. In many cases, this will be included within the dependent artifact.

A required third-party notice is any third party notice which isn't covered by the above cases.

See Bundling Other ASF Products for a note on required notices when a release contains another Apache product.