Berkeley DB relicensed to AGPLv3

Russ Allbery rra at
Thu Jul 4 18:14:52 UTC 2013

Miles Fidelman <mfidelman at> writes:

> Also, seems to be compatible with the ISC license that INN is released
> under:
> from

Note that what the FSF means by "compatible" is that you can take
ISC-liensed code and incorporate it into an AGPLv3-licensed work.  The
resulting work as a whole is then covered by the AGPLv3.

So, the way this works (at least if one uses the interpretation that a
binary linked with shared libraries is a derivative work of those shared
libraries, which is the legally conservative approach but is somewhat
controversial) is that INN as distributed by ISC remains under the same
license.  As does any build of INN that doesn't use Berkeley DB.  But a
build of INN linked with Berkeley DB is now an AGPLv3-licensed work (since
otherwise it's illegal to use Berkeley DB in it).  Anyone running that
version of INN then has to comply with the AGPLv3, which includes the
notice requirement for source code and also includes making source code

So, for instance, if you have a version of INN linked with the
AGPLv3-covered Berkeley DB and you apply some random patch, maybe from the
next version of INN, to fix some problem you're having, a conservative
reading of the license says that you now have to make available the
modified source code of INN to any client that connects to the server and
put an advertisement for how to obtain that source somewhere that clients
see.  It's not clear to me whether that can be in HELP or LIST MOTD or
whether it would need to be in the banner.

I think this is unreasonably onerous.

The AGPLv3 is trying to solve a real problem, and I have some appreciation
for the goal.  The problem it was trying to solve is that, increasingly,
computing consists of some sort of very lightweight UI shim that's
downloaded to the client (often now written in Javascript) and a server
architecture that runs as a service.  Think Amazon Web Services,
Salesforce, etc.  This is a great way of dodging out of GPL requirements,
since Amazon (for example) can use GPL software all they want internally
to construct those applications without having to provide source code to
anyone since they never actually distribute the software, just run it on a
server.  If one is concerned with keeping people from using GPL-covered
software to create proprietary software that users don't get the source
code to, that's a fairly huge hole.

INN at least superficially could fall into the same category of software,
since it's a client-server model.  However:

1. No one is commercially abusing INN in this way that I'm aware of, so
   it's irrelevant for INN even if you think this is a bad thing.

2. INN was put under a permissive license that allows commercial and
   closed-source derived works for a reason.  There's an ongoing
   philosophical difference in the community about whether copyleft is a
   good idea or not, and strong arguments to be made for either side, but
   most existing software bases have picked one approach or another and
   it's considered quite bad form to change later on (not to mention often
   legally impossible to do).  For better or for ill, INN is in the
   "closed-source derived works are fine" camp (with the exception of a
   few supporting programs).

I personally therefore find it quite annoying that a license change in a
supporting library could be used to force people to treat INN as if it
were a AGPLv3-covered work.  And I also don't believe that Berkeley DB is
anything so special and important that it should warrant this level of
protection for its open source nature when used as part of the backend of
unrelated software.  I could sort of see this if the license change only
applied to some completely novel and ground-breaking database backend, but
to take basically the same software that's existed for years and years and
make the license suddenly drastically more restrictive in a way that
affects everything that's built with it strikes me as rather obnoxious.

Russ Allbery (rra at             <>

    Please send questions to the list rather than mailing me directly.
     <> explains why.

More information about the inn-workers mailing list