Check all `berkeley-db` linked dependents are AGPLv3-compatible

[cho-m]

berkeley-db had switched license from Sleepycat to AGPL-3.0-only in v6 (we are on v18). This has some restrictions on dependents that link to libdb such as requiring a compatible license. One example is that GPLv2 is incompatible (See https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0).

Most Linux repositories had intentionally kept libdb/db package at v5 to avoid (re-)licensing issues (https://repology.org/project/db/versions) e.g.

• Arch https://archlinux.org/packages/core/x86_64/db/
  • Ref: https://lists.archlinux.org/pipermail/arch-dev-public/2013-August/025307.html
• Debian https://packages.debian.org/sid/source/db5.3
  • Ref: https://lists.debian.org/debian-legal/2013/07/msg00000.html
• Fedora https://src.fedoraproject.org/rpms/libdb/tree/rawhide
  • Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1361971

I think we should make sure dependents are compatibly licensed, or modify them to meet license terms (e.g. downgrade to existing berkeley-db@4 or a new berkeley-db@5, switch to another alternative, drop dependency, relicense, etc):

• [ ] apt -- #107303
• [ ] bogofilter
• [x] dbxml -- no issue as also AGPL-3.0 -- #100471
• [ ] gnu-cobol
• [ ] heimdal -- #106344
• [ ] isync -- #107672
• [ ] jack -- #107071
• [x] jigdo -- incompatible as GPL-2.0-only. Downgrading in #100883
• [ ] libpinyin
• [x] linux-pam -- dropped dependency in #100703
• [ ] memcacheq -- #107248
• [ ] moc -- #107071
• [x] nvi -- #107073
• [ ] perl -- #107303
• [x] rpm -- dropped dependency in #100885
• [x] skktools -- switch to gdbm in #103454
• [x] swi-prolog -- #106345
• [ ] webalizer -- #107304

Other refs:

• https://en.wikipedia.org/wiki/Berkeley_DB#Licensing

[triallax]

I'd like to help, but can you define what "AGPLv3-compatible" means exactly? For instance, is GPLv3.0-or-later compatible with AGPLv3.0-only? What about GPLv2.0-or-later and AGPLv3.0-or-later, are they compatible with AGPLv3.0-only?

[SMillerDev]

See the link in the first paragraph

[triallax]

I did, but it doesn't address the -or-later vs -only nuances.

[SMillerDev]

Because it can't specify what would be in a hypothetical GPLv4. It does specify that 2 & 3 are incompatible with AGPL.

[triallax]

AGPLv3 is incompatible with GPLv2-only, but not with GPLv3 really:

It is also technically not compatible with GPLv3 in a strict sense: you cannot take code released under the GNU AGPL and convey or modify it however you like under the terms of GPLv3, or vice versa. However, you are allowed to combine separate modules or source files released under both of those licenses in a single project, which will provide many programmers with all the permission they need to make the programs they want

I'm inclined to say that AGPLv3 is compatible with GPLv2.0-or-later (not GPLv2.0-only), GPLv3.0-or-later, and AGPLv3.0-or-later, but I'm no lawyer.

[cho-m]

In case of GPL-2.0-or-later, it may need to be relicense to GPL-3.0-or-later (https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibility -- https://www.gnu.org/licenses/gpl-faq.en.html#compat-matrix-footnote-3). Similar situation with BSD-style licenses.

Debian discussion mentioned they would probably never do this for apt as they would want every contributors' confirmation https://lists.debian.org/debian-legal/2013/07/msg00017.html. Not entirely sure on situation of relicensing from Homebrew side.

Then, one thing to worry about is propagation of licensing terms on dependents. It is possible that some formulae may no longer be distributable via Homebrew based on license of dependencies, e.g. (A)GPL-3.0 library being incompatible with GPL-2.0-only and Apache-2.0 (https://www.apache.org/licenses/GPL-compatibility.html).

I would say the above is part of headache in licensing as the onus would be on Homebrew to track the licenses. Most upstreams assume Sleepycat variant of Berkeley DB due to catering to Linux distros, which have blocked Berkeley DB 6+ from entering repositories.

---

Due to above, I usually favor checking for alternatives or seeing if we can remove berkeley-db requirement.

On side note, the Fedora issue link includes some info on various packages' usage of DB: https://fedoraproject.org/wiki/User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora

The biggest problems are currently perl and jack. For example, restricting perl to GPL-3.0-or-later would require checking for compatibility with various formulae.

[triallax]

gnu-cobol and libpinyin are both licensed under GPL-3.0-or-later (at least according to the Homebrew formulae), so they should need no change.

[triallax]

According to a comment by a Jack team member from 2020, Jack supports libdb 5.3+. What do you all think about adding a berkeley-db@5 formula?

[triallax]

I opened PRs for many of the dependents of berkeley-db. The remaining ones are:

• [ ] apt: GPL-2.0-or-later, will update to depend on berkeley-db@5 (isync and webalizer are in the same situation)
• [ ] libpinyin: GPL-3.0-or-later, I think using berkeley-db should be fine, but we might want to use berkeley-db@5 anyway just in case (gnu-cobol is in the same situation)
• [ ] perl: dual-licensed under GPL-1.0-or-later and Artistic-1.0-Perl, will update to depend on berkeley-db@5
• [ ] bogofilter: no license in formula, need to check the license first

[iMichka]

I have one question: how do we enforce this, and how do we prevent maintainers from changing back to the latest version?

[triallax]

@iMichka I have no answer for the first question, but for the second one, I plan to add comments to all the places where the berkeley-db dependency was downgraded to clarify the reason. I think that should be sufficient.

[SMillerDev]

This really should be an audit or at least fail the build since comments never stopped anyone from updating dependents.

[MikeMcQuaid]

This really should be an audit or at least fail the build since comments never stopped anyone from updating dependents.

Strongly agree 👍🏻

[MikeMcQuaid]

@cho-m what's the latest here?