Kuhn: Berkeley DB 6.0 license change and Debian

Many people off-list have been asking me to comment on this discussion,
because (like Richard Fontana) I'm a co-author of AGPLv3, and I also
(back in the early 2000's) invented the original licensing idea behind
the AGPLv1.

I thus care deeply about the license and believe it's an important
policy plan for the future of freedom in the age of network services.
(I gave a talk at SCALE 2013 about this specific issue, if folks are
curious about that: https://lwn.net/Articles/541981/ .)

Upon catching up on this thread, I believe most of what needs to be said
about the issue for Debian's perspective has been said.  Nevertheless, I
do want to point out that I think three separate issues have been
conflated in this thread:

  (a) Is the AGPLv3 a DFSG-free license and should it remain such?

  (b) Is it a bad policy decision for Debian generally to have a core
      library, used by many other packages under AGPLv3 -- thus causing
      a move of licensing of more packages toward an effective AGPLv3
      license, due to the combining those packages with an AGPLv3'd
      library.

  (c) Even if (a) and (b) are settled in as "Yes", and "No",
      respectively: is Oracle, given its 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), too dangerous for Debian and its downstream?

On (a), I think Paul Tagliamonte has summarized the issue best:

Paul Tagliamonte wrote at 09:15 (EDT) on Tuesday:
> The AGPL is a DFSG free FSF approved and OSI approved free software
> license? We made a decision, it's *free software* and fit for main.

I too believe that issue is decided and should be left alone.


On (b), I think the discussion about apt needing to be (effectively)
AGPLv3-or-later to continue using BDB is salient.  I, for one, would
like to see such a thing, but I'm a biased party who co-authored AGPLv3
and believe in its policy goals; I'd like to see more software under
AGPLv3!  But, I also see it from the point of view of Debian developers
who might feel this sort of policy change is too drastic a move to the
strongest copyleft available.

I know that some have complained that compliance with AGPLv3 may require
more work by Debian redistributors.  That is a reasonable concern, but I
think the issue can be mitigated.  The argument is roughly analogous to
this one: complying with GPLv2 is more difficult than complying with the
Apache license.  But, unless Debian wants to take a wholesale position
opposed to copyleft, I don't think this issue is or should be considered
insurmountable.

Indeed, I think that issue is what's being considered in this exchange
between Ondřej and Fontana:

Ondřej Surý wrote at 12:20 (EDT) on Tuesday:
>> 2. AGPLv3 is incompatible with Apache 2.0 license (http://
>> www.apache.org/licenses/GPL-compatibility.html)
Richard Fontana wrote at 13:03 (EDT) on Tuesday:
>>> Only in the same sense that GPL or LGPL (any version) is
>>> incompatible with any noncopyleft license in the
>>> copyleft-to-permissive direction. The Apache License 2.0 is
>>> compatible with AGPLv3 in the other direction.

I wouldn't frame the debate as Fontana has, but I agree that there's an
issue that copyleft has a certain one-way magnetism to it (by design).
And, the stronger the copyleft, the stronger the magnet.  Once a package
has copylefted parts, the whole package must be considered to be
licensed under the strongest copyleft present.  That may be too big a
leap for apt, but again: that's a policy decision for Debian developers.

Finally, I suggest that the last issue, (c), should be decided
separately from those first two.  Even *if* programs like apt can
reasonably be placed under the AGPLv3, we know that Oracle, per its
MySQL aggression...

Ben Hutchings wrote at 09:48 (EDT) on Tuesday:
>>>> If the relicensing is real and not another misconfiguration of the
>>>> build/release system (like with MySQL docs), this sounds like a
>>>> shakedown for proprietary users of Berkeley DB.  GPLv2-licensed
>>>> users are collateral damage.

... is known to use copyleft licenses as aggressive weapons to force the
sale of proprietary licenses.  Note, however that Sleepycat had roughly
the same business model with its "copyleft license hidden behind
BSD-like" license drafting.  As such, the only *real* changes I see here
are: (0) an even stronger copyleft is being used and (1) Oracle has a
lot more resources for aggression than Sleepycat did before acquisition.

Admittedly, though, (c) is a very complex policy question, and it's
precisely why I have great trepidation when a codebase is
single-copyright-held by one for-profit company.

BTW, I'd suggest a rather unorthodox solution if developers are
interested: fork this AGPLv3'd version of BDB, and begin making
substantial improvements and changes under AGPLv3.  That way, Oracle
isn't the sole copyright holder, and if Oracle were to take action under
a clause of AGPLv3, other copyright holders could intervene and indicate
they disagreed with Oracle.  If the case went to litigation, Oracle
would have a tough time because the other copyright holders would be
expert witnesses (in the USA sense -- not sure what the equivalent is
elsewhere in the world) who were saying Oracle was acting unfairly and
over-reading the license terms.  (I'd certainly be willing to be an
expert witness as the license's co-author in such cases.)

This solution is better than forking under the old Sleepycat license,
since it will help establish estoppel against Oracle being the only
valid interpreter of AGPLv3 with regard to the BDB.  Other copyright
holders of the fork will have a big say, and perhaps a greater say than
Oracle, ultimately.  Doing that for the Sleepcat license seems somewhat
pointless, given it's not a one-off license used only (now) for old
versions of BDB.

I remain willing to assist Debian as it investigates these questions.
I'm subscribed to debian-legal and will see posts there, but please cc
me on debian-devel side, as I'm not a subscriber there.
-- 
   -- bkuhn