agreed ask the owner for clarification, and suggest that we need a plan that doesn't result in license violations by ommission (+5,0,0)
action mitr to talk to change owners about db6

Basically we want to make sure packages don't link to the new version when they have incompatible licenses.

From the list:

...
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 libdb6). 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.
...

nirik added assent on list; mitr followed up on the list and did not object (?).

Replying to [comment:2 notting]:

mitr followed up on the list and did not object (?).

I understood the proposed plan to be perfectly in line with what we wanted, and intended to just confirm (on behalf of FESCo) that we are fine with it.

From today's FESCo meeting:[[BR]]
AGREED: Please contact upstream now about symbol versioning, and report back by next week; if upstream doesn't agree, have a proposed approach (+7)

• Waiting one more week for upstream response (sgallagh, 17:24:21)
• FESCo is concerned about the wide-ranging impact that the license
  change to AGPL may cause and is considering how to proceed.
  (sgallagh, 17:24:52)

hhorak, any progress from upstream or any concrete plan how will you handle the upgrade?

Replying to [comment:7 tmraz]:

hhorak, any progress from upstream or any concrete plan how will you handle the upgrade?

Not yet. But see https://bugzilla.redhat.com/show_bug.cgi?id=973056#c12 -- other distros are abandoning libdb6 for now unless there is really strong demand for libdb6-only features. So, for me personally just not shipping libdb6 seems like more and more a potential solution.

However, we still need to do better analysis of packages and their license/feature status to see which of them could be linked to libdb6, which could be linked with another implementation and which need to stay with libdb5. So, if you do not hurry about decision, feel free to postpone the talk about libdb6 for the next week.

From FESCO meeting 2014-05-21:

• ACTION: sgallagh to talk to hhorak directly (sgallagh, 17:18:37)
• AGREED: The definitive decision is deferred to next week (t8m,
  17:19:18)

Just FYI, this is a list of packages depended on libdb5 in Fedora and their license (and AGLv3+ compatibility as I understand it from https://fedoraproject.org/wiki/Licensing:Main):
http://hhorak.fedorapeople.org/libdb6issues

I also asked SRT team to put their POV here, for the alternative of staying with libdb-5 for ever (will get EOL in Dec 2016).

Replying to [comment:10 hhorak]:

Just FYI, this is a list of packages depended on libdb5 in Fedora and their license (and AGLv3+ compatibility as I understand it from https://fedoraproject.org/wiki/Licensing:Main):
http://hhorak.fedorapeople.org/libdb6issues

This is merely covering the cases where the code would cause a license incompatibility, correct?

I would be concerned about the cases where newer AGPL restrictions impose changes on the users - postix, cyrus, exim, and in many cases python would all fall into this category. (And license-incompatible apache + license-comaptible python+mod_wsgi would be an obvious test of the symbol versioning.)

FYI: I queried upstream about the symbol versioning: [https://community.oracle.com/message/12453886].

It may be worthwhile to express the desire for that feature, if such desire still exists.

Replying to [comment:13 jstanek]:

FYI: I queried upstream about the symbol versioning: [https://community.oracle.com/message/12453886].

Their respond is: "We will add this to our enhancement request list" -- I read that like it may happen some time, but we should not rather rely on it.

Replying to [comment:14 hhorak]:

Their respond is: "We will add this to our enhancement request list" -- I read that like it may happen some time, but we should not rather rely on it.

Ok, after taking this into consideration and discussing it with hhorak, we agreed that current solution should be to not ship libdb6 at all. The libdb5 support will continue for nearly two years yet, and in that time, we will encourage projects using libdb5 to move to different database. We will also offer our help with this migration. Possible candidate for migration is [https://admin.fedoraproject.org/pkgdb/package/lmdb/ lmdb], among others.

If we encounter a package that will need libdb6 functionality, we will package libdb6 as extra package, ideally with no impact on currently shipped software.

Sounds like the best practical resolution to me.

Thanks for taking care of this everyone.

@jreznik -- anything we have to do to remove the proposed Change from being listed in F21?

Replying to [comment:17 toshio]:

Thanks for taking care of this everyone.

@jreznik -- anything we have to do to remove the proposed Change from being listed in F21?

No action needed. It's not in the list as it was approved by FESCo. I'll take care of that invisible part.

No need to keep this ticket open I can see.

Please re-open if there's some further action to take.