Regardless of the intended goals of the license (as I have seen discussed in prior issues, creating a permissive license is not your intent): it clearly does not adhere to the spirit of the MMPLv1 by adding restrictions, specifically on redistribution. Calling it the MMPLv2 misrepresents the nature of the license.

Also the section "The User grants the Author all rights to any contribution." Is this a copyright assignment clause? Or simply that any contibutions are implicitly licensed perpetually to the author? The fact that it later mentions a CLA implies the latter to be the case. This should be explicitly clear.

The section on derivates also is unclear, should "The Derivative complies with the Mod license." be taken to mean that the derivativs must also be licensed under the same terms? Or does the mean something else?

I think it would be a good idea to add linking to the mod page/forum post as a requirement for modpacks. Does anyone agree?

There is no license applied to this license. This means that all copyrights in the license are owned by the authors of the various parts, and all rights are reserved, other than those released in the GitHub terms of service. To fix this, you'd need to get all authors of/contributors to any part of the license to agree to release it under a license of some sort.

As sometimes happens with projects, people want to change licenses as the project progresses down the line and (as is currently the case with Asie and Buildcraft) this is somewhat impossible, when you then have to chase down the 50-odd people who contributed something under the old system. Even if it was a single line that has been moved and refactored so much that GitHub's blame mode can't even tell you the original author any more, so you have to contact everyone on the list.
I think a clause stating that material contributed to a project using this license can be re-licensed under another (open source) license with the majority vote of active (within the last month) contributors would be welcome

I wanna be able to port MMPL-licensed Minecraft mods to Minetest.

This license is not intended to ... [s]tart arguments about terminology or definitions.

Apologies beforehand if I am trespassing on your intentions, but terminology and definitions are critical in licenses. For example the very word "argument" is ambiguous in this sense, it could mean one of two things:

1. A discussion in which the parties involved express disagreement with one another; a debate
2. An angry discussion involving disagreement among the participants; a quarrel

By context and good faith (that the above quotation is not a gag rule) I am assuming the intended meaning is the quarrel definition. But it is risky to leave ambiguity in a legal document! Ambiguity should only exist in a final draft when consensus could not be reached; only then is ambiguity an acceptable compromise. Why leave it to a judge to determine the meanings of words if there could be explicit definitions?

Can the user examine raw bytecode (I believe this is implied as it is technically required)? Can the user disassemble the bytecode (eg: javap)?

Are we going to extend this to make it work with other games and thus skirt around mentioning the minecraft deathtrap?

This license doesn't go along with the Open Source definition by the OSI. See also their FAQ.

This license doesn't allow the mod to be sold and it doesn't allow using the mod if the user doesn't have a legal copy of Minecraft.

Please don't call this license an "Open Source" or "Free Software" license.

Current version of the license (v2.0.3) doesn't have wording to cover art, media, etc assets.

Some thoughts from IRC:
Allow the author the option of excluding things categorically (eg, "This repository with the exception of art assets and sound files is licensed under the MMPLv2...") or via relative path.
Make sure that art/media already licensed under a different license can be used for mods...eg, creative commons artwork, or art derived from something else.
Provide clarity on how art derived from the Author's art should be handled.

Mod: Software which modifies the Game, in any form (source, compiled binary, etc).

I could interpret this in three different ways:

Mod: Software which modifies any form of the Game (source, compiled binary, etc).

Mod: Software in any form (source, compiled binary, etc) which modifies the Game

Mod: Any form of Software which modifies any form of the Game

The definition of modpack is loopholey. It's sort of a weird thing to define while also preventing distribution via other websites that are not authorized. I'm not sure how to deal with it myself, but I'm sure someone is.

Derivative: Software which includes any portion of the Mod other than the API, with modifications, additions, or subtractions.

Normally I see the term "derivative work" which means that the work is based on a previous, "derived" work and includes copyrightable portions of the derived work. From this I can assume that this license's definition would be better written as follows:

Derivative: Software which includes any portion of the Mod other than the API. A modified version of the Mod is considered a Derivative.

Compare this with another interpretation:

Derivative: Software which includes any portion of the Mod other than the API, including modifications, additions, or subtractions to the Mod.

Yet another one, which provides a definition for "modifications"

Derivative: Software which includes any portion of the Mod other than the API, including modifications to the Mod (additions or subtractions)

And here's a less likely interpretation:

Derivative: Software which includes any portion of the Mod other than the API, including modifications, additions, or subtractions to the API.

This license is missing a section titled "Right to Modify". Therefore I have tried to construct the equivalent rights from other sections:

1. Right to examine

The User may decompile compiled binaries of the Mod.
The User may examine the Mod's source code.

Examining the Mod is the first step in modifying it. As I raised in #34 this section is missing binary (raw) or disassembled examination, although as noted binary examination is implied by technical requirements.

Codebase: The Mod source code, complete with source history and Contributor records.
...
6. Right to contribute

The User may "fork" the Codebase.
The User may compile the Codebase.

Here I must define "fork" as creating a copy of the Codebase and appending my own modifications to the source code into the source history and Contributor records. I must also assume on good faith that §6.2 will also allow me to compile the forked Codebase; although this right is never explicitly given it does not make sense to fork without compiling the fork. The right to play the compiled fork is never explicitly given.
The right to distribute the modified fork and its compiled binaries is only implied in the form of Derivatives:

1. Right to derive

The User may create Derivative(s) based on the Mod.
A Derivative must contain changes which a reasonably informed person would consider significant.

The User may distribute a Derivative if the following conditions are met:

• The Derivative does not generate revenue.
• The Derivative provides credit to the Author.
• The Derivative complies with the Mod license.

As mentioned above, it is implied that the Derivative may be created when a fork is compiled, if the Derivative contains "changes which a reasonably informed person would consider significant". Note that the Mod license does not explicitly apply to the Derivative until it is distributed; as such it is unclear what rights the User has to a Derivative unless it is distributed. One could make the argument that the User is their own distributor but clearer wording is preferred. The rights of the Author over a Derivative are not enumerated here but rather under §8 (assets) and §10.2 (Mod name).

1. Right to distribute addons

The User may develop non-Derivative Addons.
An Addon may include the Mod API without being considered a Derivative.
The Addon may be distributed under a different license.

Addons are defined as using only the API part of the mod. It is unclear what rights if any are given or denied to the User concerning their Addon, except for the Author rights reserved under §8 and §10.2. This conclusion is only reached after making a reasonable assumption that an Addon using only the API part of the Mod is not a fork of the Mod.

Conclusion

Unfortunately the above is all I could find about the right to modify the Mod. Here is a non-exhaustive list of things not addressed:

-Modification of the Mod which a reasonably informed person would consider insignificant
-Binary (raw) modification
-Dissassembling and reassembling bytecodes
-Reassembling modified bytecodes

Modpack authors can earn rewards on Curse if they so choose, I suggest:

"This mod all derivatives and any pack containing this mod must remain free to download and available to the general public not limited to an exchange of real world currency. Real world currency includes donations and subscriptions as well as direct payment for access. Access to all components of the mod and any mods derived from or packs made with it must always be free to the end-user and all financial transactions must remain voluntary and not derived from granting access. "

To cover allowing pack creators to ship the mod and earn rewards and mod derivatives (addons) getting point rewards, but not allowing pack creators to charge for access, or server owners to sell parts.

The ability for the original author to give permissions to someone to distribute the mod behind adfly links or something else like that

Need to add language that provides protection of a mod's name.

Care needs to be taken that this doesn't get too broad...eg, Minechem is pretty unique, but a name like "Crafting Mod" might be to generic...should probably look at trademark law to see if this is even necessary.

It doesn't make any sense to me why distribution of unmodified versions would be more restricted than distribution of derivatives.

Someone could just go ahead and modify just a single instruction and make a derivative this way.
I suggest completely dropping the distinction between modified and unmodified versions.

In particular: "Unmodified copies may only be distributed through the link the mod author provides."
Think about it. It also means you're not allowed to fork a repository.

This is probably an unintended consequence of commit a3fdac8. I understand its intended purpose: To stop the classical case of "mod reposting" where a site rehosts a mod without giving credit to the author. But this is already covered by section 6: "[...]must be distributed under the same license as this mod."

The whole section 5 as of now is too restrictive to be considered Open Source. I suggest dropping it. It even conflicts with @jakimfett 's own definition of Open Source (#9).
Also: "The original mod author may revoke hosting permission from any distributor." Think about it. This is basically equivalent to "All Rights Reserved".
Open Source software should encourage users to modify and distribute the software and not stop them from doing so.

If you truly want to make an Open Source license then please focus on the community rather than on the individual mod author.
However if you're trying to prevent authors from "unfair use" of their code and put the rest of the community behind the "original mod author" then you're missing the purpose of Open Source.

I might be making a pull request with some suggested changes but I'm afraid it might be fruitless because you guys don't agree with me either way. I saw how close-minded you, @jakimfett, were about #9, no offense. I need to get some sleep first... see, that's how much I care about this license.

Although this has been mentioned in #28, it would be good to know what is happening in terms of changing the name of this license. Using the name 'MMPLv2' suggests that this license is a later version of the original MMPL, which is obviously not the case - while they are both great licenses, they serve different purposes. This can (and, eventually, will) lead to confusion between the two.

To prevent this from happening, it would be useful to change the name of this license to something other than MMPLv2.

Please remove that mention in the README, it's misleading.