Petr Kovar posted on Sat, 09 Feb 2013 23:36:24 +0100 as excerpted: > Hi all, > > I was wondering what is others' take on Pan bug 693272? > > https://bugzilla.gnome.org/show_bug.cgi?id=693272 > > It indeed looks like we can't feature linking to a LGPLv3 library > (gnutls2/3) due to the license incompatibility, which is very > unfortunate. > > Getting permission from all code contributors to relicense the code to > "GPLv2 or later" doesn't seem to be very realistic either.
I had thought because the lib was LGPLv3 (as opposed to GPLv3), it was workable, at least for dynamic linking. Turns out the FSF doesn't think so, ironically producing a situation where a proprietary app can legally (dynamic-)link the LGPLv3 lib, but a GPLv2 free software app cannot, at least according to the compatibility matrix here (as linked from the bug): http://gplv3.fsf.org/dd3-faq One alternative would be to make pan buildable a pre-lgplv3 gnutls, as lgplv2.1 is compatible, but I'm not sure how practical that is from a coding perspective. Heinrich? Additionally, something I can note from my Gentoo involvement since with the exception of the live-media (and the binpkg media, but while gentoo used to ship those, AFAIK it hasn't updated them for some years now, so if they're still distributed at all, they're way stale), gentoo normally only ships sources and build-scripts, I believe simply shipping sources is fine -- it's the folks shipping binaries that have to worry. That's how a lot of upstream (L)GPL projects can ship build options to link against either gnutls or openssl, even tho openssl isn't any-version gpl compatible -- the project is simply shipping the sources, it's the folks building the binaries that must comply with the license, and as long as the folks doing the building are the users as well -- no distribution -- it's allowed by the GPL, since the GPL only puts conditions on distribution, with end-user use explicitly allowed. So while it's definitely a problem for binary distributions, it's not a problem for pan devs or for builders or end-users, as long as they aren't distributing the binaries. Thus, Debian, being a binary distro, DOES have reason to worry, while Gentoo, being a scripted-build-from-sources distro, is in the clear, as long as they don't distribute pan (with the build-time gnutls option turned on) on the live-media (or binpkg-media), which they generally wouldn't do as it's not a base-level enough package. Also note that as a practical matter, legal or illegal, if nobody's enforcing it doesn't matter except to the folks who want to be real strict about it, which Debian is noted for. (Good for Debian; I'm glad somebody's watching out for our freedoms! =:^) And practically speaking, I suspect it's rather unlikely that anyone with copyright interest in pan and thus legal standing to enforce, is going to be that strict about it. Meanwhile, as long as the LGPLed sources aren't being modified or static- linked, AFAIK the conditions of THAT license are met (tho there's also the question of the other libs pan links against, are they all LGPL 2.1+ or similarly GPLv2 compatible? a quick look at glibc/glib/gtk+ says they are LGPL2.1+ anyway... and gcc has the libstdc++ runtime library exception), so AFAIK it's only people holding copyright in pan that would have the required legal standing. Finally, it's worth recalling that it wasn't THAT long ago that Charles did the full rewrite of pan into C++. It should thus be rather more practical than you might expect to get pan relicensed, if it's considered worth the trouble. The one vital permission we'd need to secure would be that of Charles himself. I'm assuming getting Heinrich's permission won't be a problem. While there's others who have contributed, with only a handful of feature-contribution exceptions, the patches are I think mostly either reasonably trivial thus potentially below the triviality cutoff for copyright, or API update patches and similar, thus very likely falling under the interface interoperability copyright exemptions (the Oracle vs. Google case providing very recent case law there). The handful of non-trivial feature contributors can probably either be traced down, or the code reimplemented by someone willing to grant the necessary relicensing permission, or worst-case, that feature could be removed. If Charles hadn't done that C++ rewrite, you're absolutely correct, as the history of and contributors to old-C-based-pan would indeed be non- trivial to track down. But that rewrite makes things SIGNIFICANTLY easier. The one other concern I'm aware of would be the bundled uulib code that I believe pan ships as part of the sources. I'm not enough of a coder to know how much of that pan actually incorporates, but a quick check here suggests that uulib is gplv2+, so relicensing to GPLv2+ or GPLv3+ shouldn't be a problem with it, tho attempting to switch to non-GPL would be. Talking about the bundled uulib... Most of the files in pan's uulib sources subdir specify GPLv2 or later, with the exception of fptools.[ch] and crc32.[ch] (plus Makefile.am). fptools.[ch] both specify GPL without specifying a version. I'm not sure whether that means any version, or 1.0 or whatever. Getting that cleared up might be a good idea. Might want to ask that Debian guy about it as they probably have a policy that should pass reasonable legal muster. crc32.h is small enough it might be considered too trivial for copyright. Even if not, the interface interoperability exception can easily apply to header files. That leaves crc32.c, which is a definite problem as it references the non- existing zlib.h file. The zlib license seems to be free/as-is (basically MIT/BSD-two-clause similar and compatible with pretty much everything), and that's where that file came from according to the note at the top, so the license shouldn't be a problem, but we DO need to correct that non- existing-file-reference problem, probably by copying the license bit out of the zlib.h file from the zlib sources, replacing the reference to the non-existing file. Actually, if you look at current uulib sources, that's what they've done -- the crc32.c file has the zlib license copied into it. (And the uulib crc32.h file, as pan's, remains without license wording at all.) FWIW, current uulib's fptools.* files have the same unversioned gpl wording as pan's, and I've never seen any licensing problems mentioned with uulib, so I'd /guess/ the unversioned-means-any interpretation above, must be correct. Of course, IANAL, etc, and it's probably still worth asking the Debian guy about, if /nothing/ else. He can at least check to see what they do with uulib and any legal bug history discussion they have on it.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel