Up to 90% of the current software stack is made up of open source frameworks, libraries, databases, operating systems, and innumerable standalone apps.
Open source software has well-established advantages, including increased transparency and control. But because of the ongoing conflict between the open source and proprietary worlds, many businesses are turning away from open source in order to safeguard their financial interests. The difficult problem of licensing lies at the core of all of this.
According to the Open Source Initiative (OSI), there are two main categories of licenses that fit the official definition of open source. “Permissive” licenses are popular among businesses that want to utilize the software for commercial purposes because they have few restrictions on how users can alter and distribute it. Then there are “copyleft” licenses, which provide comparable liberties but have one significant restriction: Any software that has been altered must likewise be distributed under the original copyleft license. For companies looking to safeguard their proprietary work, this isn’t very enticing.
There is more to it than that, too, as each bucket has a variety of licenses. Furthermore, there are innumerable licenses that are worth being aware of even though they are not precisely open source.
Permissive
MIT
The appropriately called MIT license, which was created at the Massachusetts Institute of Technology in the 1980s, has been the most widely used open source license by most measures and has long held the top rank among the GitHub development community.
The MIT license, which is used by projects like Ruby (a general-purpose programming language) and React (a front-end JavaScript library), permits developers to use software anyway they see fit. It is offered without warranties, as are the majority of these licenses, which releases authors from responsibility for any harm their software may do (such as data loss). Developers only need to make sure that any derivative work has the original MIT license and copyright notice.
However, there is a flaw in the MIT license: patent rights are not expressly granted. This implies that if a particular piece of software uses patented technology, it may put developers in a difficult legal position if they use the program without obtaining separate permits for the protected technology.
Nonetheless, this emphasizes one of the MIT license’s main selling points: the wording is clear and succinct, weighing only 200 words. For initiatives like web frameworks or high-level programming languages that are unlikely to be affected by patents, muddying things with vague, word-soup patent blather would add unnecessary complication.
However, a lot of open source initiatives do interact with patented technologies, such Android and other hardware-focused applications.
Apache License 2.0
In 2004, the Apache Software Foundation released Apache License 2.0, an upgrade to the original license that included a clear patent grant to shield users from legal action. Therefore, any patents that a developer owns on a unique image processing technique they submit to a project licensed under Apache 2.0 are automatically licensed to all software users.
The majority of consumers will be familiar with Google’s Android brand, which includes an app store and a number of exclusive tools and services. However, Google made a conscious effort in 2008 to compete with Apple and persuade phone manufacturers to use Android rather than the other proprietary incumbents (like Symbian) of the time by making the underlying Android Open Source Project (AOSP) substantively available under the Apache 2.0 license. And it was successful. Samsung, HTC, LG, and everyone else went on the Android bandwagon.
However, because of the patent grant text and other changes and clarifications, the Apache License 2.0 contains about five times the word count of MIT. This trade-off, however, highlights the main differences between the two most popular liberal open source licenses.
Other permissive licenses
Although there are some significant linguistic distinctions between MIT and the BSD 2-Clause License, they are otherwise comparable. For example, it stipulates that both the source code and the built binary form must be accompanied by a copy of the license. The BSD 3-Clause License, on the other hand, contains an extra “no endorsement” clause that prohibits the use of contributors’ and copyright holders’ names for marketing reasons in any derivative work.
Another option is the MIT No Attribution License (MIT-0), which is less complicated than the MIT in that derivative software is exempt from the attribution obligation. With the exception of the author’s copyright and future modification rights, using this is nearly equivalent to releasing software into the public domain.
Copyleft
GNU General Public License (GPL) v. 2.0 and 3.0
The GNU General Public License (GPL), one of the earliest copyleft licenses for general usage, was released by the Free Software Foundation (FSF) in 1989.
In contrast to projects backed by a single corporate body, copyleft licenses are frequently more appropriate for initiatives that need community engagement. Since it can be challenging to find every violation and then enforce the license’s terms, this ensures that contributors’ labor won’t be used in proprietary software without also benefiting the larger community by requiring that all modifications remain available under the same open source license.
According to GitHub data, GPL 3.0, which was introduced in 2007, is currently the third most popular license. Notable changes to GPL 2.0 were brought about by the license, such as enhanced compatibility with other open source licenses and provisions pertaining to patent grants. Additionally, it forbids the practice known as “Tivoization,” in which hardware manufacturers who profit from GPL-licensed software use digital rights management (DRM) tools to stop users from installing modified versions of that software.
WordPress is a notable example of a GPL adopter; it is available under a GPL 2.0 “or later” license, allowing the developer to choose which license to use for any modifications.
One of the most popular open source projects ever, Linux is utilized in embedded systems, servers, cloud infrastructure, and even Android. However, because Linux creator Linus Torvalds opposes several of the clauses added in version 3.0 of the license, such as the Tivoization clause, the underlying Linux kernel is only available under a GPL 2.0 license.
GNU Affero General Public License (AGPL) 3.0
Similar to GPL 3.0, the Affero General Public License (AGPL) is a “strong” copyleft license that upholds software freedoms and guarantees that modified versions stay open source. The concentration on web-based services and applications, where the software is operated from servers rather than distributed as executable files, is a significant difference with AGPL, though.
When changed software is run via a network, as SaaS apps are, developers are not obligated to provide the source code under a GPL 3.0 license. This flaw is fixed by the AGPL license, which mandates that third parties provide the source code even if the altered software is only being used on a server.
The AGPL 3.0 license, which was published by the Free Software Foundation in 2007, has become the fifth most common open source license. This growth is mostly attributable to the growth of cloud computing and SaaS.
GNU Lesser General Public License (LGPL)
The GNU Lesser General Public License (LGPL), another creation of the Free Software Foundation, is a “weak” copyleft license in that it has less restrictive sharing requirements and is more business-friendly. Although LGPL permits private applications to connect to software libraries without having to open source their complete proprietary code, it is typically used for software libraries where project developers wish to promote community contributions. The LGPL license is all that is required of anyone who makes changes to the open source library itself.
Mozilla Public License 2.0
According to GitHub’s licensing metric, the Mozilla Public License (MPL) 2.0, which was published by the Mozilla Foundation in 2012, is currently the tenth most widely used open source license. The MPL is a weak copyleft license that allows developers to profit from open source software while protecting proprietary code.
However, MPL functions at the individual file level, forcing the user to share a more limited collection of code, whereas LGPL is concentrated at the library level and GPL at the project level.
Public domain and creative commons
Even though a “open source license” confers particular rights, there are usually conditions involved. However, there are additional options available to those who wish to fully release their software into the public domain without any restrictions.
Simply publishing software without a license is insufficient because most creative works, including software, are automatically protected by copyright law. A “public domain dedication” can be useful in this situation.
The Unlicense is the ninth most popular license on GitHub and was created especially for software, albeit it’s questionable if it truly qualifies as a “license.” Despite approving it as a license in 2020, the OSI criticized the document’s “poor drafting” and questioned its legality in countries (like Germany) where donating material to the public domain is prohibited.
Although it focuses more widely on creative works, Creative Commons’ CC0-1.0 is a public domain dedication mechanism similar to the Unlicense. It may be better in line with international law since it use more formal, lucid legal terminology. It’s important to remember that in 2012, Creative Commons submitted an application to have CC0-1.0 certified as an open source conforming license. However, the OSI objected, stating that the license specifically excluded patent awards.
Other public dedication techniques, like Zero-Clause BSD, may be more appealing because of its even more straightforward wording. The ideal method for transferring all of the rights to a particular piece of software, however, is up for debate.
“Faux-pen” source
In the software industry, there are innumerable other licensing paradigms.
ICYMT: Akufo-Addo statue toppled again at Effia-Nkwanta Hospital
Depending on their goals, companies will occasionally offer software under a dual-license model, giving users the option to select between a commercial license and an established open source license. Next is “open core,” which provides the program with an open source license but paywalled for certain of its capabilities. In other cases, a business may impose commercial restrictions by adding a Commons Clause addendum to an otherwise permissive open source license.
Additionally, there are several licenses that appear and sound like open source but ultimately don’t fit the criteria of open source.
The database behemoth MongoDB switched from using the copyleft AGPL license to the server side public license (SSPL), which was created by MongoDB itself, in 2018. As far as the OSI is concerned, the SSPL is still very “open,” but it is what is referred to as “source available” because the code is accessible but has substantial commercial constraints.
Occasionally, you could also encounter so-called “ethical source” licenses, such the Hippocratic License, which forbids using software that violates globally acknowledged human rights. With the exception of one amusing final sentence: “The Software shall be used for Good, not Evil,” the open standard JSON file format also has a rather permissive license.
SOURCE: Tech Crunch
