Why the Apache Open-Source License?
11/28/2018 / By Derek Jones
11/28/2018 / By Derek Jones
Most people ignore license agreements. And it’s no wonder, we have years of practice. It started with six-point type on a card inside a software box. Now it’s a form that scrolls forever before you are allowed to click “agree” to update your phone. We are trained to be annoyed by licenses.
But they’re a fact of life, and important for digital rights. They are even more critical for projects which accept contributions, like open-source software. Original code is protected under copyright law, which in most countries gives the author the exclusive right to reproduce, distribute, or make derivative works. Without a software license, no one else has the rights to do anything but read the code. Not even use it. So it’s critical for software licenses to grant contributors and end users the ability to do stuff with the software.
And it needs to do this in a way that is uniform worldwide and minimizes the end user’s risk. It’s this protection of end users against risk that led us to the Apache 2.0 Software License.
As the number of contributors increase, so do the number of people who could lay claim against end users. This is why companies across many industries do not accept ideas from the general public. Each external contribution that is not covered by a license or work-for-hire represents risk to end users, distributors, and the company itself. Companies with products that plan to be around for a long time avoid that risk altogether.
Technology has made it easier to collaborate with talented developers around the world. GitHub in particular has made sharing work so easy, that most developers don’t consider whether they’re adding risk to end users. They just want to click the merge button and improve the software. In some circles there is even a dangerous culture of willful ignorance. They feel that legal issues are too complex or distasteful, so they proudly don’t care, as if that somehow immunizes their project. They ignore the legal implications and added risk for end users.
The Apache license includes a copyright grant for contributors that allows contributions to be licensed to others under the Apache license. It allows a project to include outside contributions without adding needless risk for end users.†
Patent owners often demand royalties for each distributed use of their patented works. This can happen after the fact, too. Sometimes a patent-holder seeks compensation from those who were unaware their software included patented works. If royalties on the software you use were suddenly levied at 5-10% of profit, or your rights were revoked, what would happen to your business?
The most popular open-source license—MIT—was created before software patents were common. Without a separate legal declaration, it’s unclear whether MIT licensed software a) contains any patented works and b) whether users are infringing on those patents. For a contemporary look at the debate and potential problems this holds, just look at the Facebook React licensing debacle. Explicitness is always preferred to implication.
The Apache license includes a specific patent usage grant to all licensees, and a company’s own right to use the software is revoked if they bring lawsuit against end users. This balances the intellectual property rights of patent holders and end users.
Like MIT and the similar BSD license, the Apache open-source license is very permissive. It has no copyleft provisions, and it contains no political agenda. It is compatible with other software licenses. It gives end users favorable rights and protects them against short and long-term risk. The Apache Software Foundation is satisified with it, and much of the web runs on software with this license. Google chose it for Android. The Cloud Native Computing Foundation chose it for Kubernetes. Apple chose it for Swift. And we’re happy to choose it for ExpressionEngine.
We have published contribution guidelines so that folks who want to get involved can get started without delay. The Apache license along with a CLA enable low-friction contributions while ensuring a long future and minimal risk for adopters.
This blog and its contents are for informational purposes only and do not constitute legal or professional advice.
† You may have noticed that ExpressionEngine also has a Contributor License Agreement. CLAs add another layer of risk mitigation. They feature active rather than passive assent. They make the grant of rights clear. And they allow a project maintainer to later relicense the work without having to seek permission from thousands of contributors. These features all further protect end users, and as such you will find CLAs in all well-maintained projects around the world.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.