Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Back on June 10, as part of a low-key release of Berkeley DB, Oracle quietly changed the license of this important embedded database library, widely used as a key-value store within other applications.
Historically, Berkeley DB -- which Oracle acquired from Sleepycat Software -- has used an OSI-approved strong copyleft license with an effect very similar to the GPL. Under the Sleepycat License, distributing software that embedded Berkeley DB involved also providing "information on how to obtain complete source code for the DB software and any accompanying software that uses the DB software." Sleepycat's business model involved selling developers an alternative, proprietary license to Berkeley DB so that they were not subject to the requirements of the copyleft clause of the Sleepycat license.
Future versions of Berkeley DB will instead use the GNU Affero General Public License (AGPL). This is also a strong copyleft license, but with an important difference. The AGPL says "your modified version must prominently offer all users interacting with it remotely through a computer network ... an opportunity to receive the Corresponding Source of your version."
That's a significant change for Web developers using Berkeley DB for local storage. Until now, they have not had to worry much about compliance with the terms of the license because they never "redistributed" the source of their Web apps -- they were simply run on servers and accessed remotely by users. But the terms of the AGPL additionally stipulate that remote usage of the software becomes a trigger for license compliance.
To work with the new license, Berkeley DB users will need to make sure their whole Web app is compliant with the AGPL. First, they now need to make full corresponding source to their Web application available. Second, they need to ensure the full app -- previously considered an internal-use asset -- has compatible and compliant licensing. That means the whole source has to be licensed under the GPLv3 or the AGPL, as well as made available to all users.
Oracle provided no rationale for the licensing change, but it may well be intended as a spur to further proprietary licensing. To avoid all this trouble with AGPL compliance, developers can simply purchase a proprietary license to Berkeley DB from Oracle. But there alternatives. One of the largest open source users of Berkeley DB used to be OpenLDAP, but it made the decision to turn to the Lightning Memory-Mapped Database (LMDB) instead. LMDB may well be usable by existing Berekely DB applications with minimal reprogramming. Additionally, there are numerous other embedded databases, although many are SQL-based rather than simple key-value store databases.
Oracle is entirely within its rights to change the license without warning; the company owns the full copyright to the code. But many will view the change as a hostile act intended to force them into a proprietary licensing relationship with Oracle. I can't help but think this betrayal of trust will drive adoption of alternatives instead.