Loomio
Wed 13 Apr 2016

When would you pick MIT?

CF
Cam Findlay Public Seen by 360

In this thread, we'd like to explore the situations in which MIT is a good, practical choice of license for the release of new open source code in government.

For context please read over the thread discussing the current draft defaults and options.

Please keep the discussion on the merits of MIT and when it is practical to select it.

The outcome of this thread is we'd like to generate some consensus on useful guidance that helps users make good license choices in the right situations.

We'll also have a thread along the same lines for the GPL discussion, please feel free to comment in both. :thumbsup:

DL

Dave Lane Wed 13 Apr 2016

An appropriate case for selecting the MIT license is when you want to propagate a new API or software library that could be incorporated in to many applications, for example a new encryption mechanism. The MIT license minimises the barriers to adoption by proprietary project developers (because it places no limitations on their ability to exploit their work) and most FOSS projects (I'm not sure if GPL'd projects can adopt MIT licensed components, although I believe in that case the GPL and MIT are compatible. Keen for verification of that point).

DS

Danyl Strype Mon 25 Apr 2016

I'm not sure if GPL'd projects can adopt MIT licensed components

While there may be some variation in compatibility between GPLv2 and GPLv3, the GPLv3 wiki has a list of licenses that are compatible with GPLv2, and it includes both licenses commonly referred to as "MIT" (Expat and X11).

Also, Karl Fogel writes in Chapter 9 of his book "Producing Open Source Software":

"While the Apache License 2.0 has the advantage of containing some explicit defenses against misuse of software patents, which might be important to your organization depending on the kind of project you're launching, the MIT license is fully compatible with all versions of the GNU General Public License, meaning that you can distributed, under any version of the GPL, mixed-provenance works that contain MIT-licensed code. The GPL-compatibility situation for the Apache License, on the other hand, is more complicated — by some interpretations, it is compatible with GPL version 3 only. Therefore, to avoid giving your downstream redistributors the headache of having to read sentences like the preceding ones, I just recommend the MIT license as the default non-copyleft license for anyone who doesn't have a reason to choose otherwise."

Remember that by definition, "permissive" non-copyleft licenses contain no rules about what license applies to redistributed or modified versions. This is one of the qualities their proponents refer to as "permissive". That being the case, my understanding is there are a number of ways this could work for Project "Foo" (GPL license), and Component "Bar" ("MIT" license). Keep in mind as always that while I make a determined effort to get my facts right, IANAL, and anything I claim about software licensing should be checked against more qualified sources (eg Software Freedom Law Centre).

Firstly, what could happen if Project "Foo" (a graphical desktop application) incorporates a verbatim copy of Component "Bar":

  • Project "Foo" identifies Component "Bar" as an external "dependency" in its packaging instructions. This means that on GNU/Linux (and most Unix systems), when a user installs a package of Project "Foo", the latest version of Component "Bar" in the same software repository will be downloaded and installed too (unless its already installed). If Project "Foo" package their own binaries of their application (eg to support use on Windows or MacOSX), they can include the most compatible version of all non-copyleft dependencies like Component "Bar", as long as a copy of the license for each dependency package is also included. Note: they can bundle copyleft dependencies too, but on the top of the copy of the license (or a link to one), they must also include a copy of the source code (or a link to one). Non-copyleft licenses don't require this.

  • Project "Foo" copies the source code of Component "Bar" into their own repository, in its own section, and distributes it under the terms of the "MIT" license supplied by the developers of Component "Bar". A copy of that "MIT" license must be included with the code. Note: Project "Foo" will usually identify Component "Bar" on their website and in their help files, and give credit to Component "Bar"'s developers ("attribution" as required by CC-BY) , but they are not legally required to do so by any of the licenses commonly known as "MIT". Thus, an "MIT license" is not fully equivalent to CC-BY.

  • Project "Foo" copies the source code of Component "Bar" into their own repository, and distributes it under the terms of the GPL. Note: this doesn't stop anyone using, modifying or redistributing it under the original "MIT" license, and as above they must bundle the original developer's license with the code anyway, so while this is legal, in practice there's little point to it.

Now, what could happen if Project "Foo" incorporates a modified copy of Component "Bar"? In each case, for as long as any "substantial portions" of Component "Bar" remain, a copy of the original "MIT" license must be distributed with it.

  • Project "Foo" copies the source code of Component "Bar" into their own repository and modifies it. They distributes their modified version under the terms of the same "MIT" license and submit their changes back as "patches" to the original developer, who may or may not incorporate them into the next release of Component "Bar".

  • Project "Foo" creates a "fork" of Component "Bar". They copy the source code into a new repository, give it a new name, modify it, and maintain this new version as a side project. They might do this to make maintenance easier if Component "Bar" was "orphaned" (not being actively maintained), or the original developer of Component "Bar" was not interested in incorporating their changes. The forked version could be licensed under the original "MIT" license, or under GPL (or any GPL-compatible license for that matter).

  • If Component "Bar" was part of a larger program, Project "Foo" could rewrite it as a library that could be linked by their program, and also by other programs. In this case, LGPL is a third license option that might be chosen (for reasons discussed in another thread) as well as either of the two above.

  • Project "Foo" copies the source code of Component "Bar" into their own repository and modifies it. They distributes their modified version under the terms of the GPL. This makes it harder for the original developer to incorporate the modifications into a future release of Component "Bar". They would have to get permission from Project "Foo" to use their modified code under the "MIT" license, or they would have to relicense Component "Bar" to GPL. Note: under the terms of a "permissive" license, it's perfectly legal for Project "Foo" to do this. But if they are going to maintain a modified version of Component "Bar" themselves they are better to fork the project, as described above, to avoid confusion.

EDIT: Sorry about the super-long posts. Please let me know if you'd rather I post the long form pieces to my own blog, and publish a TL;DR here with a link to it.

CF

Cam Findlay Wed 13 Apr 2016

Thanks for reposting @davelane - agree that it would be good to get verification on your point of GPL projects being able to make use of MIT parts.

So to clarify your MIT choice case, you are saying that libraries and component code (again perhaps there is a better agreed term for this type of code) that is used to extend existing projects or; on which new projects (commercial or not) might be built upon, in order to promote reuse of standards expressed in those libraries, then MIT is a great choice.

G

GasparI Fri 15 Apr 2016

LGPL is perfect for libraries - can use it anywhere and also the community benefits.
I would be really interested to hear a use case where an MIT license would be 'better' than LGPL for the community.
http://www.gnu.org/licenses/lgpl-3.0.en.html

RM

Russell MIchell Thu 21 Apr 2016

I have x-posted the following in the GPL thread also:

The very fact there is so much discussion around "which license" suggests it is not a mere trifle in deciding which to use. OSS developers already know this, but others new to the area, e.g. I.T. professionals having worked with pay-to-license software for the entirety of their careers, perhaps would not.

I think the development of an online tool that helps users in their decision is one way forward here. See http://choosealicense.com/. Luckily the site's codebase is itself OSS and available here: https://github.com/github/choosealicense.com and could therefore conceivably be modified for NZGOAL-SE's uses.

CF

Cam Findlay Thu 21 Apr 2016

Thanks @theruss I'm a fan of that site, keeps the decision tree of selecting suitable a license simple and effective. The descriptions and bullet point overviews are very useful (not to mention it's both content licensed under CC-BY and code is open under MIT) :thumbsup: