Bukkit made a lot of mistakes (don't we all), but I think that this talk tries to pin them on the wrong thing. Bukkit was in a failure state the second they included the Minecraft binaries. You're beholden to a third party the minute you create a server for the service, but linking the binaries in an OS project dooms you to failure eventually. Mojang could have DCMA'd the project (and thankfully didn't).
The talk seems to focus on license as the resolution - and it's an important point. However important licenses are, they aren't as important as not linking third-party closed-source binaries in your "FOSS" project.
From outside, it seems odd that Bukkit distribute the closed-source binaries rather than relying on a official minecraft client already been installed on the machine. Many older FOSS game projects add modification to an existing proprietary game and uses the game assets as a resource to be pulled from the during run-time or install. In Debian, most games located in contrib archive seems to be of this type.
Just seems as a much safer way to go about modifying software that restricts all redistribution.
This. Lesson learned: the "over 150 developers" who literally threw away their time(i.e. money) working on this had the option to work on minetest instead. They didn't. Grow up, learn your lesson (I have in much more painful ways) and only use GPL.
It looks like the lesson from Bukkit is that if you use GPL and there's some problem, then a disgruntlend copyright holder (of GPL-licensed code) can get your entire project into trouble.
The project of course was wrong to include or link to proprietary code. But had they used a free license for their own stuff, Wolfe wouldn't have had a claim to make.
Actually I can't think of a single license that would have been valid here unless it came with Mojang's permission. The problem was the proprietary code. Had everything been GPL, not a single copyright holder could have affected the project in such a way.
No, the proprietary code was a problem. Another problem was a license that gave a single developer the power to take the project down. If the code were permissively licensed, he could've not done that. Yes, it would still infringe on Mojang's rights, but that could've been addressed separately.
Another problem was a license that gave a single developer the power to take the project down.
It gave a developer the power to take down a project violating the GPL. That's probably a quite good power for them to have. I don't see how that's a problem for anyone except if you currently are or wish you could violate the terms of the GPL.
Not having your contributors sign a CLA is a huge mistake. Without a CLA, one contributors work can taint the entire project. All open source projects should be aware of this.
The Wine project has no such agreement. I'm not involved with the legal stuff myself, but I know it's been considered by the project bigwigs, and the decision was that an agreement would be too onerous and discourage contributions, especially from non-English developers.
We are, however, very careful that all submissions are accepted under the original author's name. We rarely accept patches of the form "I took someone else's half-complete patch and fixed it up." In addition, all submissions are assumed to be released under the project's license. If the original submitter doesn't have permission to release their submission under that license, then the violated party should take that up with them.
This is interesting, because I may have done this recently and I didn't think twice about it. I took someone else's patch (which had been submitted but never merged), merged it in to a newer version, fixed quite a few conflicts and tests, and committed it. Is that problematic? The original submitter's commits are intact and all the "fix-up" code is in the merge commit in my name. What if it is a rebase or cherry-pick where the commits themselves are re-written but retain the original submitter's name?
The advice to have a CLA seems mostly valuable if you want to cash in on the work of an open source community while refusing to honour the intent of their contributions, based on this story.
It's simple but easy to overlook when buried in all the other open-source pleasantries, CLAs exist explicitly for the purpose of changing the ownership of an open source project.
Aside from the few token counter examples (most of which presuppose the FSF or poison pill clauses), there is almost no possible way to exercise that power in a way that benefits the project's contributors or users.
Not really. If your changes aren't controversial, you don't really need to get permission. Arguably some developer could demand their contributions are reverted, or sue, or whatever, but for all practical purposes no one will care enough.
Having an agreement isn't a no-cost option, it adds another barrier to contribution to a project.
You change from license A to license B to your project without asking permission of those that contributed under license A. Some party uses the code under B and violates B, but not A. Their attorney argues that you didn't have permission to re-license from all contributors, so the switch wasn't possible.
You try to contact all developers that committed under A. Sadly, one of them died a year ago. To add a problem, that person lived in a legislation where you cannot give away authorship.
Suddenly, you are in a legal mess. You can choose to follow through or drop the case.
It's worth noting that Mojang never actually changed the EULA. You've never been able to make money from Minecraft. They clarified it to allow monetisation of Let's Plays and their ilk, while ensuring that pay-to-win servers were definitely a no-no.
It's also always contained the Do Not Distribute term. Bukkit has always been in the wrong here. It's not the EULA clarification that did that.
A bit OT but who are all these people making the mods? It seems really complicated and I'm impressed great developers choose to spend so much time on it. What's the incentive?
I've talked about this a few times, but I was there at the start of Bukkit, and though I haven't touched it for a few years I still think back to it now and then.
The motivation was many faceted, but the basic impetus for most people in the server mod world is that the vanilla server was so inadequate for running a server.
I got involved with a small server, and (quickly! that was a mistake haha) started to help sysadmin the box. I got us on to hMod, which was terrible in many ways but provided a vision for the future - a central, modded server, with plugin points that proffered server admins incredible flexibility configuring their servers.
hMod was run by a single (apparently inexperienced) dev, and the community grew too quickly for him so bukkit was formed.
By this point I had started contributing to hMod, but realised it was a sinking ship and switched my efforts to bukkit. It started as trying to build plugins for our server, but as I started getting commits into the core project it quickly ramped up into full on team participation.
The dev team was really really fun to be a part of. I was on mumble and irc all day talking to the other devs, and would often spend over 8 hours working on code or talking about plans. Upgrades were hectic, and everyone pulled long shifts when they happened.
As time went on and the community grew it became more like a real job, and momentum kept me going for a long time. Eventually I actually got a real job, and my participation waned.
I can't speak for others, but my motivation seemed to be a spectrum that started with scratching an itch end ended with the satisfaction of contributing to a community; the knowledge that your code is being used by thousands, if not millions, of people.
Many people set up servers so they and their real life friends can play in the same world together in real time. That way, you can both work on building a house, or a city or a world.
Larger servers have complex mods that add tremendous functionality to the game. Some may have roleplaying mods, where you can find a role (blacksmith, lumberjack, etc) and participate in the economy. Others may set up a world just for pure creation, a way to make sculptures.
There's a lot Minecraft has been extended to, so there are many reasons you may have to set up a server.
You can either join a server someone else is running, or you can set up your own server.
The Minecraft software had severe limitations around things like "griefing protection" (preventing people causing havoc); charging for stuff (which is one way servers used to raise funds); or minigames.
I used to be into 'modding' when I was sixteen, and the project I worked on turned out quite successful. In fact, some of the core team went on to work for Valve based on this (and later) mods.
Looking back, I suppose it was a bit odd that there was a group of people, most of them quite a bit older than me, who spent large amounts of time working on this project.
From the bits and pieces of personal information that I gathered about my team members, many of them, including the team leader, had 'proper jobs'. One of them actually worked as a lead level designer on a triple-A game.
I got the impression that they spent all this time on the modification because they loved building games, they loved not being constrained by budgets or non-passion related factors, they wanted to build up a portfolio to find a way into the gaming industry, or 'all of the above'. And it worked for some of them.
I'm not sure if this is the case for a majority of 'modders', but I suspect the reasons I mentioned are quite common. If you love developing things, a game is a really great thing to build. It's, ultimately, purely about fun and joy. It doesn't have to be useful. That might be enough for those who work on (boring) useful stuff during the day.
Gosh I miss hacking on GoldSrc. I was 14, running a pirate version of VC++ and spending every damned afternoon working on various mods and the like. I ended up going into web development, but my heart still lies in game dev, so thats what I do in my spare time.
Same here. After taking a detour in my college years I ended up doing web development, but I still miss designing, building and balancing levels and seeing tons of people enjoying the results of my labor! Might get back into it...
Why make any art? For the love of the game. To scratch the itch. People generate ideas all the time, and most of them never go realized... is it any wonder that people contribute to somebody else's project just to see their ideas given form? Same principles as open-source, but without the protection of open-source.
Which, of course, is why modders should be encouraged to use platforms where you retain greater control of the project, which is why I'm a fan of OSS gaming.
Yeah, they were too, it seems; there a slide asking the author himself whether the code, the copyrights, the logos, or just what exactly was sold. No answer was provided.
As far as I understand it, things owned by the Bukkit team (i.e. servers, bukkit.org) and the rights to the code owned by the 4 core devs who were hired.
I wish people would tell you what's wrong with your comment instead of downvoting you into oblivion. Sorry, sometimes HN sucks.
There's a great difference between selling access to your software and selling your project itself, i.e. the copyright assigned to your code and/or logos, trademarks, etc.
Are there any particularly good comparisons of OSS licenses in terms of facts as well as perception?
I regularly see comments on one project or another pointing to a XYZ license as the reason a project failed / has few contributors as if the 'problem' with that particular license is entirely self-evident.
It's awfully confusing as I'm sure I've seen polar opposite opinions on every major license under the sun, each entirely bereft of context.
If you want the facts, tldrlegal looks like a terrible source (except for the original license texts), and will no doubt contribute to the confusion with its vague, misleading and incomplete tl;drs.
Okay it contains the Minecraft server binary, remove it. If it's the issue then it's no longer an issue if it's the user that download it themselves (I'm pretty sure it was working like that in the past).
Is it the signatures of the methods from the official server? Is it really an issue? Isn't all GPL project full of methods signature and call to windows binaries?
Slide 41 is amusing. The list of example GPL software is headed with the GPLv3 logo, yet none of the examples are GPLv3. Three of them are GPLv2, and one is AGPL (acknowledged in the list).
To me, it looks like Bukkit was doomed to fail from the beginning. Bukkit created an LGPLv3 project based upon proprietary, decompiled Java class files which is a copyright violation, afaik. Reason #4 for failture states that not having a CLA was a problem. Bukkit certainly seems to have had many problems, but a CLA would have just been one more.
Minecraft forge http://www.minecraftforge.net/ (mainly used in the feed the beast modpacks)is still alive and kicking. Only downside is that they don't have a clojure wrapper.
GPL3 seems to be the biggest issue here. It's basically the single worst license you could pick for something who's entire basis is hooking to closed source code.
All that said I'd be very interested to see this play out in court, not to imply that it will get there. I feel strongly that the developer forfeit his control of the code on contributing it to the project. I can't say for sure though, I'm not a lawyer.
A few comments say things like "they shouldn't include the binaries" or "why can't they just link to the binary, let the user download it themselves" etc.
There may have been a way to achieve that (and we talked about a few of them quite a few times) but it was never as simple as just 'linking to the binary'.
The Bukkit project was actually composed of a few different pieces, designed to make maintenance of the mod manageable across upgrades of the game. This architectural change was one of the main reasons Bukkit split off from hMod in the first place.
There were 4 main codebases in play; the Bukkit API, the CraftBukkit server mod, the reverse-engineering-tools project, and various plugins supplied by the Project or for use as examples.
I go into more detail below, but the reason why just hooking into the binary was so hard is two fold, and meant that CraftBukkit could never really just be a server wrapper.
1. Methods, method calls, and program logic needed to be modified directly to enable things like turning off fire on the server. Anytime the game tried to start a fire CraftBukkit had to fire an event, and allow that event to be cancelled. So CraftBukkit had to be a mod in the purest sense.
2. Obfuscation meant that modified files had to be translated every single upgrade. To reduce this burden large swathes of the code was de-obfuscated, so that the upgrade process was de-obfuscate core code -> translate any mod changes that used obfuscated code -> apply mod changes on top of the core code -> fix the thousands of bugs we missed in the translate step. So much of the mod was on top of this de-obfuscated version of the server that any distribution would require distributing large amounts of de-obfuscated code - there was no other source for this.
So there may have been ways to avoid shipping Mojang code, but it was always going to be a hard slog. When the core team started conversations with Mojang it always seemed like there was never a pressing need, and as I understand it Mojang still hasn't shut down Bukkit. It was a lone developer asserting a DMCA take down.
I would be very interested to know if there is a better architecture that solves these problems, some more of which I have listed out below.
==== More Details ====
The Bukkit API consisted of JAVA interfaces, providing a stable(ish) API against which plugin authors could build plugins, and some glue code to manage the plugins. This had no code from Mojang in it.
The various 'official' plugins were coded against the API, and similarly had no Mojang code in it.
The reverse-engineering-tools project was used to, perhaps unsurprisingly, reverse engineer the official server. A lot of the code had been de-obfuscated, but that de-obfuscation was usually a painstaking task performed by hand. These tools made that process much easier. It included a decompiled version of the official server code, but the project was private and wasn't distributed. Not sure how that impacts everything.
The CraftBukkit server mod of course DID contain Mojang code, the modded server. It's job was to implement the Bukkit API.
The API was almost entirely event based. Plugins would hook on certain events, and the server would wait for the plugins to process the events before continuing with whatever it was doing.
Someone tries to set a house on fire -> LightFireEvent is fired -> NoFire plugin hooks the event -> NoFire plugin cancels the event -> in game no fire is lit.
In order to implement these events, entire code paths within the game need to be diverted, hooked in to, subverted, or replaced. There are lots of ways a fire might start, so we had events triggering when lava ignites a block next to it, and explosion sets some grass on fire, someone uses flint to light a tree, etc. Each one requires
* finding the obfuscated code path that implements the feature we want to hook
* de-obfuscating the code so it is clear(er) to see how to modify it correctly
* modifying the de-obfuscated code to introduce the hooking code, and implement the API
Every time there was an upgrade to the server we would have to map every modification made to the new obfuscated code base. So if CraftBukkit had modified or included a call to an obfuscated method (which happened often enough for it to be a pain) then those changes had to be mapped to the new method signatures of the upgraded server. c(wx, f, b, 23) might now be e(ww, f, b, 23) and translating that to a modified code base can be hell.
The Bukkit team took that process on itself, which is one of the reasons it was so successful. As long as the API points used don't change, a plugin will continue working as soon as CraftBukkit is upgraded.
>So much of the mod was on top of this de-obfuscated version of the server that any distribution would require distributing large amounts of de-obfuscated code - there was no other source for this.
How much of the updating and deployment tasks could be done by a script on the user's computer/server? Decompile with MCP and pull in all the changes as patches, like the Craftbukkit github was when I saw it?
Yeah, as I mentioned we did talk about it a lot. As it seemed like a lot of work, and since mojang had turned a blind eye, the effort never seemed worth it. The core team got bought before it all came to a head, otherwise you might have seen a greater effort to separate the code bases.
I'll have to look in to forge, I haven't yet seen what they are doing, but it sounds interesting.
EDIT: the other aspect was the fact so much code was written against the de-obfuscated version of the code base. There's an argument that distributing that patch would also be distributing mojang code.
So it failed just because of the stupid outdated law system - just like many other great ideas.
Maybe it's just my idealist part, but isn't it a shame so many efforts (or much effort? not sure) in this world went to waste just because of blabla you can't distribute or blabla you cant build upon... This is digital millenium, wake up!
Of course it can be frustrating, if you can't build upon a project, if you have an idea that you want to realize. I'd say you have to look at this from the other side. Well, you can't blame people for building upon your project as long as they don't publish or distribute it but would you be happy if somebody distrubutes a better version of your product because he's allowed to build upon its source?
Granted, Mojang did make a lot of Money with Minecraft regardless but especially with open source projects building on other open source projects or especially non-profit projects in this case, this would be really problematic.
Developers don't need to wake up, they just need to put in the effort to chose the right license and make everybody who wants to contribute to their project agree with licensing their own code under said license.
> would you be happy if somebody distrubutes a better version of your product because he's allowed to build upon its source?
If it weren't for projects that make better versions by building upon others' source, I wouldn't be here. Hopefully in the future someone will also find my code good enough to build something upon.
The talk seems to focus on license as the resolution - and it's an important point. However important licenses are, they aren't as important as not linking third-party closed-source binaries in your "FOSS" project.