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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
