F21 System Wide Change: BerkeleyDB 6

[Jaroslav Reznik]

= Proposed System Wide Change: BerkeleyDB 6 = 
https://fedoraproject.org/wiki/Changes/BerkeleyDB_6

Change owner(s): Jan Staněk <jstanek(a)redhat.com&gt;

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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Chris Adams]

Once upon a time, Jaroslav Reznik <jreznik(a)redhat.com&gt; 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.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Jan Staněk]

Dne 11.4.2014 14:57, Chris Adams napsal(a):
>  Once upon a time, Jaroslav Reznik <jreznik(a)redhat.com&gt; 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

-- 
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team

[Florian Weimer]

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(a)redhat.com&gt;
>
>  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.

-- 
Florian Weimer / Red Hat Product Security Team

[Jan Staněk]

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(a)redhat.com&gt;
> >
> > 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.

-- 
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team

[Bill Nottingham]

Jaroslav Reznik (jreznik(a)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?

Bill

[Jan Staněk]

Dne 11.4.2014 16:59, Bill Nottingham napsal(a):
>  Jaroslav Reznik (jreznik(a)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.

-- 
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team

[Florian Weimer]

On 04/15/2014 03:40 PM, Jan Staněk wrote:
>  Dne 11.4.2014 16:59, Bill Nottingham napsal(a):
> > Jaroslav Reznik (jreznik(a)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.

-- 
Florian Weimer / Red Hat Product Security Team

[Petr Pisar]

On 2014-04-11, Jaroslav Reznik <jreznik(a)redhat.com&gt; 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

[Jan Staněk]

Dne 16.4.2014 15:44, Petr Pisar napsal(a):
>  On 2014-04-11, Jaroslav Reznik <jreznik(a)redhat.com&gt; 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

-- 
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team

[Miloslav Trmač]

Hello,
2014-04-11 13:18 GMT+02:00 Jaroslav Reznik <jreznik(a)redhat.com&gt;:

>  = 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

[Jan Staněk]

Dne 23.4.2014 20:23, Miloslav Trmač napsal(a):
>  Hello,
>  2014-04-11 13:18 GMT+02:00 Jaroslav Reznik <jreznik(a)redhat.com&gt;:
>  
> > = 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
-- 
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team

[Kevin Fenzi]

On Thu, 24 Apr 2014 09:31:43 +0200
Jan Staněk <jstanek(a)redhat.com&gt; 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

[Jerry James]

On Thu, Apr 24, 2014 at 8:50 AM, Kevin Fenzi <kevin(a)scrye.com&gt; 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.
-- 
Jerry James
http://www.jamezone.org/

[Miloslav Trmač]

2014-04-24 17:22 GMT+02:00 Jerry James <loganjerry(a)gmail.com&gt;:

>  On Thu, Apr 24, 2014 at 8:50 AM, Kevin Fenzi <kevin(a)scrye.com&gt;
> 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

[Jerry James]

On Thu, Apr 24, 2014 at 9:39 AM, Miloslav Trmač <mitr(a)volny.cz&gt; 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.
-- 
Jerry James
http://www.jamezone.org/

[Jan Staněk]

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
-- 
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team

[Jerry James]

On Fri, Apr 25, 2014 at 6:24 AM, Jan Staněk <jstanek(a)redhat.com&gt; 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!
-- 
Jerry James
http://www.jamezone.org/

[Paolo Bonzini]

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

[Florian Weimer]

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.

-- 
Florian Weimer / Red Hat Product Security Team