Wednesday, 1 November, 2017 UTC
Summary
In 1997, Eric Raymond published his landmark essay “The Cathedral and the Bazaar”, which became the manifesto for the open source movement. He set forward principles like “plan to throw one version away”, “release early, release often”, and “given enough eyeballs, all bugs are shallow”, which today are part and parcel of any developer’s mind-set. A bright future was ahead for free software created for the greater good.
But time has passed since those naïve beginnings; open source has become one of the world’s biggest businesses. Developers and companies realized that in order to realize the commercial benefits of their open source work, and in order to build commercial products on top of open source, they might need lawyers, or at least some legal smarts. Open source licenses, as it turns out, can bite.
Copyleft vs. BSD-Style or Permissive Licenses
Two classes of licenses have emerged over the years, “copyleft” and “BSD-style” licenses. Copyleft licenses like GPL are, generally speaking, bad for business. They require all modifications, and any software based on the open source component, even in a small part, to be released under an open source license.
“BSD-style licenses”, also called permissive licenses, make much fewer demands on the user or modifier of the original open source code. They allow a user to build commercial software on top of open source software, or extend open source products, and declare their work as proprietary or closed source.
This has driven much higher adoption of this second category—MIT’s permissive license is used on 51% of Github projects. Apache 2.0, the runner-up, is used by another 14.8%, and 6.6% use either the 2-clause or 3-clause version of the original BSD license. A 72% market share for the leading permissive licenses, at least among Github users.
In this post we review and compare these three most popular licenses permissive licenses.
Benefits of Permissive Licenses
Permissive open-source licenses allow users to manipulate open source code and use it as they wish, given they provide attribution back to the creators and don’t hold them liable.
Why do developers choose to license their software under permissive licenses?
- These licenses encourage wider use of open source software, because they do not impose restrictions on developers who use them.
- They enable commercial adoption of open-source software.
- Companies can build on top of open-source code without needing to disclose the technologies or skills that gave them a competitive advantage.
- This MIT license permits reuse of software in proprietary projects, provided any future licensed software contains a copy of the license terms and copyright notice. The MIT license is short, clear, and easy to understand.
- The disadvantage is that anyone can take software licensed under MIT, change the branding, and sell it as proprietary software. Commercializing software released under an MIT license is more challenging. A common business model involves licensing the software as open-source, and offering proprietary extensions built on top of that software.
- Furthermore, MIT licenses don’t explicitly include a patent license grant. This means anyone who copies, uses, or distributes the software might become liable for patent infringement if the creator or contributor patented certain components. It is uncertain whether the law would imply a patent license, if the creator of the software were to sue a user for patent infringement.
- Facebook recently relicensed its open source projects React, Jest, Flow, and Immutable.js under the MIT license in September 2017, having failed to convince its user community to support the use of its new, restrictive license, “BSD + Patents”.
- Apache 2.0 allows users of the software to distribute, modify, or otherwise use software for any purpose, as long as the user complies with the license terms. The terms state that users can’t remove existing copyright, patent, trademarks and attribution notices.
- Recent updates of the license, leading up to Apache 2.0, allow it to be included by reference, instead of listed in every software file, meaning developers don’t need to insert license text into the GUI.
- In addition, this latest version has two patent clauses. The first states the software can be used regardless of software patents which are in effect, without any further obligations. The second states that software users can’t initiate litigation over patent infringement (and if so, they lose their license).
- This license is considered by many to offer the best patent protection among the permissive licenses.
- A limitation of this license for developers is that it requires you to add prominent notifications of any changes you make to a file.
- The Berkeley Software Distribution (BSD) licenses are a family of permissive licenses. From this family, the most common licenses are the 3-clause BSD license and the 2-clause license.
- The 3-clause (modified) BSD license includes a non-endorsement clause, which says users don’t have the right to market software using BSD-licensed components in such a way that their product appears to be endorsed by the original developers. The 2-clause BSD license removes this clause.
- Both licenses (2- and 3-clause) allow users to use the open source code as they please. The BSD license is suitable for long-term research projects which require near-zero licensing costs, and freedom to commercialize research results.
- BSD licenses can help minimize the legal and organization overheads associated with open-source projects.
- Lastly, the standard BSD license doesn’t specify any patent terms. A new and controversial license introduced by Facebook in 2014, BSD+Patents, specifies that if you sue the creator of the software for patent infringement, even if unrelated to the current open source software, you lose the patent license granted by the creator. Using software under BSD+Patents can endanger a company’s own patents, and can be frowned upon if it is acquired by a larger company.
| License | Code Use, Modification & Distribution | User Obligations | Patent License Grant | Linking code to other licenses | Trademark Grants |
|---|---|---|---|---|---|
| Apache 2.0 | Permissive. Must notify users of code modifications. | Can’t remove copyright, patent, trademark and attribution notices | Yes: Explicitly defined | Permissive | Not allowed |
| MIT | Permissive | Future licensed software must contains a copy of license and copyright notice | Not explicitly defined | Permissive | Not mentioned. Advance permission required |
| BSD | Permissive | BSD 3-clause: avoid appearance that product is endorsed by the original developers | Not explicitly defined* | Permissive | Not mentioned |
(*) Facebook’s modified BSD+Patents license contains a specific, restrictive patent section.
Conclusion
The long and short of it—if you use open source software within your software development project, any permissive license should be fine. The implications of using Apache 2.0, MIT or BSD are mainly relevant for the open source developer. As a developer, stopping to consider the fine details between the licenses can save you concerns further down the road.
But while understanding the differences between permissive licenses is important, far more important is drawing the line between them and their unfriendly counterparts, copyleft. As a user of open source components, copyleft licenses can “infect” your entire code base and impose restrictions that might prevent you from commercializing. As a developer of open source software, copyleft can significantly limit the appeal and adoption of your components.
If you use open source within your code and want to get better visibility of the licenses they use, and your possible exposure to legal issues, contact us! We’ll be happy to help.