subject:"Re\: \[Openvpn\-devel\] Amend OpenVPN license to allow continued mbed TLS support \(allow mbed TLS 3.x linking\)"





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?


In that case your proposed exception doesn't work.  You've modelled it
on the OpenSSL exception which was designed to cover the use case where
OpenSSL *is* a system library (thus covered by the system library
exception) but imposes incompatible additional restrictions on whole
binary, specifically the GPLv2 pieces.

To make this work assuming the crypto library isn't a system one, you
need an exception to the section 2 requirement to ship the whole under
GPLv2 ... or a simple declaration that you think openssl and mbedtls
are system libraries for the purposes of OpenVPN, so the system library
exception applies to them regardless of how they are shipped.


The origin of the existing exception is the Debian project (or at least 
has been used a lot in relationship with the project). Until very 
recently Debian did NOT consider the OpenSSL library to be a system 
library, so they asked GPLv2 projects to add this clause to allow 
linking with the OpenSSL library. So that makes me believe that this 
clause is fit for the purpose that we are using it for.



See as an example here 
https://lists.debian.org/debian-legal/2004/05/msg00595.html



The change that Debian considers the OpenSSL library a system library in 
Debian is from 2020:


https://lists.debian.org/debian-devel/2020/10/msg00168.html
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html


So I trust that the exception does indeed allow for linking against 
OpenSSL as a non-system library as otherwise adding this exception would 
have made no sense in the context that it was used.


Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

вс, 15 янв. 2023 г. в 22:29, Gert Doering :

> HI,
>
> On Sun, Jan 15, 2023 at 10:12:03PM +0600,  ?? wrote:
> > 1) distributing openssl dll for windows installer is illegal
> > 2) distributing openssl/libressl with tunnelblick is illegal
>
> Neither, because we do have an exception for OpenSSL.
>

that expection is for "system" openssl variant only, not for 3rd parties
openssl ?


>
> But distributing with mbedTLS is what we have been told is problematic.
>
> gert
> --
> "If was one thing all people took for granted, was conviction that if you
>  feed honest figures into a computer, honest figures come out. Never
> doubted
>  it myself till I met a computer with a sense of humor."
>  Robert A. Heinlein, The Moon is a Harsh
> Mistress
>
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

On Sun, 2023-01-15 at 16:04 +0100, Gert Doering wrote:
> Hi,
> 
> On Sun, Jan 15, 2023 at 08:37:00AM -0500, James Bottomley wrote:
> > The GNU project began in 1982.  Static libraries for SYS-V were
> > initially proposed around 1986 and didn't become widespread until
> > the 90s.
> 
> And exactly when was *the Apache license* published, or GPL *v2*?
> 
> This was the context, not "the GNU project".
> 
> Wikipedia says the GPLv2 was released in June 1991, and as you say,
> shared libraries already existed then.

No, I'm saying two things

   1. The GNU project began before shared libraries were a thing, so
  the system library exception was specifically designed to allow
  shipping of GNU tools along with huge statically linked blobs of
  proprietary or otherwise differently licensed code under a non-
  GPL licence.
   2. The advent of Apache-2 didn't change the analysis in 1.

James

signature.asc
Description: This is a digitally signed message part
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

HI,

On Sun, Jan 15, 2023 at 10:12:03PM +0600,  ?? wrote:
> 1) distributing openssl dll for windows installer is illegal
> 2) distributing openssl/libressl with tunnelblick is illegal

Neither, because we do have an exception for OpenSSL.

But distributing with mbedTLS is what we have been told is problematic.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)


Am 15.01.23 um 17:12 schrieb Илья Шипицин:

that means

1) distributing openssl dll for windows installer is illegal
2) distributing openssl/libressl with tunnelblick is illegal



It means the exception for OpenSSL applies to it and it is on very solid 
ground (at least with OpenSSL up to 1.1.1). It should be also safe with 
OpenSSL 3.0 but interpretation of the clause is not 100% clear with 
OpenSSL's license change, so we want to reaffirm that.


Arne



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

On Sun, 2023-01-15 at 16:34 +0100, Arne Schwabe wrote:
> Am 15.01.23 um 16:22 schrieb James Bottomley:
> > On Sun, 2023-01-15 at 15:22 +0100, Arne Schwabe wrote:
[...]
> > >   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?

In that case your proposed exception doesn't work.  You've modelled it
on the OpenSSL exception which was designed to cover the use case where
OpenSSL *is* a system library (thus covered by the system library
exception) but imposes incompatible additional restrictions on whole
binary, specifically the GPLv2 pieces.

To make this work assuming the crypto library isn't a system one, you
need an exception to the section 2 requirement to ship the whole under
GPLv2 ... or a simple declaration that you think openssl and mbedtls
are system libraries for the purposes of OpenVPN, so the system library
exception applies to them regardless of how they are shipped.

James

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

that means

1) distributing openssl dll for windows installer is illegal
2) distributing openssl/libressl with tunnelblick is illegal

?

вс, 15 янв. 2023 г. в 22:09, Arne Schwabe :

> Am 15.01.23 um 17:07 schrieb Илья Шипицин:
> > 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.
>
> LibreSSL counts as modification of OpenSSL.
>
> Arne
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)


Am 15.01.23 um 17:07 schrieb Илья Шипицин:
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.


LibreSSL counts as modification of OpenSSL.

Arne



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

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 :

> 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

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)


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

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

Hi,

On Sun, Jan 15, 2023 at 10:22:06AM -0500, James Bottomley wrote:
> >  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.

The open source world is a bit bigger than "Linux", and not all the other
platforms supported by OpenVPN (none, to be precise) ship mbedTLS as part
of their OS distribution.  Some do not even ship OpenSSL.

ports/pkgsrc/... are very clearly "3rd party components", and not
"part of the OS distribution".  Gentoo ebuilds are something in between.

As much as we'd like to declare this a non-issue, pointing to the system
library exception will not help us solve the problem.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de

signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

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.

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

James



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

Hi,

On Sun, Jan 15, 2023 at 08:37:00AM -0500, James Bottomley wrote:
> The GNU project began in 1982.  Static libraries for SYS-V were
> initially proposed around 1986 and didn't become widespread until the
> 90s.

And exactly when was *the Apache license* published, or GPL *v2*?

This was the context, not "the GNU project".

Wikipedia says the GPLv2 was released in June 1991, and as you say,
shared libraries already existed then.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

Hi,

On Sun, Jan 15, 2023 at 08:23:11AM -0500, Selva Nair wrote:
> Some may find this discussion a waste of time but let's not belittle
> people's contributions.
> I do care about how my work is licensed.

I find having to spend my time on "how can two *free software licenses*
be made compatible" a colossal waste of time that could be spent on
improving said software instead.

This does not imply that I do not care about your contributions, or
want to belittle them.  Sorry if I created the impression.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

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 and see the problem different is that the GPL2 covers the whole
binary and also the Apache2 licensed parts. And then the restrictions
become a problem. 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.

Mark McLouglin (Red Hat and Openstack) did an excellent analysis at the
time the licence change was announced explaining the issues
(unfortunately it seems to have gone from gnome but the wayback machine
still has it):

https://web.archive.org/web/20220204042851/https://people.gnome.org/~markmc/openssl-and-the-gpl.html

That is a nice analysis but I do not see any mention of a change in the
situation for Apache2.

Arne

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)


Am 15.01.23 um 14:23 schrieb Selva Nair:

Hi,

We would like to be able to continue to build/ship OpenVPN with mbed
TLS. We want all contributors to ask if they agree to license change
that adds explicit permission to link with Apache 2 licensed libraries:


Special exception for linking OpenVPN with Apache 2 licensed libraries:

    In addition, as a special exception, OpenVPN Inc and contributors
    give permission to link the code of this program to libraries
with the
    "APACHE LICENSE, VERSION 2.0", and distribute linked combination
    including the two.  You must obey the GNU General Public License in
    all respects for all of the code used other than these
libraries.  If
    you modify this file, you may extend this exception to your
version of
    the file, but you are not obligated to do so.  If you do not wish to
    do so, delete this exception statement from your version.


Instead of this exemption I would vote for a change to 'GPL v2 or any 
later version'.
That would keep the license in the spirit by which people like me 
contributed.


Using an existing license that has already been vetted also avoids the need
for legal counsel.

I do not understand the argument about 'GPLv2 and later...' and embedded 
devices. Those who
are currently embedding based on GPL v2 can continue to do so, those who 
want/need v3
can do so too. Those who need v3 but also want to lock the firmware on a 
consumer device
may be affected. But that's a choice they make, why would we want to 
promote that?


Some may find this discussion a waste of time but let's not belittle 
people's contributions.

I do care about how my work is licensed.


Okay. I think the embedded thing is a bit of a misunderstanding. I am 
not trying to promote that. What I wanted is to express why changing to 
GPLv3 might not be an option as some license holders of OpenVPN will not 
be okay with changing to GPL3 since they need that.


So the situation is basically, we need somehow to still be able to link 
Apache 2.0 licensed SSL libraries. While we have an exception for 
OpenSSL, some might argue that this only covers the old OpenSSL license.


So to go forward we either need to change OpenVPN 2.x to a license 
compatible with Apache 2.0 like GPL3 or adding an excerption for linking 
against Apache 2.0.


At the hackathon we discussed the options and there already voices 
against going GPL3 instead of GPL2 but everyone there was okay with 
staying with GPL2 and adding an exception.


This approach of taking the exception route instead of GPL3 is mostly a 
pragmatic approach to be able to have something that might have a chance 
of succeeding.


I (and probably also others) are also to other suggestions how to solve 
the problems. I don't know if a change to GPL2+ + exception for Apache2 
might a be solution that is more agreeable by more people.


Overall this license situation is quite frustrating and I just looking 
for a solution to let OpenVPN continue to work in the future. I don't 
think anyone wants to have OpenVPN die on platforms like Windows and 
other platforms that do not include OpenSSL as system library. But the 
way forward seems very difficult.


Personally I don't think adding an exception to the Apache2 license 
violates the spirit of the GPL as it only allows "restrictions" of the 
Apache2 designed to protect users of its source code that the GPLv3 also 
includes. But from a license standpoint the GPLv2 does not allow these 
additional protection (E.g. the patent grant clause).


Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

On Sun, 2023-01-15 at 05:23 +0100, Arne Schwabe wrote:
> > Even if, for the sake of argument, I assume that what you're doing
> > isn't covered by the system library exception, then what you're
> > proposing doesn't fix your problem.  Your problem becomes section 2
> > of the GPLv2: you must distribute the whole thing under GPLv2.  No
> > amount of permissions to link can get you out of this if, as you're
> > assuming, Apache-2 and GPLv2 are incompatible because you're still
> > required to ship an Apache-2 piece (mbedtld) under GPLv2.  You
> > would have to frame your additional license permission as an
> > exception to the section 2 requirement to distribute the whole
> > under GPLv2
> 
> I am confused here. The proposed paragraph is phrased that it is a 
> special exception that allows doing this. The paragraph explicitly 
> states that we allow as a special exception to distribute the
> binaries containing the Apache2 library and the OpenVPN code. This
> uses the same wording as the existing OpenSSL exception.

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.

Mark McLouglin (Red Hat and Openstack) did an excellent analysis at the
time the licence change was announced explaining the issues
(unfortunately it seems to have gone from gnome but the wayback machine
still has it):

https://web.archive.org/web/20220204042851/https://people.gnome.org/~markmc/openssl-and-the-gpl.html

James

___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

On Sun, 2023-01-15 at 14:12 +0100, Arne Schwabe wrote:
> Am 15.01.23 um 14:10 schrieb Matthias Andree:
> > Am 15.01.23 um 12:44 schrieb Gert Doering:
> > > Hi,
> > > 
> > > On Sat, Jan 14, 2023 at 05:28:09PM -0500, James Bottomley wrote:
> > > > What do you mean "a source"? every apache licensed library
> > > > that's statically linked with a GPLv2 program would be an
> > > > example of this ... in the early days there was no dynamic
> > > > linking, so all the early GNU tools were statically linked with
> > > > wodges of proprietary binary gunk.
> > >  
> > > These "early day" precede the creation of the Apache license or
> > > GPLv2 by many years.
> > 
> > Certainly not the GPLv2 (1991). GPLv3 (2007) maybe. This seems to
> > be the oldest converted to Git and reachable from the 2.5 and 2.6
> > carrying branches:
> 
> I think Gert wanted to say that the days before dynamic libraries
> were not invented yet and every was linked statically was well before
> the GPL.

The GNU project began in 1982.  Static libraries for SYS-V were
initially proposed around 1986 and didn't become widespread until the
90s.

James



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

2023-01-15 Thread Selva Nair

Hi,

We would like to be able to continue to build/ship OpenVPN with mbed
> TLS. We want all contributors to ask if they agree to license change
> that adds explicit permission to link with Apache 2 licensed libraries:
>
>
> Special exception for linking OpenVPN with Apache 2 licensed libraries:
>
>In addition, as a special exception, OpenVPN Inc and contributors
>give permission to link the code of this program to libraries with the
>"APACHE LICENSE, VERSION 2.0", and distribute linked combination
>including the two.  You must obey the GNU General Public License in
>all respects for all of the code used other than these libraries.  If
>you modify this file, you may extend this exception to your version of
>the file, but you are not obligated to do so.  If you do not wish to
>do so, delete this exception statement from your version.
>

Instead of this exemption I would vote for a change to 'GPL v2 or any later
version'.
That would keep the license in the spirit by which people like me
contributed.

Using an existing license that has already been vetted also avoids the need
for legal counsel.

I do not understand the argument about 'GPLv2 and later...' and embedded
devices. Those who
are currently embedding based on GPL v2 can continue to do so, those who
want/need v3
can do so too. Those who need v3 but also want to lock the firmware on a
consumer device
may be affected. But that's a choice they make, why would we want to
promote that?

Some may find this discussion a waste of time but let's not belittle
people's contributions.
I do care about how my work is licensed.

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)


Am 15.01.23 um 14:10 schrieb Matthias Andree:

Am 15.01.23 um 12:44 schrieb Gert Doering:

Hi,

On Sat, Jan 14, 2023 at 05:28:09PM -0500, James Bottomley wrote:

What do you mean "a source"? every apache licensed library that's
statically linked with a GPLv2 program would be an example of this ...
in the early days there was no dynamic linking, so all the early GNU
tools were statically linked with wodges of proprietary binary gunk.

These "early day" precede the creation of the Apache license or GPLv2
by many years.


Certainly not the GPLv2 (1991). GPLv3 (2007) maybe. This seems to be the
oldest converted to Git and reachable from the 2.5 and 2.6 carrying
branches:


I think Gert wanted to say that the days before dynamic libraries were 
not invented yet and every was linked statically was well before the GPL.


Arne



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

вс, 15 янв. 2023 г. в 19:09, Arne Schwabe :

> Am 15.01.23 um 13:52 schrieb Илья Шипицин:
> > subject says "allow mbed TLS 3.x linking".
> > is OpenSSL currently restrictive as well ?
> >
>
> Yes that is what the subject says but OpenSSL 3 also uses Apache 2.
>
> In laymen terms, the Apache 2 license contains additional protections
> for users using the source code that GPLv2 does not. While these
> additional protection are in the spirit of the GPL (the GPL3 includes
> the same protections), they are not in the letter of GPL2 and GPL2 does
> not allow additional restriction (like these protections).
>
> So it would be nice if you could just agree to allow the special
> exception, so we can continue using mbed TLS and OpenSSL with OpenVPN.
>

I agree with moving toward Apache license (or some kind of exception), also
I'm fine with dropping mbed TLS for good.


>
> Arne
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

2023-01-15 Thread Matthias Andree


Am 15.01.23 um 12:44 schrieb Gert Doering:

Hi,

On Sat, Jan 14, 2023 at 05:28:09PM -0500, James Bottomley wrote:

What do you mean "a source"? every apache licensed library that's
statically linked with a GPLv2 program would be an example of this ...
in the early days there was no dynamic linking, so all the early GNU
tools were statically linked with wodges of proprietary binary gunk.

These "early day" precede the creation of the Apache license or GPLv2
by many years.


Certainly not the GPLv2 (1991). GPLv3 (2007) maybe. This seems to be the
oldest converted to Git and reachable from the 2.5 and 2.6 carrying
branches:

* 6fbf66fa 2005-09-26 | This is the start of the BETA21 branch. It
includes the --topology feature, and TAP-Win32 driver changes to allow
non-admin access. [james]

I'd added OpenVPN 1.2.1 to FreeBSD in Mid 2002:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=39750



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)


Am 15.01.23 um 13:52 schrieb Илья Шипицин:

subject says "allow mbed TLS 3.x linking".
is OpenSSL currently restrictive as well ?



Yes that is what the subject says but OpenSSL 3 also uses Apache 2.

In laymen terms, the Apache 2 license contains additional protections 
for users using the source code that GPLv2 does not. While these 
additional protection are in the spirit of the GPL (the GPL3 includes 
the same protections), they are not in the letter of GPL2 and GPL2 does 
not allow additional restriction (like these protections).


So it would be nice if you could just agree to allow the special 
exception, so we can continue using mbed TLS and OpenSSL with OpenVPN.


Arne


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

Hi,

On Sun, Jan 15, 2023 at 06:52:40PM +0600,  ?? wrote:
> subject says "allow mbed TLS 3.x linking".
> is OpenSSL currently restrictive as well ?

OpenSSL has always been restrictive, which is why our license has
always had a permit-linking-to-OpenSSL exception.

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

subject says "allow mbed TLS 3.x linking".
is OpenSSL currently restrictive as well ?

вс, 15 янв. 2023 г. в 18:24, Arne Schwabe :

> Am 15.01.23 um 13:21 schrieb Илья Шипицин:
> > I am fine with dropping MBED TLS for good
> >
>
> Please read the full mail. This also affects OpenSSL. We would like to
> reaffirm that contributors are still okay linking with OpenSSL even
> after OpenSSL changed its license to Apache2.
>
> Arne
>
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

Hi,

On Sun, Jan 15, 2023 at 06:21:21PM +0600,  ?? wrote:
> I am fine with dropping MBED TLS for good

This is not the question asked.

For the record: I am fine with the proposed change of license.

(I think this is all a tremendous waste of time, but since sufficient
number of licensing lawyers say "linking GPL2 with something that has
additional restrictions and shipping the result is not legal" *and*
mbedTLS can not be considered a system library anywhere, as in "it
will be always there if you install that system" - like a libc - it's
either this or drop mbedTLS support)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)


Am 15.01.23 um 13:21 schrieb Илья Шипицин:

I am fine with dropping MBED TLS for good



Please read the full mail. This also affects OpenSSL. We would like to 
reaffirm that contributors are still okay linking with OpenSSL even 
after OpenSSL changed its license to Apache2.


Arne



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

I am fine with dropping MBED TLS for good

On Sat, Jan 14, 2023, 11:30 PM Arne Schwabe  wrote:

> Hey,
>
> This is the first round and will be only to the openvpn-devel list.
> After that I will also write to individuals email addresses but I want
> to start with sending this to the devel list.
>
> We are writing to you since you are or were a contributor in past to
> OpenVPN and we would like to  ask for your permission to amend the
> license of OpenVPN.
>
> OpenVPN 2.x is licensed under the GPL v2. This license has served us
> well in the past and we are not trying to change that. However, changes
> in licenses of our dependencies make this change necessary.
>
> Both mbed TLS and OpenSSL nowadays use the Apache 2.x license. For the
> OpenSSL library we have a special exception that allows us linking with
> it. For newer mbed TLS version, we cannot do this any more.
> Compatibility of Apache 2.x and GPL 2.x has to our knowledge never been
> tested in court and even FSF and ASF disagree about the issue
> (https://www.apache.org/licenses/GPL-compatibility.html)
>
> We would like to be able to continue to build/ship OpenVPN with mbed
> TLS. We want all contributors to ask if they agree to license change
> that adds explicit permission to link with Apache 2 licensed libraries:
>
>
> Special exception for linking OpenVPN with Apache 2 licensed libraries:
>
>In addition, as a special exception, OpenVPN Inc and contributors
>give permission to link the code of this program to libraries with the
>"APACHE LICENSE, VERSION 2.0", and distribute linked combination
>including the two.  You must obey the GNU General Public License in
>all respects for all of the code used other than these libraries.  If
>you modify this file, you may extend this exception to your version of
>the file, but you are not obligated to do so.  If you do not wish to
>do so, delete this exception statement from your version.
>
>
> You might wonder why we are going for a generic Apache 2 exception
> rather than one targeted at mbed TLS specifically. We believe that a
> generic exemption is better since it also implicitly allows forks of
> mbed TLS and even if a SSL library might emerge in the future we do not
> have to discuss if it is a fork or not. Also granting an explicit
> exception for Apache 2 style licenses reaffirms the linking to OpenSSL.
>
> We also considered going for a change from GPL2 to GPL2+ but we think
> that GPL3 would hurt the ability to distribute OpenVPN as part of router
> or other embedded devices as the GPL3 has been explicitly developed (at
> least in part) to make this use case harder/impossible
> (https://en.wikipedia.org/wiki/Tivoization)
>
> If you are okay with this, please reply to this mail and confirm that.
> Otherwise we might be forced to remove and/or rewrite your code.
>
>
> As a reminder, the The current OpenSSL exception reads as follows
> (COPYING). We don't intend to change or remote it:
>
>Special exception for linking OpenVPN with OpenSSL:
>
>In addition, as a special exception, OpenVPN Inc gives
>permission to link the code of this program with the OpenSSL
>library (or with modified versions of OpenSSL that use the same
>license as OpenSSL), and distribute linked combinations including
>the two.  You must obey the GNU General Public License in all
>respects for all of the code used other than OpenSSL.  If you modify
>this file, you may extend this exception to your version of the
>file, but you are not obligated to do so.  If you do not wish to
>do so, delete this exception statement from your version.
>
>
>
> ___
> 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

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)

Hi,

On Sat, Jan 14, 2023 at 05:28:09PM -0500, James Bottomley wrote:
> What do you mean "a source"? every apache licensed library that's
> statically linked with a GPLv2 program would be an example of this ...
> in the early days there was no dynamic linking, so all the early GNU
> tools were statically linked with wodges of proprietary binary gunk.

These "early day" precede the creation of the Apache license or GPLv2
by many years.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Amend OpenVPN license to allow continued mbed TLS support (allow mbed TLS 3.x linking)