I have noticed freswa has bumped BerkeleyDB to v6 (again) and started pushing rebuilds to staging repo. Arch Linux had made this update already in August 2013 and discussions lead us to revert this back quickly: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... Here you can find some thoughts why 3rd party applications may not be legally compatible to use the AGPLv3 licensed BDB v6: https://lwn.net/Articles/557820/ https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 It's pretty questionable if someone is allowed to build and redistribute packages against the newly AGPLv3 licensed BDB version without checking and probably changing related application licenses. But I'm not a lawyer. Most major Linux distributions still stick with BDB v5 therefore. So we did back then in 2013 until now. Some distributions have added v6 along v5 and only use it carefully when upstream projects declare their license AGPLv3 compatible to be usable with later BDB versions. Two major concerns I have here: 1) No public discussion happened here or somewhere else before such a major change. The packager will have known there's something special with such a long flagged package in core. All major changes affecting the core repo should really go through some discussion before they happen. 2) I've immediately raised my concerns pinging freswa at IRC and only see today the rebuilds went ahead and keep going on. That's not how our team should deal such maybe critical step. I don't want to imagine Arch spending all funded money for some curt fights we could easily avoid here. Please start some public discussion why this change happened and why the concerns of other distributions and our own developers are not worth to take a small break to think about it again. -Andy
On Sun, Dec 11, 2022 at 08:46:07PM +0100, Andreas Radke wrote:
I have noticed freswa has bumped BerkeleyDB to v6 (again) and started pushing rebuilds to staging repo.
I've checked every affected package for it's license: 389-ds-base: GPLv3+ https://github.com/389ds/389-ds-base/blob/main/LICENSE.GPLv3%2B apr-util Apache 2.0 https://github.com/apache/apr/blob/trunk/LICENSE bogofilter GPLv2 and v3 mixed https://gitlab.com/bogofilter/bogofilter/-/blob/main/bogofilter/COPYING dsniff BSD https://github.com/tecknicaltom/dsniff/blob/master/LICENSE evolution-data-server LGPLv2 All source files contain "under the terms of the GNU Lesser General Public License" COPYING file contains GPLv2: https://gitlab.gnome.org/GNOME/evolution-data-server/-/blob/master/COPYING gnucobol GPLv3 and LGPLv3 https://sourceforge.net/p/gnucobol/code/HEAD/tree/trunk/README https://sourceforge.net/p/gnucobol/code/HEAD/tree/trunk/COPYING inn INN, GPLv2+, Public Domain, BSD, BSD-2, MD5 https://github.com/InterNetNews/inn/blob/main/LICENSE iproute2 GPLv2 https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/COPYING isync GPLv2+ All src files contain "the Free Software Foundation; either version 2 of the License, or (at your option) any later version." https://sourceforge.net/p/isync/isync/ci/master/tree/LICENSES/GPL-2.0-or-lat... jack2 linux subfolder: LGPLv2.1 and GPLv2+ dbus subfolder: GPLv2 jack2-dbus doesn't link against libdb, only libjackserver.so and libjack.so do. => Linking happends between LGPLv2.1 and AGPLv3 src: https://github.com/jackaudio/jack2 jnettop GPLv2 Main homepage seems to be down, but there are mirrors, for example: https://github.com/jwilk-mirrors/jnettop/blob/trunk/COPYING libical MPL or LGPL2.1 https://github.com/libical/libical/blob/master/COPYING neomutt GPLv2+, GPLv3 See src files. https://github.com/neomutt/neomutt/blob/main/LICENSE.md opendkim BSD and sendmail https://github.com/trusteddomainproject/OpenDKIM/blob/master/LICENSE https://github.com/trusteddomainproject/OpenDKIM/blob/master/LICENSE.Sendmai... perl GPLv1+ https://github.com/Perl/perl5/blob/blead/README perl-berkeleydb Perl https://metacpan.org/pod/BerkeleyDB php PHP https://github.com/php/php-src/blob/master/LICENSE php7 PHP https://github.com/php/php-src/blob/master/LICENSE postfix EPL https://de.postfix.org/ftpmirror/index.html python-bsddb BSD-3 https://github.com/underrun/pybsddb/blob/master/LICENSE.txt reprepro GPLv2 https://salsa.debian.org/debian/reprepro/-/blob/debian/COPYING skktools GPLv2+ and GPLv3 See src files here: http://openlab.ring.gr.jp/skk/tools/ License: http://openlab.jp/skk/skk/main/READMEs/COPYING squid GPLv2+ See src files. https://github.com/squid-cache/squid/blob/master/COPYING subversion Apache2 swi-prolog BSD https://github.com/SWI-Prolog/swipl-devel/blob/master/LICENSE As far as I understand, the main concern is linking GPLv2 against AGPLv3. Thus I'd propose to create db5.3 for the GPLv2 only projects: bogofilter iproute2 jnettop reprepro Best regards, Frederik
2022. 12. 12, hétfő keltezéssel 17.16-kor Frederik Schwan ezt írta:
As far as I understand, the main concern is linking GPLv2 against AGPLv3. Thus I'd propose to create db5.3 for the GPLv2 only projects:
bogofilter iproute2 jnettop reprepro
I seems to me it's not enough. Probably all dependent packages must be compatible with the AGPLv3 license, not just those packages which specify BerkeleyDB as a dependency explicitly. -- György Balló Trusted User
On Mon, Dec 12, 2022 at 07:14:42PM +0100, Balló György wrote:
2022. 12. 12, hétfő keltezéssel 17.16-kor Frederik Schwan ezt írta:
As far as I understand, the main concern is linking GPLv2 against AGPLv3. Thus I'd propose to create db5.3 for the GPLv2 only projects:
bogofilter iproute2 jnettop reprepro
I seems to me it's not enough. Probably all dependent packages must be compatible with the AGPLv3 license, not just those packages which specify BerkeleyDB as a dependency explicitly.
Good point. That adds a few to the list: bogofilter iproute2 jnettop reprepro inn (links against pam) jack2 (depends on dbus) neomutt (didn't check, depend on libdb can be removed probably) subversion (depends on lz4) swi-prolog (depends on gperftools -> libunwind) These are fine: isync (depends are BSD, GPLv3 and zlib) libical (depends on LGPLv2, MIT, BSD, zlib, GPLv3) opendkim (depends on BSD, OpenLDAP Public, cyrus-sasl, LGPLv2) postfix (depends on openssl, cyrus-sasl, zlib) skktools (depends on GPLv3 and LGPLv2, MIT, BSD) evolution-data-server and squid have been moved away from bdb in the meantime.
What is the latest news on this? I noticed PHP was patched for db-6
and later on db support was removed completely. Will the db/db5
package be dropped entirely?
Greetings,
Pierre
On Mon, Dec 12, 2022 at 8:16 PM Frederik Schwan
On Mon, Dec 12, 2022 at 07:14:42PM +0100, Balló György wrote:
2022. 12. 12, hétfő keltezéssel 17.16-kor Frederik Schwan ezt írta:
As far as I understand, the main concern is linking GPLv2 against AGPLv3. Thus I'd propose to create db5.3 for the GPLv2 only projects:
bogofilter iproute2 jnettop reprepro
I seems to me it's not enough. Probably all dependent packages must be compatible with the AGPLv3 license, not just those packages which specify BerkeleyDB as a dependency explicitly.
Good point. That adds a few to the list: bogofilter iproute2 jnettop reprepro
inn (links against pam) jack2 (depends on dbus) neomutt (didn't check, depend on libdb can be removed probably) subversion (depends on lz4) swi-prolog (depends on gperftools -> libunwind)
These are fine: isync (depends are BSD, GPLv3 and zlib) libical (depends on LGPLv2, MIT, BSD, zlib, GPLv3) opendkim (depends on BSD, OpenLDAP Public, cyrus-sasl, LGPLv2) postfix (depends on openssl, cyrus-sasl, zlib) skktools (depends on GPLv3 and LGPLv2, MIT, BSD)
evolution-data-server and squid have been moved away from bdb in the meantime.
-- Pierre Schmitz, https://pierre-schmitz.com
On Wed, Dec 14, 2022 at 10:56:30AM +0100, Pierre Schmitz wrote:
What is the latest news on this? I noticed PHP was patched for db-6 and later on db support was removed completely. Will the db/db5 package be dropped entirely?
I removed db support where it seemed like a proper solution. For PHP I couldn't find any application in our repos nor in the (maintained) wild relying on it. In general the goal from 2013 to deprecate db entirely still stands. Though some applications don't give us a choice. I'll move the rebuilds to testing later today. I plan to keep them there for a couple of days to check if I missed some use cases (e.g. for PHP). If all goes well, I'll work on bumping db to v18 afterwards.
Thanks for looking into it. I am fine with removing db support as it
is really unlikely someone wants to use it with a modern PHP.
On Wed, Dec 14, 2022 at 11:24 AM Frederik Schwan
On Wed, Dec 14, 2022 at 10:56:30AM +0100, Pierre Schmitz wrote:
What is the latest news on this? I noticed PHP was patched for db-6 and later on db support was removed completely. Will the db/db5 package be dropped entirely?
I removed db support where it seemed like a proper solution. For PHP I couldn't find any application in our repos nor in the (maintained) wild relying on it. In general the goal from 2013 to deprecate db entirely still stands. Though some applications don't give us a choice. I'll move the rebuilds to testing later today. I plan to keep them there for a couple of days to check if I missed some use cases (e.g. for PHP).
If all goes well, I'll work on bumping db to v18 afterwards.
-- Pierre Schmitz, https://pierre-schmitz.com
participants (4)
-
Andreas Radke
-
Balló György
-
Frederik Schwan
-
Pierre Schmitz