Re: License issue with optional TLS component ( bug 693272)

Am 10.02.2013 17:01, schrieb Dominique Dumont:
> Hello Duncan
>
> [ Note: I'm the guy packaging Pan for Debian ]
>
>> 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?
> I do not think it's practical: what about potential security fixes done after
> the lgpv3 release ?
not an option, yes.
>
>> 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.
> IANAL, but I think you're confusing issues. The GPL mostly affects
> redistribution of software. The fact that the software is re-distributed as
> source or binaries does not matter. What matter is that source files are
> available when re-distributing software as binary.
>
> GPL license apply when you're re-distributing aggregated software, i.e.
> software B uses (i.e. C link, nodejs require or Perl use..) a GPL software,
> then you must comply with GPL requirement as listed in
> http://gplv3.fsf.org/dd3-faq
>
>> 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.
> Indeed. Tolerance may be common between open-source projects, but it may set a
> precedent for license abuse. Something like, "yes I hijacked this GPL software
> for my company, but it's common practice for other projects". That's a
> slippery slope.
>
>> 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.
> Indeed.
>
>> 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.
> It means GPL 1.0. I'm more worried by the fact that there's no (c) holder for
> this file. It will be difficult to have this file re-licensed if its author
> cannot be contacted.

>> 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.
i've removed those files. not needed ....
>>
>> 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.)
> While analysing the copyright and licenses of Pan files, I came to the same
> conclusion (see [1], I admit I did not see the licence problem with
> uulib/fptools.[ch])
i think i'll drop uulib anyway. but that's a future goal.
>
> Other problematic files are:
>
> Files: pan/gui/e-cte-dialog.c
> Copyright: 2001 Ximian, Inc
> License: GPL-2
>
> Files: pan/gui/e-charset-dialog.c
> Copyright: 2001, Ximian, Inc
> License: GPL-2
those two are problematic. i'll implement my own widgets perhaps...
>
> Files: pan/tasks/task-article.*
> Copyright: 2002-2006, Charles Kerr <[email protected]>
>     2002-2007, Charles Kerr <[email protected]>
>     2007, Calin Culianu <[email protected]>
>     2007, Charles Kerr <[email protected]>
> License: GPL-2
i'll contact calin.
>
> Files: pan/usenet-utils/ssl-utils.h
> Copyright: 2011 Heinrich Müller <sphemuel-t+0fs1LuQyGVdxy9aTz+TW+fIWL0DMyzTDyeXAhcDKU@public.gmane.orgde>
>   2002-2006 Charles Kerr <[email protected]>
>   2003 Jay Case
>   2002 vjt (irssi project)
>   2002, 2003, 2004, 2005, 2007, 2008, 2010 Free Software
> License: GPL-2
will be removed
> For each file, a pan re-licensing would require either:
> - a re-licensing message from copyright holders
> - use a more recent version of the file with a compatible license
> - modify pan to not use this file
>
>
thanks for the info so far.

cheers.