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."
BrownDB will now be created to complement MariaDB and the other forks Whoracle has forced with their greed.
Mod me down, my New Earth Global Warmingist friends!
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Not true, it has good use in webapplications. Think about something like phpbb where they want to release full code for it, but don't want people to modify it even if "only for their server".
AGPL is a perfectly fine license, and I use it myself for certain projects. I'm not sure it's quite appropriate for this case though.
It is intended to attack the software-as-a-service loophole in the GPL, which allows people to take software (e.g. WordPress Multisite) and because it never leaves the server it is running on, it's not being distributed, and so changes are not distributed. And so users cannot take the modified software and run it on their own server.
Like the GPL, the AGPL is a license for end users. It allows them (the end users) to ensure that they always have access to the source code of the software they use.
And frankly, I think that if anyone really cares, they can just fork from the last "good" version.
The only issue that I can just think of (and pointed out in the Debian thread), is that for software that uses the database, they may have to be re-licensed. AGPL is irrelevant though, it would still be the case if BerkeleyDB was re-licensed to GPL or another strong copyleft (OMG virus!) license.
Also, the Infoworld article is simply wrong. If someone uses BerkeleyDB for a webapp, they don't have to make the whole app AGPL, merely GPL3 (which means that if it's an internal only (not distributed) webapp, that nothing changes). Just because it is GPL3, it doesn't mean that it has to be distributed. Though, as pointed out, you can continue to buy a proprietary license if you want.
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
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.
From FSF's very own "Four Freedoms":
Freedom 0: The freedom to run the program for any purpose.
From the DFSG:
6. No discrimination against fields of endeavor
With this non-free piece of shit license, you can't take parts of the code and reuse them in about anything else than pretty much just a web service. Want a mail server (both exim and postfix use bdb)? An IMAP server? A networked lift control (don't laugh, I've seen a wifi-connected one)? An IRC bot? Sorry.
I'm a strong proponent of the GPL, but AGPL is a train wreck akin to GnonFDL (literal reading of which prohibits using a technology known as "door lock" from protecting your machine).
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
Are you sure the damage is just limited to the configuration changes you made? The attorneys in my organization believed that the language could be extended to anything that runs on the same set of servers, and anything that interacted with the same database.
And it's even worse for libraries (e.g. iText) - there, the thought was that it could require sharing every bit of code used to run the web site. Not surprisingly, we're not using or contributing to anything licensed under the AGPL.
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.
Actually, "Open with as much Freedom as possible" would be releasing the code into the public domain.
The entire purpose of a license, ANY license, is to place restrictions on what can be done with the code.
Your eyesight must be going because Oracle didn't build it
Oh, don't be pedantic, they bought the company that built it.
and the impact of a license change effects large numbers of non-commercial existing open-source projects.
If anything, it will impact closed-source adopters of those projects. Open-source projects, by definition, have no problem in distributing their source code.
Oh, it's relevant. The principle users of web software are the admins. They configure the software, they maintain the installation, they monitor what people are doing to it, etc. The GPL does something useful for those folks; it ensures that someone won't fork these tools, create their own versions of them, and sell them without giving their changes back. So it serves a useful purpose.
The AGPL, by contrast, adds additional restrictions on the site admins, but adds nothing of value for the so-called "users". Random website guests do not have direct access to the database (and it would be disastrous to give them such access), making their ability to spin off their own copy of the site largely moot except in very limited circumstances. And even if they somehow could get their data, for the most part, what makes a site valuable is usually the community, not the data, which means it would mostly be useless anyway.
In other words, it's a solution in search of a problem—maybe if someone were writing Google Docs under the AGPL... but nobody is ever going to do that, realistically—nobody sane, anyway.
Ironically, the software that Affero builds, given that it involves payment systems, is again precisely the sort of software where private customization is most crucial to the success of the software, and where again no end user could usefully take advantage of the changes anyway.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
Altering BerkleyDB has nothing to do with this. The existing Sleepycat license has always said that compiling against their libraries and distributing the result requires that you either release your application as open source, or buy a commercial license. You can't assume it acts like a GPL or BSD license, it's really aggressive in its own unique way. This is not Oracle taking a regular open-source product and giving it a restrictive commercial license. BerkleyDB always had such a commercial license clause. The change Oracle is making is mainly about closing the loophole where you could avoid even compiling against the database by building a SAAS interface to it.
He never said that. He suggested SQLite as an alternative to Berkeley DB.
He only suggested PostgreSQL if you have DB needs greater than what SQLite can offer, but that doesn't cover BDB; basically, he's saying that you can cover most of your database needs with one of those two databases: SQLite on the low end, and PostgreSQL on the high end.
They sued because they wanted people to use Java ME instead, but if they'd actually tried to sue over Java ME, the case would never have gotten as far as it did, because Dalvik was based on Apache Harmony, which in turn was an implementation of Java SE. Not ME. There was absolutely no copying from ME, either actual or even alleged.
The patent part of the suit was more strongly related to Java ME, insofar as the patent licenses for SE didn't apply to mobile devices. However, since Google wasn't practicing their patents, that also got them nowhere.
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.
I'll give an example of a use of AGPL. I develop game software with a handful of other devs. I'm the only coder. Prior to game release I license all my contributions under the AGPL so that if I quit, I can take my code with me. However, if they want to sell my code as closed source, they'll need to make it to completion and have me dual license under BSD. At that point we can sell a closed source version of the game software. At any time after sales begin, any member of the dev team can then release the source code as AGPL or BSD. So, there's no "we can't release source without rights holder permissions". We worked that out ahead of time.
In this way I don't have to trust anyone and they don't have to trust me. We do trust each other, but the system is future proof against falling outs (which is frequent in the indie game dev community). No one can just take their ball and go home -- Were I to leave the project I could still use the engine on other projects, and they could still make a game, and get another coder, but the end result would have to be open source. Compliance with AGPL is actually built into the game engine. In addition to containing an archive of the source as an asset during builds, any scripts or mods are necessarily transferred from the server to the client at run-time so that the game can function. A BSD licensed version can simply transfer pre-compiled bytecode instead of textual scripts, and remove the compressed source code from the asset library.
So, here we have a use case that's not exactly aligned with the intended goal of AGPL, unless a goal is to prevent anyone from benefiting from your code without you also benefiting from the additions too. It's actually directly opposite to your claim that I wish to prevent competition, I actually want to ensure competition can exist and ensure no complete loss of effort is possible. Sure, I run the risk of a team member bolting and releasing code under AGPL, but that doesn't prevent us from re-licensing as BSD down the road.
I'd love to release everything open source all the time (and do this for all software that's not game related) but it exponentially increases the number of cheaters in online games (don't give a damn about offline cheats). I've experienced this several times in online game communities, in both directions, closed to open, and open to closed. Until more effective community management systems are in place, games remain unique pieces of software where it's OK to not give users every tool they need to cock-up the game for everyone else (so long as the game respects the end-user, i.e., doesn't have non-features like DRM / spyware). One bad apple spoils the bunch, so griefers affect far more people than themselves. I agree that AGPL isn't the right choice for all projects, but to say it's never applicable except in some narrowly defined scope is just silly; I'm not arrogant enough to make such claims, I'm sure other use cases exist.
P.S. The saying "Security through Obscurity is No Security at all" is utterly false. All security is security through obscurity, and every bit of obscurity counts. 512 bits is 1/2 as secure as 513 bits of obscurity -- Obscurity increases security exponentially, DERP! If the obscurity was no hindrance then "open source" wouldn't even need to exist, eh? It's true that where there's a will, there's a way, so why not require sterner wills to brave harmful ways?