Hacker News new | ask | show | jobs
by RKoutnik 4266 days ago
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.
3 comments
belorn 4265 days ago
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.

link
scourge 4265 days ago
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.
link
clarry 4265 days ago
> 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.

link
krisdol 4265 days ago
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.
link
clarry 4265 days ago
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.
link
forgottenpass 4265 days ago
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.

link
davexunit 4265 days ago
Minetest is LGPL, btw.
link
enneff 4265 days ago
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.
link
coldpie 4265 days ago
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.

link
sanderjd 4265 days ago
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?
link
davexunit 4265 days ago
I couldn't disagree more. CLAs are a terrible idea. See http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.htm... for details.
link