Re: Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
> Steven Chamberlain <firstname.lastname@example.org> writes:
>> And since BSD and GNU software are unable
>> to link against each other, [...]
Oops, I should have said there that "BSD software *if now linking
against LibreSSL*" couldn't link with GNU software any more.
On Mon, 14 Jul 2014 13:32:40 -0700, Russ Allbery wrote:
> I'm not sure that I understand your argument. In fact, this seems like a
> rather strong argument *against* using LibreSSL.
It is, and yet I hope that's some reassurance that packaging LibreSSL
would not be harmful - if only certain packages are able to use it at
all due to licensing - and still fewer packages are allowed to link
against those packages in turn. The effect of licensing makes the
problem of conflicting symbols much less likely to happen.
Potential (someday) users of packaged libressl libraries may tend to be
non-GPL, or BSD-specific, "leaf" packages. Some ideas:
* nginx, lighttpd, stud
* postfix or simpler MTAs
* some basic FTPDs
* bare-bones 'fetch'-type utilities
* some of GNU/kFreeBSD's freebsd-utils, such as geom
* things that people build on their own systems
* embedded systems
Using LibreSSL in something like libcurl is where it would be most at
risk of symbols clashing with OpenSSL when linked with other things, but
that seemingly should never happen due to licensing (too much software
would be excluded from using it, for libcurl to switch).
> In the world in which BSD software is linked with LibreSSL and the license
> exceptions have not been changed to allow OpenSSL-derived software, now
> (due to the way that Debian applies this rule transitively) GPL software
> can't link against BSD-licensed libraries that link with LibreSSL
Yes, exactly this.