lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev EXTERNAL: https support? (was too long)


From: pk
Subject: Re: lynx-dev EXTERNAL: https support? (was too long)
Date: Tue, 11 Aug 1998 15:20:07 -0700 (PDT)

On Tue, 11 Aug 1998, Jacob Poon wrote:

> On Tue, 11 Aug 1998, Philip Webb wrote:
> 
> > 980811 Jacob Poon suggested: 
> > > Shouldn't Lynx support https via externals (from  lynx.cfg ),
> > > to produce cleaner code without breaking the law?
> > > ie Lynx would contain only code for handling data
> > > via existing https connections,
> >                    ^ : surely a typo for `http'
> > > but use only a third-party executable to negotiate https connections
> > > via an executable configured by Lynx's 'EXTERNAL:' settings,
> > > will the Lynx source still be legal and GNU free?
> > 
> > it should be, since there would be nothing in Lynx itself to offend
> > & its ability to call up external programs presumably must be open-ended.
> 
> Well, if that's the case, the next step is to integrate the current https
> patch in Lynx and leave the 'illegal' code to build the external
> executable.
> 
> > > it will greatly simplify https support. 
> > > users can simply download a compiled binary
> >                               ^^^^^^^^^^^^^^^
> > > to let Lynx go to those places, without recompiling.
> > 
> > do such programs exist? in binary?
> 
> Even if no compiled https application exist, at least that will only
> require compiling the external app, not Lynx.  Isn't that the external
> feature designed for?  Besides, that will minimize the problems of
> maintaining both https patches and the remaining Lynx sources.  In other
> words, the https patch has to be done away sooner or later by externals,
> when legal problems are resolved. 

This still might not be enough to get around the legal problems.

For example, mutt is distributed in both a US and an international version,
while containing no real encryption code -- only hooks for external PGP
support. I don't know of any problems Michael Elkins may have had regarding
putting in the PGP hooks, but it was done that way to cover the developers.

ISTR him saying that even having only the hooks in the program would cause
it to be considered a munition.

-- 
GPG & PGP public keys: <URL:http://www.psnw.com/~posterkid/keys/> 
PGP fingerprint: 42 57 B3 D2 39 8E 74 C3  5E 4D AC 43 25 D2 26 D4


reply via email to

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