Hacker News new | past | comments | ask | show | jobs | submit login

Thank you for making me realize I'm not the only crotchety old bastard who bitches and moans about this! My kids are old enough to play Minecraft but too young to understand how to install mods.

Speaking of that, I've looked into the mod making scene and it's rather disgusting. Mojang really dropped the ball by not having an official way to write mods/plugins. Instead we get a horrible client side mod environment (Minecraft Forge), and a half decent server side (Bukkit), but they're not compatible with each other. Bravo Mojang!




Bukkit's dead now anyway. The entire development team decided to call it quits due to legal uncertainty and general exhaustion, then Mojang announced that they weren't allowed to do that because Bukkit was actually owned by Mojang and had a special deal which meant there were no legal issues, contradicting what they'd told people who asked privately. Then one of the main developers got pissed about the fact that he'd been secretly working for Mojang for free and used the DMCA to kill the whole thing off - something he could do because his code, and all of Bukkit, was licensed under the GPL and using it for modding Minecraft was a GPL violation(!). This didn't stop Mojang from arguing that he had no legal right to do so, though. They're really keen on the whole free labour thing.


Craftbukkit was never licensable under the LGPL. From the projects inception, it contained proprietary, closed-source Mojang code used without a license. It's LGPL license was invalid from the start.

  From the get go we were plagued with issues and obstacles we needed to overcome, one of which we were sadly unable to tackle despite our best efforts: the legal barrier of licensing and permission. When starting the Bukkit project and even getting involved with hMod before that, we all knew that our work - no matter how well-intentioned - fell into a dangerous legal grey area.  - EvilSeph[1]
This calls into question the legal standing of all derivative works of Craftbukkit.

The contributors still have copyright over the things they wrote, but they also weren't writing them in a vacuum. They were creating derivatives of Craftbukkit under the assumption it was valid LGPL.

The LGPL wasn't violated because it came out that Mojang controls the Bukkit project. It was voided before these contributions came into question. It's not clear what license, if any, the contributions by Wesley, et. al. fall under.

I am very interested in the legal issues of this whole situation and am constantly looking for the best resources I can find. If you're curious, I suggest reading some posts by /u/VideoGameAttorney on reddit[2]

[1] https://forums.bukkit.org/threads/bukkit-its-time-to-say.305... [2] http://www.reddit.com/user/VideoGameAttorney


This is not how it works. When you write code, you are the owner unless you sell/disclaim all rights. You can contribute your code under a license, a license DOES NOT TRANSFER RIGHTS. Just because something else went wrong with the licensing of other code in the same project does not mean you lose your rights to the code.

Now, in the bukkit project there's two sources of code:

1. Mojang owned closed-source 2. Contributions made by commiters under the LGPL

Then it was distributed in it's entirely under the LPGL. Source #1 clearly is incompatible with this, and this is an issue. However, this has NOTHING to do with the fact that all contributions were licensed by their rights owners, THE CONTRIBUTORS, under the LPGL.

Just because you contribution was distributed with something that's incompatible with the license it was distributed under does not mean you lose the rights to your code.


IANAL These are just some of my opinions gathered from information surrounding the Bukkit drama. I have spent a good deal of time this week researching what I could, but I can very well be wrong.

I'm not arguing that anyone, including Wesley, should have lost valid interests in the code they developed. Please consider the following scenarios:

1) Contributor was clear to license his contributions free end clear under the LGPL. They contributed them to a project that was a priori in violation of said license. If they were unaware of the conflicted project status and were led to believe it was valid LGPL, they should have sought correcting actions as a soon as they were made aware.

1.a) If they knew that contributing their code would directly create a violation of the LGPL, they shouldn't have contributed. If they knew and did it anyway, they are party to violating the license.

2) Contributor code is encumbered and isn't free to be licensed under the LGPL. Depending on circumstances, just because you type the keys doesn't mean you're completely clear of another entities interest in the work. In this case not only is the project encumbered but so is the contribution. It's unknown what the validity of any license would be in this case.

A case could be made that the trigger to this recent mess, Wesley's DMCA notice, is scenario #1. That the contributors were just recently made aware that the project they contributed to was violating the LGPL. They would be right to seek redress for the violation of the license. This is the process working like it's supposed to.

It could also be that we're seeing cases of #1.a (or if skeptical #2). Certain contributors weren't just submitting patches to an email list. They were also the ones accepting pull requests to the main repo. It would stand to reason that they would be aware of the status of the main project. It's a legal nightmare.

In _any_ of the three scenarios, the status of the project as a whole is still infringing. It's so encumbered that it can't be distributed and individual rights owners who are being violated should seek remedy. This doesn't take the rights away from anyone. If they have found their rights to be violated, they should speak to an attorney.

Addedum to 1.a "You can't violate your own license." The contributor could have dual-licensed the code under the LGPL, but then contributed it to the project under some other, unspecified license. That would be ok depending on the terms of the other license, but it's not documented and impossible to verify. Also, we have contributors stating that their LGPL licensed code being violated, which discounts this possibility.


> This didn't stop Mojang from arguing that he had no legal right to do so, though. They're really keen on the whole free labour thing.

My read on the situation is this:

0) Bukkit people reverse-engineer MC code. MC code is non-GPL'd.

1) Bukkit people release RE'd MC code under GPL.

In order for the Bukkit folks to be able to relicense their code, they would have had to add a couple of steps, and rewrite step one:

0.25) Bukkit folks write a spec from the RE'd MC code.

0.75) Bukkit folks hand that spec to an unrelated third party who then implements that spec without any other input from Bukkit.

1) That third party releases their work under the GPL.


My understanding is that Bukkit people didn't reverse engineer the Minecraft code - they decompiled it. That's a problem.

(Apologies if this is what you meant by "reverse engineered" - it isn't clear)


Everyone left that matters is on #sponge @ irc.esper.net recruiting and planning Bukkit's successor called Sponge, it aims to be something like Bukkit+Forge.


It was so much worse before Forge. With Forge, it's still incredibly arcane, but it's not batshit crazy like it was before. Of course, now you need to have the Forge version of a mod, and you have to have the right version Minecraft too.

I'm getting mad just thinking about it. I need to stop now.


This also highlights why client side mods (Forge based or not) are the vast minority of 'Modded Minecraft'.

Configuring a Bukkit server would still have taken some work, but it also only required that to be expended on the server side.

Players would be able to connect with a purely vanilla client and benefit from the enhanced interactions and gameplay mechanics that could be handled on the server side only. This attracts thousands more people than fiddling with launchers, or worse, .jar files.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: