On Thu, Apr 24, 2014 at 8:50 AM, Kevin Fenzi <kevin@xxxxxxxxx> 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/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
