just curious, is linking against LibreSSL allowed ? os x Tunnelblick is
shipped with both LibreSSL and OpenSSL builds, but neither of them is
"system" lib as far as I know.

вс, 15 янв. 2023 г. в 21:35, Arne Schwabe <a...@rfc2549.org>:

> Am 15.01.23 um 16:22 schrieb James Bottomley:
> > On Sun, 2023-01-15 at 15:22 +0100, Arne Schwabe wrote:
> >>
> >>> If that's the source of this issue, then I think there's a
> >>> misunderstanding about the problem the OpenSSL exception is
> >>> addressing. The problem was that the OpenSSL licence required
> >>> additional conditions be imposed on the binary as a whole, even
> >>> though openssl itself was a system library.
> >>>
> >>> https://spdx.org/licenses/OpenSSL.html
> >>>
> >>> Specifically the advertising and redistribution clauses.  The
> >>> OpenSSL exception is to make GPLv2 compatible with the OpenSSL
> >>> licence's additional restrictions, not the other way around.  There
> >>> is still a considerable body of opinion that thinks the system
> >>> exception covers this case as well, but just in case, people added
> >>> the OpenSSL compatibility exception to GPLv2.
> >>>
> >>> The goal of changing OpenSSL to Apache-2 was to remove those
> >>> additional restrictions and make the library behave like a normal
> >>> linked library from a licensing point of view.  The Apache-2
> >>> licence imposes no additional restrictions on the binary as a
> >>> whole, which is why no exception is necessary.  Specifically the
> >>> patent retaliation and indemnity clauses which some people think
> >>> cause the cut and paste incompatibility don't apply to the binary
> >>> as a whole, only to the Apache2 pieces.
> >>
> >>
> >> Yes. That is my understanding as well. But I think where we have been
> >> told
> >
> > Who told you?  Because I'd like to tackle this misinformation at source
> > before it spreads further than openvpn.
> >
> >>   and see the problem different is that the GPL2 covers the whole
> >> binary and also the Apache2 licensed parts.
> >
> > It does under section 2 for any component that can't be classified as a
> > system library, yes.  But the system library exception is the way you
> > avoid this for linking with most libraries.
>
> So we have the same interpretation and just disagree if mbed TLS and
> OpenSSL can be seen as system library on non-Linux/non-BSD systems.
>
> >>   And then the restrictions become a problem.
> >
> > Only if the library you're linking with isn't a system library, which I
> > think we can all agree in not the case on every Linux distribution
> > because they all ship both openssl and mbedtls as part of the
> > distribution.
> >
> >>   So you are right in the sense that the Apache2 is just
> >> a normal library to link for most purposes, the GPL licenses are
> >> special in the way that they want to cover the whole source
> >> code/binary. Sometimes this feature of the GPL is called viral by
> >> opponents of the license.
> >
> > Not for system libraries ... that's what the system library exception
> > is all about.
>
> Yes but neither mbed TLS nor OpenSSL is a system library on Windows or
> macOS. And even mbed TLS is sketchy as many distributions do not have in
> their base system. So just assume, at least for the sake of argument
> that they are not. In that case I think we need this exception. So I am
> asking if you are willing to allow this exception to the license even
> though you think it is unnecessary to make the people that think that it
> is needed happy?
>
> Arne
>
>
>
>
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to