Hacker News Reader

Comment by andrew_deane_ | Hacker News Reader

Today bet365 have signed the agreement to purchase all Basho IP. We expect the agreement to be ratified in the US courts next week. Once cleared, our intention is to open source all code, help rebuild the community and collaboratively take the development of RIAK forward.

In the coming weeks we will hopefully answer the questions people have and will be calling on the community to help forge the initial RIAK Roadmap.

One of the initial questions we have for the community is which OSS license would people like applied to the code? Our thought is the most open and permissive.

View on HN

GPLv3, as it protects from patent trolls and also encourages creating an better ecosystem.

There are companies that refuse to use GPLed code. They want to modify and then sell closed forks of your product, without paying you, and by doing so they fragment the userbase. GPL prevents this.

If you want to allow them to do so you can always switch to BSD or dual-license - perhaps after a private agreement and if you find the companies reputable.

Would make sense to use the same license as Erlang - Apache2

Fantastic news! I just used Riak Core for making a multi-master service. It was impressively straightforward! Glad to hear there are people intents to continue the project as OSS.

Will this include the Basho technical documents? Much of the better technical documentation lives on basho.com and was returning 404's.

[edit: and a +1 for Apache V2 (or MPL)]

https://www.tiot.jp/riak-docs/

Great! There aren't that many persistent (disk-based) KV-stores out there. I planned to, but didn't get to actually use Riak, and was sad when the company seemed to go down.

As far as licensing goes, it would be great to have one that would allow me to link the client code libraries and run the servers without having to worry about anything. If I understand correctly, Apache2 goes way beyond that, while GPL is somewhat ambiguous on that. (Yes, one could implement their own client, but that'd be reinventing the wheel).

Thank you for keeping this work alive!

GPLv3 and Apachev2 are the best in regards to dealing with patents.

Please don't do GPL – It's a no-go and too restrictive for a lot of organizations.

Apache 2 or MIT would be the most permissive.

You mean its a no go for a company to go away with the work of others without giving credit beside naming?

Strange world we are living in ...

As I replied below, the distinction between libraries and servers is a good one. I was too extreme in my statement without making that distinction.

For libraries, yes, absolutely, companies should rightly be cautious, because it's relatively easy to expose yourself to legal risk.

Nobody is "going away with the work of others" – the whole point of a license is so contributors decide how others can use their work. What exactly is the issue here?

GPLv3 is for a lot of companies too aggressive on requirements around patent defense, etc. Though many were never fond of the copy-left nature of GPLv2(and 1), they allowed it. GPLv3 upped the bar, to a degree that many lawyers won't sign off on its use.

Apache 2.0 is the standard for almost every company I've dealt with, with MIT and BSD 3 clause being accepted as well. But Apache 2 seems to make most lawyers happy.

You say the GPLv3 is too aggressive on requirements around patent defense, but the Apache 2.0 is okay? The Apache 2.0 license requires a patent grant. How do they differ in the patent grant?

I'd speculate that for many companies the GPLv3 is too strong in its copy-left stance, by disallowing Tivoization.

GPLv3 patent text was created by literally copying the part from the Apache 2.0 text, and then adding a paragraph to handle patent agreements such as the one between Novel and Microsoft.

The distinction between the two text is case of paten agreements.

If your organization uses any of: Linux, Android, emacs, gcc or any GNU utility, OpenJDK, or MongoDB, then GPL is clearly not a no-go. GPL only poses issues when the product is a library. For standalone products or ones with linking/access exceptions like OpenJDK, GPL poses no issues, and organizations aren't afraid to use it, especially when they don't intend to modify it.

GPL is a great license that ensures that improvements to the product are shared back with the community. In fact, for a database like Riak, Affero GPL, like the MongoDB license may even be better, as organizations that make improvements to Riak but don't redistribute it but run it internally on their servers would also be required to contribute back their modifications.

> If your organization uses any of: Linux, Android, emacs, gcc or any GNU utility,

Two things wrong with this right off the bat. First, not all of these are GPLv3, which is the version with the problematic patent clauses that scare companies away. Second, it is not just in libraries that the GPLv3 is generally accepted to pose potential issues. You need look no further than Apple and the great investment they went through to avoid ever shipping GPLv3 software. The GPL kicks in as soon as you distribute the software.

> First, not all of these are GPLv3, which is the version with the problematic patent clauses that scare companies away.

So, if Linux were GPLv3 you're saying that most companies wouldn't use it?

> You need look no further than Apple and the great investment they went through to avoid ever shipping GPLv3 software.

Most companies aren't like Apple.

> The GPL kicks in as soon as you distribute the software.

That's right, and that's a good thing. If you distribute GPL software that you modify, you need to make your modifications public. But as Riak is not a library, it does not infect any other component. If you distribute software with (say, Android) Linux but don't modify Linux then the GPL doesn't infect the other components of your software, as they're not actually linked (or Linux has some explicit exceptions).

> GPL only poses issues when the product is a library

What about the client libraries? Do you consider them to be a part of the product? It might make sense to release the client code (library) and the server code under different licenses (Apache2/GPL, respectively) if GPL is to be used.

> It might make sense to release the client code (library) and the server code under different licenses (Apache2/GPL, respectively) if GPL is to be used.

Yep.

That's a valid point, GPL is especially scary for libraries, less so with server software. Maybe I was a bit hyperbolic. :)

I think APACHE-2.0 is probably the best for end users in terms of acceptability in enterprises etc. A lot of places have issues with the virality of GPL licensing.

Seconded on Apache-2.0 - it's what we use. GPL is not attractive to enterprise and will limit the adoption of the tech.

Anecdotally, those who decide to use GPL don't like the results - users are afraid to extend functionality, and conscientious extenders provide code that specific to their use-case and that can't be used.

I think the GPL worked brilliantly for forcing companies to e.g. contribute gcc ports to the commons.

But that doesn't mean it would work for most projects.

-1 on GPL. Apache 2 generates very little friction.

Riak and riak core are already Apache 2. Sounds fine.

https://github.com/basho/riak/blob/develop/LICENSE

https://github.com/basho/riak_core/blob/develop/LICENSE

Like BSD or MIT licenses? That would be great.

Apache 2 is probably the best choice here to avoid potential future issues related to patents.

Reply on news.ycombinator.com