Re: [Pan-devel] License issue with optional TLS component (bug 693272)

[Duncan]

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