Discussion:
Bug#987013: Release goal proposal: Remove Berkeley DB
(too old to reply)
Bastian Blank
2021-04-15 16:20:02 UTC
Permalink
Package: release.debian.org
Severity: wishlist

Hi

I would like to propose a release goal:

Remove Berkeley DB (finally)

Berkeley DB was relicensed to AGPLv3 almost eight years ago. Since
then, Debian stayed with the last version before the license change.
The license change means, we can't take upstream patches, so security
support is only provided by other distributions with in the same state.

After this time we really should try to get rid of this package, which
even is NMU maintained since three years.

Affected source packages to remove:
- db-defaults
- db5.3

Bastian
Martin Zobel-Helas
2021-04-16 08:00:01 UTC
Permalink
Hi,
Post by Bastian Blank
Package: release.debian.org
Severity: wishlist
Hi
Remove Berkeley DB (finally)
Berkeley DB was relicensed to AGPLv3 almost eight years ago. Since
then, Debian stayed with the last version before the license change.
The license change means, we can't take upstream patches, so security
support is only provided by other distributions with in the same state.
After this time we really should try to get rid of this package, which
even is NMU maintained since three years.
- db-defaults
- db5.3
I second this proposal.

Best regards,
Martin
--
Martin Zobel-Helas
Technischer Leiter Betrieb
Tel.: +49 2166 9901-0
Fax: +49 2166 9901-100
E-Mail: martin.zobel-***@credativ.de
pgp fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
http://www.credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
GeschÀftsfÌhrung: Dr. Michael Meskes, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz
Gerardo Ballabio
2021-04-16 08:40:02 UTC
Permalink
Post by Bastian Blank
Berkeley DB was relicensed to AGPLv3 almost eight years ago.
Sorry but I don't understand, why is that a problem?
I believe the AGPL (you mean the GNU Affero General Public License,
right?) is a free license. Is it not?

Gerardo
Bastian Blank
2021-04-16 18:20:01 UTC
Permalink
Hi Gerardo
Post by Gerardo Ballabio
Post by Bastian Blank
Berkeley DB was relicensed to AGPLv3 almost eight years ago.
Sorry but I don't understand, why is that a problem?
I believe the AGPL (you mean the GNU Affero General Public License,
right?) is a free license. Is it not?
Yes, the AGPLv3 is a free license.

However the freeness is not the problem here. The problem is the AGPL,
it's extended source provisions, the incompatibility with the license of
existing software and also a bit "Oracle".

The AGPL was created for network services. It requires to provide the
source to anyone accessing it via network. So this is tailored for the
services themselves, not arbitrary libraries deep within the dependency
chain. There where a lot of discussions about this problems at the
time.[1]

So even if we would switch to a current version of Berkeley DB, we would
need to do the same work to make sure every software that uses it is in
compliance with the AGPL. AFAIK every distribution either stayed with
BDB 5.3 and often just removed it's use as much as possible or just
killed it alltogether.

Regards,
Bastian

[1]: https://lwn.net/Articles/557820/
--
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3
Gerardo Ballabio
2021-04-19 07:50:02 UTC
Permalink
Thanks for your explanation.

Gerardo

Il giorno ven 16 apr 2021 alle ore 20:09 Bastian Blank
Post by Bastian Blank
Hi Gerardo
Post by Gerardo Ballabio
Post by Bastian Blank
Berkeley DB was relicensed to AGPLv3 almost eight years ago.
Sorry but I don't understand, why is that a problem?
I believe the AGPL (you mean the GNU Affero General Public License,
right?) is a free license. Is it not?
Yes, the AGPLv3 is a free license.
However the freeness is not the problem here. The problem is the AGPL,
it's extended source provisions, the incompatibility with the license of
existing software and also a bit "Oracle".
The AGPL was created for network services. It requires to provide the
source to anyone accessing it via network. So this is tailored for the
services themselves, not arbitrary libraries deep within the dependency
chain. There where a lot of discussions about this problems at the
time.[1]
So even if we would switch to a current version of Berkeley DB, we would
need to do the same work to make sure every software that uses it is in
compliance with the AGPL. AFAIK every distribution either stayed with
BDB 5.3 and often just removed it's use as much as possible or just
killed it alltogether.
Regards,
Bastian
[1]: https://lwn.net/Articles/557820/
--
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3
Marco d'Itri
2021-04-16 15:10:01 UTC
Permalink
Post by Bastian Blank
After this time we really should try to get rid of this package, which
even is NMU maintained since three years.
I am not persuaded. I maintain libberkeleydb-perl and it works fine, it
is mature software.

But even if we agree that all the libdb5.3 reverse dependencies must
migrate to a different database then probably we will need to keep
around db5.3-util (and its dependency libdb5.3) to allow dumping and
restoring the databases.
Not all software uses libdb as a cache which can just be regenerated
and/or supports multiple databases and has internal dump/restore tools.

And then all the packages currently depending on libdb5.3 will need to
implement, or at least document, a transition strategy.
Let me just mention postfix (easy), inn2 (possible but very resources
intensive) and slapd (I am not sure, but it is critical and scary).
--
ciao,
Marco
Bastian Blank
2021-04-16 18:40:02 UTC
Permalink
Hi Marco
Post by Marco d'Itri
Post by Bastian Blank
After this time we really should try to get rid of this package, which
even is NMU maintained since three years.
I am not persuaded. I maintain libberkeleydb-perl and it works fine, it
is mature software.
Mature and unmaintained are not opposites. It works, but this does not
mean it's advised to be used, especially if it works on untrusted data.
(I the time I installed by current notebook, Linux 4.0 was the current
version. It would still work, but would you really still use it on the
internet?)
Post by Marco d'Itri
And then all the packages currently depending on libdb5.3 will need to
implement, or at least document, a transition strategy.
My first goal would be to drop it from base packages, so not every
system out there needs to have it installed.
Post by Marco d'Itri
Let me just mention postfix (easy), inn2 (possible but very resources
intensive) and slapd (I am not sure, but it is critical and scary).
postfix is easy. Would inn2 be license compliant with a AGPL licensed
BDB, aka able to provide the source to it's users, or what is the plan
anyway? slapd defaults to LMDB since several years and you need to
explicitely specify the bdb or hdb backend.

Regards,
Bastian
--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6
Marco d'Itri
2021-04-16 20:40:01 UTC
Permalink
Post by Bastian Blank
postfix is easy. Would inn2 be license compliant with a AGPL licensed
BDB, aka able to provide the source to it's users, or what is the plan
anyway?
The plan is to continue using 5.3, not upgrading.
Post by Bastian Blank
slapd defaults to LMDB since several years and you need to
explicitely specify the bdb or hdb backend.
Sure, but the point was how to convert existing systems.
--
ciao,
Marco
Adrian Bunk
2021-05-09 18:10:02 UTC
Permalink
Post by Marco d'Itri
Post by Bastian Blank
postfix is easy. Would inn2 be license compliant with a AGPL licensed
BDB, aka able to provide the source to it's users, or what is the plan
anyway?
The plan is to continue using 5.3, not upgrading.
Post by Bastian Blank
slapd defaults to LMDB since several years and you need to
explicitely specify the bdb or hdb backend.
Sure, but the point was how to convert existing systems.
As far as I can see, the realistic best case would be to drop
Berkeley DB *after* bookworm.

For usages that are not just build-time tests or temporary caches,
we need at least one release for migrating the data of our users.

apt-listchanges is using Berkeley DB through Python (#988090).
This is one global database, and the user-friendly way of migration
would be either in the maintainer scripts during the upgrade to bookworm
or at runtime when the version in bookworm discovers a legacy Berkeley
DB database.

If Python in bookworm would not be able to read legacy Berkeley DB
databases, we would be screwing our users by not being able to offer
them automatic migrations in packages like apt-listchanges.

I maintain bogofilter (a spam filter). It would be feasible to implement
a transparent migration from Berkeley DB to a different format in
bookworm, but this requires a bogofilter tool compiled against libdb5.3
in bookworm.

Which would not be possible without libdb5.3 in bookworm.
Post by Marco d'Itri
ciao,
Marco
cu
Adrian

Niko Tyni
2021-05-05 19:00:02 UTC
Permalink
Post by Bastian Blank
Post by Marco d'Itri
And then all the packages currently depending on libdb5.3 will need to
implement, or at least document, a transition strategy.
My first goal would be to drop it from base packages, so not every
system out there needs to have it installed.
Hi, please note that there's a number of indirect users of libdb via
interpreter packages - at least Perl, presumably Python too.

Given perl gets installed on almost all systems, this seems to to be
on the path to the first goal.

For the perl core, the libdb5.3 bindings are exposed with the DB_File
module. I think this is the only place but have not cross-checked that.
(The libberkeleydb-perl package is an entirely separate matter AIUI.)

I see 110 source packages in Debian matching DB_File. The list will
need to be inspected manually to weed out false positives. The remaining
packages need to be changed before perl can drop its libdb5.3 dependency.
I suppose this will also need a long list of Breaks declarations on the
perl side.

Then there's user code too. I also think we'll need at least a dumper
utility so that users can migrate their data manually when they discover
their program no longer works after upgrading.
--
Niko Tyni ***@debian.org
Matthias Klose
2021-05-06 05:40:02 UTC
Permalink
Post by Niko Tyni
Post by Bastian Blank
Post by Marco d'Itri
And then all the packages currently depending on libdb5.3 will need to
implement, or at least document, a transition strategy.
My first goal would be to drop it from base packages, so not every
system out there needs to have it installed.
Hi, please note that there's a number of indirect users of libdb via
interpreter packages - at least Perl, presumably Python too.
Given perl gets installed on almost all systems, this seems to to be
on the path to the first goal.
For the perl core, the libdb5.3 bindings are exposed with the DB_File
module. I think this is the only place but have not cross-checked that.
(The libberkeleydb-perl package is an entirely separate matter AIUI.)
I see 110 source packages in Debian matching DB_File. The list will
need to be inspected manually to weed out false positives. The remaining
packages need to be changed before perl can drop its libdb5.3 dependency.
I suppose this will also need a long list of Breaks declarations on the
perl side.
Then there's user code too. I also think we'll need at least a dumper
utility so that users can migrate their data manually when they discover
their program no longer works after upgrading.
For Python, the dbm/ndbm.py module, based on the _dbm extension is also
affected. You can build the _dbm extension using libgdbm-compat-dev, however
that changes the on-disk format, and the license used (likely the new one should
be moved into the python3-gdbm package).

Matthias
Loading...