GNOME Bugzilla – Bug 465374
libdb linkage in libedataserver causes LGPL to be invalid
Last modified: 2008-04-29 15:13:26 UTC
libedataserver contains some utility code which uses Berkeley DB. libedataserver is LGPL. Berkeley DB is Sleepycat Licensed (http://www.opensource.org/licenses/sleepycat.php) which says: "Redistributions in any form must be accompanied by information on how to obtain complete source code for the DB software and any accompanying software that uses the DB software." If I write a closed source application I should be able to link it against libebook (which is LGPL). However libebook links to libedataserver, which links to libdb... which means I need to provide the source to my application. Clearly this is bad. I think the best solution is to create a new library, libedatabackend or something, which contains the bits of libedataserver which are libdb wrappers (and anything else which is only used in the backends).
From a quick look over the source, the following files in libedataserver must be moved: e-dbhash.[ch] e-db3-utils.[ch] The following files are not effected by this issue, but would make natural counterparts in the backend library ("libebackend"?): e-data-server-module.[ch] e-file-cache.[ch]
Hm, damn, just discovered that evolution/calendar/gui/migration.c uses e-dbhash.
I guess the easy solution would be for evolution to link against libebackend too. Its really just libedataserver-gpl.
Created attachment 93574 [details] [review] Patch Something like this.
Ross, the solution seems fine to me, may be you can close on this once we branch out. Just test everything as usual :-)
Bumping version to a stable release.
I've refreshed this patch against e-d-s trunk. Unfortunately the svn diff hasn't dealt with the moved files in a particularly graceful manner. Please look through and let me know of any glaring errors. I built with "./configure --with-openldap=yes --enable-gtk-doc" and that appeared to enable almost everything to build. Evolution will also need a patch to get it to link to libebackend but i'll follow that up on another bug. If you are happy with this then just let me know and i'll push straight from my local working copy (so that the svn mv's work correctly)
Created attachment 109757 [details] [review] Patch against trunk.
I'd love to push this right now, *but* there is the matter of Evolution linking to e-db-hash to perform a migration. Moving e-db-hash to another library breaks existing evolution binaries, but at the moment libedataserver is dubiously licensed so something has to be done.
Obviously one solution is to remove the code and bump the soname version of libedataserver. People who build from svn get breakage all the time, and packagers get a new soname to allow multiple versions to exist at once.
Ross, I didn't get the exact thing. What do you mean by breakage here ?
Evolution currently links to libedataserver to use e-db-hash. This patch moves e-db-hash into libebackend, which Evolution doesn't currently link again. Thus, Evolution fails to start with runtime linking failures. The solution here I guess is to bump the soname of libedataserver, as the ABI has been broken. Or, we ignore this problem and let companies which link closed-source applications to libedataserver deal with this themselves. Nokia for example moves the files which link to libdb from libedataserver into the file backend directly, which works for them because they only ship the file backend.
Ross, lets do it right. Lets fix Evolution to depend on the right version of e-d-s after this. (Let it look for where ever e-db-hash is there).
Okay this is now commited with a bumped version number for libedataserver (wasn't in the original patch.)
Please see http://bugzilla.gnome.org/show_bug.cgi?id=530576 for the Evolution bug.