pan-users
[Top][All Lists]
Advanced

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

Re: [Pan-users] Port 119 blocked - no newsgroup access!


From: Duncan
Subject: Re: [Pan-users] Port 119 blocked - no newsgroup access!
Date: Sat, 23 May 2015 03:47:22 +0000 (UTC)
User-agent: Pan/0.140 (Chocolate Salty Balls; GIT af87825)

David Shochat posted on Fri, 22 May 2015 17:26:00 +0000 as excerpted:

> On Fri, 22 May 2015 17:18:35 +0000, Maurice wrote:
> 
>> On Fri, 22 May 2015 16:36:43 +0000, Duncan wrote:
>> 
>>> Edit > Edit News Servers > [select server, gmane in this case] > Edit
>>> > Security > TLS (SSL) settings > Use Secure SSL Connections.
>> 
>>   Edit News Servers shows no Security option for any of the servers.
> 
> I think you missed a key part of what Duncan posted:

>>>Assuming your pan binary was built with secure-connections support

> It sounds like you need to recompile, and this time say:
> ./configure --with-gnutls (along with whatever additional options you
> want).

Precisely. =:^)

Some (legal and technical) background...

Some distros disable the gnutls option, for various reasons, including a 
potential licensing issue -- pan is GPLv2 while gnutls v3 was originally 
upgraded to LGPLv3/GPLv3 (older gnutls was LGPLv2.1+).  GPLv2 is normally 
incompatible with LGPLv3, so building in that support, while allowed for 
the end-user, would be a problem for distributors, including distros.  As 
such, they'd be required to build without that linkage and thus without 
secure connections support.

Fortunately, once the gnutls folks became aware of the bind they were 
putting many gplv2-only projects in, they reverted to LGPLv2.1+, which 
again allows distributing gplv2 apps linked against it.

The pan devs had only just been made aware of the issue (reported by the 
Debian pan maintainer, IIRC, the free software community owes them a lot 
in regard to safeguarding our freedoms, as they're pretty strict about 
such things and frequently they're the first folks reporting such 
problems) and were considering other options (like switching to polarssl, 
mostly used for embedded targets but with a compatible license, so...) 
when a followup to the original notification was posted, saying gnutls 
was switching back to LGPLv2.1+, so the problem was temporary.

However, depending on how old and stale your distro gnutls is, it's quite 
possible your distro ships one of the early gnutls-3.x "gap" versions 
that was upgraded to LGPLv3 and thus at least technically GPLv2 apps like 
pan can't link to it and be legally distributed, even tho both older 
versions (before the license upgrade) and newer versions (after the 
revert/downgrade) can be.

And even if the distro now ships a newer gnutls that has the LGPLv2.1+ 
license again, it may be that they simply haven't reviewed the situation 
since the gnutls license downgrade back to LGPLv2.1+, and thus believe 
they still can't ship pan with the gnutls linking option turned on.

Meanwhile, as I mentioned, as long as you don't distribute, you can link 
pan to any gnutls version that it's technically compatible with, because 
those license restrictions don't apply to those building or using the 
binaries only for themselves, only to those that distribute the built 
binaries to others.

(FWIW, that's also an advantage of from-source distros like gentoo that 
the end-user-admin builds themselves either manually, or in the gentoo 
case, using automated scripts.  Because the end-user is actually building 
the binaries themselves, the distribution-only license restrictions of 
various copyleft software don't apply.  Similarly, various patent 
restrictions apply to the built binaries only, not to the sources, which 
are exempt for free speech reasons.  Thus a sources-based distro can 
freely distribute the sources, with the end-user then choosing whether to 
enable the patent-restricted options, or not, in the binaries they 
build.  In gentoo, both of these cases are covered with the bindist USE 
flag and restriction.  If these are set, then license or patent 
restricted functionality is disabled for the packages using this feature, 
and the resulting packages should be free to legally distribute as they 
won't be using the encumbered code.)

-- 
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




reply via email to

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