Changes/BerkeleyDB 6

BerkeleyDB 6

Summary

Add BerkeleyDB v. 6, which changed license from previous releases (Sleepycat to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license.

Owner

• Name: Jan Staněk
• Email: jstanek@redhat.com
• Release notes owner:

Current status

• Targeted release: Fedora 21
• Last updated: 2014-04-25
• Tracker bug: <will be assigned by the Wrangler>

Detailed Description

The BerkeleyDB, used between others by rpm, changed license between versions 5.* and 6.* from Sleepycat to AGPLv3+. As the latter license is more demanding, packages using the BerkeleyDB either has to check and possibly change its license to AGPLv3+ compatible, keep on using the older BerkeleyDB or use another DB entirely.

Target of this change is to create new set of packages from current libdb, which contains the v5 version, and keep it alongside the latest BerkeleyDB.

As simple mass rebuild with v6 would very likely introduce license incompatibilities, it will be necessary to update and verify all dependent packages to make sure they use the legally compatible version.

Benefit to Fedora

This change enables projects and packages to use BerkeleyDB with Sleepycat license, allowing them to work until the upstream makes their decision about the license change, and at the same time do not restricts projects which already adopted the BerkeleyDB with new license to the older versions of it.

Scope

• Proposal owners: Create new set of packages and introduce proper versioning in order to not confuse the dynamic linker. Supervise verification of proper version linking against other packages.

• Other developers: Packages dependent on libdb would have to specify which version they want to use (specify version in the spec Requires: field). They need to make sure their package links against the version with license compatible with their package. Rebuilds of dependent packages will be necessary.

• Release engineering: None

• Policies and guidelines: None

Upgrade/compatibility impact

If the versioning of the symbols will be implemented in the v5, user-built software linked against it will need to be rebuilt.

How To Test

Check if dependent projects builds, runs as expected and do not have license incompatibilities.

User Experience

None (ideally).

Dependencies

$ repoquery --disablerepo='*' --enablerepo=fedora --enablerepo=updates --whatrequires 'libdb-5.3.so()(64bit)' --qf '%{base_package_name}'  | sort | uniq

Current output of the above command

389-ds-base
apr-util
claws-mail
clisp
cyrus-imapd
cyrus-sasl
dsniff
evolution-data-server
exim
hail
httpd
httpd-itk
iproute
isync
jigdo
kdesvn
libapreq2
libdb
libetpan
libpinyin
libserf
libsolv
libzhuyin
log4cxx
mod_gnutls
mod_security
nmh
nss_updatedb
nvi
open-cobol
opendkim
openldap
openser
opensips
pam
pam_abl
pam_ccreds
perdition
perl-BDB
perl-BerkeleyDB
perl-DB_File
perl-eperl
perl-Qt
perl-XML-LibXSLT
php
postfix
postler
python
python3-bsddb3
rapidsvn
redland
rpm
rsvndump
ruby
sendmail
sks
spamprobe
squid
squidGuard
subversion
tabled
trustedqsl
webalizer
xemacs

Contingency Plan

• Contingency mechanism: Revert the shipped configuration, try again for the next release.
• Contingency deadline: Beta Freeze
• Blocks release? Yes

Documentation

• Changelog entry about the license change