Re: Berkeley DB 6.0 license change to AGPLv3
Excerpts from Scott Kitterman's message of 2013-07-10 08:28:54 -0700:
> On Wednesday, July 10, 2013 05:03:20 PM Bastian Blank wrote:
> > On Wed, Jul 10, 2013 at 03:50:03PM +0200, Adam Borowski wrote:
> > > There is just one caveat: you must make sure to never, ever, distribute
> > > that piece of software, because once you do, you permanently lose your
> > > right to use it without obnoxious and potentially crippling restrictions.
> > Not right. You have to allow _access_ to it via a computer network.
> > > That's section 9 of AGPL v3.
> > Please read section 9 of GPL v3, it is identical.
> > > Per section 13, any derived software that "supports remote interaction
> > > through a computer network" must present a prominent offer to every user,
> > > no matter if that's feasible or possible.
> > You miss a vital part of this sentence: "(if your version supports such
> > interaction)". Please quote complete sentences if you try to proof
> > something.
> > > The official FTPmaster response came in #495721, and it doesn't even
> > > mention this issue, only three minor points (cost of running a webserver
> > > with sources, private use, contaminating reverse dependencies).
> > GPL also contaminates its reverse dependencies. So what? Okay, in this
> > case you actually have to do something for it.
> It's precisely the forced distribution of modifications that makes it
> unsuitable for any use that is any way security sensitive. If you take a
> GPLv3 web server (as an example) and it is built by your distributor against
> the AGPL libdb version, the combined work is effectively AGPL, which means if
> you use a local security fix on your web server, you've violated the terms
> under which you've received the code. Totally unsuitable. It doesn't matter
> if libdb supports network interaction or not.
Clause 13 again:
"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."
First off, I think the AGPL is far too vague and fails at its goals of
assuring user freedom when interacting with software over the net. If the
goal was to make sure web apps like MediaGoblin and Wordpress weren't
turned into big commercial services without giving the code back to
the users, then specific clauses would have made a lot more sense. The
vagueness of the "interacting with it remotely through a computer network"
part is particulary frustrating and has led to the AGPL being a tool
for legal bludgeoning.
Given the scenario Scott brings up above, AGPL for a webserver would be
a disaster. Thus, any plumbing/libraries/etc. are really bad candidates
for AGPL. This rather subtle imbalance is why MongoDB being AGPL leads to
10gen being able to "shake down" commercial entities who use MongoDB. They
may have thought they were getting Free software, but suddenly they have
to start considering whether or not they have to provide the source for
whatever version of MongoDB they might be running. Legally one could make
an argument that their proprietary webapp is just acting as a proxy for
the users to interact with MongoDB.
I'm not saying that argument is right, and I am not a lawyer, but I do
know that lawyers hate vagueness for this exact reason.
I do think AGPL complies with all of the clauses of the DFSG. There is
very little difference in an AGPLv3 licensed library as a GPLv3 licensed
library. Before linking, one must always check the library license. If
we do let BDB 6.0 into Debian with its new AGPL license, it is on the
BDB maintainer(s) to file RC bugs in the reverse dependencies to help
maintainers avoid accidentally shipping AGPL licensed binaries that are
not in compliance with the AGPL.