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

[Lonewolf666]

In this case, I have my doubts. MySQL was pretty popular, BerkeleyDB seems to be a niche product and according to TFA, the most prominent projects relying on it are already moving away.

I guess BerkeleyDB will simply disappear.

Re:Yawn, another fork

[Lunix Nutcase]

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.

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

[drinkypoo]

Using the AGPL is being "greedy"? Isn't that the very license the FSF recommends for software run over a network?

Sure. That's not what bdb is. You can use it to build software run over a network, though. If it should be changed to anything, it should be LGPL.

Re:Yawn, another fork

[Anonymous Coward]

BDB has been mostly replaced by SQLite for local, non-network based databases. And SQLite has been working well in many critical appliations. There is no market left for BDB except to migrate people off of it.

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

[Anonymous Coward]

It will only affect people distributing less free software. They should consider that a bug and fix it by license their software under a compatible license. There, problem solved and more free software to the world.

Re:Yawn, another fork

[AMDinator]

Because, you know, some businesses don't rely on closed-source software for their continued existence...

Re:Yawn, another fork

[angel'o'sphere]

A license change does not affect the people who currently use the product.

They still have the old license.

it only affects new "customers"/users.

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

[gl4ss]

it is kinda difficult, since as you say even when oracle goes by FSF's best practice for backend sw license they get flack..

Re:Yawn, another fork

[gl4ss]

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.

would anything limit you from making that part separate though? the performance hit wouldn't be that bad.

you could of course just use sqlite or something else..

Re:Yawn, another fork

[Goaway]

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

Re:Yawn, another fork

[rwven]

It absolutely affects them. If they want to upgrade to the next version, they are forced into a license that may be incompatible with their needs.

Re:Yawn, another fork

[fuzzyfuzzyfungus]

Eh, people saying mean things on the internet are a dime a dozen, I doubt Oracle cares very much. And(not that there's anything requiring them to) the fact that Oracle tends to get religion on the GPL only when they either wish to sell commercial licenses for a product, or to push people onto a commercial product, tends to make people rather mistrustful of their altruism.

Re:Yawn, another fork

[Tough Love]

I do not agree that "Whoracle" is being evil this time, quite the contrary, but I agree strongly with your point about forking. If it bugs you, don't waste bandwidth whining, just fork, it's your right. Even your duty, if you want to be honest.

Re:Yawn, another fork

[guruevi]

Yes they do but the fact remains that this is a horrible business model. Someone, somewhere has already built an open or cheaper alternative to whatever software you can think up.

Re:Yawn, another fork

[Anonymous Coward]

Python no longer ships the Berkeley DB module (it's still in 2.x for compatibility reasons, but is considered deprecated in 2.6 and 2.7 and was removed in 3.x). Perl only ships with support for Berkeley DB 1.x; you need to download a CPAN package to get support for anything newer. And I cannot find anything about Java shipping with Berkeley DB. It may have been the standard 10 years ago, but it hasn't been for quite a while.

Re:Yawn, another fork

[Richard_at_work]

Are they owed those things?

Re:Yawn, another fork

[jbolden]

I agree with you it is niche. It is sort of one step up from SQLLite. There are other options today but it is a good fit for that "I don't want to force a database server but I need some storage..."

Re:Yawn, another fork

[jbolden]

I agree. It isn't being "greedy". This is something the /. crowd should applaud.

Re:Yawn, another fork

[jbolden]

I should say though I don't really have any problem with Oracle making Berkley a good AGPL product, MySQL a good GPL product and Oracle a good commercial product. Berkley's big usage was the scripting community and it wouldn't shock me if many of them are comfortable with the AGPL. In some way by ditching the commercial and semi-commercial customer base they allow Berkley to focus on an easy to support niche which doesn't have conflicting interests with Oracle.

Oracle could move Berkley over to other groups like their development tools group who might get along fine with the Perl / Ruby / Python crowd.

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

[greg1104]

The FSF's best practice for software licenses involves zero license fees, always. There are multiple practices the FSF follows that people accept only because they are the FSF. Copyright assignment is another thing the FSF can do, but when it's adopted by a commercial company it's presumed they are violating the spirit of free software by taking contributor work into a private commercial version. The exact motives and license recommendations of the FSF may change over time, but they are transparent and as consistent as they can be. When a commercial entity emulates part of their behavior, but they add a profit motive and license inconsistency, they are not acting like the FSF anymore at all.

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:Yawn, another fork

[Anonymous Coward]

There's nothing bizarre about it. You are distributing the software. Just because there used to be a loophole where someone could distribute free software without distributing the source doesn't mean that always has to be. It was a bug and the bug was fixed.

Re:Yawn, another fork

[angel'o'sphere]

You see: "want" and "forced" are at a very distributed end of the spectrum.

Re:Yawn, another fork

[jbolden]

That's a good clarification of my answer. You are right there.

In terms of up I was thinking speed. I know there are a lot of complex issues about contention and... but Berkley is under most conditions way way faster.

Re:Yawn, another fork

[angel'o'sphere]

My point was: everybody seems to believe that changing the current license affects stuff that already *is* licensed.
It does not.
On top of that: they switch from one open source license to another one.
I hardly see a reason to even make a /. article about this.
You use a software someone else has written. You payed nothing for it. Why do you complain? Do you have a god given right(priviledge) which I'm not aware off?

Re:Yawn, another fork

[drinkypoo]

I agree. It isn't being "greedy". This is something the /. crowd should applaud.

I'd applaud a switch to LGPL, but I will not applaud a switch to AGPL. The first is laudable, and should be applauded. The latter, what they have actually done, is (ironically) an assault on Free Software, because it will force downstream projects to change licenses or libraries, or to deal with a fork.

The only good news is that a fork should be forthcoming shortly.

Re:Yawn, another fork

[rtfa-troll]

And, you know, anyone who wants to actually have bugfixes and updates for BerkleyDB from Oracle .

TFTFY. And you will notice it also became a much smaller problem.

Re:Yawn, another fork

[RulerOf]

Yes they do but the fact remains that this is a horrible business model. Someone, somewhere has already built an open or cheaper alternative to whatever software you can think up.

There are cheaper, open source alternatives to Windows. Its closed-source nature can't really be a horrible part of Microsoft's business model if it's profitable.

I'd like to see Windows (more specifically, the NT kernel itself) be both free and open source, but that has nothing to do with business.

Re:Yawn, another fork

[Dcnjoe60]

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.

Wait, if BerkelyeDB comes standard with Java, does that mean Java is going to be AGPL instead of LGPL?

Re:Yawn, another fork

[Dcnjoe60]

You see: "want" and "forced" are at a very distributed end of the spectrum.

Which is probably why the summary says the change will killoff BerkelyDB. To avoid being forced into the new license, people will continue with the old version. Of course, if they want bug fixes and new features, then they have to choose between using the new new license and BerkelyDB or swiching to some other database that doesn't make them make such choices.

Re:Yawn, another fork

[AMDinator]

Not necessarily. Embedded systems, for example, can absolutely rely upon closed-source software for which there is no open/cheaper/comparable alternative. I posted my reply while on break from working on such a very thing. The company's growing rapidly and raking in $$$. I fail to see how they have a "horrible business model".

Re:Yawn, another fork

[MichaelSmith]

Berkeley DB is often used as a back end for MySQL.

Re:Yawn, another fork

[jbolden]

The latter, what they have actually done, is (ironically) an assault on Free Software, because it will force downstream projects to change licenses or libraries, or to deal with a fork.

It only does that for non Free Software. Free Software doesn't have a problem with AGPL.

Re:Yawn, another fork

[batkiwi]

Only if they take updates as opposed to forking it.

You cannot remove a license from something you've already released.

Re:Yawn, another fork

[Anonymous Coward]

Or, third option: fork the Berkley DB code, and maintain that fork and carry on with business as usual.

Re:Yawn, another fork

[Goaway]

Generally, it is considered ethical to provide people with bugfixes for code you are responsible for.

Re:Yawn, another fork

[Goaway]

I am confused. Did you think I was ever referring to anything other than exactly that?

Re:Yawn, another fork

[Marillion]

Sometimes SQL is too much for simple problems. The soul of what BerkeleyDB is has always been about being world's most rock-solid embedded single-process key-value pair storage in the world. The besides being very high quality, the liberal license was the other key key factor to its wide adoption. Wikipedia has a partial list of applications that use it. Now that BerkeleyDB has a stricter license, it is un-embeddable for many current users.

I'm really hoping for a fork.

Re:Yawn, another fork

[Anonymous Coward]

It's still an issue though. I just deployed a logging platform built around Graylog2. Graylog2 has a dependency on MongoDB. MongoDB is AGPL. The lawyers hated that; I had to do battle to get MongoDB cleared for use. In the end they decided we were covered because another group in our business already had a commercial license with 10Gen. If we didn't already have that, I never would have got it cleared and I wouldn't have been able to use Graylog2, which would have been a crying shame because it's damn good and it's not even licensed under the AGPL.

When your license makes lawyers nervous, you may have gone too far (and for the record, our lawyers are Class 1 A-OK with GPLv3. Just not the AGPL.)

Re:Yawn, another fork

[Anonymous Coward]

Lawyers have a problem with AGPL, which in turn can have an impact on people even deploying Free software. AGPL can actually drive people towards non-Free solutions.

Re:Yawn, another fork

[Lisias]

Generally, is considered ethical being paid to provide people with bugfixes for code you are responsible for.

From the GPL:

15. Disclaimer of Warranty.

    THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

    16. Limitation of Liability.

    IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.

It's NICE to have the product's owner providing you with bugfixes. But by no means it will be unethical if he/she/it stops doing that - when it's the case, go code your own fixes or pay someone to do that for you.

Re:Yawn, another fork

[jbolden]

Lawyers have a problem with AGPL, which in turn can have an impact on people even deploying Free software.

Absolutely. But lawyers will only have that problem for companies that are using their own commercial stuff in combination. It does nothing to companies that are open. As an aside many people faced those same issues with the GPL in the mid 90s and early 2000s.

AGPL can actually drive people towards non-Free solutions.

It is meant to. It is meant to make it very difficult to link to free software and keep your own source closed.

Re:Yawn, another fork

[Anonymous Coward]

lawyers will only have that problem for companies that are using their own commercial stuff in combination

Nope. See my other comment. A 100% Free Software stack that was nearly, and still could be, torpedoed because of the AGPL.

Lawyers literally break out in hives at the mere mention of AGPL. GPLv3? Fine. Hell, we're one of the largest contributors to a VERY well known Open Source project: at this point we must have more than 50 developers contributing patches upstream. Even against that backdrop, the AGPL is like the 3rd rail of Free Software licenses: touch it and you die. It's counter productive.

Re:Yawn, another fork

[Anonymous Coward]

Berkeley DB is often used as a back end for MySQL.

[Citation needed]

Re:Yawn, another fork

[jbolden]

Well OK I see your story, but your story doesn't make much sense. If you already release the code the AGPL doesn't ask you to do anything else. So what were they worried about? Lawyers usually give a more detailed analysis.

Re:Yawn, another fork

[idunham]

Picture this:
You throw a Python script that uses BDB on your server, which happens to use a source-based distro.
You update BDB, and this requires a small patch.

Now, you are obligated to distribute source to BDB and Python.
No, I'm not kidding: that's how I read the AGPL.

http://www.gnu.org/licenses/agpl.html:

A secondary benefit of defending all users' freedom is that improvements made in alternate versions of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation. However, in the case of software used on network servers, this result may fail to come about. The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.

The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

Re:Yawn, another fork

[Anonymous Coward]

Since it is possible that you might have modified the installed version of BDB and Python it is just reasonable that you have to distribute them as well. Otherwise we could end up in situations where the source code is distributed, but effective made non usable by depending on modified versions of free software that is not distributed.

Re:Yawn, another fork

[unixisc]

Open Source is the horrible business model: shared source is what's good. Open source licenses prevent an ISV from legally preempting downstream re-distribution, thereby ensuring the potential of initial customers becoming competitors. Shared source, OTOH, allows customers to reap the benefits of open source, while protecting the financial interests of the ISVs.

Re:Yawn, another fork

[Lonewolf666]

Oracle as owner of the copyright can re-license new versions in whatever way they want. The only thing they cannot do is remove the old license from copies they have already distributed.

Re:Yawn, another fork

[Anonymous Coward]

Our platform is built on top of hundreds, if not thousands, of components. The healthy majority of them are FOSS and we contribute back, but we do have some closed components that we don't release the code for, and apparently our lawyers would quite like to keep it that way.

We'd also have a hard time selling our software on to customers if it contained AGPL components, because that then ties them into the rather onerous and obnoxious definition of "redistribution" that the AGPL imposes.

Re:Yawn, another fork

[jbolden]

Some closed components is a closed system. Most of Oracle, the scripts, are open source. Oracle could probably Open source 95% of the engine given all the stuff in their architecture guides without revealing a single secret. It would still be a closed source database. Similarly if customers are concerned about redistribution then they want to be closed.

The AGPL is designed to prevent exactly your use case. That's not a bug, it is doing exactly what it was designed to do.

Re:Yawn, another fork

[guruevi]

And in the real world, how much times has that happened? Unless you are already selling to your competitors, you have nothing to fear and even then, for your competitors to be competitors, they would have to have something similar in place already that is sufficiently different to make a difference in the market. Your customers don't have a clue about your software nor will they be selling it because it's simply not their core business nor something they are competent at supporting (which is where the money is). Even in the closed source world, you'll see companies being way more profitable selling support than licenses because licenses you'll sell once and if it's expensive enough, they'll use it for 10-20 years eventually becoming a support nightmare for your company, if the license is cheap and the support reasonable, they'll buy it every year and your company will only have to support one of the more recent-ish models.

Re:Yawn, another fork

[guruevi]

Oh and yes, I have sold open source software (embedded platforms) which I have made from scratch.

Re:Yawn, another fork

[guruevi]

When the company goes out of business or gets taken over by another entity, who will be doing support for those devices? How can a company justify having a broken, closed source system without support options? I have made and sold open source embedded hardware/software solutions, I use open source as a selling point.

Re:Yawn, another fork

[S.O.B.]

Berkeley DB is often used as a back end for MySQL.

[Citation needed]

[Citation given]

http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html

Although it disappears from the manual after 5.0. The conspiracist in me would think the removal had something to do with an impending license change. Hmmmmm.

Re:Yawn, another fork

[rtfa-troll]

I don't know what you wanted to refer to. I do know that Red Hat distributes Berkley DB, and so you can get bug fixes from them independently of Oracle. That means that your statement is very different from my statement.

Re:Yawn, another fork

[unixisc]

If customers are the type who are likely to study the source code, modify and use it as per their needs, chances are that they would have a good idea about the software. Yeah, it's not their core business, but under an open source license, there is nothing stopping them from selling or freely distributing it to others. They don't have to promise any support or any such thing whatsoever. Let's say they spent $10k buying the software from you: they recoup that expense by re-selling it at $100 to say, 100 people, and they're a wash. From that point on, anything they do w/ the software - create another product, resell more copies, et al would be pure gravy.

I'm not thinking here so much about things like Libre Office or Linux: there, you are right. Nobody redistributes them since they're already free. I was thinking about things like CAD packages, where typically, customers would need to have a high level of expertise to even use them, and chances are that they'd understand some of the code used to build it. As you say, making it expensive enough is somewhat of a disincentive for them to give that away to anybody. But note that there is nothing in the license that prevents it - it's not even against the spirit of the license to do so. By contrast, w/ a shared source license, they'd use the source for what they need - modifying it to suit their custom requirements, porting it to exotic platforms and so on, while not doing what's not in the ISV's interest - redistributing it.

I wasn't claiming that open source software can't be sold - of course, it can. Only issue - it takes just one customer who puts it up on github or somewhere to make it available for no cost to anyone who doesn't want to buy the support. You claim that very few people/companies would do it. Companies, yes, but I have my doubts about people. It's a lot cleaner when an ISV picks a license that allows only what he wants or is okay with, and explicitly disallows everything he doesn't want.

Re:Yawn, another fork

[Goaway]

I don't know what you wanted to refer to. I do know that Red Hat distributes Berkley DB, and so you can get bug fixes from them independently of Oracle.

And they can only keep doing this if they fork it and start fixing bugs themselves.

Re:Yawn, another fork

[Anonymous Coward]

So in your strange universe, if company A has 50 developers working on 5 Open Source projects and contributing back hundreds of thousands of lines of code but has one single item that is not open, that's bad? All that Open Source they do contribute has a net value of zero, in your eyes?

You're insane, and I'm glad I don't live in your universe.

Re:Yawn, another fork

[gstoddart]

On top of that: they switch from one open source license to another one.

Well, traditionally SleepyCat has been under a more BSD-like license, this is more of a GPL variant.

With the BSD license you could basically incorporate the BerkelyDB into a commercial product, with the GPL one you have a few more restrictions. So there is more than just "from one open source to another".

If what you're storing is key/value pairs, SleepyCat/BerkeleyDB is a really useful database.

Since there's two schools of thought on which is better, not everyone is going to like the shift to a GPL based one.

Re:Yawn, another fork

[rwven]

You're arguing semantics... They will "want" to upgrade because the security holes "force" them to have that desire.

Re:Yawn, another fork

[angel'o'sphere]

Did not know that BerkleyDB has security holes ...
How should that even be possible for an embedded DB?

Re:Yawn, another fork

[rwven]

Holes/bugs/vulnerabilities/whatever. For that matter: "Any reason you might need/want to upgrade this software." You're still arguing semantics when any ignoramus can see what my intended point was. An example doesn't have to be all-encompassing.

Re:Yawn, another fork

[angel'o'sphere]

You would be right if you would talk about a piece of software that actually changes often.

BerkleyDB is stable since decades ... people who use it very likely NEVER upgrade or change the base they have.

Re:Yawn, another fork

[hyc]

5.0 is pretty ancient. MySQL abandoned BDB as a backend in 2006, shortly after Oracle acquired BDB. They couldn't use vanilla BDB, it required their own patches to the BDB source tree.

http://archive09.linux.com/articles/56835

Re:Yawn, another fork

[rwven]

Yeah, certainly can't be any increased cost, risk, or time in THAT solution.

lol

[Anonymous Coward]

but GPL v3 and AGPL are good, right? Right?

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:lol

[Anonymous Coward]

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

Re:lol

[Anonymous Coward]

So exactly how many custom changes do you make to large projects for your own little in-house needs?

Re:lol

[jythie]

As an embedded developer, I sympathize with why one would find the AGPL evil... though at the risk of going down a 'they came for the X, but I was not an X' line. Back end developers did not seem to understand why embedded developers were uncomfortable with GPLv3, which was written in such a way as to not anger the more network and infrastructure oriented projects but really put the screws on embedded ones.

Re:lol

[KiloByte]

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

Re:lol

[Anonymous Coward]

So exactly how many custom changes do you make to large projects for your own little in-house needs?

Easily one of the lamest questions you could ask.

Serious answer: It's a database program. He/she needs to create a schema. That schema would be covered under the AGPL.

Re:lol

[gl4ss]

ironically though it should be more RMS friendly.

it's entirely reasonable. it's just not the kind of open and free you're looking for :)

(in fact, most gpl web sw is quite irrelevant that it is such.. because the end users can't get the code)

Re:lol

[Ly4]

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.

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

[Anonymous Coward]

i doubt AGPL requires you to release your data or scripts, since they are not part of the software. If you change the actual code of the database itself, then you need to release the changes. Do you hardcode you table names into the database itself?

Re:lol

[dgatwood]

Lots of them, actually. Any website is likely to have an authentication system already. Any website wanting to add features using existing open source technology is going to want to tie into that system. This common use case is fundamentally incompatible with Affero, because that authentication system cannot necessarily be made open source, and the AGPL does not provide a linking exception.

Also, before I adopt any piece of software these days, I do a thorough security audit. Mind you, I prefer to give those changes back when possible, because it makes future upgrades easier, but when the changes involve many thousands of lines of code changes (e.g. rewriting every single SQL query in parameterized form), this is often not appreciated as much as one might expect.

In short, anything I touch usually experiences a major fork and a large-scale rewrite prior to deployment. And that's not even counting all the minor stuff like skins, custom icons, etc., much of which often involves minor code changes because of inadequate class and ID attributes in HTML output, the need to manipulate the order of large blocks in ways that makes CSS unhappy, etc.

Re:lol

[aztracker1]

BDB is embedded, which means your code that reads/writes database access in fact does need to be AGPL too.

Re:lol

[Anonymous Coward]

I don't think your interpretation is right: AGPL affects source code, not configuration files. As long as you ship an "example config file" when a user requests the source code, should be enough.

Re:lol

[dgatwood]

Well, I know that a lot of folks moved away from Berkeley DB several years ago when Oracle first acquired it (and by "moved away", I mean "ran away") and embraced SQLite. Now might be a good time for the rest of the open source community to do the same.

Alternatively, for situations where SQLite is insufficient, IMO, PostgreSQL is usually a good alternative.

Better yet, adopt a middleware library like PDO so that with a small amount of effort (rewriting CREATE/ALTER TABLE queries, anything involving triggers or automatic time/date stamping, and a few other rough edges), it can be ported to arbitrary backend databases.

Re:lol

[Anonymous Coward]

The "example config file" is not in the license language: http://www.gnu.org/licenses/agpl.html

Re:lol

[DigiShaman]

So basically, AGPL is just poisoning the well waters here intentionally?

Re:lol

[dgatwood]

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.

Re:lol

[devent]

What a hypocrite you are. Why aren't you build your own forum software, why are you getting a free ride?
Or, if you lack skill or time, why aren't you buy a proprietary license from the developers of PHPBB?

If your modifications are useless to anyone else then there is no risk and no argument to release them. Just drop your code to Gibhub and be done. You could have an argument 20 years ego, when you have do mail CDs or Floppies to anyone ask for them, but today sharing code have zero costs and takes maybe 5 minutes of your time.

> Basically, AGPL is only useful for a very, very narrow range of software designed specifically ....

You know, you are an ass. It's up to the software developer to decide what license is best for their project.
If you don't like the license, you are free to negotiate a different license.
How about a little email to the developers of PHPBB:

Dear Developers,
I'm a small software developer myself, and I can't release my modifications, because I'm a lazy ass.
How about 50$ and a case of beer for a proprietary license?
Regards.

Re:lol

[LordLimecat]

AGPL is horribly evil.

Wow, so I might have reserved that word for something like "genocide" or "the holocaust", but if you want to use it for a license which you happen to have a dislike for, I guess that works.

After all this is slashdot, and perspective is SO passé.

Re:lol

[dgatwood]

Who is talking about a configuration file? Have you ever tied a piece of software into a different authentication system? This isn't a config file change. It's potentially thousands of lines of code changes throughout the software, depending on how the software was written and how many assumptions it makes about the nature of the authentication system. (For example, my current authentication system does not use cookies. Any software that assumes cookie-based authentication tokens requires considerable changes.)

Re:lol

[devent]

Yes just ignore the other freedoms.

The use of the BerkeleyDB do not put any restrictions on your software, as long as you do not statically link it.
A database connection is not covered by the GPL or AGPL and do not make it a derivative work.
As long as you use, for example Debian, you already comply with the AGPL license, because Debian distribute the sources already.

Re:lol

[KiloByte]

As long as you use, for example Debian, you already comply with the AGPL license, because Debian distribute the sources already.

Alter a single bit and you need to distribute your modified version. Which for most networking protocols is impossible or impractical.

Re:lol

[Anonymous Coward]

I don't have any sympathy for embedded projects that are uncomfortable with GPL V3. It was specifically designed to prevent the TIVO situation. I heartily approve of that. Let me tweak the software, for heavens sake.

Re:lol

[jbolden]

Configuration files aren't under AGPL. The source code itself is. System admins don't need and generally aren't capable of making C-langauge source changes for using software in normal configs.

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.

Re:lol

[jbolden]

If you are talking about thousands of lines of code changes to dozens of files ... yes you should be make it public. It becomes an example for the next person looking to use an authentication system.

Alternatively you could write an authentication layer make it BSD and make that public.

Re:lol

[Just Some Guy]

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

So in other words, it's not really Free Software. Got it.

Re:lol

[kthreadd]

Some of the best C programmers I know are system administrators. Going into the source code to something really helps when you're debugging why a specific service doesn't work or program X hammers the NFS share with 4 kB requests.

Re:lol

[greg1104]

phpBB is currently under the GPLv2. The person you replied to didn't say they are unwilling to share their source code, just that such work would be unproductive. Do you always rant about straw men like this?

Re:lol

[greg1104]

The use of the BerkeleyDB do not put any restrictions on your software, as long as you do not statically link it.

The Sleepycat license doesn't trigger based on linking; it's triggered by compiling against it. See The Sneaky Sleepycat License and comments from Oracle's forums. The existing license was already very "viral" in terms of how aggressively it required either open source distribution or a commercial license.

Re:lol

[greg1104]

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.

Re:lol

[KZigurs]

You are a confused man and it appears you might have never used ether one of those.

The use cases are completely different. You cannot seriously talk about substituting BerkeleyDB with PostgreSQL (not that it wouldn't work, but it is so far at each extremes of persistence spectrum when it comes to functionality and operational overhead that they might as well be from different planets).

Re:lol

[devent]

If the license would say that you need to share your modifications, then that is what you agreed to.
It can be unproductive, but that is not the issue. The issue is that you agreed to the license.
I have offered the alternative: to negotiate a different license. Sure it means that you probably have to pay.

But you are a hypocrite if you take a free product, and demanding that the developer is using a less restrictive license.
And you are more a hypocrite if you make up some arguments, like sharing your modifications is unproductive, the license the developer choose is "unacceptable", the license is "horrible", etc.

Re:lol

[icebraining]

I find it extremely hard to believe that a court would consider a schema to be a "derivate work".

Re:lol

[icebraining]

because that authentication system cannot necessarily be made open source

What? Why not? There are plenty of open source authentication systems. In fact, I'd say it's extremely reckless to use a security system that hasn't been widely vetted, and that requires available source.

Besides, it's not true that it would necessarily require open sourcing the authentication system. If you're using something with a service interface, then only the "bridge" that extends the webapp to talk to it should have to be open sourced.

Mind you, I prefer to give those changes back when possible, because it makes future upgrades easier, but when the changes involve many thousands of lines of code changes (e.g. rewriting every single SQL query in parameterized form), this is often not appreciated as much as one might expect.

Irrelevant. None of the (A)GPL licenses require you to give anything back. All you need to do is inform your users that a copy can be arranged if they ask for it, nothing more.

Re:lol

[icebraining]

It forces proprietary developers to spend time and money writing their own code instead of milking the free software cash-cow. If nothing else, that makes it worthwhile.

Re:lol

[batkiwi]

Free software advocates would argue that your users are "running" your software, and thus are owed the source code.

If you are running a forum you ARE running software as a service.

Re:lol

[batkiwi]

Your description and outrage is how MANY people feel about the GPL vs the LGPL.

Re:lol

[dgatwood]

If you depend on the high-availability, replicated functionality available in recent BerkeleyDB systems, then PostgreSQL can potentially be used as an alternative where many lightweight database systems (SQLite, for example) cannot be seriously considered.

I have no idea what the NoSQL space is like these days, so there may be better choices over there. I've never used those parts of BerkeleyDB (those features didn't even exist until years after I last touched BerkeleyDB), so I can't say how they compare performance-wise.

Re:lol

[dgatwood]

because that authentication system cannot necessarily be made open source

What? Why not?

Because I spent a lot of time on that software, and I'm not really interested in giving it away? Look, the only reason I'm modifying the open source software at all is so that users don't have to create two login accounts. That hardly warrants giving away the source code for an existing login system that is an entirely separate piece of software in its own right, merely so that the open source software can use that login system. Any software whose license demands such a thing is going to get no more than a laugh and an eye roll from me as I search for other software whose license isn't so utterly absurd.

And this is not to say that I won't at some point choose to give away that source code. I will not, however, even consider using a piece of software whose license would force that decision and the timing thereof.

There are plenty of open source authentication systems. In fact, I'd say it's extremely reckless to use a security system that hasn't been widely vetted, and that requires available source.

None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)

Irrelevant. None of the (A)GPL licenses require you to give anything back. All you need to do is inform your users that a copy can be arranged if they ask for it, nothing more.

You missed my point entirely. The point I was trying to make was that even as a user of software whose license does not require me to give the changes back, I do at least make the attempt if those changes would potentially benefit anyone else. I'm not averse to giving back changes. However, as a site admin, I absolutely require the right to be able to make the final decision as to which changes I make publicly available and which changes I don't. It's fine if you don't agree with me, and it's fine if you decide to license your software under AGPL because of it, but if you do, I guarantee that I won't use your software. Ever. Even if I don't need to modify it initially. Why? Because it locks me into a situation where if I ever needed to modify it in the future for any reason, those changes would have to be public, no matter how sensitive those changes might be. That isn't an acceptable risk to me.

Re:lol

[dgatwood]

If the license would say that you need to share your modifications, then that is what you agreed to.

PHPBB is licensed under GPL, not under AGPL. The GPL requires you to share your source code modifications with anyone to whom you distribute the software. PHPBB being a server-side app, none of the software is distributed. At all. Therefore, its license says that I am under no obligation to make available local modifications.

But you are a hypocrite if you take a free product, and demanding that the developer is using a less restrictive license.

I'm not demanding that the developer use a less restrictive license. I'm saying that I'm glad the developer chose to use the less restrictive license because had the developer used AGPL, it would have prevented me from even considering its use.

Re:lol

[jythie]

Our product used open source. We gave back a significant amount. Library work, bugfixes, drivers, management was supportive of contributing. But, our final device required a network of trust, people using them (and, more importantly, underwriters and regulators) needed to know that OTHER people were not running modified software and cheating other users.

So when GPLv3 came out, we had to stick to GPLv2, which ment participating less. Then we switched to Windows, which ment we did not participate at all anymore.

When an embedded device connects to other devices, sometimes the integrity of the network is more important then individual's desire to get a leg up or tinker.

Re:lol

[dgatwood]

Wow, so I might have reserved that word for something like "genocide" or "the holocaust", but if you want to use it for a license which you happen to have a dislike for, I guess that works.

It's a question of scale. Consider an ant attacking another ant; it's murder from an ant's perspective, but on the human scale, we don't care. Same deal for AGPL vs. the holocaust. In the context of licensing, AGPL is horribly evil. In the context of human civilization as a whole, it's below the noise floor. :-)

Re:lol

[bug1]

AGPL is not good ... cannot make changes necessary to tailor it to my particular site configuration without releasing the source to those changes

I dont know berkleyDB, can you explain the reasonaing behing concluding that "site configuration" changes are part fo the program.

Does it not have seperate config files or something... maybe you could submit a patch ?

Re:lol

[Grishnakh]

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.

Re:lol

[icebraining]

Because I spent a lot of time on that software, and I'm not really interested in giving it away?

So, it's not that it can't, it's just that you don't want to. That's fine, but hardly the same.

None of the ones I saw met my needs. None of them even came close, actually. The token-based authentication that most websites use makes it way too easy to sniff a few packets and then impersonate someone, and regrettably, the exorbitant cost of multi-domain certificates makes SSL infeasible at this time. Therefore, my base requirement was a robust and fairly lightweight, pure-JavaScript means of signing each individual HTTP request with a shared secret key derived from the user's passphrase and an arbitrary nonce generated by the server. (Still on my to-do list is adding synchronized timestamping and/or regular nonce rotation to prevent replay attacks, but given the site design, the damage posed by such an action would be fairly minimal, so I'm in no hurry.)

Just curios: how does your system prevent an attacker from simply replacing/modifying your JavaScript code with a snippet that copies the user's passphrase to his/her server?

Have you read Matasano Security's critique of JavaScript cryptography? Last time it was discussed on Hacker News, the only real objection was that you could use a browser extension to implement the crypto - nobody had a solution for pure, extension-less cryptography.

Re:lol

[devent]

See, that is why you are a hypocrite.
Oh how glad the developers of PHPBB must be that dgatwood is using their software.
In that discussions I sometime wish that there would be no GPL, AGPL or BSD or any other open source software so that people like you would not get a free ride.

Re:lol

[Vanders]

How does forcing developers into not making use of Free software help anyone?

Re:lol

[Vanders]

System admins don't need and generally aren't capable of making C-langauge source changes for using software in normal configs.

That's news to me. I think you might underestimate sysadmins.

Re:lol

[icebraining]

In the same way that increasing the cost of whips would help the slaves.

Re:lol

[Anonymous Coward]

yeah you're talking sweedish and I'm talking greek. The network is never to be assumed safe. If you have to make that assumption, you've already failed.

Re:lol

[VortexCortex]

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?

Re:lol

[aix tom]

Exactly. If "the schema" would fall under AGPL, then "the data" they put in the DB would probably also fall under the AGPL.

In the same vein, any novel written in a GLP text editor would have to be GPL, and any song recorded with a GPL recording software would have to be GPL. There still is a difference between "modifying the software" and "putting data into the software the way you are supposed to"

Re:lol

[dgatwood]

See, that is why you are a hypocrite.

Come again? The word "hypocrite" doesn't just mean someone who disagrees with you or does things you don't like. It means someone who says one thing while simultaneously doing the opposite. Nothing I have said or done in this thread even remotely qualifies as hypocrisy.

In that discussions I sometime wish that there would be no GPL, AGPL or BSD or any other open source software so that people like you would not get a free ride.

Free ride? Hardly. I spent about half a decade maintaining a Linux distro on a platform that only a few thousand people ever cared about. I've released quite a bit of software as Open Source, both on my own and through my employer. I'm one of the open source advocacy people within my company, actively encouraging development teams to release software as open source.

I'm not being a hypocrite here. You are. You're insisting that I'm somehow doing evil by using software well within the terms under which it was licensed, and you're arguing that in order to use open source, I should be forced to release everything I do, no matter how distantly related, as open source. Unlike what I'm doing, your argument is hypocrisy—claiming to support the GPL while simultaneously attacking people who use GPLed software in full compliance with the license, thus giving the entire Free Software movement a bad name.

Oh how glad the developers of PHPBB must be that dgatwood is using their software.

Oh, but they are. You see, the only way to get more eyes on the code fixing bugs is to actually have other programmers using that code. When I use a piece of software, I invariably find bugs. Lots of bugs. And I fix those bugs and submit patches. Therefore, it is in PHPBB's best interest to have more people like me using their software—actual programmers, rather than mere end users with no programming skills who leech off their efforts and contribute nothing back. In exchange for me finding and fixing bugs, PHPBB's license allows me to keep private my site integration changes that would not benefit anyone and that are nobody else's business. This strikes a good balance between the needs of the admin/user and the needs of the developer.

The AGPL instead fails to strike a balance. It represents the effect of our entitlement-driven society on the Open Source movement, demanding that every change be made available even if you do not redistribute the modified software. And that changes the delicate balance between site developer and software developer in a way that makes it much less useful to me.

You can disagree with me all you want to, but disagree with me by pointing out reasons why you disagree. Name-calling ranks right up there with Godwin's law; it automatically means that the debate is over and you have lost.

Re:lol

[dgatwood]

Actually, that's a great analogy, but not for the reasons you think. By increasing the cost of the whips, the plantation owners require more output from the slaves to cover the extra cost of the whips, so they drive the slaves even harder.

In much the same way, by making contributions back from the community an absolute demand as the AGPL does (and, to a lesser degree, the GPL does), developers who cannot or are unwilling to comply with those requirements must reinvent the wheel, thus increasing market fragmentation and reducing the number of eyes looking at any one implementation. This, in turn, reduces the quality of all of the offerings and hurts the Free Software community every bit as much as it hurts the businesses. In order to make up for the loss of developers, those community developers must work even harder if they want their software to be seen as a viable alternative to the commercial equivalent.

Re:lol

[dgatwood]

In this case, it's one line of JavaScript that queries a PHP script that fetches a database record out of a different database and inserts a cookie into the browser while simultaneously blowing a matching user record into PHPBB's database, coupled with lots of changes to rip out every place with a login/logout button, a password change button, or an account creation button. None of that is going to be all that useful to... well, anybody, really. It is entirely a site-specific hack. It's also going away because I found a different bulletin board suite that is actually based on XHR requests so it can integrate with my authentication system correctly. (By contrast, making PHPBB integrate with it properly would have required a near-complete rewrite of PHPBB.)

Re:lol

[dgatwood]

Incidentally, the only reason it interfaces with PHPBB's code at all is because PHPBB has a specific way of sanitizing the UTF-8 data for certain fields, and there's no good way to replicate that. So for compatibility, it has to use PHPBB's function, which would put that piece under the GPL if it were distributed (which it isn't). If it were under AGPL instead of GPL, it would have to be redistributed, and would reveal details that I don't want to reveal.

Really, there are large chunks of PHPBB that would be better off under a less restrictive license like the LGPL, if only so that third-party plug-ins that call back into parts of PHPBB aren't forced to be GPL-licensed. But that's not my decision to make.

Re:lol

[dgatwood]

Just curios: how does your system prevent an attacker from simply replacing/modifying your JavaScript code with a snippet that copies the user's passphrase to his/her server?

The same thing that prevents an attacker from grabbing cookies out of the browser's cookie store. Third-party JavaScript does not have access to client-side storage unless it was served from my origin, and the code running on my origin is vigilant about ensuring that third-party JavaScript cannot be injected. (For the one part of my site that allows HTML submission, I have a whitelist of HTML tags and attributes that are allowed, and anything not on that whitelist gets eaten.) Now I'll grant you that a malicious extension could modify a link somewhere that causes *my* JavaScript code to do something on behalf of the user, but even in that case, the risk is no greater than it would be with cookies.

Re:lol

[dgatwood]

So, it's not that it can't, it's just that you don't want to. That's fine, but hardly the same.

In this case, it is my code to do with as I wish. The point I was trying to make is that it is not true for every case, particularly when you're working for a company that may have contradictory agreements with other companies.

Re:lol

[jbolden]

Then publish the patch file to rip out everything. For the one line of javascript just publish a generic version of the line. Now you qualify.

Re:lol

[icebraining]

That's fine; I rather work harder than help the slave owners.

Re:lol

[icebraining]

Now I'll grant you that a malicious extension could modify a link somewhere that causes *my* JavaScript code to do something on behalf of the user, but even in that case, the risk is no greater than it would be with cookies.

Well, if you used cookies, you could set them as HttpOnly, which would prevent even your JavaScript code from accessing them.

That said, I was thinking more about that scheme vis-a-vis using HTTPS, and in particular in the case of a man-in-the-middle attack. The problem with JS crypto is that you can't securely deliver the code to the browser, so all bets are off if you have an attacker that can modify the stream.

Re:lol

[badkarmadayaccount]

leveldb, google?

Re:lol

[Anonymous Coward]

You say infect, I say liberate.

Prove to me that you have the right to control code you've written. Prove to me that it's not derivative of public domain work.
Hint: You can't.

Software freedom as a tool of the oppressor?

[Anonymous Coward]

Say it ain't so!

Where is your God now RMS, WHERE IS HE???

License drama

[Anonymous Coward]

Has anyone ever been sued over an open source deployment done off license? This seems to be much ado about nothing.

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:License drama

[Anonymous Coward]

yeah, that was a core bit of the MySQL business model.

Re:License drama

[Anonymous Coward]

And Oracle sued Google, in part because Google's Dalvik was under a less restrictive license than Java's GPL

Oracle sued over Java ME, which is proprietary. the JRE and JDK as well as the GPL they're both licensed under never factored into the equation.

Re:License drama

[Xtifr]

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.

Wait.. let me get this straight...

[Anonymous Coward]

I thought we liked the GPL around here?

Isn't Oracle using a GPL compatible license exactly what we want and should support?

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

[Anonymous Coward]

Yes. TFS is yet another anti-copyleft troll.
You can tell by the blatant misuse of the verb use:

developers using BerkeleyDB will need to check their code is still legally licensed.

As usual with copyleft licenses, use is as free as with public domain software.

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

[Nerdfest]

It's the intentions behind it. Switching to GPL3 means it is much more restrictive in how it can be used in commercial products. As a general guideline, if there's ever a question about Oracle's motivations when it comes to a choice between advancing open source and trying to force more people to their proprietary products, he answer is pretty straight forward.

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:Wait.. let me get this straight...

[gl4ss]

you can use it for commercial products.. you just can't take the freedoms for yourself while restricting your users from those freedoms.

you could always just go for some bsd licensed db if you'd rather want that.

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

[Goaway]

Except with the AGPL, use is not free.

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

[Anonymous Coward]

Here's a hint: the user is the person running the program in a web browser, not the admin deploying it on the server.

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

[Anonymous Coward]

If that were true, it wouldn't be compatible with the GPL.

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

[Anonymous Coward]

You've described this as if it weren't a big deal, but there is a lot of GPLv2 software that's going to require changes if the new version of BerkeleyDB is giong to be used with it. For Debian that means either a) sticking wtih an old version of BerkeleyDB before the license change, b) a LOT upstream projects changing their license (which realistally they likely can't), or c) switching away from BerkeleyDB to an alternative and patching the various source packages to make it work.

Just to give you a short list of packages affected (Ondej Surý gave an exhaustive list, which I'm greatly summarizing here):

      apt
      bind9
      bitcoin
      bogofilter
      boxbackup
      cfengine2
      cfengine3
      cyrus-imapd
      cyrus-sasl2
      dnshistory
      dovecot
      drac
      dsniff
      exim4
      glusterfs
      iproute
      iproute2
      lucene2
      opendkim
      openldap
      nvi
      pam
      perdition
      perl
      php5
      postfix
      python2.7
      python3.2
      python3.3
      reprepro
      rpm
      sendmail
      spamprobe
      squid
      squid3
      squidguard
      subversion
      tcpstat
      webalizer
      vacation

and many others. Regardless of the solution chosen, this change represents a lot of required work needed to fix something that before now wasn't broken.

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

[Anonymous Coward]

No they aren't.

The readers of documents I produce using open source tools aren't the user of those tools either.

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

[Anonymous Coward]

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.

Where was the outcry when MySQL AB switched their client library from LGPL to GPL?

http://lists.mysql.com/mysql/120620

There was some,

http://www.infoworld.com/d/developer-world/open-source-lock-in-134

but Monty needed $$$$. So now he has money, and look what happens,

http://openquery.com/blog/mariadb-client-libraries-end-duallicensing

client library is now LGPL again - perhaps just to piss into Oracle's pond.

But I get it, whatever Oracle does is bad. Whatever other people do that is similar, is good.

Nothing to see here, move along. People can always use SQLite or PostgreSQL. Oh wait, they were for last 10 years.

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

[Goaway]

And it is not, except by having special case terms in the license to allow it even though it would not usually be allowed.

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

[Anonymous Coward]

Explain to me how your definition applies to MongoDB?

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

[idunham]

It's only "compatible" because GPL3 (and not GPL2, note!) explicitly allows combining GPL3 software with AGPL.

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

[Xtifr]

A great many of those packages are GPL2+, which is compatible with the AGPL. Of course, that means the overall license for the binary would end up AGPL, but the original code would remain under the GPL2+ license, just as BSD code included in a GPL'd binary remains BSD-licensed.

The only projects that would be affected would be those which chose GPL2-only, which in my surveys, is a very small number. Somehow, I seriously doubt that the Linux kernel is or ever was using bdb. :)

How big a deal is this?

[fuzzyfuzzyfungus]

Even as the copyright holder, Oracle can't do jack about existing versions released under other licenses(even if they went full nuclear, and actually terminated all downloads/media purchases under any prior license, there are still third party mirrors. So, Version X-1 is Sleepycat forever.

Is BerkeleyDB a project where Big New Features or Much Needed Upgrades are something that happens frequently, meaning that if you aren't running Version X, you might as well go home? If so, Oracle has actual leverage. If not, it seems likely that a maintained-if-not-terribly-active version can exist in perpetuity, with Oracle having to offer serious advantages in order to retain their status as the standard against which 3rd party development is done.

Re:How big a deal is this?

[jythie]

I do not think BDB has changed much in the last two decades.... it is a pretty conservative project.

Re:How big a deal is this?

[Anonymous Coward]

Yes, it did. Minor API changes (enough to break code, though), and very very noticeable scalability and internal changes.

That said, it would not be a problem to just fork BDB 5, for example. Debian is likely to just do that.

Upstream FLOSS projects are all jumping ship to LMDB, which is _really_ nice for most uses one would want berkeleydb for.

Re:How big a deal is this?

[jbolden]

This started with a thread on Debian. There are dozens of projects on Debian that use BerkleyDB. Should they be configured to 5.3 forever? If so what if there are security problems how will Debian even know? If not they go over to 6. Which means dozens of libraries switch over to AGPL....

Re:How big a deal is this?

[fuzzyfuzzyfungus]

This started with a thread on Debian. There are dozens of projects on Debian that use BerkleyDB. Should they be configured to 5.3 forever? If so what if there are security problems how will Debian even know? If not they go over to 6. Which means dozens of libraries switch over to AGPL....

I suspect that that depends on who actually does the work to keep those packages in Debian. As a distribution(considering their positions on firmware blobs, what you have to do to qualify as 'debian' rather than 'debian-unfree', etc.), Debian doesn't seem like a terribly obviously candidate for being hugely worried about the AGPL.

Given that Debian is also the basis of about a zillion other distros, as well as in-house quasi-distros, though, I suspect that they have a reasonable number of users, probably including some genuinely useful ones, who have purposes for which an AGPL BerkleyDB is Not Going To Fly. We'll have to see how that shakes out.

Re:How big a deal is this?

[jbolden]

I think Debian will go AGPL without much problem. They are a free software distribution. I think RedHat will likely fork but they will call the project something else. And from I think Debian will allow individual maintainers to decide which to link to.

Re:How big a deal is this?

[idunham]

Debian doesn't change things like this until all the license compatibility issues are solved. In this case, that's a whole lot of software to go through.

does anyone actually give a shit?

[Anonymous Coward]

license shmicense i use what i want.

Confused!

[Anonymous Coward]

So, all projects should be Open with as much Freedom as possible UNLESS they're run by Oracle??? Am I supposed to support the GPL or not???

Please /., tell me how I'm supposed to think on this!!!

Re:Confused!

[bonehead]

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.

Re:Confused!

[Sq]

Actually, "Open with as much Freedom as possible" would be releasing the code into the public domain.

Except, in most countries (like most of EU and USA) you as an author CANNOT release the code into public domain (unless you die, stay dead for 70-90 years, and hope copyright protection does not extend in that time, which is a hope against current trend of practically infinite copyright). For example, see http://en.wikipedia.org/wiki/Public_domain_in_the_United_States

The entire purpose of a license, ANY license, is to place restrictions on what can be done with the code.

That is totally incorrect. It is the copyright that places restrictions (remember "all rights reserved" phrase?). If there was no license at all, standard copyright would be in effect and you would have no right to copy, modify, translate, etc. work at all (except as governed under fair use and similar exceptions).

The license is actually copyright holder GIVING UP some of his/her copyright protections, sometimes (but not always, see WTFPL for example) in exchange for some other promise on users side (for example, proprietary licenses might allow you to to make 5 copies of some program IF you agree to give them e-mail to spam you; or GPL might allow you to copy that program without limits IF you agree you'll also allow others makes copies of your derived work, etc.)

who cares?

[magic maverick]

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.

SleepyCat achieved the startup dream

[Anonymous Coward]

They built up a substantial developer interest, they hired a few people, they got some excited customer names, and they got bought. Their founder is now off suggesting *REALLY, REALLY BAD* database ides such as putting a "provenance aware" BDB database into the filesystem. (This failed in WinFS for much the same reasons it's a bad idea for BDB: it's a huge CPU hit and it's not possible to stabilize or recover from the inevitable corruption.)

It had achieved its limits. Errors are unrecoverable, it doesn't scale, and atomic transactions weren't, which led inevitably to errors. The open source world abandoned BDB years ago for precisely these reasons: Oracle bought it to get the customer list and put the existing customers out of their unsupportable misery, and migrate them to something usable and fixable, such as Oracle or MySQL now that they also bought Sun Microsystems.

Amusing . . .

[Anonymous Coward]

. . . unintended consequences.

GPLv3 = poison pill

iText

[Anonymous Coward]

That's what happened with iText (a Java library for manipulating PDFs.) It was LGPL, the author got tired of well-heeled organizations using it without contributing either blood or treasure (including, I hear, some who were violating LGPL) and switched new versions to AGPL (with the option of a paid commercial license.)

Some went along, the project (under AGPL) is still going, but many others just keep using the last LGPL version. It ain't exactly broke.

Gratuitous criticism against Oracle

[peppepz]

So they develop a complex software project in-house, they give it away for free, they put it under a well-respected, user-friendly, open source, free software license, and we attack them because that might scare away commercial freeriders lest they'd have to provide a link to the source code in case they modify it and then use it on a web site?

Bah, I must be getting old, because this looks completely unreasonable to me.

Re:Gratuitous criticism against Oracle

[ilguido]

Don't worry, it's the usual anti-FSF, anti-GPL FUD by soulskill.

Re:Gratuitous criticism against Oracle

[Anonymous Coward]

Bah, I must be getting old, because this looks completely unreasonable to me.

Your eyesight must be going because Oracle didn't build it and the impact of a license change effects large numbers of non-commercial existing open-source projects.

Re:Gratuitous criticism against Oracle

[Todd Knarr]

It's not that they have to provide source to BDB. It's that the AGPL changes the rules. Before usage as an embedded database in a Web app was considered internal use, not distribution, so BDB's license didn't impact the licensing of the Web app itself and didn't require release of the source code for the Web app. The AGPL means that if you use BDB in a Web app then the Web app itself has to be licensed under AGPL-compatible terms. That's... a huge change. And even though I normally use GPL terms, I don't really agree with it. If you were talking about an entire Web app framework, AGPL is appropriate. But for such a small component? That smacks to me of arm-twisting in a bad way, of trying to force users into buying proprietary licenses without coming out and saying that's what you're trying to do.

Similar things are why we have the LGPL, and why so many library components use it instead of the GPL. The GPL is suitable for entire programs, the LGPL is more suitable for libraries used by other programs. And while I don't have a problem with a library declaring itself licensed under the GPL, I do have a problem with a library starting out under the LGPL and then changing it's licensing to GPL. That changes a fundamental rule about what kinds of usage impact licensing, and it feels to me like I was suckered in.

Re:Gratuitous criticism against Oracle

[drinkypoo]

So they develop a complex software project in-house,

Congratulations, you have no fucking idea what you're on about.

Re:Gratuitous criticism against Oracle

[peppepz]

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.

Re:Gratuitous criticism against Oracle

[Anonymous Coward]

hardly. Being /. I assume you didn't read discussion on the Debian dev list. There's plenty a number of them grousing on about how, in this case, the AGPL is too strong a license and that there are a number of different projects that are going to be affected by this including Debian's package manager, apt. Frankly, assuming this isn't an accident by Oracle, it is hilarious that these Debian devs (who are some of the most anal about FOSS license issues as witnessed by their usual ragging on Canonical/Ubuntu) think that Oracle is screwing them over because it changed a open source project's license to a stronger FSF approved copyleft license. It's brilliant.

Re:Gratuitous criticism against Oracle

[peppepz]

Oracle paid the people who wrote it in order to acquire that software. Oracle is currently paying their wages while they continue to develop the software. Your sarcasm is completely out of place.

Re:Gratuitous criticism against Oracle

[drinkypoo]

Oracle paid the people who wrote it in order to acquire that software.

That is not even vaguely close to the same thing as developing it themselves, and no amount of wishing will make it so.

Oracle is currently paying their wages while they continue to develop the software.

Yes, and Oracle is currently retroactively changing the license to something less desirable, and it's reasonable for people to be upset about this. It is a form of bait and switch because if it had used this license from an earlier date, then less people would have used the library, and a competitor would have been used by more people, and experienced more improvement.

Re:Gratuitous criticism against Oracle

[peppepz]

Oracle paid the people who wrote it in order to acquire that software.

That is not even vaguely close to the same thing as developing it themselves, and no amount of wishing will make it so.

That, together with

Oracle is currently paying their wages while they continue to develop the software.

is the same thing as "developing it themselves", and no amount of changing the point of the discussion will make your initial answer any less wrong.

Re:Gratuitous criticism against Oracle

[drinkypoo]

No, no it doesn't. Oracle did not initially develop BDB, and is now paying for its maintenance. We call that further development, but it is not all of the development.

Oracle didn't create BDB, which is what we mean when we say "developed", as denoted by the past tense. Oracle is not in a condition of having developed BDB, they are in a condition of maintaining and developing it.

Further, not all development is benevolent, so I'm really not clear on what you hoped to prove to begin with.

Oracle clearly has the legal right to do what they are doing, and there is no morality in business, so that is the only right that matters. It doesn't change the fact that this is an offensive action, and that the most likely reason is that it constitutes an attack on one or more applications using BDB. Oracle is perfectly capable of utilizing a nuclear option to handle a minor goal; they've demonstrated their antisocial nature repeatedly.

Re:Gratuitous criticism against Oracle

[peppepz]

The people who initially created BDB (past tense) now work for Oracle, or have worked with Oracle as long as they've worked on BDB, and they're working there on further development of it.

http://en.wikipedia.org/wiki/Margo_Seltzer
http://en.wikipedia.org/wiki/Keith_Bostic

So Oracle have the past, the present and presumably the future of BDB within them, whether we like it or not.

Re:Gratuitous criticism against Oracle

[Anonymous Coward]

They don't have the past.

They bought a free product which competed with their paid for stuff. They bought it to destroy it and reduce choice for their customers.

Whether you like it or not.

Re:Gratuitous criticism against Oracle

[devman]

AGPL is bad EULA, and it violates freedom zero. If they had just changed it to GPL I don't think you'd be seeing this backlash.

Re:Gratuitous criticism against Oracle

[peppepz]

there are a number of different projects that are going to be affected by this including Debian's package manager, apt

From the list:

Sorry for not checking apt license myself. Anyway... effectivelly relicensing apt to GPL-3 might not be a problem for apt

There's a lot of FUD on that list, too, by people who didn't even know what license BDB was under in the first place. They thought it was under the BSD license, while it was under the Sleepycat license instead, which is a strong copyleft, GPL-like license. Now I'm not saying that changing a license is an easy thing to manage, just that answers like "AGPL kills kittens" are unacceptable.

Re:Gratuitous criticism against Oracle

[peppepz]

AGPLv3 is identical to GPLv3 with the following section added.

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

How does this violate freedom zero?

Re:Gratuitous criticism against Oracle

[devman]

An "on use" provision makes the license a EULA. Which in my book is a "Bad Thing". AGPL places requirements on how you use the software, which no other endorsed open source license does. Forget the fact that EULA's themselves are of questionable nature and the fact that AGPL is presented in the same clickwrap fashion. FSF and GNU have been against EULA's since inception because they violate freedom zero, and now they created a EULA.

This is an embeded library database

[Electrawn]

Why is this not LGPL? (Keep the "viral" self contained to the library), or GPL (Application level viral-ability). AGPL? That "infects" everything (Airborne meta-viral!)

Either the developers/lawyers at Oracle don't understand their own product ... or worse that they are nefariously trying to end of life BDB.

Re:This is an embeded library database

[KiloByte]

"Never attribute to stupidity that which can be adequately explained by malice."

How does copyright cover non-copying?

[Bogtha]

treats web deployment as a trigger to license compliance

How does this work in the USA? If you obtain it from them directly, they are giving you a copy, you aren't copying it yourself - so that's not copyright infringement. Copying software as an essential step in using it does not count as copyright infringement in the USA - so installing it on your server doesn't count as copyright infringement. Responding to incoming web queries doesn't copy any of their work - so that's not copyright infringement. So if you aren't doing anything that is protected by copyright, why do you need a license?

Re:How does copyright cover non-copying?

[Anonymous Coward]

Just because they make the data generally available doesn't mean you're allowed to have a copy of it. They own the copyright to the data, and will only grant you the right to have a copy of that data if you follow whatever terms they set in place.

Re:How does copyright cover non-copying?

[Todd Knarr]

The thing in question is a Web app. That means that the end user doesn't make or get a copy of the program. It runs on the server, the user accesses it but never actually copies it. Which left the possibility of someone taking a GPL'd program, adding their own extensions and setting it up as a Web application, offering access to it without having to give users the source code to it as they normally would.

The AGPL was the response. The end user may not be copying, but the operator of the Web app would've had to copy the AGPL'd software onto their server. They can't make that copy without a license. The AGPL license says that if you make a copy and run it on your own server, you have to give users a copy of the code if they ask as a condition of you being able to copy the software to use in the first place. The intent of the AGPL was that it'd be applied to entire applications or to Web services (which're isolated by a network interface, so the AGPL wouldn't extend to software that used those Web services). Oracle here is trying to use it on a small but important component to force Web app developers to choose between AGPLing their entire Web app or buying a proprietary license to BDB.

Personally I'd have no problem with using the AGPL this way from the start. I wouldn't use a component like that, but the author IMO has every right just like they have the right to use the GPL instead of the LGPL on a conventional library intended for use in other programs. But I have heartburn with Oracle changing the license rules in such a fundamental way now, after people have committed to use based on the original rules. NB: I have the same heartburn with an LGPL project going GPL after widespread adoption.

Re:How does copyright cover non-copying?

[gl4ss]

it's an use license...

call it an EULA if you wish. since shrink wrap and install EULA's are legal in usa too bad.

Re:How does copyright cover non-copying?

[devman]

I don't like AGPL for the simple reason that it is a EULA. It is no better than any of the other shrink wrap EULA's of questionable enforcability. Fundamentally it violates freedom zero. GNU should have stuck to distribution licenses instead of wading in to the mess that is EULAs with AGPL.

Re:How does copyright cover non-copying?

[Todd Knarr]

That depends. For a Web app, who is the end user, the author/operator of the Web app or the person using the Web app? And I view the AGPL as addressing the issue of public performance. Web apps don't involve copying in the way conventional software distribution does, but copyright gives me as the copyright holder control over more than just that. As the copyright holder I also have the sole right to publicly perform (or authorize the public performance of) my works. If you want to read my book aloud to an audience, you need a license from me no less than if you want to hand each person a copy. And a Web app looks very much like a public performance of the underlying software. It's not merely the author/operator of the Web app seeing it do it's job, it's users of the Web app as well. So if you're running a piece of software I wrote in public and letting your entire audience interact with my software, how is that not akin to a public performance for which you'd need a license from me that I can set terms for?

This is why the AGPL came about. Freedom zero involves your use of the software you received. Web apps involve someone else's use of the software you received. And the fundamental motivation for the GPL family is to insure that software licensed under GPL terms stays under GPL terms. The AGPL just makes it explicit that if you give other people access to software I wrote and licensed under GPL terms, you must pass along the rights you got. You can't simply refuse to give them the access you got to it. The standard GPL and LGPL would've given you a loophole, the AGPL allows me to close that loophole and protect the rights I intend all users of the software to have to it.

Re:How does copyright cover non-copying?

[devman]

I call it a EULA, because it is a EULA. If you don't agree to the terms you can't USE the software, that is a EULA. EULA's violate freedom zero. FSF and GNU had been against EULA's since there inception, but suddenly just throw freedom zero out the window.

Re:How does copyright cover non-copying?

[devman]

I know why the license was created. It can be rationalized anyway people like, but at the end of the day it is still inconsistent with freedom zero. Any EULA violates freedom zero. AGPL is a EULA because if you don't agree to the terms you cannot USE the software, that is placing an additional restriction on use. If there views have evolved on freedom zero they should retract it or reword it, but as of right now AGPL is inconsistent with the "freedoms" listed on there website.

Re:How does copyright cover non-copying?

[Bogtha]

Just because they make the data generally available doesn't mean you're allowed to have a copy of it.

Copyright doesn't cover having a copy. That's property law, not copyright law. For example: if you steal a book from a shop, at no point has the copyright holder given you permission to have that copy, yet you haven't committed copyright infringement.

Copyright covers making copies. The copies you make when using it in a web application - installing on the server, copying into RAM, etc. - are explicitly excluded from copyright protection by USA law.

Re:How does copyright cover non-copying?

[Bogtha]

Could you actually read my comment all the way through instead of stopping at the first few words and assuming I don't know what a web app is? I've been writing web apps for about 15 years. You don't have to explain to me how they work.

the operator of the Web app would've had to copy the AGPL'd software onto their server. They can't make that copy without a license.

As I stated in the comment you replied to, this is something that is explicitly excluded from copyright protection in the USA, so why do they need a license?

My question is not "hur dur, what's a web app?", it's "copyright in the USA doesn't provide them with enough power to enforce this as far as I can see, so what gives?"

Re:How does copyright cover non-copying?

[Todd Knarr]

Well, you can use AGPL'd software without needing to agree to the terms. What it doesn't allow is for you to let other people use it. Which has precedent in copyright law: if I buy a copy of the score for a piece of music I can play it in my home without needing a license, but I can't go and perform it publicly without getting an additional license to do so and usually paying a royalty for each performance.

C'mon. That's moronic

[Anonymous Coward]

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

Sigh. Just the usual red herring.

You never know how useful those changes might be to others.

Besides, if you're that bad at coding that knowing your table names yields a vector of attack... you should probably better leave that to others.

Re:C'mon. That's moronic

[dgatwood]

You never know how useful those changes might be to others.

Yes, I do. Unless someone steals the closed-source authentication system in question, tying into it is not useful in the slightest.

Besides, if you're that bad at coding that knowing your table names yields a vector of attack... you should probably better leave that to others.

If you think that not knowing the table names does not make all vectors of attack more difficult, you should probably leave the advice to people who understand security. :-)

In computer security (or any security, for that matter), the best defense is a layered defense . I'm quite good at performing security audits, having spent significant amounts of time over the years doing so. However, any sufficiently large chunk of code, no matter how well analyzed, stands some small risk of containing security holes. So in the event that I missed something, using nonstandard table names provides an additional defensive layer that makes any sort of compromise considerably more difficult.

Implicit right to audit

[Anonymous Coward]

The Affero GPL gives parties the implicit right to audit your software code. If you run affero, you might find a bailiff at your door serving an order for an inspection of your server.

Berkeley DB is a steaming POS

[Anonymous Coward]

who cares. the sooner it gets killed off the better

Re:Berkeley DB is a steaming POS

[physburn]

No Berkeley DB is a fine piece of kit, i spent several months building a web forum system with Berkeley DB as the database. It worked fine, Berkeley did exactly what the API promised with no extra messing about needed. I would recommend Berkeley for simple NoSQL applications.

Re:Berkeley DB is a steaming POS

[hyc]

You would be doing anyone you make such a recommendation to a disservice. BerkeleyDB was a nice piece of work for the 1980s. It is totally outclassed by LMDB today.

It's a Bug

[Somebody Is Using My]

Don't worry, I'm sure that in a few days Oracle will announce that this change was just a bug, just like when they did it with the MariaDB man pages a few weeks back. It's all an innocent mistake made by their software. Oracle is our friend and only has the best of intentions for everything it does.

(The above was intended to be somewhat tongue-in-cheek; I have no real opinion of the change or whether it is good or bad for the end-uses. It just amuses me that Oracle would attempt something like this after getting spanked for a similar change they made just a few weeks back. Did they think nobody would notice? They don't have such a good reputation to begin with; better to be above-board rather than try to silently slip in a new re-licensing).

AGPL != AGPL3

[wiredlogic]

The AGPL in question is actually AGPL3 (implemented using the GPL3 extension mechanism). AGPL is a derivative of GPL2.

Do they actually have the legal right?

[tlambert]

Oracle clearly has the legal right to do what they are doing, and there is no morality in business, so that is the only right that matters.

Do they actually have the legal right? I contributed patches to BDB 1.0; I don't remember being asked for an assignment of rights so that they could legally change the license. The SleepyCat license only applied to the newer code added by Margo, which, if you wanted to use the newer code, you accepted the license on the aggregate work, and if not, you could excise the new work from the code by using an older version.

It's not clear to me from TFA exactly what the license change means, or if this is merely hand-wringing, since so far it has not changed the tar ball contents, and therefore the license declaration within the tar ball. However, if their intent is to relicense *all* the code, not just the SleepyCat portion of the new code, then that's a problem.

From one weird license to another

[Anonymous Coward]

Depending on your application, this could be a good thing or a bad thing, mainly for commercial works. Under Sleepycat:

Redistributions in any form must be accompanied by information on how to obtain complete source code for the DB software and any accompanying software that uses the DB software.

This is more aggressive than the traditional GPL view of linking, where function calls count as linking but IPC and sockets don't.

Oracle, of course, takes a very broad view of "accompanying software" and "uses the DB software"; if you distributed something like a virtual machine image with a proprietary PHP frontend to a Cyrus IMAP server (which uses BDB), then Oracle would say that the PHP frontend must be open sourced or paid for with a license, even though the PHP frontend is just using a generic IMAP connection and is in no way a derivative work of the IMAP server.

The AGPL is not as viral when it comes to traditional software distribution, but it does impose distribution requirements on user-facing server software that pwouldn't have been under the GPL.

I can't really begrudge Oracle for trying to make money off of BDB; rather, I blame free software developers for unwittingly using a license that has always been more viral than the GPL, especially for projects like Python that were never GPL to begin with. I think this is because Oracle never enforced the licensing restrictions against fully free software projects, just against ones that mixed commercial and free components.

Full disclosure: the company I worked for had to pay Oracle a bunch of money every year for licensing BDB.

Berkely db doesn't come standard with java.

[Anonymous Coward]

There is a database included in the jdk called javadb. Same as derby, which came from cloudscape.

SQLite

[Anonymous Coward]

Is still unencumbered, correct? Sad to see yet another 'classic' piece of code go the way of the dodo due to greedy companies.

Serial killer..

[h8sg8s]

Larry kills another one. The ultimate bait-and-switch operation is Oracle.

Never trust Oracle

[Anonymous Coward]

If you are using anything Oracle could exert any legal argument over, stop using it immediately. Look at the Federal Government, they are running away from it at light speed so that now you much show a major justification to use any Oracle products. Even the Feds have been screwed too many times by this company. So if you are using anything that they can exert a legal claim to - switch to something else. This is a company best killed...

Just now many databases....

[Anonymous Coward]

Just now many databases do these wankers own anyway?