Re: [Pan-users] SSL/TSL and Linux pan 0.139

[Duncan]

Mike Brown posted on Sun, 23 Feb 2014 21:15:11 -0600 as excerpted:

> I have 0.133 on my Linux system, as it is an older version of Fedora. I
> also have it un my XP laptop, but it is version 0.139.
> 
> On the Linux system I was told that TSL/SSL was supported in 0.133 yet.
> It is in the 0.139 that I have on the XP box.

I believe you mean that you were told that TLS/SSL was *NOT* supported in 
0.133 yet, correct?

> But, my friend loaded 0.139, via yum, on his latest version of Fedora,
> only to find that the security option doesn't exist in the news server
> setup GUI.
> 
> Any particular reason why it would be missing from the Linux GUI?

The technical answer is that secure-connection support is a build-time 
option.  Presumably, the packager who built and packaged that version 
either deliberately turned off the option, or simply left it at the 
default and didn't have the required deps (gnutls, or more precisely in 
binary distributions such as fedora that split the runtime libs from the 
components necessary to build packages depending on them, gnutls-dev(el), 
of the appropriate version) to activate that option available when he did 
the build.

The political/legal answer (speaking as an interested non-lawyer layman, 
get qualified legal help if you need it!) likely behind the technical 
disabling is rather more complicated.  Pan is licensed GPLv2 (only), not 
the recommended GPLv2 "or any later version".[1]  The library currently 
providing the ssl/tls support is gnutls, which was in the past and is now 
again licensed with the compatible LGPLv2.1 with the recommended "or any 
later version" language, which is legally compatible.

But there's a later version of both licenses, version 3.  For a few 
versions (but no longer) gnutls was trying to switch to LGPLv3 or later 
and was shipping with that license (actually, the latest release 
apparently still is, the switch back appears to be only in unreleased 
code, ATM), updating from the LGPLv2.1.  Unfortunately, LGPLv3 is legally 
incompatible with GPLv2 only, so distributors who cared about being legal 
had to disable pan's secure-connection support since pan's GPLv2 only 
license doesn't allow distribution when linked against the incompatible 
LGPLv3.

A number of binary-based distro releases occurred during the period gnutls 
was licensed LGPLv3+ instead of LGPLv2+, and your friend's latest fedora 
very likely still ships a gnutls licensed LGPLv3+, so a binary-pan 
package shipped for that release won't legally be able to link to gnutls, 
and pan's secure-connection feature build option was likely disabled for 
that reason.

Some later release will presumably ship a newer gnutls, again licensed 
LGPLv2+, and the binary-package pan shipped with it will again be able to 
legally enable the secure-connections build-time option.


Meanwhile, it's worth noting that this legal restriction applies to 
"distributors" ((L)GPLv2.1 term) or "conveyors" ((L)GPLv3 term, chosen 
for broader international effect) of the software binaries, *NOT* to 
individual end-users and NOT to people distributing the source code only, 
no binaries.  It's thus entirely legal from the GPL perspective for end-
users to build their local package linking to whatever they want, 
including proprietary libraries of they so choose, as long as they don't 
distribute the resulting non-source binaries.  (Of course, the license of 
whatever you're linking to would apply too, and many servantware 
distributors do certainly attempt to ban such linking from their side, 
but that's their side, not the GPLv2's side.)

So you're legally free to download the pan code and build it yourself, 
activating that build-time option as you please, as long as you don't 
distribute the resulting binaries.

Similarly, source-based distributions such as gentoo avoid having to 
worry about both this problem and most of the patent-related issues, 
since (with the exception of LiveCDs and the like) all they distribute is 
a framework and scripts to automate the build process, with the end-user 
actually doing the build and thus able to choose to enable or not based 
on where they live (some jurisdictions don't consider software patents 
valid, so they won't apply there, and if the user isn't distributing the 
binaries, those restrictions won't apply either).

Since I'm a gentoo user and thus build pan myself, it can have gnutls/
secure-connections enabled without issue, as long as I don't distribute 
it. =:^)

Meanwhile, pan's secure-connection feature legal history is actually 
rather longer and more complex than that (the original implementation was 
openssl, which is freedomware, but not GPL compatible either, thus the 
switch to gnutls, and there's also the twist with the GPLv2 licensed 
polarssl, considered as an option when gnutls first switched to LGPLv3 
and the issue became known, before gnutls reverted to LGPLv2), but 
(speaking as an interested non-lawyer, get qualified legal help if you 
need it!) the above is a reasonably accurate description of the current 
situation.

---
[1] Technically, pan's GPLv2 only license could be changed, but 
practically, the effort required to do so isn't worth 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