Open source makes the technology world go ’round, 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’s a perennial struggle between the open source and proprietary realms, leading many companies to retreat from open source to protect their commercial interests. At the heart of all this is the thorny issue of licensing.
There are two broad kinds of licenses that meet the formal open source definition as laid out by the Open Source Initiative (OSI). “Permissive” 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 “copyleft” 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’t so appealing to businesses wishing to protect their proprietary work.
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.
Permissive
MIT
Originating at the Massachusetts Institute of Technology in the 1980s, the aptly-named MIT license is the most popular open source license by most metrics, sitting in the top spot among the GitHub development community for many years.
Used by projects including React (front-end JavaScript library) and Ruby (general purpose programming language), the MIT license allows developers to use software however they like. As with most such licenses, it’s 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.
But the MIT license has one shortcoming: It doesn’t 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.
However, this underscores one of the key selling points of the MIT license: with just 200 words, 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.
But plenty of open source projects do intersect with patented technologies, such as hardware-centric software like Android.
Apache License 2.0
The Apache Software Foundation published the Apache License 2.0 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.
Most people will be familiar with Google’s brand of Android, replete with app store and suite of home-grown tools and serv …