According to Mend.io research, the Apache 2.0 license is the most popular license of its kind, as 30% of open source licenses currently in use is Apache. Owing to its frequent use, it’s important to understand how the license works, its benefits, limitations, implications, and requirements. To help you, here are ten frequently asked questions about it:
The Apache License is a permissive open source software license. This type of license gives you a broad range of permissions to use, modify, distribute, and sublicense the software, with minimal restrictions. You can integrate the source code into proprietary software and distribute it under a different license with your own specific terms and conditions that govern how others use, reproduce, or distribute their modified code. And you can use software with an Apache license for any purpose: personal, internal or external, and commercial. This flexibility makes it popular among developers.
The rights it gives you can be applied to both copyrights and patents, unlike other permissive licenses applicable only to copyrights. These rights are perpetual, worldwide, irrevocable, but also non-exclusive. That means anyone else can freely use the licensed work.
When you redistribute software with Apache-licensed components, you must include a copy of the license, provide a clear license attribution, and add modification notices to all the files that you modify. Nevertheless, you can release modified or derived products under different licenses if you choose. Any unmodified parts of the software must retain the Apache License.
You can choose to add a copyright statement about your modifications to any Apache-licensed software. It isn’t mandatory, but it’s considered good practice. What is required is the original copyright notice provided with the Apache-licensed software.
The first version of the Apache license was released in 1995, but it’s rarely used now. Version 1.1 was released in 2000. It introduced some improvements and clarifications, including patent and trademark grants.
Version 2.0 was released in 2004. It includes patent grants that allow you to use the software without patent infringement concerns. Also, you can modify, copy or update the source code of existing software and distribute any such changes, in source or binary form, providing they retain the copyright notice and disclaimers. You must include a copy of your Apache 2.0 license, a clear attribution, and a notice stating that changes have been made to the software.
No. The Apache 2.0 License is permissive. It allows you to use, modify, and distribute the licensed software, including creating derivative works, without requiring those derivative works to be licensed under the same terms. You can release the modified parts of the code under any license you prefer.
There are some obligations. You must release all the unmodified parts of the software under the same license (the Apache License), and you must include copyright and attribution notices, disclaiming warranties, and provide a copy of the license with any distribution of the software.
The GNU GPL is a copyleft license. Software that uses any GPL-licensed component must release its full source code and all rights to modify and distribute the entire code. The Apache License 2.0 doesn’t impose any such terms. You’re not forced to release your modified version. And unlike the GNU GPL, you can also choose to release your modified or derivative version under a different license, although you’re required to retain the Apache License for the unmodified parts of the code.
Apache License 2.0 is compatible with GPLv3, so you can freely mix the code that’s released under these two licenses. Nevertheless, the resulting software must be released under GPLv3. It is incompatible with GPLv2.
MIT is a more permissive license than Apache 2.0. Basically, you can do whatever you want with MIT-licensed software, provided you add a copy of the original MIT license and copyright notice to it.
Apache is stricter because it requires you to list all the modifications you make to the original software. A copy of the license, with copyright and attribution notices, must be included in the source code and any modifications. A specific section on contributions outlines the conditions for accepting external contributions to the project. The MIT license requires a copyright notice, but it does not have explicit requirements for the license or attribution notices.
Apache covers patent rights. It requires contributors to grant a license to any patents they hold that are relevant to the software. The MIT license does not. Apache allows users to sublicense the software under the same license terms. The MIT license does not address sub-licensing.
Apache includes provisions related to trademarks, requiring explicit permission from the license holder to use any trademark associated with the software. The MIT license does not. Also, you can’t name your product in any way that hints at the product being endorsed by Apache.
While both licenses allow software to be combined with projects under different licenses, Apache has more restrictions in terms of license compatibility compared to the MIT license.
The MIT license is gaining popularity with developers due to its short and clear license agreement that makes it simple and flexible to use. The Apache license agreement provides more protection for patents, contributions, and trademarks, but is far longer.
The BSD (Berkeley Software Distribution) license has minimal restrictions regarding the modification and distribution of software. Apache has more stipulations regarding these considerations, patent grants, and software sublicensing. Apache explicitly defines all the terms and concepts that it uses, leaving little scope for ambiguity.
Apache includes a clause that provides users with a patent license from the contributors of the software. This grant is perpetual, meaning it continues even after the license termination. BSD does not include a specific patent grant clause, which means it does not provide explicit protection against potential patent claims.
Apache includes an explicit indemnification clause, which offers some protection to contributors and users against legal claims related to patent infringement or other issues. BSD does not typically have such a clause, so it does not provide the same level of legal protection.
The BSD license is compatible with other open-source licenses, but some copyleft licenses, such as the GPL, may impose additional restrictions when combined with BSD-licensed code. The Apache license is generally considered more compatible with other open-source licenses, even copyleft licenses, as long as the license requirements of both licenses are met.
Finally, Apache can be easily used by other projects without any rewording of the license.
When using Apache-licensed software in your commercial product, you must follow the terms and conditions of the Apache license, such as:
Yes. You can release your own software under the Apache license, as long as you comply with the license’s terms and conditions. And you can sell any Apache-licensed software/code but you must comply with the terms of the Apache 2.0 license. This includes providing attribution and making the source code available to users, among other obligations outlined in the license. Additionally, any modifications you make to the open-source software must be released under the same Apache 2.0 license. Always review the terms and conditions of the license to ensure compliance with them. Take legal advice when licensing and selling open-source software.
You may face legal consequences from the Apache Software Foundation (ASF), which oversees the license, or the copyright holder. The specific action taken can vary depending on the circumstances and the severity of the violation. Some possible actions are as follows:
The Apache license is popular because it is permissive. Nevertheless, you must ensure compliance with and proper use of Apache-licensed software. The best way to do this is to deploy a compliance tool, consult the full text of the license, and seek legal advice. After all, better safe than sorry.