This article is written by Preetish Agrawal, pursuing a Diploma in Intellectual Property, Media and Entertainment Laws from lawsikho.com.

Introduction

A software license is a document that provides legally binding guidelines on the usage, modification, and distribution of the software; without violating the creator’s copyright. These licenses can be either closed source licenses or open-source licenses. Closed source licenses are for proprietary software, and the code protected under these licenses are not made available to anyone except the licensees. Hence, any modifications in the code can only be done by the owners of the closed source code. On the other hand, open-source licenses allow for the license to be freely used, modified, and be distributed.  The Massachusetts Institute of Technology (MIT) license is an example of an open-source license. Open-source licenses are further divided into permissive and restrictive (or copyleft) licenses. In this article, we would first explore the difference between permissive and restrictive licenses. We would then understand if an MIT licensed software can be redistributed under any other license, and explore a few advantages and drawbacks of the same.

Understanding the difference- permissive and restrictive licenses

Both permissive and restrictive licenses are open-source licenses, and hence allow the user to freely distribute, copy, and change the software that uses them. The difference, however, is the condition under which a user can do the same.

In a restrictive license, there are a few caveats attached to the free use of the license. For example, the General Public License (GPL) is a type of restrictive license. If the software is licensed under a GPL license, a person cannot take the licensed piece of software and release it under a proprietary (closed source) license. Moreover, sublicensing is not allowed in GPL licenses. Hence, if someone copies, distributes, or modifies a software protected by a GPL license, he must make the modified code available; along with its build and install instructions.

Permissive licenses, on the other hand, offer no such restrictions. The MIT license is an example of a permissive license. So, if the software is protected under the MIT license, anyone can do whatever they want with the code, including sublicensing it, and/or converting it into a proprietary (closed source) license. The only necessity required is that the original copyright and license notice shall be included in the copy of the software. Hence, while a software protected under the MIT license can be converted into a GPL license, the vice versa is not permissible.

To put it simply, while the MIT license (and permissive licenses in general) is a non-intimidating license that is used to popularize the code as much as possible, a GPL license (and restrictive licenses in general) is an open-source license that stops someone else from profiting from the creator’s work. We would further understand MIT licenses in greater detail.

MIT licenses- A close look

As explained earlier, the MIT license is short and permissive. An MIT-licensed code can be redistributed under any other license if the original copyright and license notice is included in the software license. A copy of the MIT license can be found here. The MIT license has various advantages and is hence the most popular open-source license being used in the world today, with around 45% of licensed projects on GitHub using it [2015]. However, despite its immense popularity, the MIT license does have its fair share of drawbacks. The advantages and drawbacks of the MIT license are discussed below:

Advantages of the MIT License

Arguably, the biggest advantage of using the MIT License is that it is very permissive. It is not only welcoming to open-source developers, but also to businesses (Proprietary). This quality of the license allows it to be both business-friendly and open-source friendly, while still making it possible to be monetized.

As the MIT license is permitted for the closed source as well, it makes it a great license for commercial purposes. As the license is so permissive, the code is used by many people to develop third-party software. The major concern amongst various developers, however, is regarding the monetary return of the code protected under this license.

This concern is addressed by Bill Patrianakos, in his article ‘Why I use the MIT License’ [2016]. Bill mentions how he created ‘Coverage’, a health insurance coverage finder software, and monetized it while protecting it under the MIT License. As per Bill, the value of an idea does not lie in the bits and bytes of the code, but in the ability to use the code and having the same problems that a code solves. Hence, third-parties would make several modifications in his code while using it for themselves, allowing the bill to understand the exact needs of its consumers while making the code more popular. We would now look at the drawbacks of MIT Licenses.

Drawbacks of the MIT License

The first major drawback of the MIT license, and any permissive license in general, is that it cannot stop someone else from profiting from the creator’s work. Hence, someone can easily take an MIT licensed software, and build another proprietary (closed source) software, while making a profit out of the same.

The second drawback specific to the MIT license is that it has no explicit patents clause. This drawback leaves the users of a patented MIT software at the risk of facing patent infringement charges. This problem was seen in the software GraphQL. In GraphQL, Facebook held the patent over the GraphQL library and had released the software under the MIT license. Hence, if any user would use the GraphQL library in their own product, they could be sued by Facebook for patent infringement [Worth Hiding, 2018]. This is how the MIT license can leave its users vulnerable.

The third drawback specific to the MIT license is that it does not grant specific rights for the object code of a software. The MIT license is silent about the rights for the reuse and redistribution of the software and fails to explicitly grant usage rights to compiled binaries [Worth Hiding, 2018]. This could result in compiled binaries being considered as not subjected to the same terms and would put the users at the risk of copyright infringement.

We now explore another permissive open-source license as a solution to these drawbacks.

Apache 2.0 as an alternative to MIT licenses

While the MIT license is a great alternative to license a software code that can be licensed further, the Apache 2.0 might just be a better alternative with the same intention. While the Apache 2.0 has a similar philosophy to the MIT license, it is much more detailed and specified. While these factors make it a little wordy and complicated, it does offer much more recourse to the creator of the software.

As Apache 2.0 is also a permissive open-source license, software licensed under this license can also not prohibit someone else from profiting from the creator’s work. To address that drawback, the creator shall prefer going for restrictive open-source licenses like the GPL license.

However, the other two concerns are pretty skilfully handled by the Apache 2.0 license. The Apache 2.0 license includes an express clause granting patent rights to all the users of the licensed software. It hence shields all the users of the software from patent infringement suits. This does not leave the user in a vulnerable position and contributes to making the code more popular.

Also, the Apache 2.0 license explicitly grants a right for both the source and object code. It also explicitly clarifies that the object code generated from the licensed source code would be subjected to the same terms and conditions as the source code [Worth Hiding, 2018]. A copy of the Apache 2.0 license can be found here.

Conclusion

An MIT licensed software can be redistributed under any other license if the original copyright and license notice is included in the software license. The licensed software can be used, distributed, and modified to any extent; even for proprietary purposes (Closed source licenses). Hence, the MIT License in its very nature is very permissive. This fundamental quality of the license is its biggest advantage, but also a drawback.

An advantage, as the permissive nature, allows the software to become business-friendly, as well as open-source friendly. This makes the licensed software very popular and results in it being used by various third parties. In a few cases, these opportunities can be monetized as well! While this is a huge advantage, it can act as a disadvantage as well! There is indeed a high possibility that the license would fail to stop someone from profiting from the creator’s licensed work. Not only this, but the MIT license is also very short in its design. While this makes it easier to understand, it offers no protection to the user from patent infringement of the software, as well as its copyright infringement in some cases. This can make the Apache 2.0 License a better alternative, as it addresses these drawbacks while being a little wordy and complicated.

The gist of the discussion is that it all depends on the expectation of the creator. The MIT License is made for a creator that has a very specific goal in its mind for its code. If the creator intends to stop anyone from using its code, be it for-profit or non-profit, then it is expected to not go for the MIT License, and go for other restrictive open-source licenses. If it intends to patent its licensed software, it should also not consider going for the MIT License and prefer other options like the Apache 2.0 license. But, if the creator intends to popularize his work while making it very permissive and not patenting it, the MIT License should be its best bet!!

Students of Lawsikho courses regularly produce writing assignments and work on practical exercises as a part of their coursework and develop themselves in real-life practical skill.

LawSikho has created a telegram group for exchanging legal knowledge, referrals and various opportunities. You can click on this link and join: