The more I think about the MIT licence the more I think it enables bad behavior. Unsurprisingly I think from the perspective of an open source contributor the MIT licence is not good. Perhaps more surprisingly I think from my perspective of a business owner it's also not the best choice.

The main reason I think it's a bad choice for both is because this licence encourages freeloading and doesn't deal with some important issues around patents.

For the most part I think you should prefer using the MPLv2 over the MIT licence if you are looking for a permissive licence. This article covers most of the main points. The rest of this article exists as an explanation as to why I strongly avoid the MIT license these days.

Patent issues are the time bomb of the MIT licence

The MIT license was written before many of the issues around software patents were litigated on. It also predated the whole Tivoization debacle as well. So despite the best intentions the MIT license really hasn't aged so well.

Many of the issues with the license are due to the evilness of software patents. Unfortunately some jurisdictions treat software patent rights very differently to others and if your project has contributors from multiple countries you need to proactively protect the contributors rights to their own work. Some jurisdictions will not necessarily assess your open source code as prior art for patents that are directly derived from it, not dealing with this situation sets up very real danger. Because the MIT licence has no explicit grant of patent rights as a condition of use of the code you open yourself up to abuse from bad actors. This is because you can have a situation where you release your project's code under the MIT licence then someone else can take it and patent parts of this process then legally threaten you with patent lawsuits.

Why I think the MIT licence is bad for contributors

This is fairly simple, the MIT license allows people to take your work and benefit from it without giving back at all. In the worst cases the MIT licence allows people to take your work then directly exclude you from the benefits derived from it with nothing given in return. Maintaining a healthy community project requires effectively dealing with bad actors like freeloaders. It's hard to maintain a strong stance to protect your project from freeloading when your licence officially allows it.

Strong communities require protecting their members from bad actors. The social contract is much better if you set up a situation whereby the licence protects the rights of the contributors against bad actors. The MIT license has very few restrictions but consequently cannot protect the rights of contributors as effectively.

Patent issues

The evilness that is the software patent issue is once again impossible to overlook here, if contributors are at risk of having their own contributions taken, then weaponized against them in the form of patent trolling, they will be strongly disincentivised from contributing to a project. Making sure that a project has a license that protects my rights as a contributor is an important consideration that I — and many others — will take when deciding on which projects to contribute to.

People will only really want to work on a project if they know their work won't be used to disadvantage them in the future.

Make sure that your licence explicitly deals with patent issues

Recognition

A huge part of the value of contributing to open source projects for many people is the visibility and recognition that you get from being involved in these projects. For some people this value comes in the form of helping them in their careers, for others its about feeling good about contributing to the public. Recognizing the contributions of individuals to a project is something that I think a good licence should aim to protect. Unfortunately the MIT licence allows dark forks where the code is forked and subsequently hid from public view. This in effect means that your software could be being used to great effect and nobody would ever know. If some software is generating a lot of value I think the authors of that software deserves to at least attribution for it if they are not being directly paid for their work.

The community making the software gets harshly punished by the use of MIT licenses due to the lack of attribution that MIT licenses enable, this is especially so when you consider the impact of dark forks.

Make sure that your license will recognize any contributors who have contributed their time to your project

Sharing changes

A lot of people are encouraged to work on something when other people share their changes too.

One bit of wishful thinking I run into occasionally is that people think by getting wider adoption they will get more people contributing back to their projects due to the higher volume of users. Unfortunately the vast majority of users of software will not contribute back financially or with patches unless they have to. If the main goal is to get more contributions to your project then choosing a license that requires people to share their changes upstream is a good way to achieve this. You don't have to go the strong copyleft route to do this, MPLv2 will allow you to have fewer restrictions on distribution while ensuring that changes are shared upstream.

As someone who's been involved in open source projects my opposition to the MIT licence has become stronger over time. Open source has a large problem with burning out the people involved in it, part of this is due to the fact that many freeloaders make great profits from open source without giving back, and sometimes even directly at the expense of the open source maintainers that made the opportunities in the first place.

Choosing licenses that protect your contributors helps keep a project more sustainable and healthy.

Make sure that your license will ensure contributions are shared upstream if that is a goal of your project

Why I think the MIT licence is bad for companies

As a business owner the uncertainties regarding patent rights when using the MIT licence is a deal breaker for me. Since I do a lot of international work I wouldn't want to rely on something that exposes me to legal risks that are different in different jurisdictions. So picking a license that explicitly deals with the patent rights issue is important to my business.

People have often said that the MIT licence is "business friendly" but really I think it's only friendly to freeloading businesses such as patent trolls.

The MPLv2 is a far more friendly license for a software business to use than the MIT license

But beyond the patent issues, as a business that is creating new code, using the MIT licence would just mean giving away code to competitors without getting much in return.

As someone who owns a business I might want to take up a strategy of commoditizing the complements of my business. Back in 2002 Joel Spolsky wrote about how a strategy of commoditizing the complements of your business is a powerful force in the technology world, in the article he provides some good examples of the dynamic like this:

Demand for a product increases when the prices of its complements decrease. For example, if flights to Miami become cheaper, demand for hotel rooms in Miami goes up — because more people are flying to Miami and need a room. When computers become cheaper, more people buy them, and they all need operating systems, so demand for operating systems goes up, which means the price of operating systems can go up.

So the way this might work is that you have an advanced optimization package for warehousing and logistics that makes the most optimal picking and slotting decisions. A complement here is the computing systems on which this optimization software runs, logistics managers don't want to have to care about things like the details of how to run servers or containers or Kubernetes or whatever the newest technical approach is, they mostly just want to improve their logistics operations by making use these things. From our perspective as a software supplier we want to focus as much as possible on the value creation for our clients. In this situation we want to make it as easy as possible to guarantee the continuity of the value that our software enables. So if we run into a bug in some system that prevents this we would love to be able to fix it, and having access to the source code is an extremely strong guarantee that we can get a fix if such a fix is possible. Even though we may get great value from better continuity by having source code access we may not necessarily want to bring the ownership of these products in house.

By making the deployments of our code cheaper we can bring a lot more value from our core proposition, we also help the progress of the broader industry and community by sharing these improvements. Making these fixes available to the general public is great for our marketing and brand because it helps push progress forward. As I hinted at before this is not just a marketing concern, there's a strong business case in improving the accessibility of running your products because it provides your business extra opportunities to be profitable. But how do we actually go about the licensing for such code? From my experiences of running a business involved in machine learning and applying mathematical optimization to solve commercial problems, there are two main classes of code artifacts:

1. Code that forms part of the competitive advantage of the company and our clients
2. Code that doesn't form a core part of the competitive advantage but is useful in a general sense

Code in category #1 tends to not be released as open source by businesses for a variety of reasons, many of which are obvious.

Code of category #2 is almost always a liability and very rarely is an asset so typically you don't want to own this code if you can avoid it. Take for example emails. Email is a crucial part of the operations of the company, but yet we really don't want to be in the business of writing code for email delivery since we are not an email company. Writing in-house code for this would incur a substantial maintenance overhead and would have a very high opportunity cost. Finding an open source project that meets requirements wherever possible is extremely cost effective. The open source nature is critical because if there's some shortcoming in those open source projects we have the recourse to fix it ourselves or by hiring people to do that work. If we put engineering time into improving those projects we want it to be available to everyone because that's generally the right thing to do, given that we derived so much value from the community that built that open source product. We realize that for cultural reasons some people may need to invent some "story" for why this is a good business case ¹.

Spending our own time or money on open source fixes is far easier to defend if it doesn't directly reduce our competitiveness. If our contributions were under the MIT license then we would effectively be subsidizing the time of freeloading companies who could take up our changes while not contributing their own.

This touches on one of the other major problems of the MIT licence:

The MIT license allows dark forks

A dark fork is a situation where someone else forks the code and makes their own changes to it without sharing their changes back. This can have substantial commercial implications as your code can be taken by a competitor who uses your work without giving anything back. In some cases this can be very abusive, like the patent trolling case.

The threat of licenses being abused is not just a hypothetical. One important public case involving the deliberate abuse of license terms was known as Tivoization. This involved using hardware to enforce that only certain software could run on a device in order to exploit a license loophole.

The other more common concern is the situation where if your open source project gets very popular then major players like cloud service providers can take your code into their platforms and undercut any offering you may be providing. Now in this case if I'm a running a business and I'm deciding to release code as open source, I don't mind other companies using it, if I did I wouldn't be releasing the code under an open source license. But the issue here is that the main reason for open sourcing most code is precisely to get contributions from multiple groups to the projects and attract clients for whom that level of continuity and control is important. If a competitor is able to use the code without contributing back the whole reason for us releasing the code to the public is mostly circumvented in many cases.

Make sure that your licence protects your company from patent troll lawsuits and ensures that changes are contributed upstream in return for use.

What licence can I use instead?

If you are wanting to ensure that changes are upstreamed then you can use the MPLv2 or a strong copyleft licence like the AGPLv3.

If you aim to have minimal restriction on use prefer the Apache version 2 licence over the MIT license as this has the fewest restrictions while still protecting you from patent related issues.

If you are a business choosing the MPLv2 is a better choice than MIT as it protects you from patent issues. The MPLv2 also ensures that changes are made available upstream which is usually a core part of the business case for open sourcing code in the first place.

Generally speaking if you want to make your code business friendly I think the MPLv2 is a much better choice than the MIT licence, business can still use it but you simultaneously protect the interests of project contributors against bad actors much better than MIT. If you want fewer limitations on use, then the Apache v2 license is also easy for businesses to consume although may receive less patches than the MPLv2 would in return.