{"id":819358,"date":"2025-01-12T23:11:49","date_gmt":"2025-01-13T05:11:49","guid":{"rendered":"https:\/\/newsycanuse.com\/index.php\/2025\/01\/12\/open-source-licenses-everything-you-need-to-know\/"},"modified":"2025-01-12T23:11:49","modified_gmt":"2025-01-13T05:11:49","slug":"open-source-licenses-everything-you-need-to-know","status":"publish","type":"post","link":"https:\/\/newsycanuse.com\/index.php\/2025\/01\/12\/open-source-licenses-everything-you-need-to-know\/","title":{"rendered":"Open source licenses: Everything you need to know"},"content":{"rendered":"
\n

Open source makes the technology world go \u2019round, forming as much as 90%<\/a> of the modern software stack via frameworks<\/a>; libraries<\/a>; databases<\/a>; operating systems<\/a>; and countless standalone applications<\/a>.<\/p>\n

The benefits of open source software are well understood, promising greater control and transparency. However, there\u2019s a perennial struggle<\/a> between the open source and proprietary realms, leading many companies to retreat from open source<\/a> to protect their commercial interests. At the heart of all this is the thorny issue of licensing.<\/p>\n

There are two broad kinds of licenses that meet the formal open source definition<\/a> as laid out by the Open Source Initiative (OSI<\/a>). \u201cPermissive\u201d licenses carry few restrictions in terms of how users can modify and distribute the software, making them popular with companies that wish to use it commercially. And then there are \u201ccopyleft\u201d licenses, which offer similar freedoms but with one notable caveat: Any modified version of the software must also be distributed under the same original copyleft license. This isn\u2019t so appealing to businesses wishing to protect their proprietary work.<\/p>\n

But there is more to it than that, with various licenses existing within each bucket. Moreover, there are countless licenses that, while not strictly open source, are also worth knowing about.<\/p>\n

Permissive<\/h2>\n

MIT<\/h3>\n

Originating at the Massachusetts Institute of Technology in the 1980s, the aptly-named MIT<\/a> license is the most popular open source license by most metrics, sitting in the top spot<\/a> among the GitHub development community for many years<\/a>.<\/p>\n

Used by projects including React<\/a> (front-end JavaScript library) and Ruby<\/a> (general purpose programming language), the MIT license allows developers to use software however they like. As with most such licenses, it\u2019s provided without warranties, meaning authors are absolved from any liability resulting from damages caused by their software (e.g. data loss). All developers need to worry about is including the original copyright notice and MIT license in any derivative work.<\/p>\n

But the MIT license has one shortcoming: It doesn\u2019t explicitly grant patent rights. This means that if a given piece of software relies on patented technology, this might create legal uncertainty for developers who deploy the software without securing separate permissions for said patented technology.<\/p>\n

However, this underscores one of the key selling points of the MIT license: with just 200 words<\/a>, the language is simple and concise. Muddying things with ambiguous, word-soup patent spiel would add needless complexity for projects unlikely to be concerned with patents, such as high-level programming languages or web frameworks.<\/p>\n

But plenty of open source projects do intersect with patented technologies, such as hardware-centric software like Android. <\/p>\n

Apache License 2.0<\/h3>\n

The Apache Software Foundation published the Apache License 2.0<\/a> in 2004, an update to an earlier license with an explicent patent grant to protect users from litigation. So if a developer were, for example, to contribute a unique image processing algorithm to a project licensed under Apache 2.0, any patents that developer holds on that algorithm are automatically licensed to all users of the software.<\/p>\n

Most people will be familiar with Google\u2019s brand of Android, replete with app store and suite of home-grown tools and services. But the underlying Android Open Source Project (AOSP) is substantively available under the Apache 2.0 license, a deliberate move by Google<\/a> in 2008 to combat Apple and encourage phone manufacturers to use Android versus the other proprietary incumbents (e.g. Symbian) of the time. And it worked. Samsung, HTC, LG, and all the rest jumped on Android.<\/p>\n

A byproduct of this, though, is that the Apache License 2.0 has around five times the number of words<\/a> of MIT, owing to the patent grant text, among other additions and clarifications. But that\u2019s the trade-off, and it illustrates the key distinctions between the two most common permissive open source licenses.<\/p>\n

Other permissive licenses<\/h3>\n

The BSD 2-Clause License<\/a> is similar to MIT, but with key differences in terms of the language used. For instance, it specifies that a copy of the license should be included with both the source code and the compiled binary form. And then there is the BSD 3-Clause License<\/a>, which has an additional \u201cno endorsement\u201d clause that restricts the use of the names of the copyright holders and contributors for promotional purposes in any derivative project.<\/p>\n

There\u2019s also the MIT No Attribution License<\/a> (MIT-0), which is simpler than the MIT, in that there is no requirement for attribution in derivative software. Using this is close to putting software in the public domain, except the author does retain the copyright and ability to change things in the future.<\/p>\n

Copyleft<\/h2>\n

GNU General Public License (GPL) v. 2.0 and 3.0<\/h3>\n

The Free Software Foundation (FSF<\/a>) published the GNU General Public License (GPL) in 1989, and was one of the first copyleft licenses for general use.<\/p>\n

Copyleft licenses are often better suited for projects requiring input from the community, versus projects supported by a single corporate entity. By requiring that all modifications remain available under the same open source license, this assures contributors that their hard work won\u2019t be used in proprietary software without also benefiting the wider community \u2014 in theory, at least, as it can be difficult to discover every contravention and then enforce the terms of the license.<\/p>\n

Launched in 2007, GPL 3.0<\/a> is the third most popular license, according to GitHub data<\/a>. The license ushered in notable updates on GPL 2.0<\/a>, including patent grant provisions and improved compatibility with other open source licenses. It also prohibits what has come to be known as \u201cTivoization,\u201d where hardware makers that benefit from GPL-licensed software prevent users from installing modified versions of that software, using digital rights management (DRM) mechanisms.<\/p>\n

Notable GPL adopters include WordPress, which is available under a GPL 2.0 \u201cor later\u201d license, leaving it to the developer to decide which license they distribute any modification under.<\/p>\n

Linux, for its part, is among the most successful open source projects of all time, used in servers, cloud infrastructure, embedded systems, and even Android. However, the underpinning Linux kernel is only available under a GPL 2.0 license, given that Linux creator Linus Torvalds is against some of the provisions<\/a> added in version 3.0 of the license \u2014 including the Tivoization clause.<\/p>\n

GNU Affero General Public License (AGPL) 3.0<\/h3>\n

The Affero General Public License (AGPL<\/a>) is similar to GPL 3.0, insofar it\u2019s a \u201cstrong\u201d copyleft license that promotes software freedoms and ensures modified versions remain open source. However, a key distinction with AGPL is that it\u2019s focused on web-based services and applications, where the software is run from servers rather than distributed as executable files.<\/p>\n

Under a GPL 3.0 license, developers aren\u2019t required to release the source code for modified software if it\u2019s run across a network, as SaaS applications are. The AGPL license closes this loophole, requiring third-parties to make the source code available even if the modified software is only running from a server.<\/p>\n

Published in 2007 by the Free Software Foundation, the AGPL 3.0 license has grown in popularity due in large part to the rise of cloud computing and SaaS, and today it\u2019s the fifth most popular open source license<\/a>.<\/p>\n

GNU Lesser General Public License (LGPL)<\/h3>\n

Also a product of the Free Software Foundation, the GNU Lesser General Public License<\/a> (LGPL) is a \u201cweak\u201d copyleft license, insofar as it\u2019s more business friendly with less stringent stipulations on what is shared. LGPL is normally used for software libraries where project authors want to encourage contributions from the community, but it allows proprietary software to link to the libraries without having to open source their entire proprietary code. If someone modifies the open source library itself, then they need only release those modifications under the LGPL license.<\/p>\n

Mozilla Public License 2.0<\/h3>\n

Published by the Mozilla Foundation in 2012, the Mozilla Public License<\/a> (MPL) 2.0 is the tenth most popular open source license today as per GitHub\u2019s licenses metric<\/a>. MPL is also a weak copyleft license designed to protect proprietary code while enabling developers to benefit from open source software.<\/p>\n

However, while LGPL is focused at the library level, and GPL at the project level, MPL operates at an individual file level requiring the user to share a narrower set of code.<\/p>\n

Public domain and creative commons<\/h2>\n

While an \u201copen source license\u201d grants specific rights, there\u2019s always stipulations attached. Those who want to place their software entirely in the public domain without any caveats, however, can do so through other means.<\/p>\n

It\u2019s not enough to simply publish software without a license; copyright law applies by default to most creative works, including software. This is where a \u201cpublic domain dedication\u201d can help.<\/p>\n

Designed specifically for software, the Unlicense<\/a> is the ninth most popular license on GitHub (though whether it can actually be called a \u201clicense\u201d is debatable). Even though the OSI approved<\/a> it as a license in 2020, it noted that the document is \u201cpoorly drafted\u201d and questioned its legal efficacy in jurisdictions (e.g. Germany) where it\u2019s not possible to donate work to the public domain.<\/p>\n

Like the Unlicense, Creative Commons\u2019 CC0-1.0<\/a> is also a public domain dedication tool, though its focused more broadly on creative works. It uses clearer, more professional legal language that might be more in tune with international law. It\u2019s worth noting that Creative Commons applied to have CC0-1.0 approved<\/a> as an open source compliant license in 2012, but withdrew the application<\/a> after the OSI raised concerns that it explicitly excluded patent grants.<\/p>\n

There are other public dedication tools, such as Zero-Clause BSD<\/a>, which might appeal as it has even simpler language. However, there\u2019s no consensus on the best mechanism for giving away all rights to a given piece of software.<\/p>\n

\u201cFaux-pen\u201d source<\/h2>\n

There are countless other licensing paradigms across the software spectrum.<\/p>\n

In some cases, businesses will release software under a dual-license model<\/a>, with the user able to choose between a recognized open source license and a commercial license, depending on their intentions. Then there is \u201copen core,\u201d which offers the software under an open source license, but with key features paywalled. In other instances, a company might add a Commons Clause<\/a> addendum to an otherwise permissive open source licence, putting commercial restrictions in place.<\/p>\n

There are also plenty of licenses that look and smell like open source, but are ultimately incompatible with the open source definition.<\/p>\n

In 2018, database giant\u00a0MongoDB<\/a> transitioned from a copyleft AGPL license to the server side public license (SSPL<\/a>), a license of MongoDB\u2019s own creation<\/a>. While the SSPL is still fairly \u201copen,\u201d it\u2019s what is known as \u201csource available,\u201d in that the code is accessible but has significant commercial restrictions, which is a big no-no<\/a> as far as the OSI is concerned.<\/p>\n

The folks at MariaDB<\/a> forged a similar path with the business source license (BUSL), which imposes commercial restrictions before transitioning to a true open source license after a set number of years. There is another similar movement under way<\/a> that\u2019s looking to make \u201cfair source<\/a>\u201d licensing a thing. This includes the Functional Source License<\/a>, which is touted as a simpler alternative to BUSL.<\/p>\n

You may also come across so-called \u201cethical source<\/a>\u201d licenses from time to time, such as the Hippocratic License<\/a>, which prohibits the use of software in violation of internationally recognized human rights. Similarly, the open standard JSON<\/a> file format has an extremely permissive license, barring one hilarious clause at the end: \u201cThe Software shall be used for Good, not Evil<\/em>.\u201d<\/p>\n<\/div>\n

Read More<\/a>
\n Paul Sawers<\/p>\n","protected":false},"excerpt":{"rendered":"

Open source makes the technology world go \u2019round, forming as much as 90% of the modern software stack via frameworks; libraries; databases; operating systems; and countless standalone applications. The benefits of open source software are well understood, promising greater control and transparency. However, there\u2019s a perennial struggle between the open source and proprietary realms, leading<\/p>\n","protected":false},"author":1,"featured_media":819359,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[37816,3278,46],"tags":[],"class_list":{"0":"post-819358","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-licenses","8":"category-source","9":"category-technology"},"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/posts\/819358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/comments?post=819358"}],"version-history":[{"count":0,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/posts\/819358\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/media\/819359"}],"wp:attachment":[{"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/media?parent=819358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/categories?post=819358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/newsycanuse.com\/index.php\/wp-json\/wp\/v2\/tags?post=819358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}