Live data from Hacker News

Kicking the Bukkit: Anatomy of an open source meltdown

slideshare.net

41–50 of 59 posts

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#41
I seriously doesn't understands the issue here.

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?

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#42
post #27
post #6

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 see…

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.

Minetest is LGPL, btw.

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#43
post #2

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?

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.

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#44
post #27
post #6

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 see…

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.

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#45

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 e…

tldrlegal.com is a really good resource

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.

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#46
post #2

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?

What's the incentive?

People can and do build things without dollar signs in their eyes.

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#47
post #12

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 di…

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

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#48
post #14

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.

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#49
post #39
post #35

Earlier quoted context omitted.

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.

Controversy isn't part of the equation here. 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…

spindritf said "make any changes"

coldpie seemed to assume s/he meant "any changes", not "any changes to the license"

Re: Kicking the Bukkit: Anatomy of an open source meltdown

#50
post #44
post #27

Earlier quoted context omitted.

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.
Post reply on HN