[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Berkeley DB 6.0 license change to AGPLv3


On Wed, Jul 3, 2013 at 5:34 PM, Bradley M. Kuhn <bkuhn@ebb.org> wrote:
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

  (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?

I don't think that neither (a) nor (b) is the core issue here.

I might have missed one important point in my first email. We want to keep just one (default) Berkeley DB version in each Debian release for practical reasons (maintainers sanity, mutual compatibility, etc.). So, you need to view the issue from a perspective of picking just one Berkeley DB version.

I think the core issue apart from (c) is:

(d) Is it ok to switch 106 source packages and their reverse depends to AGPLv3?

And the answer here is clearly "No" for two reasons.

1) I think this should be made with consent of upstream authors
2) We need to pick the Berkeley DB version compatible with all packages that use the library.

And from quick scan of http://ftp-master.metadata.debian.org/changelogs/main/$L/$P/unstable_copyright:

389-ds-base: GPLv2-only
apr-util: Apache 2.0
boxbackup: 4-clause BSD
canl-c++: Apache 2.0
clisp: GPLv2-only
cyrus-imapd-2.4: 4-clause BSD
cyrus-sasl2: 4-clause BSD
dovecot (parts): 4-clause BSD
evolution-exchange: GPLv2-only
exim: sasl parts are 4-clause BSD[1]
gqcov: GPLv2-only
gridengine: tcsh parts under 4-clause BSD, rest is SISSL[2]
hpsockd: GPLv2-only
iproute2: GPLv2-only
jabberd2: GPLv2-only
jigdo: GPLv2-only
kamailio: OpenSSL parts with advertising clause
ldiskfsprogs: GPLv2-only
libqxt: contains file with LGPL2.1-only
lucene2: Apache 2.0
moc: GPLv2-only
netatalk: GPLv2-only file[3]
nordugrid-arc: Apache 2.0
nvi: 4-clause BSD
pavuk: advertising clause
php5: PHP License 3.01[4]
postfix: IBM PUBLIC LICENSE 1.0[5]
prayer: cyrus-imap parts under 4-clause BSD
radiusd-livingston: 4-clause BSD
redland: Apache 2.0
reprepro: GPLv2-only
rpm: lib/merge.c is 4-clause BSD[1]
spamprobe: QPL[6]
squidguard: GPLv2-only
subversion: Apache 2.0
wvstreams: LGPLv2.1-only
zeroc-ice: GPLv2-only

This list is by no means complete or 100% correct. There might be oversights and/or bugs in debian/copyrights (BTW the machine readable copyrights would help here).

All those listed packages would have to stop using Berkeley DB (or relicense) before we could make the switch to Berkeley DB 6.0. The rest of the packages (especially the networked ones) would have to comply with AGPLv3 before we could make the switch to default Berkeley DB 6.0.
This applies also for all the packages further down the tree (e.g. libsasl2 users if we keep the sasldb plugin[7])

1. BTW this links 4-clause BSD with GPL code within the same source
2. SISSL is not GPL compatible according to Wikipedia
3. And a couple of files under UNKNOWN license :)
4. AFAIK GPL-incompatible
5. http://www.gnu.org/licenses/license-list.html#IBMPL
6. http://www.gnu.org/licenses/license-list.html#QPL
7. However this case might be the borderline case as outlined here: http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

Ondřej Surý <ondrej@sury.org>

Reply to: