Slashdot Mirror


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

4 of 219 comments (clear)

  1. Re:Yawn, another fork by jythie · · Score: 4, Informative

    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.

  2. Re:Yawn, another fork by Xtifr · · Score: 4, Informative

    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.

  3. Re:lol by dgatwood · · Score: 4, Informative

    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.

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.

  4. Re:Yawn, another fork by Just+Some+Guy · · Score: 4, Informative

    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.

    --
    Dewey, what part of this looks like authorities should be involved?