pan-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dominique Dumont
Subject: Re: [Pan-devel] License issue with optional TLS component ( bug 693272)
Date: Sun, 10 Feb 2013 17:01:18 +0100
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

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 ? 

> 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.
> 
> 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]) 

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

Files: pan/tasks/task-article.*
Copyright: 2002-2006, Charles Kerr <address@hidden>
   2002-2007, Charles Kerr <address@hidden>
   2007, Calin Culianu <address@hidden>
   2007, Charles Kerr <address@hidden>
License: GPL-2

Files: pan/usenet-utils/ssl-utils.h
Copyright: 2011 Heinrich Müller <address@hidden>
 2002-2006 Charles Kerr <address@hidden>
 2003 Jay Case
 2002 vjt (irssi project)
 2002, 2003, 2004, 2005, 2007, 2008, 2010 Free Software
License: GPL-2

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

HTH


Dominique

http://packages.debian.org/changelogs/pool/main/p/pan/current/copyright

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]