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:
- 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 freswa@archlinux.org wrote:
On Mon, Dec 12, 2022 at 07:14:42PM +0100, Balló György wrote:
- 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.
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 freswa@archlinux.org wrote:
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.
arch-dev-public@lists.archlinux.org