Oracle Quietly Switches BerkeleyDB To AGPL

WebMink writes "A discussion in the Debian community reveals that last month Oracle quietly disclosed a change for the embedded BerkeleyDB database from the quirky Sleepycat License to the Affero General Public License (AGPL) in future versions. AGPL is only compatible with GPLv3 and treats web deployment as a trigger to license compliance, so developers using BerkeleyDB will need to check their code is still legally licensed. Even if they had made the switch in the interests of advancing software freedom it would be questionable to force so many developers into a new license compatibility crisis. But it seems likely their only motivation is to scare more people into buying proprietary licenses. Oracle are well within their rights, but developers are likely to treat this as a betrayal. As a poster in the Debian thread says, "Oracle move just sent the Berkeley DB to oblivion" because there are some great alternatives, like OpenLDAP's LMDB."

Comments

Yawn, another fork

[binarylarry]

BrownDB will now be created to complement MariaDB and the other forks Whoracle has forced with their greed.

Re:Yawn, another fork

[rwven]

The problem isn't the AGPL (though it's a pretty horrible license in its own right). The problem is the license change, the reason for the change, and how the change will adversely affect people who currently use the product.

They're very different things.

Re:Yawn, another fork

[fuzzyfuzzyfungus]

Using the AGPL is being "greedy"? Isn't that the very license the FSF recommends for software run over a network? MongoDB is also AGPL and there was none of this drama directed at 10gen over it.

LOL hypocritical freetards.

I'm going to make the optimistic assumption that you aren't merely trolling: AGPL is, indeed, what the FSF recommends for software likely to be used primarily on backend-type stuff(where conventional GPL, even v3, does nothing to stop the formation of an in-house mostly proprietary setup).

Oracle, however, is in the business of selling database software, not of being the FSF. So, when they take an existing database and re-license it in ways that are calculated to force existing users of that database to either leave or stump up for a proprietary license from Oracle, they get called 'greedy'.

This really isn't all that difficult.

Re:Yawn, another fork

[jythie]

Niche is a tricky description since BerkeleyDB tends to lurk in the underbelly of projects. MySQL you can see running, but Berkeley you generally do not know if a project is using it unless you look through the library linkage and cat a bunch of data files.

Re:Yawn, another fork

[Phs2501]

The MongoDB core is AGPL. Its drivers are all Apache license, as explained here, therefore not polluting your web application code and forcing it under the AGPL.

BerkeleyDB, on the other hand, is linked in directly, and would force anything using it to be under the AGPL.

Re:Yawn, another fork

[Xtifr]

BerkeleyDB seems to be a niche product and according to TFA

It comes standard with Perl, Python and Java, among many other things. It may appear niche because it rarely gets much mention, but it's pretty much been the standard tool used for persistent associative arrays for a long time. Of course, it's also fairly generic, and eminently replaceable. I agree that this is unlikely to be a huge problem.

Re:Yawn, another fork

[Goaway]

And, you know, anyone who wants to actually have bugfixes and updates.

Re:Yawn, another fork

[Just Some Guy]

Up? Sideways. They both fit in the same solutionspace of "internal, in-process databases" but serve utterly different use cases. BDB is sweet when you want a key-value store. SQLite is awesome when you want a relational DB with an SQL frontend. Neither is better than the other because you wouldn't really use them for the same problems.

Re:Yawn, another fork

[Just Some Guy]

It will only affect people distributing less free software.

...for certain bizarre-ass values of "distributing" that include "running on their own server but allowing external users to interact with it".

Re:lol

[dgatwood]

AGPL is not good. AGPL is horribly evil. It means that I, as a sysadmin installing a piece of software, cannot make changes necessary to tailor it to my particular site configuration without releasing the source to those changes, even though those changes cannot possibly be of any use to anyone outside my server team except for attackers wishing to discover security bugs, learn the names of database tables, etc. for nefarious purposes.

I don't know about anyone else, but I personally have an absolute zero tolerance policy for Affero. It has no valid place among reasonable open source and free software licenses, as it is the antithesis of software freedom.

Re:Wait.. let me get this straight...

[Xtifr]

It already was GPL-compatible, so that part hasn't changed. They've gone from a more liberal license (the old license was compatible with, among other things, the GPL v2) to a less liberal one. That's always going to piss off some people. Just look at the controversy when a project goes from BSD or MIT to GPL.

Re:License drama

[Xtifr]

Has anyone ever been sued over an open source deployment done off license?

Um, yes, it happens all the time. The owners of BusyBox, for example, have not only sued, but won several cases, for example. And Oracle sued Google, in part because Google's Dalvik was under a less restrictive license than Java's GPL—and they only lost because Google was able to show that the parts they actually copied (the API) weren't subject to copyright. But that's a clear precedent for worry about what Oracle might do.

Re:lol

[dgatwood]

PHPB is precisely the sort of situation where AGPL is unacceptable, because it infects code that has no legitimate association with the software itself. For example, on a website that I run, I currently use a heavily customized PHPBB setup that hooks into the (non-open-source) login system used for the site that it is integrated into. None of those changes would be even slightly useful to anyone but me.

Further, without the ability to migrate the actual data, being able to replicate the service itself is basically useless, which means that putting something like PHPBB under a horrible license like AGPL would buy you absolutely nothing.

Basically, AGPL is only useful for a very, very narrow range of software designed specifically for use in "software-as-a-service" situations, and even then, it is only acceptable if you don't need to tie it into existing infrastructure. In short, it is basically never acceptable, and its only sensible use is for businesses to be able to say, "Hey, look, we've open sourced our stack," while simultaneously ensuring that no legitimate business would ever even contemplate replicating that stack and competing with them.

Re:lol

[harlows_monkeys]

The FSF has a definition of the term "free software".

Software under AGPL is not not free software according to that definition. It violates freedom 0.

Yet the FSF approved AGPL! This was an ethical disaster.

A key difference between free software licenses and commercial software EULAs was that the latter was a two way bargain. The copyright owner, who the law gives the exclusive right to make copies (including, for computer software, making temporary copies in RAM to use the software) grants you via the EULA permission to do that, in exchange for you agreeing not to do some things that otherwise would be allowed under copyright law. For example, you might have to agree to not reverse engineer the software, or to sell it when you are done with it.

The free software licenses, on the other hand, only grant you permissions. They do not require you to give up anything.

Until AGPL. AGPL goes beyond just granting you permission to do things that copyright law says require permission. It places restrictions on what you do with the software on your own machine. It is a EULA.