
The MIT License, Line by Line - monocasa
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html
======
richardfontana
_Despite the assumption of some newer open-source developers that sending a
pull request on GitHub “automatically” licenses the contribution for
distribution on the terms of the project’s existing license—what Richard
Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t
recognize any such rule. Strong copyright protection, not permissive
licensing, is the default._

That isn't quite what I mean by "inbound=outbound". Rather, inbound=outbound
is a contribution governance rule under which inbound contributions, say a
pull request for a GitHub-hosted project, are deemed to be licensed under the
applicable outbound license of the project. This is, in fact, the rule under
which most open source projects have operated since time immemorial. The DCO
is one way of making inbound=outbound more explicit, and I increasingly think
one that should be encouraged (if only to combat the practice of using CLAs
and the like). But under the right circumstances it works even where the
contribution is not explicitly licensed (I think this is what Kyle may be
questioning). There are other ways besides the DCO of creating greater
certainty, or the appearance of greater certainty, around the inbound
licensing act, such as PieterH's suggestion of using a copyleft license like
the MPL, or the suggestion of using the Apache License 2.0 (whose section 5
states an inbound=outbound rule as a kind of condition of the outbound license
grant).

~~~
loeg
What does DCO mean in this context?

~~~
richardfontana
The Developer Certificate of Origin. It's the 'Signed-off-by:' process
introduced by the Linux kernel project.

[http://developercertificate.org/](http://developercertificate.org/)

[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=refs/tags/v4.8-rc7#n409)

I particularly recommend the presentations and writings of James Bottomley on
the DCO, e.g.: [http://www.hansenpartnership.com/FOSDEM-
DCO-2016/#/begin](http://www.hansenpartnership.com/FOSDEM-DCO-2016/#/begin)

~~~
loeg
Thanks!

------
PieterH
This is a really good article. There's one part in particular that struck me:

"Despite the assumption of some newer open-source developers that sending a
pull request on GitHub “automatically” licenses the contribution for
distribution on the terms of the project’s existing license—what Richard
Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t
recognize any such rule. Strong copyright protection, not permissive
licensing, is the default."

In other words the fork + pull request + merge flow _does not_ work on a
project unless you have an explicit step like a CLA, or an alternative
solution.

We faced this problem early on in ZeroMQ, that asking contributors to take
this extra step increased the work for maintainers (to check, is this the
first time person X contributes, and have they made a CLA?) It also scared off
contributors from businesses, where this often took approval (which took time
and was often denied).

Our first solution in ZeroMQ was to ask contributors to explicitly state, "I
hereby license this patch under MIT," which let us safely merge it into our
LGPL codebase. Yet, again, another extra step and again, needs corporate
approval.

Our current solution is I think more elegant and is one of the arguments I've
used in favor of a share-alike license (xGPL originally and MPLv2 more these
days) in our projects.

That works as follows:

* When you fork a project ABC that uses, say, MPLv2, the fork is also licensed under MPLv2.

* When you modify the fork, with your patch, your derived work is now also _always_ licensed under MPLv2. This is due to the share-alike aspect. If you use MIT, at this stage the derived work is (or rather, can be) standard copyright. Admittedly if you leave the license header in the source file, it remains MIT. Yet how many maintainers check the header of the inbound source file? Not many IMO.

* When you then send a patch from that inbound project, the patch is also licensed under MPLv2.

* Ergo there is no need for an explicit grant or transfer of copyright.

I wonder if other people have come to the same conclusion, or if there are
flaws in my reasoning.

~~~
pash
_> I wonder if other people have come to the same conclusion, or if there are
flaws in my reasoning._

Unfortunately, it doesn't work the way you've hoped. Although there are some
licenses (e.g., Apache) that purport to apply automatically to new code
submitted to the licensed codebase, the MPL doesn't make that claim, and such
clauses are legally dubious anyway.

So just because I write some code that can be applied as a patch to your MPL-
licensed codebase, my code is not automatically subject to the MPL. By
default, I hold the copyright, with all rights reserved, and the MPL license
on your code does nothing to change that. You still need explicit agreeement
from me to place my code under a compatible license.

Github, Gitlab, et al., should really put a checkbox on pull requests that
says, "I hereby license this code under $REPO_LICENSE."

~~~
snuxoll
Actually, you're wrong about the MPL. The MPL is a file based copyleft
license, the share-alike clause applies to any modifications made to a file
already containing MPL'ed code. This is only an issue when you add new files
to the project, and any MPL project should be vigilant about accepting patches
to ensure new files added contain the MPL header.

~~~
pash
Yes, there's a good argument that the license would apply automatically to
modifications to an existing file, but even in that case it is somewhat
questionable. Is the modification substantial enough that it could be
considered a new, stand-alone, derived work? If so, the pre-existing license
may not apply. Was the modification submitted as a patch in a file format that
does not incorporate all of the pre-existing code? If so, it may be a new,
stand-alone work to which the pre-existing license does not apply. Etc., etc.
Very little of this stuff has been well tested in court, so there's a lot of
room for facially plausible legal challenges.

And it's fairly clear that new files are new works. So, really, in all cases,
unless you're getting an explicit statement from contributors that they have
placed their contributions under the relevant license, there will be a a lot
of uncertainty about whether they really have been—particularly if the
contributor (or his or her employer) later challenges your claim.

That's why Github and other platforms for projects on the pull-request model
should really build explicit consent to licensing into the process.

~~~
PieterH
You cannot modify a work so much that the original licence no longer applies,
unless you in effect create a new work.

~~~
pash
Yes, absolutely a code file can be transformed enough that the original
license no longer applies. Copyright law in the United States applies the same
tests to code as to textual works and works in other media: is the
transformation substantial enough to consider the transformation a new
(derived) work, copyrightable in its own right? If so, its author holds its
copyright completely independently of any copyrights or licenses attached to
the work from which it is derived.

The case law on what constitutes a new, derived work is not at all well
developed in the context of software. But looking at analogues from other
media—and that's what the law does—it is easy to imagine that a very
substantial refactor, touching basically every line, or a less substantial
refactor with substantial additions, might qualify as a new, separately
copyrightable work.

The claims of copyleft are almost entirely untested in court, and it's very
likely that many of them will prove empty if they're ever challenged. Indeed,
many of copyleft's claims, those which place obligations on users and
contributors, are more TOS-style claims than claims that look like ordinary
"reserved rights" under copyright law, and therefore presumably have a legal
basis of enforcement in contract law, not in copyright law.

Explicit agreement by contributors to be bound by a license, however, covers
most bases, whether the license is interpreted as a license per se, pursuant
to copyright law, or whether it's ibstead interpreted as a contract under
contract law (or both).

~~~
PieterH
If you claim that copyleft is almost 'untested in court' you are either
wilfully ignorant or trolling.

~~~
infinite8s
Can you cite any cases where the case has gone to judgement?

------
SamBam
> The phrase “arising from, out of or in connection with” is a recurring tick
> symptomatic of the legal draftsman’s inherent, anxious insecurity.

Indeed. I'm trying to imagine a court saying "Well... there were damages, but
they arose _out of_ the software and not _from_ the software, so therefore-
oh, wait! The license actually includes arising "out of" the software as well
as "from" the software, so I guess the limitation of liability stands. Case
dismissed!"

~~~
sdkmvx
Lawyers are rather fond of such doublets and triplets. Consider free and
clear, null and void, terms and conditions, and even law and order. The origin
of a lot of legalisms is the historical confusion over language in ancient
English courts: Latin, French, or English? Most odd legal grammar is actually
of French origin.

~~~
nzp
It's one of my favourite lists:
[https://en.wikipedia.org/wiki/Legal_doublet](https://en.wikipedia.org/wiki/Legal_doublet)

~~~
tzs
> A legal doublet is a standardized phrase used frequently in English legal
> language consisting of two or more words that are near synonyms.

...

> power and authority

Should that really be on the list? Power is the capability to do something,
authority is the permission to do it. Sometimes power and authority are near
synonyms, such as in frontier areas with little government, but generally in a
functioning, civilized society they are quite distinct.

~~~
nzp
I'd say you're quite optimistic in thinking that _not little_ government
implies power =/= authority, and quite pessimistic in thinking that _little_
government does not imply a civilized, functioning society.

But even without getting into political debates which could get really
nuanced, can't authority mean capability in this context? I'm not a native
English speaker so I'm not sure, but I don't find it odd. It is also possible
that these two words have different (Anglo-Saxon vs French) origin, as most of
the examples listed, and that their original meaning was synonymous (of
course, I'm far too lazy and tired to check that now).

~~~
Nomentatus
Law is old; in Medieval times such redundancy was considered normal - usually
triple - and was very common; presumably it was considered a literate
flourish, embellishment and arabesque (sorry couldn't resist a go at it
myself.)

------
gakada
It's funny that the MIT license has the reputation of being "The license you
choose when you don't care about attribution, or it would be unreasonable to
require attribution".

As the article points out, copies of MIT licensed code must include not only
the copyright line but the whole damn license.

~~~
tbirdz
Indeed, for works where I don't care about attribution for binary users I use
the zlib license [0] which says "This notice may not be removed or altered
from any source distribution."

You'd still have to include the notice in any source distribution, but that's
not really as onerous in my opinion, since you're already having to distribute
all your source files, so what's just one more notice.

Of course, my projects normally use a language with a compiler that produces
binaries. I'm not sure how this would apply to a language that keeps things in
source form like javascript. Maybe webasm will become the new binary form?
asm.js? minified javascript?

0:
[https://opensource.org/licenses/Zlib](https://opensource.org/licenses/Zlib)

~~~
CamperBob2
_You 'd still have to include the notice in any source distribution, but
that's not really as onerous in my opinion, since you're already having to
distribute all your source files, so what's just one more notice._

But neither MIT nor zlib _require_ you to distribute any source files. With
zlib it's pretty clear what's expected, but with MIT, I'm actually not sure
what attribution if any is required in a binary-only distribution.

~~~
tbirdz
Just to clarify my previous statement. I didn't mean to imply that zlib or MIT
require you to distribute your source. I meant that if you are distributing
your source code (for reasons other than any requirement from zlib or MIT
licenses), then it's not too much of an additional burden to include the zlib
license attribution, because you'd already be including the files that I had
licensed under zlib, and each of those files has a little header saying it's
licensed under zlib. Including the zlib license is then not much more work
than including another source file from the project.

The way I've seen MIT interpreted most often is that you have to distribute
the license and attribution even for binary only distribution, or distribution
in binary form as part of a larger work.

But you're right the language does seem kind of vague on what "The Program"
actually means.

------
AstroJetson
Crushed under load, to get the cache

[http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://writing.kemitchell.com/2016/09/21/MIT-
License-Line-by-Line.html)

I've always wondered about the nuances around the different licenses, it's
nice to get a non-lawyer guide to the MIT one.

~~~
kemitchell
Dang. I didn't get a notification.

Recently moved from GitHub pages to a VPS, for strict transport security and
other goodies. Instant karma.

------
tbirdz
Does anyone know if this will be part of an ongoing series, covering many open
source licenses?

~~~
3JPLW
That would be incredible, but if he spends 4600 words explaining those 171
words, I can't imagine the time investment involved in the GPLv2 (2910), GPLv3
(5644), or MPLv2 (2346).

~~~
tbirdz
Those licenses are very wordy, but not as dense. For example, about a third of
the GPLv2 is the preamble that explains the FSF's "four freedoms" of free
software philosophy and the ending section after the legal terms that explains
how to apply the license to your own product. Cutting those out reduces the
GPLv2 to only 2017 words of actual legal text.

I also feel like it might be easier to explain a more legalese license like
GPLv3, MPLv2 or Apachev2. Like the article explains, the MIT license doesn't
use the "language of the law" and uses more common language and language
familiar to academics and programmers. A license written with more lawyer-
oriented langauge, actually using the same wording as the original laws use,
might be much easier for a lawyer like Mr. Mitchell to explain. I'm thinking
it's an explicit vs implicit type situation, where even though some licenses
are longer they define more things explicity, which means the explanation
doesn't have to fill in as many gaps.

There are also plenty of simpler licenses that would be great for an
explanation. And as part of a series, the author could assume that you are
familiar with his MIT license explanation so as to not repeat the same things.
Other good candidates I'm thinking would be the BSD licenses, the ISC license,
the zlib license, maybe even Apache v2.

------
tunnuz
Also relevant, this free and very accessible book from O'Reilly
[http://www.oreilly.com/openbook/osfreesoft/book](http://www.oreilly.com/openbook/osfreesoft/book)
that explains the history and caveats of most open source licenses.

~~~
kemitchell
Highly recommended.

------
twhb
A bit off-topic, but I would be very interested in somebody making a case for
why an OS license is better than a simple line like "This code is free for
everybody to use as they wish." I've read about it plenty, but remain
unconvinced.

The OS software I write is for the good of everybody, not just its own
popularity or the OS community. I'm fine with all uses of it, in whole or in
part, whether or not I'm credited. The license reproduction requirement
therefore feels like unnecessary noise, and I'd like to think that courts are
sane enough that the warranty disclaimer is unnecessary too - is there any
real court case where somebody has been sued for a defect in free, OS
software, without an explicit warranty, and lost?

~~~
monfrere
Not a lawyer, but I always thought maybe someone could take your code, modify
it to produce variations A, B, C, the three major use cases of your code, and
slap patents on those modified versions of your code. So then anyone who wants
to use your code with any of those three use cases in mind (i.e., most people
who would want to use your code) would then likely be in trouble.

Or something like that.

A second issue would be one the author of the article seems worried about,
which is that without a warranty-free clause people might sue you for bugs in
the code. If you're distributing your code, with a line like "free for
everybody to use," there may or may not be implicit quality guarantees,
according to the article.

~~~
witty_username
Has any such lawsuit actually occurred?

------
kazinator
These licenses have little flaws upon closer examination. One day I was
reading the BSD license closely, in the context of its use in the TXR project,
and was astonished to find that it was buggy and required tweaking to make it
more internally consistent and true to its intent. I added a METALICENSE
document where the changes are detailed:

[http://www.kylheku.com/cgit/txr/tree/METALICENSE](http://www.kylheku.com/cgit/txr/tree/METALICENSE)

[http://www.kylheku.com/cgit/txr/tree/LICENSE](http://www.kylheku.com/cgit/txr/tree/LICENSE)

The main problem is that the original says that both the _use_ and
redistribution of the software are permitted provided that the "following
conditions are met", which is followed by two numbered conditions, 1 and 2.
But the two conditions do not govern use at all; they are purely about
redistribution! Rather, the intended legal situation is that use of the
software means that the user agrees to the liability and warranty disclaimer
(which is not a condition). But the BSD license neglects to say that at all;
it says use is subject to the conditions (just that 1 and 2), not to the
disclaimer.

~~~
matt4077
You shouldn't touch these licenses unless you're a professional.

I'm no lawyer either, but I believe that clauses such as "use of this software
constitutes agreement to" change its nature from a license grant to a
contract.

I have no idea what the practical difference could be, but I don't want to
find out, either.

Additionally, making changes in licenses makes it harder to reuse code. The
license may be incompatible or it may just run afoul of procedures in larger
organizations who sometimes have whitelists of approved licenses.

~~~
kazinator
The point of the liability disclaimer is that if someone, say, uses the
software and happens to lose data due to a bug, the authors (original ones or
downstream modifiers or whoever) are not held liable. That requires agreement;
it has to be spelled out: if you do not agree with this disclaimer of
liability, then you are not licensed to use the software. If you use it
anyway, it is an unlicensed use. This is exactly how it works in shrink-wrap
EULA's in proprietary software; by opening the shrink wrap, or clicking on
some button or whatever the heck, you agree to those things. (If that's a
contract, then let it be a contract.) I'm confident that I nailed it to the
way it should be, and that "constitutes agreement" is excellent wording.

The difference is that I'm covered, liability wise, better than someone just
using the original BSD license, which has a possible interpretation that it
allows the use of the software without the user agreeing to the disclaimers,
since the license doesn't appear to require acceptance of the disclaimer.

From the developer's POV, that's the only part of a BSD-like license that
actually matters. You've already given away the code, and allowed it to be
used in proprietary code, so you're not going to be harmed by anyone stealing
anything from you. At best, your code could be plagiarized: copied in source
code form without you being credited, which isn't very significant. The one
way you can be harmed, as in financially, is that someone wants to sue you
because of some alleged bug in your code having caused some alleged loss.

By the way, here is how we can be certain that in the BSD license, the
disclaimer is not one of the conditions which require agreement. It's because
the second condition says: _".. must reproduce the above copyright notice,
this list of conditions and the following disclaimer ..."_. I.e. the following
disclaimer is clearly distinct from the conditions, and not one of them. Since
it is not one of the conditions, it is not _a_ condition! The license might
effectively not be conditional on the disclaimer.

In contrast, in the GPL v2, the two disclaimers are one of the numbered
conditions (11 and 12). There is nevertheless a slight flaw in the GPL v2 I
just noticed. It introduces the conditions like this: _" The precise terms and
conditions for copying, distribution and modification follow._" But unless
"copying" is construed as use, conditions clauses 11 and 12 are not related to
copying, distribution and modification. These disclaimers apply purely to use.
A bug in the program isn't going cause harm while you're copying, modifying or
redistributing it.

In the past I've seen misinformation disseminated about the GPL like "you
don't have to agree with it to use the software", which is complete nonsense;
you agree with the disclaimers when you use the software.

~~~
nzp
This reminds me of an anecdote about Godel, not sure if it's true or not, but
here goes. When he was taking the Constitution exam to get the US citizenship,
he proceeded to explain to the judge how he has a formal proof that the US
Constitution is inconsistent and allows for a dictatorship to take over
completely legally. Einstein was accompanying him and he somehow managed to
quickly shut him up and continue to go through the motions of the exam.

It also, for some reason, reminds me of what Peter Thiel once said about
physics PhDs: “Because they know fundamental things, they think they know
everything.”

~~~
apricot
Gödel predicted Trump. Film at 11.

~~~
nzp
I wish I could share your optimism about political candidates.

------
nickpsecurity
Licenses like MIT and BSD should be avoided due to the patent risk in favor of
licenses that explicitly grant patent protection like Apache 2.0. The patent
troll risk is just way too high. As rando said, companies like Microsoft are
even open-sourcing code while raking in hundreds of millions from patent suits
against open-source software. That this is even working for them shows the
permissive licenses need to eliminate that tactic entirely.

------
reitanqild
This is fantastic IMO. More of this.

I also think there could be room for something similar about code (but I
haven't had time to read aosabook.org yet, so maybe that is wheree I'll find
it.)

A note on the Crockford joke:

I think it is on IBM, not the lawyers: I think he describes somewhere the fun
of getting a payment from IBM followed by sending an additional license
entitling IBM to use the software for evil.

~~~
Sanddancer
He didn't get a payment, but he did give a license for "IBM, its customers,
partners, and minions, to use JSLint for evil.”

[http://dev.hasenj.org/post/3272592502/ibm-and-its-
minions](http://dev.hasenj.org/post/3272592502/ibm-and-its-minions)

------
vonnik
We've worked with Kyle Mitchell. He's a smart guy.

------
branchly2
This looks excellent, and I'm going to curl up with it and a cup of tea
tonight to read it more carefully. Thanks!

Would love to see the author do one for the GPL. I realize the result would be
quite a bit longer.

------
breakingcups
A very lovely article, I enjoyed it very much since it gives insight into the
"syntax" of legal documents in the US.

This article brought up a point I find very interesting. The MIT license (and
a bunch of other licenses as well) are very US-oriented when it came to their
writing, provisions, etc. I'd love to read a similar article exploring
licenses like these from a, say, European point of view. Would the same
constructs hold up in a German court, for example. What language is missing or
superfluous?

~~~
Iv
I can talk for France. I used to work in a lab depending from the CNRS and
arriving there I learned about the French version of the GPL, BSD and LGPL,
the CeCILL familly (CeCILL-A, -B or -C respectively) (
[https://en.wikipedia.org/wiki/CeCILL](https://en.wikipedia.org/wiki/CeCILL) )

They claim compatibility with GPL, BSD and LGPL and also that CeCILL was
necessary for valid open source licenses in France. That made me raise
eyebrows on many levels:

\- Does it mean the GPL/BSD/LGPL is unenforceable in France?

\- Does it mean the CeCILL is unenforceable in other countries?

\- The CeCILL allows to relicense a work under a future revision of the
license. I know some GPL projects do that, I personally am extremely
suspicious of this possibility.

I raised these points but never got good answers from law specialists. The
guys I could reach were specialized in "intellectual property valorization"
and actually did not know anything about open source. They also made me
realize in the french version of the law, the notion that copyright protects a
source code is extremely disputable:

In France you can't patent or copyright an idea, and numbers and mathematical
formulas are recognized as ideas. It is accepted that a computer algorithm is
equivalent to a mathematical formula. Ergo, in a source code, you can't
protect an algorithm but an implementation. That is, as I understood when
pushing a bit more, variable names and whitespace structure are the only
copyrightable things in a program.

My understanding is that an obfuscater or a code formatter would likely remove
any copyright claim from a source code when it comes to french laws.

I wish we had an actually active Pirate Party or EFF to try push the limits
over that nonsense.

------
cpdean
Would someone care to elaborate why the "Good, not Evil" clause in the JSON
license is bad?

~~~
ajdlinux
a) It doesn't meet the Free Software Definition or Open Source Definition.
What if you want to use the software for evil?

b) Who defines what Evil is? What if the author sues you on the grounds that
you're using their software for a perfectly legal activity, the morality of
which is widely accepted by the general public, but which they personally
disagree with? For example, many authors who have written these types of
licences are pacifists who disagree with the actions of Western military
forces. Are said military applications "Evil"?

~~~
cpdean
ah, gotcha

Thanks!

------
MindTwister
Huh? I submitted this 23 hours ago with the exact same url, glad to see som
discussion though.

~~~
AstroJetson
It happens, at one point there were 9 submissions round the Yahoo story.

------
cyphar
> The MIT License is the most popular open-source software license.

I'm fairly certain the GPL is still more popular.

~~~
matt4077
Maybe by line count or importance, considering the Linux kernel. By project
count, MIT dominates: [https://github.com/blog/1964-open-source-license-usage-
on-gi...](https://github.com/blog/1964-open-source-license-usage-on-github-
com)

~~~
belorn
The link provides the API on how to poll github repositories for license data,
but is a far cry from being a reliable method in measuring usage.

Lets suggest following criteria for a survey:

1#, no duplicates. A survey with duplicate has no meaning. Github data in the
blog post do not exclude dubplicates.

2#, no empty projects. A project with no data in it is not actually a project.
The Github data do not exclude such projects.

3#, only project with code in them. A lot of github projects is text
collaboration, like party planning, discussion around the latests online
drama, and so on. Github data do not exclude those.

4#, only project with running code that is useful for at least 1 person.
Random data, incomplete or abandon attempts is not actually "a software
project". Github data do not attempt to run projects, and very much do not
limit its data storage to only code that works.

To my knowledge, only one license survey exist that passes those criteria, and
that one was based on the curated repository of Debian. The study showed GPL
to be heavily favored (80%), but the study concluded that more such studies
(and discussion on research methodology) is highly needed.

