Hacker News Reader

Comment by RKoutnik | Hacker News Reader

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.

View on HN

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.

> 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.

Minetest is LGPL, btw.

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?

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.

Reply on news.ycombinator.com