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.
Apache 2 or MIT would be the most permissive.