
The MIT license. What does it do? - teamhappy
There are arguably too many threads about the [MIT license][1] on the internet. What&#x27;s worse is that most of them contradict each other or are at the very least misleading.<p>Let&#x27;s try to figure it out together, shall we.<p>The license starts with a definition of the word &quot;software.&quot; Specifically, it says that software isn&#x27;t just code, but also &quot;associated documentation files.&quot; Cool.<p>What follows is a detailed description of all the things you can do &quot;without restriction, including without limitation.&quot; The things you&#x27;re allowed to do are pretty much <i>all the things</i>. Cool.<p>In order to get to do all those things you need to satisfy a condition. The condition is to include the copyright notice and the permission notice in all copies. For the MIT license, that&#x27;s pretty much everything but the disclaimer at the end. Cool.<p>All that seems pretty clear to me, and yet, you find comments like:<p>- You have to retain the original copyright.<p>- You aren&#x27;t allowed to remove license comments from individual files.<p>- You aren&#x27;t allowed to remove copyright notices from individual files.<p>The list keeps going. I&#x27;m sure you&#x27;ve read (hopefully not written) many of them yourself. I&#x27;d love to find out where these interpretations come from.<p>Assuming that I have a credits page* (not sure how you&#x27;d satisfy the condition without one) that includes the licenses, why wouldn&#x27;t I be allowed to remove whatever I want from the code? &quot;Without restriction&quot; sounds unambiguous to me.<p>*If you&#x27;re building native apps your &quot;credits page&quot; might be a directory hidden deep inside your app bundle.<p>[1]: https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;MIT_License
======
belorn
A license, like a ticket, is what gives you permission where you otherwise
would not have any. Its the answer to the question: What gives you permission
to distribute copies.

MITs condition for granting this permission is a single term: _" The above
copyright notice and this permission notice shall be included in all copies or
substantial portions of the Software."_

You do not need to retain the original copyright notices as it exist in the
files, so long the notice is included. You can remove the original copyright
notice or license comments and copyright notices in individual files, as
keeping them is not a condition of the license.

However, copyright also has a moral aspect to it, which include authorship. If
you add your own copyright on something you have not made without clearly
distinguish what is yours and what is someone else's, then that is most likely
illegal since you are misrepresenting the copyright owner of the MIT licensed
work. Its doubtful any license could ever grant permission to do this, as it
would infringe on an inalienable right of the author.

------
dalke
Yes, there's a bunch of folk beliefs about licenses. Many of them are not
based in copyright law.

"You have to retain the original copyright"

That is meaningless. It has two interpretations. 1) the copyright holder
maintains copyright. This is inherently true because the license is not a
copyright transfer agreement. 2) you have to retain the copyright _notice_.
This retention requirement is explicit in the license agreement.

"You aren't allowed to remove [license comments/copyright notices] from
individual files"

The MIT license doesn't have that requirement. It says the notice must be
"included in all copies or substantial portions of the Software." It doesn't
even use the word "file." I am unaware of a court decision which has
quantified what "substantial" means. Most people keep it attached to the file,
though they likely do not need to do so.

The GPLv2 license states, in "How to Apply These Terms to Your New Programs":
"To do so, attach the following notices to the program. It is safest to attach
them to the start of each source file to most effectively convey the exclusion
of warranty."

That sense of safety no doubt is behind the folk beliefs.

"credits page* (not sure how you'd satisfy the condition without one)"

The MIT license only requires that the copyright notice and this permission
notice be included in the software. There is no requirement that the
information be visible to the end user. The clause you are thinking of comes
from the GPL

The GPLv2 has a requirement that interactive programs "print or display an
announcement including an appropriate copyright notice and a notice that there
is no warranty (or else, saying that you provide a warranty) and that users
may redistribute the program under these conditions, and telling the user how
to view a copy of this License." This is most often done with a credits page.
However, that is not an MIT license requirement.

"why wouldn't I be allowed to remove whatever I want from the code?"

Under copyright law you can only do what the license grants, or what is
available to you under fair use. You can remove whatever you want from the
code "subject to the ... conditions". You cannot remove the copyright
statement. You cannot remove the permission notice. Those are the conditions.

~~~
teamhappy
Looks like we see eye to eye on this one. Basically what I said is that the
license (technically without the disclaimer) needs to appear (the ISC license
chooses that language) somewhere. That's it. Put _one_ copy of it somewhere
(not sure if it needs to be visible to the end user) and your good to go.
(Assuming that the license includes the copyright notice at the top.)

~~~
dalke
I find your answer somewhat grating. I will explain why.

We do not see eye to eye. I'm not trying to "figure this out together". I
'figured this out' years ago. I'm pointing out that you are using the wrong
terminology, and trying to correct your understanding. We are not at the same
level.

For example, you said "not sure how you'd satisfy the condition without [a
credits page]". That's the wrong terminology. It's a copyright notice and a
permission notice. That doesn't require a "credits page". Though those notices
could go on such a page, there's no requirement that there be a "page", and
the term "credits page" adds needless terminology.

By repeating meaningless or at least ambiguous phrases like "You have to
retain the original copyright", and by using new and irrelevant terms like
"credits page", you are adding to the confusion around copyright.

Further, in your response to jeffmould you said "You're not contradicting
anything I said, are you?". The thing is, you have since made a contradiction.
jeffmould said that the code from ProjectA which is in ProjectB is not subject
ProjectB's license. You said that the code is subject to a dual license. This
is a post-hoc contradiction.

~~~
teamhappy
Fair enough.

> It's a copyright notice and a permission notice. That doesn't require a
> "credits page".

Of course it doesn't. I tried to come up with a real world example because
people (obviously) have a hard time figuring out what it means. I also added
that the "credits page" might just be a folder full of licenses somewhere
inside your project's directory structure. I hear you though.

> jeffmould said that the code from ProjectA which is in ProjectB is not
> subject ProjectB's license. You said that the code is subject to a dual
> license. This is a post-hoc contradiction.

I said it _could_ be subject to two licenses. It doesn't have to, of course.
You've also mentioned license compatibility in your other comment — I think
you're trying to explain to me that my license can't revoke any rights granted
to you by "the other" license. Does that sound about right?

~~~
dalke
"not sure how you'd satisfy the condition without one" doesn't fit with "Of
course it doesn't."

Regarding the second point, code from ProjectA, released under the MIT
license, which is in ProjectB is not subject to ProjectB's copyright. This was
jeffmould's scenario, and this code is not subject to two licenses.

The ProjectB developers must do some creative act to the code before they can
assert copyright on the modified code. Copying code from multiple sources is
then subject to both licenses.

It is also possible that with enough changes ProjectB is no longer subject to
the original copyright from ProjectA. Quoting from
[http://www.ca10.uscourts.gov/opinions/13/13-6181.pdf](http://www.ca10.uscourts.gov/opinions/13/13-6181.pdf)
:

> A corollary of the “sameness” requirement is that “[c]opying deleted or so
> disguised as to be unrecognizable is not copying.” See v. Durang, 711 F.2d
> 141, 142 (9th Cir. 1983); see also Int’l Ass’n of Machinists & Aerospace
> Workers, AFL-CIO v. Winship Green Nursing Ctr., 103 F.3d 196, 203 n.6 (1st
> Cir. 1996) (“Even if a work is copied, however, no copyright infringement
> exists if substantial changes render the work unrecognizable.”); Warner
> Bros. Inc. v. Am. Broad. Cos., Inc., 720 F.2d 231, 241 (2d Cir. 1983) (“‘[A]
> defendant may legitimately avoid infringement by intentionally making
> sufficient changes in a work which would otherwise be regarded as
> substantially similar to that of the plaintiff’s.’” (quoting 3 Nimmer on
> Copyright § 13.03[B] at 13-38.1 to -38.2 (1983)).

Which means that you could, with sufficient changes to the code, revoke rights
granted by the other license. This is how Berkeley extracted itself from the
AT&T license for Unix.

------
jeffmould
IANAL, but my interpretation of the MIT license has been (I could be wrong
here) as follows:

Let's assume I create an open-source piece of software called ProjectA and
license it under the MIT license. You come along, like what you see, but think
you can make it better. You download ProjectA, modify the code, and decide
that you are going to sell your modification as ProjectB.

Since the original code I developed was licensed under the MIT license you are
required to continue the MIT license within your version on the parts that are
part of ProjectA.

So if John comes along and buys the software from you, he is free to modify
the portions of the software that were part of the original ProjectA. You are
welcome to license your modifications however you wish, but the original
ProjectA, or any code that was part of ProjectA, would still fall under the
MIT license.

~~~
teamhappy
That's a good illustration of why the requirement exists in the first place.
You're not contradicting anything I said, are you?

FYI: The MIT license allows me to sublicense ProjectA's code, so technically
it could fall under two licenses.

~~~
dalke
I don't know what "it" you mean here.

The developers of ProjectA hold a license to that code. If ProjectB is under
teamhappy license, then those parts of ProjectB which are unchanged from
ProjectA are still only under the MIT license, because copyright requires
creative input. As ProjectB made no changes, there was no creative input, so
they cannot use copyright law to enforce difference license terms.

The portions from ProjectA are under the MIT license. The portions from the
ProjectB developers are under the teamhappy license. If I use ProjectB then I
am a licensee for both MIT and teamhappy licenses.

This co-mingling of software from multiple copyright holders with multiple
licenses is why the licenses have to be "compatible."

~~~
teamhappy
> As ProjectB made no changes, there was no creative input, so they cannot use
> copyright law to enforce difference license terms.

I'm not sure that's true. BSD-style licenses allow you to sublicense the code
under a more restrictive license if you feel like it.

This is has no real-world effect though.

If you have code licensed under two licenses you (the user) can always choose
to use to code under the more permissive license (MIT in our case). But
technically, it's licensed under two and I don't think they have to be
compatible.

By the way: This has nothing to do with copyright. If I didn't change your
code than I'm not a copyright holder of your code. Doesn't mean I can't
license it to other people under a different license though.

~~~
dalke
I'm sure it is true. See Bridgeman Art Library v. Corel Corp .

Yes, there is a real-world effect. As I mentioned and jeffmould wrote, I can
use those part of ProjectB which came from ProjectA without being subject to
the teamhappy license of ProjectB. It's not a question of dual licenses, it's
one of license compatibility.

If I am IBM, and SCO sues me because my distribution of the Linux kernel
contains code which is part of Unix, whose copyright is controlled by SCO, and
without an SCO license, then a valid response is to point out to SCO (and the
court) that that shared code was released into the public domain by AT&T. Even
if some Linux kernel developer actually did copy the code from SCO Unix (very
unlikely!), there is no new copyright claim by SCO for "slavish" copying.

