Debian, Berkeley DB, and AGPLv3

Oracle recently released an update to the Berkeley DB (BDB) library, and near the end of that announcement was a line noting a change in licensing, moving from the project's historical Sleepycat License to the GNU Affero GPLv3 (AGPL). Some in the free software community smell trouble with the move, suspicious that Oracle is attempting to either marginalize BDB or to squeeze money out of commercial BDB users. On a more practical level, the license change has raised questions for Debian, which utilizes BDB for important components like the Apt packaging system. Any upstream license change can be a hassle, but this one has the potential to cause considerably more waves downstream.

BDB originated in the official BSD from the University of California, Berkeley, and its simple architecture has made it popular for quite a few free software projects that need database functionality, but are not interested in SQL. Sleepycat Software was formed to develop and extend BDB in response to a request from Netscape, which was interested in developing a BDB-based LDAP server. The Sleepycat License, subsequently selected for the code, is similar to the GPL in that it requires corresponding source distribution (or a source code offer) to accompany binary distributions of the software. It is distinct from the BSD license, it qualifies as both open source and as free software, and is compatible with the GPL. Nevertheless, Sleepycat Software also made BDB available under proprietary terms, primarily to customers who did not want to release the source code to their own commercial products.

Oracle acquired Sleepycat Software in 2006 and, with it, the copyright to BDB. Since 2006, Oracle has continued to offer BDB under both the Sleepycat and proprietary licenses; that only changed with the BDB 6.0 release on June 10, which moved to a choice between the AGPLv3 and a proprietary license. The primary difference is that AGPL's copyleft provision is considerably stronger, because it triggers a source code requirement whenever the licensed software is accessed "remotely through a computer network". Ondřej Surý drew attention to the move on the debian-devel list in July, worried that under AGPL, BDB will be headed "to oblivion" as other projects drop it in favor of other lightweight databases.

Consequently, Surý said, Debian has a decision to make about its future relationship with BDB. The project could stick with the last Sleepycat-licensed release (version 5.3), at least for the time being, but perhaps indefinitely. It could also remove BDB entirely, perhaps replacing it with another database library, or writing a BDB wrapper around some other library. Or it could simply package up the new BDB 6.0 release and relicense the downstream software that relies on it. He suggested looking at Kyoto Cabinet as one possible replacement. Finally, he noted that "the most prominent users of Berkeley DB are moving away from the library anyway, so this might not be a big deal after all." Those users being the Cyrus IMAP server, OpenLDAP, and Subversion.

Upstream/downstream

One might well ask why a "decision" needs to be made at all. The previous release of BDB (version 5.3) is still available, and many projects who have been using it for years may see no compelling reason to upgrade to 6.0 anyway. Plus, as several on the list, such as Paul Tagliamonte, pointed out, AGPL clearly meets the Debian Free Software Guidelines (DFSG); there is no reason why it has to be removed from the archive. On the other hand, the AGPL has its critics—for instance, Bernhard R. Link contended that its requirement for source distribution for remote network access prevents people from running the software if (for example) they have modified it to include passwords or other confidential data.

Link's interpretation of the AGPL is, to say the least, exceedingly broad. The Free Software Foundation (FSF) provides some guidelines about what could accurately be described as "interacting with [the software] remotely through a computer network". Nevertheless, Link is correct to point out that there are commercial users who avoid the AGPL because they want to keep their own source code secret. Ben Hutchings pointed out that the license change may be a business tactic on Oracle's part to squeeze additional proprietary licenses out of existing BDB users, since AGPL widens the scope of activities that trigger the source requirement.

Russ Allbery also commented that AGPL was not written for libraries, and as a result has terms that are difficult to interpret for non-web-applications.

Regardless of Oracle's specific plans for the future, the most fundamental issue for Debian is the fact that Apt uses BDB. In particular, apt-get is licensed under GPLv2+, so in order to link against an AGPLv3 library, it would effectively need to be relicensed to AGPLv3. That could be a complicated process, and there are a lot of downstream tools built on top of Apt that would be affected. Surý also compiled a list of the other Debian packages that depend on BDB; while there are several that are well-known (for example, Bitcoin, Dovecot, and evolution-data-server), Apt is maintained by the Debian community itself.

Bradley Kuhn chimed in to suggest that there are in fact three separate issues at hand, which could be unintentionally conflated if not addressed separately. First, there is the question of whether the AGPL is an acceptable license for packages Debian includes. Second, there is the question of whether including a core library like BDB under the AGPL has ripple effects that are undesirable from Debian's perspective, particularly with regard to combining BDB with other programs. Third is whether Oracle's "history of abusive copyleft enforcement (by refusing to allow full compliance as an adequate remedy and demanding the purchase of proprietary licenses by license violators)" makes the new BDB too dangerous for Debian and downstream projects. The first question is a clear yes, he said, while the second is a policy decision for Debian as a project. But the third is more difficult.

In particular, he said, the fact that Oracle is now the sole copyright holder (at least on all changes since the acquisition) gives it considerable power in the event that Oracle brings a license-violation suit to court. In litigation, the interpretation of the license becomes the issue (presumably in an AGPL case, the "interacting with [the software] remotely through a computer network" clause in particular). To that end, Kuhn suggested the unorthodox solution of forking the new, 6.0-era BDB code and continuing to improve it without Oracle's help. Such a new project could also aid the targets of Oracle AGPL-violation lawsuits, offering a valid alternative interpretation of the license.

Surý replied that there is a fourth issue: whether Debian should unilaterally relicense all the BDB-dependent packages (at least, all of those packages that can be relicensed), rather than letting the upstreams worry about that themselves. To that point, Kuhn clarified what is a frequently-misunderstood issue: when Debian releases its distribution, the combined work that it constitutes can be relicensed without relicensing any of the original upstream packages. In other words, if Debian builds and links BIND 9 (which is under the BSD-like ISC license) against the AGPL'ed BDB 6.0, the resulting BIND 9 binaries would be under the AGPL, but that new license only flows downstream to subsequent redistributions of Debian.

Then again, Kuhn continued, in the long term such relicensing issues are out of Debian's hands—the upstream projects themselves are all impacted by the BDB license change, and will all have to make their own decisions about how to move forward. Similarly, Hutchings noted that if an upstream has already made the decision to remain GPLv2-only, then that project has already taken a stance with regard to relicensing; those projects are unlikely to relicense their code now.

Apt questions

Still, as Surý commented in his reply to Kuhn, from a practical standpoint Debian only wants to include one version of BDB in its archive, so it must choose which. And since Apt is so central to Debian, that may very well determine the direction that the distribution takes.

David Kalnischkies pointed out how little of the Apt family is actually dependent on BDB; a single component uses BDB to cache the contents of .deb packages. Essentially none of the Debian project infrastructure still relies on BDB either, he said, outside of "'just' 'some' derivatives". So migrating to a new database would be a plausible option. On the other hand, he said, "it's more likely that hell freezes over than that we track down every contributor since 1997 to ask for an agreement for a license change". Relicensing Apt itself would also force downstream projects built on top of Apt to consider their own license change.

It would seem, then, that migrating Apt to a different database library would be the preferable option. Dan Shearer considered BDB features, saying that "there are many KVP (key value pair) stores not many are transactional, allow multi-version concurrency control and support multi-threaded and multi-process access." He recommended taking a look at OpenLDAP's Lightning Memory-Mapped Database (which is alternatively referred to as LMDB or MDB), but said the outstanding question was whether MDB's primary maintainer, Symas, was "likely to do what Oracle just did to BDB". Symas's Howard Chu responded to say that MDB was under the control of OpenLDAP, not Symas itself, and that the project required no copyright assignment from contributors. Consequently, the company would not be in the position to relicense MDB itself if it wanted to, and it has no interest in doing so anyway.

Of course, Chu's point about holding copyright is relevant as Debian considers moving to a different database. But Michael Banck pointed out that Oracle has not been the only contributor to BDB over the years. Banck was initially suggesting that the mix of code from inside and outside Oracle might not be relicensable. Upon further inspection, it does seem like the combination can be relicensed, but Kuhn suggested taking nothing for granted. "It's probably a good idea for someone to carefully verify these facts. The community shouldn't assume Oracle got all this right."

After all, Oracle does have a reputation for pressuring customers into buying proprietary licenses with some parts of the community; Kuhn at least has spoken about that issue in the past. Certainly those licenses do not come cheap, either. The company's June 2013 price list [PDF] ranges from US $900 to $13,800 for proprietary BDB licenses—per processor. Regardless of the price tag consideration, however, the simple act of swapping one license for another is a major disruption. All of the open source projects that, like Debian, rely on BDB are now faced with a practical dilemma (regardless of what project member may feel about Oracle, the AGPL, or copyleft). Surý summed up the situation quite succinctly when noting that he does not object to the AGPL: "The evil thing is the relicensing at the point where people depend on you, and not the license itself."