Open source licensing: Everything you need to know

Open source drives the tech world forward, shaping 90% of the modern software stack through frameworks; library; database; operating system; and countless standalone applications. The benefits of open source software are well understood, promising greater control and transparency. However, there is a constant struggle between open nature and ownership, which has led many companies to withdraw from open source to protect their commercial interests. At the heart of all this is the issue of licensing. There are two types of licenses that fit the official open source definition as provided by the Open Source Initiative (OSI). “Permissive” licenses contain few restrictions on how users can modify and distribute the software, making it popular with companies looking to use it commercially. Then there’s the “copyleft” license, which offers the same freedom but with one important caveat: Modified versions of the software must also be distributed under the same original copyleft license. This is unfortunate for businesses that want to protect their proprietary work. But there is more to it than that, with different licenses in each bucket. In addition, there are many licenses that, although not open source, should also be known. MIT Permissive Originating from the Massachusetts Institute of Technology in the 1980s, the aptly named MIT license is the most popular open source license by metric, sitting at the top of the GitHub development community for years. Used by projects including React (a front-end JavaScript library) and Ruby (a general-purpose programming language), the MIT license allows developers to use the software as they see fit. As with most such licenses, they are granted without warranty, which means that the author is not responsible for damages caused by the software (for example, loss of data). All developers should be concerned about including the original copyright notice and MIT license in any derivative works. But the MIT license has a drawback: It doesn’t grant patent rights clearly. This means that if certain software relies on patented technology, this may create legal uncertainty for developers who distribute the software without obtaining separate permission for the patented technology. However, it emphasizes one of the main selling points of the MIT license: with only 200 words, the language is simple and concise. Muddying things with ambiguous, word-soup patent spiel will add unnecessary complexity to projects that have nothing to do with patents, such as high-level programming languages ​​or web frameworks. But many open source projects intersect with proprietary technologies, such as hardware-centric software like Android. Apache 2.0 License The Apache Software Foundation published the Apache 2.0 License in 2004, updating the previous license with an explicit patent grant to protect users from litigation. So, if a developer, for example, contributes a unique image processing algorithm to a project licensed under Apache 2.0, any patents developed by the developer on that algorithm are automatically licensed to all users of the software. Most people will be familiar with Google’s Android brand, complete with its app store and home devices and services. But the Android Open Source Project (AOSP) is basically available under the Apache 2.0 license, a deliberate move by Google in 2008 to fight Apple and encourage phone manufacturers to use Android against other proprietary incumbents (eg, Symbian). And it worked. Samsung, HTC, LG, and all the rest are jumping on the Android bandwagon. However, the byproduct of this is that the Apache 2.0 License has about five times the word count of MIT, due to the patent text, among other additions and clarifications. But this is a trade-off, and represents a major difference between the two most common open source licenses. Other permissive licenses The BSD 2-Clause License is similar to the MIT, but with a major difference in the language used. For example, it specifies that a copy of the license must be included with the source code and compiled binary form. Then there’s the BSD 3-Clause License, which has an additional “no endorsement” clause that restricts the use of the copyright holder’s and contributor’s names for promotional purposes in any derivative project. There is also the MIT No Attribution License (MIT-0), which is simpler than the MIT, as there is no requirement for attribution in derivative software. Using this is close to placing the software in the public domain, except that the author has no copyright and the ability to change things in the future. Copyleft GNU General Public License (GPL) v. 2.0 and 3.0 The Free Software Foundation (FSF) published the GNU General Public License (GPL) in 1989, and it was one of the first copyleft licenses for public use. Copyleft licenses are often more appropriate for projects that require input from the community, rather than projects supported by a single corporate entity. By requiring all modifications to remain available under the same open source license, it assures contributors that their hard work will not be used in proprietary software without also benefiting the wider community – at least, in theory, as it can be difficult to find every infringement and then implement the license requirements. Launched in 2007, GPL 3.0 is the third most popular license, according to GitHub data. The license provides important updates on GPL 2.0, including patent grant provisions and better compatibility with other open source licenses. It also prohibits what has come to be known as “Tivoization,” where hardware manufacturers who benefit from GPL-licensed software prevent users from installing modified versions of the software, using digital rights management (DRM) mechanisms. Notable adopters of the GPL include WordPress, which is available under the GPL 2.0 “or later” license, leaving developers to decide what license to distribute. Linux, for its part, is one of the most successful open source projects of all time, used in servers, cloud infrastructure, embedded systems, and even Android. However, the basic Linux kernel is only available under the GPL 2.0 license, because Linux creator Linus Torvalds objected to some provisions added in version 3.0 of the license – including the Tivoization clause. GNU Affero General Public License (AGPL) 3.0 The Affero General Public License (AGPL) is similar to GPL 3.0, while it is a “strong” copyleft license that promotes software freedom and ensures that modified versions remain open source. However, the main difference with AGPL is its focus on web-based services and applications, where the software is run from a server rather than distributed as an executable file. Under the GPL 3.0 license, developers are not required to release the source code for modified software if it runs on a network, as is the case with SaaS applications. The AGPL license closes this loophole, requiring third parties to make the source code available even if the modified software runs only from a server. Published in 2007 by the Free Software Foundation, the AGPL 3.0 license has become popular due in large part to the rise of cloud computing and SaaS, and is now the fifth most popular open source license. GNU Lesser General Public License (LGPL) Also a product of the Free Software Foundation, the GNU Lesser General Public License (LGPL) is a “weak” copyleft license, as it is more business-friendly with less strict provisions about what is shared. The LGPL is typically used for software libraries where project authors want to encourage contributions from the community, but allow proprietary software to link to the library without having to open source all proprietary code. If someone modifies the open source library themselves, then they should only release those modifications under the LGPL license. Mozilla Public License 2.0 Published by the Mozilla Foundation in 2012, the Mozilla Public License (MPL) 2.0 is currently the tenth most popular open source license according to GitHub license metrics. MPL is also a weak copyleft license designed to protect proprietary code while allowing developers to benefit from open source software. However, while the LGPL focuses on the library level, and the GPL on the project level, MPL operates on the individual file level requiring the user to share a set of code arrows. Public domain and creative commons When the “open source license” gives certain rights, there are always provisions attached. Those who wish to place their entire software in the public domain without caveats, however, can do so in other ways. It is not enough to simply publish software without a license; Copyright law applies by default to most creative works, including software. This is where “public domain dedication” can help. Designed specifically for software, Unlicense is the ninth most popular license on GitHub (although whether it can be called a “license” is debatable). Although the OSI approved it as a license in 2020, they noted that the document was “well-designed” and questioned its legal validity in jurisdictions (for example, Germany) that cannot contribute works to the public domain. Like Unlicense, CC0-1.0 Creative Commons is also a public domain dedication tool, although it focuses more on creative works. It uses a more clear and professional legal language that may be compatible with international law. It’s worth noting that Creative Commons applied to have CC0-1.0 approved as an open source compatible license in 2012, but withdrew the application after OSI expressed concern that it clearly excluded patents. There are other common dedicated tools, such as Zero-Clause BSD, which may be attractive because of their simpler language. However, there is no consensus on the best mechanism for assigning all rights to a given piece of software. “Faux-pen” Sources There are many other licensing paradigms across the software spectrum. In some cases, businesses will release their software under a dual-license model, with users able to choose between a recognized open source license and a commercial license, depending on their purpose. Then there is “open core,” which offers software under an open source license, but with key features that are paid for. In other cases, companies can add a Commons Clause addendum to the open source license that allows it, creating commercial restrictions. There are also many licenses that look and smell like open source, but are ultimately incompatible with the definition of open source. In 2018, database giant MongoDB transitioned from a copyleft AGPL license to a server-side public license (SSPL), a license created by MongoDB itself. While the SSPL is still quite “open”, it is what is known as “available source,” because the code is accessible but has significant commercial restrictions, which cannot be done under OSI. The folks at MariaDB forged a similar path with the business source license (BUSL), which imposed commercial restrictions before moving to a true open source license after a few years. There are other movements that are similar in the way that are looking to create a “fair source” license chapter. This includes the Functional Source License, which is said to be a simpler alternative to BUSL. You can also find “ethical source” licenses from time to time, such as the Hippocratic License, which prohibits the use of software that violates internationally recognized human rights. Also, the open standard JSON file format has a very permissive license, minus the funny clause at the end: “The Software shall be used for Good, not evil.”

Source link