I'm confused what selling an open source project would even mean in this context?
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.
Kicking the Bukkit: Anatomy of an open source meltdown
31–40 of 59 posts
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#32Are 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.
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#33Are 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
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#34Bukkit 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…
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.
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#35The 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 also important when you want to make any changes without tracking down everyone who ever contributed.
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.
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#36I'm confused what selling an open source project would even mean in this context?
For example, RedHat, Cisco, Suse (Novell), Alfresco, Wordpress, Drupal, etc. Can sold their Free Software project. You can have it free. And it's ok. But having success is possible too (recheck my examples). You can refuse to pay. But, if you want support : $$$ for value++. (you just buy the brand) See this for more info https://www.gnu.org/philosophy/selling.en.html
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.
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#37To 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.
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#38GPL3 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.
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#39Earlier quoted context omitted.
It's also important when you want to make any changes without tracking down everyone who ever contributed.
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 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.
Re: Kicking the Bukkit: Anatomy of an open source meltdown
#40Bukkit 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…
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.
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.