= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
Change owner(s): Jan Staněk jstanek@redhat.com
Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license.
== Detailed Description == The BerkeleyDB, used between others by rpm [1], changed license between versions 5.* and 6.* to AGPLv3+ from GPLv2+. As those two licenses are not compatible, packages using the BerkeleyDB either has to 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 [2], which contains the v5 version, and keep it alongside the latest BerkeleyDB.
== Scope == * Proposal owners: Create new set of packages and introduce proper versioning in order to not confuse the dynamic linker. * Other developers: Packages dependent on libdb would have to specify which version they want to use (specify version in the spec Requires: field). Rebuilds of dependent packages will be necessary. * Release engineering: None * Policies and guidelines: None
[1] https://apps.fedoraproject.org/packages/rpm [2] https://apps.fedoraproject.org/packages/libdb _______________________________________________ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Once upon a time, Jaroslav Reznik jreznik@redhat.com said:
Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license.
Have the packages that cannot use libdb-6 because of the license been identified? That probably needs to be confirmed before moving forward, due to libdb's symbols conflicting between versions if both get loaded. For example (don't think these have license issues, just picked them off the top of my head), if Apache linked with libdb-5 (because of license), and perl linked with libdb-6, mod_perl would be broken.
If there are any conflicts because of the license incompatibility, then moving to libdb-6 may not be a good idea.
Dne 11.4.2014 14:57, Chris Adams napsal(a):
Once upon a time, Jaroslav Reznik jreznik@redhat.com said:
Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license.
Have the packages that cannot use libdb-6 because of the license been identified? That probably needs to be confirmed before moving forward, due to libdb's symbols conflicting between versions if both get loaded. For example (don't think these have license issues, just picked them off the top of my head), if Apache linked with libdb-5 (because of license), and perl linked with libdb-6, mod_perl would be broken.
If there are any conflicts because of the license incompatibility, then moving to libdb-6 may not be a good idea.
I'm aware of that problem, and it should be addressed by introducing the symbol versioning (see [1], first bullet). The exact problem you are mentioning was encountered before ([2]), and similar problem was dealt with in [3]. I intend to follow that case.
To answer your question, I've not yet identified the packages, but I will look into it (or you are welcome to :) ).
[1] https://fedoraproject.org/wiki/Changes/BerkeleyDB_6#Scope [2] https://bugzilla.redhat.com/show_bug.cgi?id=768846 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1045013
On 04/11/2014 01:18 PM, Jaroslav Reznik wrote:
= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
Change owner(s): Jan Staněk jstanek@redhat.com
Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license.
Please correct the wiki page. The old license was Sleepycat (a short license with a relatively strong copyleft component), and not GPLv2+.
We had a packaging bug in some Fedora versions which labeled the libdb license incorrectly, but this was fixed in Fedora 20.
Dne 11.4.2014 15:55, Florian Weimer napsal(a):
On 04/11/2014 01:18 PM, Jaroslav Reznik wrote:
= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
Change owner(s): Jan Staněk jstanek@redhat.com
Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license.
Please correct the wiki page. The old license was Sleepycat (a short license with a relatively strong copyleft component), and not GPLv2+.
We had a packaging bug in some Fedora versions which labeled the libdb license incorrectly, but this was fixed in Fedora 20.
Wiki page corrected, thanks for pointing that out.
Dne 11.4.2014 16:59, Bill Nottingham napsal(a):
Jaroslav Reznik (jreznik@redhat.com) said:
== Scope ==
- Proposal owners: Create new set of packages and introduce proper versioning
in order to not confuse the dynamic linker.
Is this symbol versioning intended to be upstream?
Ideally, yes, but given the upstream willingness to incorporate community-proposed changes, I fear that we may in fact introduce downstream symbol versioning. The fact is that in order to reliably provide both library versions, we *need* the symbol versioning - preferably upstream, but if it won't be possible, we will have to version downstream (or find another solution to this problem).
I will contact the upstream about this.
On 04/15/2014 03:40 PM, Jan Staněk wrote:
Dne 11.4.2014 16:59, Bill Nottingham napsal(a):
Jaroslav Reznik (jreznik@redhat.com) said:
== Scope ==
- Proposal owners: Create new set of packages and introduce proper versioning
in order to not confuse the dynamic linker.
Is this symbol versioning intended to be upstream?
Ideally, yes, but given the upstream willingness to incorporate community-proposed changes, I fear that we may in fact introduce downstream symbol versioning.
There is support for appending a unique suffix to all exported symbols. See @DB_VERSION_UNIQUE_NAME@ in the sources. It is not ELF symbol versioning, but it might help.
The conflict between development packages remains, though.
On 2014-04-11, Jaroslav Reznik jreznik@redhat.com wrote:
= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
[...]
The BerkeleyDB, used between others by rpm [1], changed license between versions 5.* and 6.* to AGPLv3+ from GPLv2+. As those two licenses are not compatible, packages using the BerkeleyDB either has to change its license to AGPLv3+ compatible, keep on using the older BerkeleyDB or use another DB entirely.
Does that mean than any GPL+ package linked to libdb-6 will have to change license to AGPLv3+? That would have significant impact not only on packagers but also on users.
-- Petr
Dne 16.4.2014 15:44, Petr Pisar napsal(a):
On 2014-04-11, Jaroslav Reznik jreznik@redhat.com wrote:
= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
[...]
The BerkeleyDB, used between others by rpm [1], changed license between versions 5.* and 6.* to AGPLv3+ from GPLv2+. As those two licenses are not compatible, packages using the BerkeleyDB either has to change its license to AGPLv3+ compatible, keep on using the older BerkeleyDB or use another DB entirely.
Does that mean than any GPL+ package linked to libdb-6 will have to change license to AGPLv3+? That would have significant impact not only on packagers but also on users.
I'm no lawyer, but as I understand it, any GPLv2+ package linked against libdb-6 will need to change license - however, AFAIK it could change its license to GPLv3+, because AGPLv3+ and GPLv3+ both have clauses that make them compatible with each other ([1], [2]). On the other hand, the clause [1] basically states (if I understood it correctly) that any such combination is basically under AGPLv3+, so i don't know if it makes much difference.
[1] http://www.gnu.org/licenses/gpl-3.0.html#section13 [2] http://www.gnu.org/licenses/agpl-3.0.html#section13
Hello, 2014-04-11 13:18 GMT+02:00 Jaroslav Reznik jreznik@redhat.com:
= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
At the FESCo meeting, we were unclear what happens to packages that don't get updated; will they sty at v5, or will they (immediately, or after a possible mass rebuild) start using v6?
FESCo would prefer a transition plan in which we don't risk violating licenses by omission (e.g. requiring an active maintainer's action to move a package to v6, or having somebody sign up to verify all packages in case the owners forgot). Mirek
Dne 23.4.2014 20:23, Miloslav Trmač napsal(a):
Hello, 2014-04-11 13:18 GMT+02:00 Jaroslav Reznik jreznik@redhat.com:
= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
At the FESCo meeting, we were unclear what happens to packages that don't get updated; will they sty at v5, or will they (immediately, or after a possible mass rebuild) start using v6?
FESCo would prefer a transition plan in which we don't risk violating licenses by omission (e.g. requiring an active maintainer's action to move a package to v6, or having somebody sign up to verify all packages in case the owners forgot). Mirek
Well, in the current plan (make libdb5 "compat" package and updating the libdb to v6), after the mass rebuild the packages would start using v6.
We could do it other way around (keep libdb in v5 and make libdb6 package), but this approach invites future problems with consecutive versions (v7, v8 probably should not be packaged in libdb*6*). Using another naming scheme would take care of part of the problem.
I would actually prefer somebody to verify all packages that Require libdb and work with maintainers of said packages to eventually update their requires. If no one signes up to this, I will do it as part of the change (but even the I could use some help).
If this proposal seems good to you, I will update the wiki page to reflect the agreement.
Regards, Jan
On Thu, 24 Apr 2014 09:31:43 +0200 Jan Staněk jstanek@redhat.com wrote:
Well, in the current plan (make libdb5 "compat" package and updating the libdb to v6), after the mass rebuild the packages would start using v6.
Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild for some other reason and are not on v6 when it's a licensing problem. ;(
We could do it other way around (keep libdb in v5 and make libdb6 package), but this approach invites future problems with consecutive versions (v7, v8 probably should not be packaged in libdb*6*). Using another naming scheme would take care of part of the problem.
Right.
I would actually prefer somebody to verify all packages that Require libdb and work with maintainers of said packages to eventually update their requires. If no one signes up to this, I will do it as part of the change (but even the I could use some help).
Yeah. This could be tracked with a tracker bug and bugs against the remaining packages I guess.
If this proposal seems good to you, I will update the wiki page to reflect the agreement.
Yeah, seems fine to me...
kevin
On Thu, Apr 24, 2014 at 8:50 AM, Kevin Fenzi kevin@scrye.com wrote:
Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild for some other reason and are not on v6 when it's a licensing problem. ;(
I need some advice on how to handle this for XEmacs, which is a GPLv3+ package. It provides some optional database functionality, but the underlying database can be any of libdb, gdbm, or postgresql. When I first turned this on for Fedora, in response to a request in bz 581614, I chose libdb for reasons that I no longer remember. So now I need to choose between: - libdb (going to AGPLv3+) - gdbm (GPLv3+) - postgresql (PostgreSQL, essentially MIT)
Does the fact that multiple database implementations can be used mean that the coupling is loose enough that the libdb license won't taint XEmacs proper? If not, then I would rather migrate away from libdb than deal with the possible licensing consequences. But then I have to deal with user databases that are already in libdb format, and hence cannot be read by the new XEmacs build using gdbm or postgresql. That's the part I don't know how to handle. Do I provide some automated migration capability? I suspect that won't ever work properly, because I don't have any way to discover where all such possible databases are located. Do I put up big warning signs somewhere that say: "You must convert all of your XEmacs databases before updating to Fedora 21, and here is a recipe to do so?" (And, to be honest, I have no idea what that recipe would be.)
Thanks in advance for any advice.
2014-04-24 17:22 GMT+02:00 Jerry James loganjerry@gmail.com:
On Thu, Apr 24, 2014 at 8:50 AM, Kevin Fenzi kevin@scrye.com wrote:
Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild for some other reason and are not on v6 when it's a licensing problem. ;(
I need some advice on how to handle this for XEmacs, which is a GPLv3+ package. It provides some optional database functionality, but the underlying database can be any of libdb, gdbm, or postgresql. When I first turned this on for Fedora, in response to a request in bz 581614, I chose libdb for reasons that I no longer remember. So now I need to choose between:
- libdb (going to AGPLv3+)
- gdbm (GPLv3+)
- postgresql (PostgreSQL, essentially MIT)
You'll have the option of moving to libdb5 , without a license change or need to convert data. That should be easiest, at least in the medium term while libdb5 is actively maintained. Mirek
On Thu, Apr 24, 2014 at 9:39 AM, Miloslav Trmač mitr@volny.cz wrote:
You'll have the option of moving to libdb5 , without a license change or need to convert data. That should be easiest, at least in the medium term while libdb5 is actively maintained.
Sure, but long term I still have the same problem, so I might as well suffer through the pain now and be done with it.
Dne 24.4.2014 17:22, Jerry James napsal(a): <snap>
I need some advice on how to handle this for XEmacs, which is a GPLv3+ package.
<snap>
Well, both GPLv3+ and AGPLv3+ have clause ([1], [2]) that allow code licensed under one of them link with code under the other one legally - only if you run the full product on a server and it interact with users trough network, you have to provide the source code.
So AFAIK in your case you can use even the v6 libdb without license change.
[1] http://www.gnu.org/licenses/gpl-3.0.html#section13 [2] http://www.gnu.org/licenses/agpl-3.0.html#section13
On Fri, Apr 25, 2014 at 6:24 AM, Jan Staněk jstanek@redhat.com wrote:
Well, both GPLv3+ and AGPLv3+ have clause ([1], [2]) that allow code licensed under one of them link with code under the other one legally - only if you run the full product on a server and it interact with users trough network, you have to provide the source code.
So AFAIK in your case you can use even the v6 libdb without license change.
[1] http://www.gnu.org/licenses/gpl-3.0.html#section13 [2] http://www.gnu.org/licenses/agpl-3.0.html#section13
Ah, excellent. That is the best possible answer. Thanks a lot, Jan!
Il 24/04/2014 16:50, Kevin Fenzi ha scritto:
Well, in the current plan (make libdb5 "compat" package and updating the libdb to v6), after the mass rebuild the packages would start using v6.
Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild for some other reason and are not on v6 when it's a licensing problem. ;(
(Sorry for the late reply).
It's not just packagers, it's also users. If a dependent package switches from GPL (any release) to AGPL, users will have to add the "get sources" button to their code when the AGPL conditions apply. If they are not able to distribute sources at all, they will have a problem (of course the same happens for say GPLv2+ -> GPLv3+ switches, but then it only affects redistribution and not usage).
Paolo
On 04/11/2014 01:18 PM, Jaroslav Reznik wrote:
The BerkeleyDB, used between others by rpm [1], changed license between versions 5.* and 6.* to AGPLv3+ from […]. As those two licenses are not compatible, packages using the BerkeleyDB either has to change its license to AGPLv3+ compatible, keep on using the older BerkeleyDB or use another DB entirely.
Debian's stance on this is here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748192
Considering that various parties (author, SFLC, FSF) thought that libbitcoin needed a license exception https://wiki.unsystem.net/index.php/Libbitcoin/License, I wonder if that changes our stance on the impact libraries licensed under the AGPL.
devel@lists.stg.fedoraproject.org
-
Bill Nottingham -
Chris Adams -
Florian Weimer -
Jan Staněk -
Jaroslav Reznik -
Jerry James -
Kevin Fenzi -
Miloslav Trmač -
Paolo Bonzini -
Petr Pisar