Re: Berkeley DB 6.0 license change to AGPLv3
On Wednesday, July 10, 2013 09:20:37 AM Clint Byrum wrote:
> 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.
I'm already talking with upstreams to make sure mdb is supported for packages
I maintain. I'm certainly not planning on effectively making anything AGPL.
Scott K
Reply to: