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.

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.

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.)

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.

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?

"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 :

> 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.

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.

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.

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."

> 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.

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.