Hopefully Microsoft can reign in all of that crap and make the game less of a nightmare to maintain.
Hopefully Microsoft can reign in all of that crap and make the game less of a nightmare to maintain.
He's smart, but not a genious. He's doesn't even speak or understand english. Most kids can learn to do their own minecraft-management.
Kids love minecraft. They love to have their own server. I shamelessly abuse that love to install some *nixcraft on them.
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!
I'm getting mad just thinking about it. I need to stop now.
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.
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.
(Apologies if this is what you meant by "reverse engineered" - it isn't clear)
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
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.
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.
Of course the forums are a Wild Wild West of inconsistent solutions that make me feel like Druidic incantations would be just as effective.
Its a really retro game, and I'm not talking about block graphics. Culturally and technologically its like something out of shareware game programming on a C64 in the 80s.
The crazy thing, is in 2014 there's a lot of people making a lot of money telling us that doesn't work, but just like 80s software development, it really DOES work. Maybe not well, maybe lots of heads pounding on desks in frustration, but it works surprisingly well.
If you're in the modern dev community it does feel like visiting a museum or an Amish community, very deja vous.
Mojang really needs to fix this: standard mod interface (which doesn't require jar surgery), sane distribution, etc.
I would find it difficult to live with just one mod. Half the time it doesn't even make sense; they assume the presence of others.
See my previous comments on this exact problem[1].
I'm actually working on a server app thing to make this easy. The idea is pre-configured sets of mods which will work together, installable with a single click. I have various techniques to constrain the resources used by mods so they don't kill other servers on the same machine, too.
The mod part isn't ready yet, but on-demand Minecraft server provisioning is working well.
People on HN probably aren't the real market since most here can wade through the horrors of incompatible mod versions etc, but my contact details are in my profile if anyone is interesting in testing it.
Minecraft is probably attracting tens of new people to Java and game modding every day. Backgrounds vary all over the place. Not everyone knows the best practices well enough to just go out and start on them.
This leads to the scenarios described around here about poor mod management in 2014. The 'state of the art' definitely has changed, but it's not a structured community so the outside view still looks similar to 3 years ago.
I find the most odd thing about minecraft is how much 3rd party adds to the game, but is in no way supported by mojang. Even when Things such as pistons and horses began as mods, and were implemented into the standard game years later.
Its been years since mojang announced they'd make a mod api, and it still doesn't exist.
Technically, CPM 2.2 is much more secure than windows 8.1 but its not sweeping the market.
Launcher aside, mods are easily able to have shady code in them anyway. I remember a server which required you to use a custom modded client which, upon decompiling, i found contained a nice FTP module inside its mandatory anticheat, allowing anyone with permission on the server to issue your client commands to retrieve anything from your minecraft directory.