The Apache license 2.0 is one of the most popular permissive OSS licenses. There are many examples of prominent software products and successful projects licensed under Apache 2.0. The list includes Kubernetes (the famous open source system for deployment and management of containerized apps), the majority of the Android mobile platform and its documentation, Apache HTTP Server (one of the most popular web servers), Swift (programming language for iOS and macOS). There are two older versions of the Apache 2.0 license – Apache 1.0 which was released back in 1995 and Apache 1.1 which was published in 2000. However, version 2.0 has greatly outperformed those in terms of adoption and prominence.
As a typical representative of permissive open source licenses, Apache 2.0 grants broad rights and freedoms to the end users and only imposes certain attribution requirements upon redistribution.
One thing that is certainly commendable about the Apache 2.0 license is its detailed definitions section. This section provides clear and useful descriptions of key terms such as “source form”, “object form”, “work”, “derivative work”, “contribution”, etc. For example, the “source form” is stated to include source code, documentation source, and configuration files and is established as the preferred form for making modifications. In turn, “object form” is defined as the result from the mechanical transformation or translation of the source form that includes object code, documentation and conversions to other media types. Another useful point is the definition for “derivative work”. This is any work (in source or object form) that is based on a work made available under Apache 2.0 where the applied modifications represent, as a whole, an original work of authorship. It is interesting to note that works that remain separable from or merely link to the interfaces of the initial work made available under Apache 2.0 do not fall within the scope of the notion of “derivative work”.
Unlike many other permissive OSS licenses, Apache 2.0 grants the recipient of the code with both a copyright license and a patent license.
As for the grant of copyright, the Apache 2.0 license grants the end users with a perpetual, non-exclusive right to copy, modify, sublicense and distribute a covered work and any derivatives of a covered work in both source code and object code. Unlike copyleft licenses, here the recipient of the code is free to apply any license of its choice to a modified work. There is also the possibility to turn a derivative work into closed source software and distribute it under a proprietary license.
One thing that is peculiar about Apache 2.0 is that it also comes with a patent grant. Under Section 3 of the license, the code recipient is granted by each software contributor a perpetual, irrevocable, non-exclusive patent license to make, use, sell, and transfer the relevant patented work, as the grant would normally apply only to those patent claims that are licensable by the respective contributor. Moreover, section 3 also includes what is called a “patent peace” clause. The rationale behind such a provision is to reduce patent infringement claims in the open source community and to foster freedom to operate and innovate. In the case of Apache 2.0, the provision stipulates that in case an end user initiates patent litigation against any entity with the allegation that the software as a whole or any contribution incorporated in it constitutes a patent infringement, then any patent licenses granted to the end user under Apache 2.0 for that software shall terminate as of the date the litigation is started.
When it comes to redistribution, the recipient of the code is free to make copies of a covered work or a derivative work based on a covered work and to distribute those copies in source and object form provided that certain conditions are met. First, a copy of the Apache 2.0 license must be communicated to any subsequent recipient of the code. Second, if any of the files in a covered work are modified, then prominent notices should be applied about the performed changes. This is a requirement that can rarely be seen in other permissive licenses. For example, no such requirement can be found in the text of the MIT license or in the text of the BDS family of licenses. Third, when a derivative work is distributed, all copyright, patent and trademark notices from the source code of a covered work must be retained also in the source code of the derivative work. Finally, if a covered work contains a “NOTICE” text file with attribution notices, then any distributed derivative work of that covered work has to include a readable copy of the attribution notices that are contained in the NOTICE file. The license prescribes several ways through which this can be realized: i) through a NOTICE text file distributed as part of the derivative work, ii) through the source code or the documentation of the derivative work, iii) within a display that is generated by the derivative work.
Apache 2.0 disclaims any warranty from the licensor. A covered work is provided on an “as is” basis without any warranties or conditions of any kind. Accordingly, the recipient of the code gets no warranty of title, non-infringement, merchantability or fitness for a particular purpose. In such a situation the licensee is solely responsible to determine the appropriateness of using the work or redistributing it. Furthermore, the licensee carries all ensuing risks originating from the exercise of the granted rights under the license.
Additionally, Apache 2.0 excludes any liability of the licensor for direct, indirect, special, incidental, or consequential damages under any legal theory and both in contract and tort. The relevant license provision (Article 8) is so broad that despite being named limitation of liability, it gravitates towards an exclusion of liability. The only balancing term is the condition “unless required by applicable law or agreed to in writing” which gives way for any statutory positions that prohibit limiting certain types of liability. It has to be mentioned that such an approach is far from surprising since both the disclaimer of warranty and the exclusion of liability are common techniques employed by most OSS licenses.
Interestingly enough, Apache 2.0 explicitly permits that upon redistribution of a covered work or derivative work a licensee (including a legal entity) may offer additional obligations for support services or additional coverage for warranty, indemnity or liability and can respectively charge a fee for those extra obligations. However, in such a scenario, the licensee will be able to act only on its own behalf and not on behalf of any other code contributor in the covered work. Accordingly, the licensee will have to indemnify, defend and hold harmless each code contributor against any asserted claims or for any incurred liability as a result of the licensee accepting additional coverage for liability and warranty.
There is also an appendix to Apache 2.0 which describes how a developer can apply the license to a work. In particular, a copy of the license text must be placed into a file named LICENSE in the top directory of the distributed work. Additionally, a NOTICE file (with the content described in Article 4.4 of Apache 2.0) has to be placed in the same directory as the LICENSE file.
One final thing to have in mind is that Apache 2.0 is not compatible with the popular GPLv2 license. The position of the Free Software Foundation which has published GPLv2 is that the incompatibility is due to the patent termination and indemnification provisions in the Apache 2.0 license as no equivalent provisions are present in GPLv2.
Apache 2.0 is however compatible with GPLv3, so you can mix code released under these two licenses. However, you should keep in mind that in such a situation the final work result will have to be released under the GPLv3 license. This is due to the copyleft effect in GPLv3 which dictates that if code under a different license becomes part of a composed work together with GPLv3 code, then this other code and the composed work would also have to be distributed under GPLv3. It is due to this viral effect that code under GPLv3 cannot be included into projects of the Apache Software Foundation.
You must be logged in to post a comment.