Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Oracle

Oracle Quietly Switches BerkeleyDB To AGPL 219

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."
This discussion has been archived. No new comments can be posted.

Oracle Quietly Switches BerkeleyDB To AGPL

Comments Filter:
  • Yawn, another fork (Score:4, Insightful)

    by binarylarry ( 1338699 ) on Friday July 05, 2013 @12:46PM (#44196353)

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

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

      • by jythie ( 914043 ) on Friday July 05, 2013 @01:13PM (#44196611)
        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.
      • by Xtifr ( 1323 ) on Friday July 05, 2013 @01:36PM (#44196851) Homepage

        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.

        • 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?

          • by batkiwi ( 137781 )

            Only if they take updates as opposed to forking it.

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

      • by jbolden ( 176878 )

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

        • by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Friday July 05, 2013 @03:22PM (#44198173) Homepage Journal
          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.
          • by jbolden ( 176878 )

            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.

  • 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 n

    • by jythie ( 914043 )
      I do not think BDB has changed much in the last two decades.... it is a pretty conservative project.
    • by jbolden ( 176878 )

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

      • 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 inc

        • by jbolden ( 176878 )

          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.

  • by magic maverick ( 2615475 ) on Friday July 05, 2013 @01:10PM (#44196577) Homepage Journal

    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.

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

  • 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 [copyright.gov] - 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

    • 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

      • by devman ( 1163205 )
        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.
        • 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 a

    • by gl4ss ( 559668 )

      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.

  • 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 ge

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

We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall

Working...