Again, the project is not planning on doing it this way. Chris even says this: " Once we reach an agreement on the path to take, we can start talking about logistics of how to get there."

Both of the licenses used in LLVM contain the following clause:

> Permission is hereby granted... to deal with the Software without restriction, including... the rights to... sublicense

The effect of this clause is that all LLVM contributors have already consented to a chance in license, whether that change is done by you, me, Debian, or the Pope.

The only question is whether the LLVM organization wishes to exercise this authority itself. It's clear that the majority of the key contributors are in favor of it, so it seems like a foregone conclusion at this point.

The whole reason that this license change is coming up is that some people in the project (and I assume Apple as well) want to provide some level of protection from patent infringement cases for the users of LLVM. The ability to sublicense doesn't help here because the patent clause in the Apache 2.0 license would only apply to the patents owned by you, the one who is doing the sub-licensing. They want these protections to apply to the patents of any of the authors of LLVM, which of course cannot be done without their consent.

There is debate about to what extent patent protection is already extant in the current licenses. One example, the MIT has

> to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software

The word "patent" does not appear here, but the words "use" and "distribute" seem to imply the granting of rights necessary to achieve those ends (of which a limited patent license would be one), and the phrase "deal in the software without restriction" is a statement so broad that it seems difficult to argue a patent license (and perhaps many future IP innovations unknown to us today) was not granted by the rules of equitable estoppel.

The reason for this license change is to resolve the ambiguity that arises because the word "patent" does not appear as a word in this clause. It was found that the GPLv2 did not grant patent rights because it was not mentioned in that license [0], although the circumstances of that case and the text of the MIT are far apart.

As a result of all this LLVM may go around and get people to sign off on the Apache grant but it is likely to be under the banner of "clarifying" an implied patent grant rather than establishing a new one. Depending on how worried the lawyers are about the legal meaning of "deal in the Software without restriction" they may not be worried about the contributors they are unable to track down.

[0] See https://www.fenwick.com/FenwickDocuments/potential_defenses.... for an analysis of the GPLv2 situation

You're correct, I should have said better patent protection, not patent protection at all.

Does 'sublicensing' imply a change in the license terms? I wouldn't think so, but IANAL.

Well to cite an actual IP attorney [0], yes. A sublicense means that you (the licensee / sublicensor) grant somebody else (the sublicensee) the right to use the software, and you can do it under any terms you are permitted by the grant of sublicense.

The MIT/NCSA do place some restrictions on sublicenses ("subject to the following conditions") but I don't see any reason why the Apache license would present a problem as the choice of sublicense.

I am not a lawyer, I am not your lawyer, this is not legal advice.

[0] http://danashultz.com/blog/2010/10/19/what-is-a-sublicense-a...

License changes are not unheard of.

Wine changed from the MIT license to LGPL without all of the developer's support.

That's fine within the terms of the MIT license. It's not okay to relicense LGPL to MIT without author consent.

You can't do that but you can do further contributions under the LGPL which essentially makes it an LGPL project.

What provision of the MIT license prevents it? My understanding is that MIT -> GPL is legal as long as the required notice is kept for MIT compliance, since MIT is a subset of GPL.

What provision of the MIT License allows it? By default it is prevented in a copyrighted work. I don't think the sublicense clause covers it.

MIT is not copyleft. If you can sublicense MIT to be proprietary (which is what most people consider to be a "benefit" of the MIT license) then you can also sublicense it to be under the GPL[1]. The GPL does not strictly provide more rights than the MIT license.

[1]: http://danashultz.com/blog/2010/10/19/what-is-a-sublicense-a...

We don't change the license on the original code when we include it in proprietary software. I cannot just take a piece of MIT licensed code and change the license to what I want. I can add code of a different license.

You can't make the original code not-MIT-licensed, since the author already released it as such (and even they cannot make it not-MIT-licensed). But you can release it (with or without modifications) under another license as long as it lets you follow the MIT license's only restriction (reproduction of the copyright notice).

What do you think being GPL-compatible (for example) means other than that? The GPL requires you to release all parts of the derived work under the GPL, not just a compatible license.

> You can't make the original code not-MIT-licensed

Yes, that's what I was saying.

Actually you are saying different things. Even thought the original code will still be forever available under MIT, you can, for example, sell it under a proprietary license (without changing a line of code) to whoever is willing to pay for that.

Yes you do (well change is the wrong word, you're sublicensing your copy of the code). Otherwise the software would not be proprietary. Windows for example used to ship BSD licensed code, and it would have been a violation of Windows' license to modify that code (even though the original code was under a free software license).

I don't understand which part of this is confusing you -- the MIT license explicitly states that sublicensing is permitted. If you didn't sublicense the code, then users would be allowed to have all the freedoms that come with the MIT license. This would make it impossible to have a proprietary version of an MIT licensed project -- which is something that we objectively know is possible because it happens all the time.

You cannot change the license on someone else's copyrighted work.

> Windows for example used to ship BSD licensed code, and it would have been a violation of Windows' license to modify that code (even though the original code was under a free software license).

Microsoft didn't include source and if I had obtained the BSD licensed source, I could certainly modify it and distribute it (but not the code written by Microsoft). Also, the BSD doesn't have a sublicense clause which is problematic for your first sentence.

> You cannot change the license on someone else's copyrighted work.

The grandparent already said that "changing" is not the thing being discussed here, but "sublicensing", so this is a strawman.

It's never fine to relicense works of others, unless you have a CLA giving you that explicit right.

Or a license that gives you that explicit right (like the MIT license does).

> The contributors own their work and licensed it under one license, and the project wants to change it without doing the Herculean job of getting permission from all.

And how Theo figured that the plan isn't to get approval for the license change from all contributors?