An open letter: Change the license of spigot obfuscation mappings to some open-source license.

Discussion in 'Spigot Discussion' started by myokan, Feb 10, 2021.

  1. Earlier today I was discussing the prospect of using Mojang's provided mappings for a spigot derivative with some people. Despite the intent and purpose of these mappings being clearly for modders, such as the servers community, to be able to use their provided obfuscation mappings to make modding easier (see an official statement by Dinnerbone: https://twitter.com/Dinnerbone/status/1293597326561488897), the clear sentiment is that Spigot will not be moving to these mappings and will continue to use md_5's mappings. This is understandable in my opinion and is not what I care about. However, I'd like to address a huge flaw with these mappings that should be changed immediately.

    There is a glaring flaw with Spigot's obfuscation mappings. Despite Spigot being heralded as a great open-source project, these mappings are under a proprietary license. Why does this matter, you might ask? Simply put, this heavily restricts what derivative projects of Spigot may do, and unfairly so. By these mappings having a proprietary license (as opposed to a MIT license, for example), any derivatives must also be reliant upon the terms and will of Spigot in regards to mappings as all rights are reserved.

    Here is a likely future scenario which could happen: let's say there is a fork of Spigot (let's call it "Faucet") which wants to expand their project such that plugin developers can write their plugins using Mojang's mappings, with a Mojmap-remapped jar being used at runtime in accordance with Mojang's mappings license. Now, in order to preserve support for Spigot plugins, the maintainers of Faucet may wish to make a mappings file which correctly maps md_5 mappings to Mojang mappings. While this perfectly follows the licensing of the mojang mappings (see the "complete and unmodified" clause), spigot's more restrictive proprietary licensing does not allow for this as the mappings need to be included in this derivative's server distribution for the transformation to function properly. In my opinion (and the opinions of many prominent members of this community), this goes completely against all principles of free and open-source software.

    My proposed solution to this glaring problem is clear and simple: re-license the Spigot mappings to an open-source license and allow our community to thrive and improve. Almost all other areas of the modding scene are thriving and expanding. Conversely, the servers community and server modding is losing its edge to more innovative projects with clear commitments to open-source like Fabric. Please don't let this happen, @md_5 . We have always been the community to take a lead and help create the most innovative experiences in the game. Let's keep it that way.
     
    • Agree Agree x 25
    • Like Like x 2
    • Optimistic Optimistic x 1
  2. JanTuck

    Supporter

    Heard about paper?
     
    • Optimistic Optimistic x 5
    • Agree Agree x 1
    • Winner Winner x 1
  3. Paper isn't relevant to this. Please don't diminish the validity of my suggestion just because you have a misinformed understanding of what they are actually doing. There's a reason I didn't mention Paper in my post, and it's because this has to do with more than just some downstream controversy.
     
    • Friendly Friendly x 3
    • Agree Agree x 2
  4. One of the major problems with your argument is you've actually failed to explain why using mappings like Mojang (or even any other kind of mapping) is a good decision. Especially when your argument boils down to "forks are using it causes licensing problems in a very specific scenario." Are you sure there's no workaround?
    Does the derivative even need to ship the mappings? Isn't it possible for the server jar to be shipped mapped to spigot mappings, as well as the plugin?
    Licensing problems are also pretty weak arguments because minecraft dev is a total grey area anyways, so what's another legal problem on top of so many already? Your argument not very convincing considering the effort required to move the entire toolchain to a different set of mappings just to solve minor licensing problems.


    Using different mappings (whether it be Mojang, Yarn, or MCP) is better for spigot for reasons other than minor licensing inconveniences. Notably:

    1. Updating minecraft versions
    My time updating paper for minecraft versions has taught me a lot about the general update logic for dealing with a patch stack (which is what spigot also uses). While a lot of conflicts & issues arise because of simple code diff in the patch target areas, there is also a considerable amount of problems that arise when dealing with mapping changes. Unlike most mappings, spigot mappings are not remotely stable across versions and cause differences in source code due to naming changes alone. So a lot of time spent updating patches can be attributed to solely just mapping changes.
    Having a better set of mappings will also improve the update process in general, as reading the code is going to be easier with better mappings. I know there were a lot of problems post 1.14 due to the changes made, and a better mapping set would accelerate the understanding of the new code (and old code! it's easy to forget what the code was doing for a patch you wrote 3 months ago) which would make the update go smoother.

    2. Plugins using NMS
    Due to the fact spigot mappings are not stable across even minor versions, the nms rev has to exist and force breakages on even minor versions (on 1.16.5, spigot is on rev 3 for 1.16). While breakages on major versions are expected, unstable mappings causing problems for minor versions is an unnecessary problem. I can see people being unable to update to newer minor versions because they need to wait on nms based plugins.
    You can make an argument that these plugin devs should just PR API so they don't need to use nms, but you and I both know they're entirely incapable of writing acceptable API. Can't shift this problem to people who are incapable of solving it.


    So most of the problems are rooted with unstable mappings. Mojang's is the best for solving this problem since they will always be complete (no mapping updates need to occur except for version updates) and immediately available on releases (so updating is never stalled waiting on other mappings to update).
     
    • Like Like x 1
    • Creative Creative x 1
  5. Here's an explanation of where my initial argument was:

    My initial argument didn't have anything to do with Spigot or other derivatives actually switching mappings to anything other than what they are using. While I also think it would be excellent for Spigot to use Mojang's mappings with the license it currently has (one that is very reasonable, I might add), I thought it would be useful to push for a small, simple change that would fix the issue of derivative projects being unable to accomplish the full scope of their goals. Freeing the spigot mappings by changing them to a permissive license would allow for the creation of Spigot -> Mojang mappings, which would open the possibility for forks to have a Mojang-mapped jar at runtime (different from the approach a certain fork is going) without breaking compatibility for whatever gross mappings Spigot is using. This is another hacky workaround, but it is one that would allow these derivative projects to accomplish "the best of both worlds" at a large technical cost in the presence of inflexibility from Spigot.

    Here's what I've learned since then and where I see this suggestion now:

    Changing the license for these mappings may or may not be a controversial licensing topic like Bukkit/CB! It's asserted at the top of all mapping files in BuildData that the copyright of the mappings belongs to SpigotMC Pty. Ltd. However, some community members have brought up that this copyright claim is dubious because the mappings originated from CB/Bukkit mappings, which would mean that Mojang most likely actually owns the copyright to these mappings, implying they would fall under the EULA. If the former is true, and they are truly owned by Spigot, then it's no problem to change the license to something permissive! If it's the latter, and they are Mojang's, then this entire argument of "freeing the mappings" lies on a false premise because Spigot doesn't actually have the copyright to the mappings as they claim.

    If they are Mojang's mappings, covered by some all-rights-reserved agreement (or even the EULA), at that point why not just switch to the official MC server mappings provided by Mojang which have an even more permissive license? It seems silly to keep using terrible mappings when Mojang specifically GIVES US their mappings and says that they hope modding platforms (mentioning Spigot by name) use their mappings which they have graciously improved the license of at our request.

    Whatever the "solution" is, I think it's incredibly sad that a project which is supposed to be for the community requires us to find hacky workarounds all because one maintainer might not agree with what the vast majority of community members think is a good direction to go in. This is not how a community should operate and I find it incredibly infuriating that we can't have any kind of flexibility on Spigot's end. Bukkit and Spigot's janky handling of NMS mappings has always been a sore spot for the project, and it's honestly depressing that we have a simple and nearly 'perfect' solution in front of us that we are unable to use because the lead maintainer does not see the same vision as the entire rest of the community.
     
    • Agree Agree x 2