Will OpenSSL's license change impact us?

Will OpenSSL's license change impact us?

[Ævar Arnfjörð Bjarmason]

They're changing their license[1] to Apache 2 which unlike the current
fuzzy compatibility with the current license[2] is explicitly
incompatible with GPLv2[3].

We use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.

This still hasn't happened, but given the lifetime of git versions
packaged up by distros knowing sooner than later if this is going to
be a practical problem would be good.

If so perhaps we could copy the relevant subset of the code int our
tree, or libressl's, or improve block-sha1.

We also use OpenSSL for git-imap-send, AFAICT with no fallback other
than "don't use ssl" or "use stunnel".

1. https://www.openssl.org/blog/blog/2017/03/20/license/
2. https://www.openssl.org/docs/faq.html#LEGAL2
3. https://www.apache.org/licenses/GPL-compatibility.html

Re: Will OpenSSL's license change impact us?

[demerphq]

On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> They're changing their license[1] to Apache 2 which unlike the current
> fuzzy compatibility with the current license[2] is explicitly
> incompatible with GPLv2[3].

Are you sure there is an issue? From the Apache page on this:

Apache 2 software can therefore be included in GPLv3 projects, because
the GPLv3 license accepts our software into GPLv3 works. However,
GPLv3 software cannot be included in Apache projects. The licenses are
incompatible in one direction only, and it is a result of ASF's
licensing philosophy and the GPLv3 authors' interpretation of
copyright law.

Which seems to be the opposite of the concern you are expressing.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Will OpenSSL's license change impact us?

[Ævar Arnfjörð Bjarmason]

On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:
> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> They're changing their license[1] to Apache 2 which unlike the current
>> fuzzy compatibility with the current license[2] is explicitly
>> incompatible with GPLv2[3].
>
> Are you sure there is an issue? From the Apache page on this:
>
> Apache 2 software can therefore be included in GPLv3 projects, because
> the GPLv3 license accepts our software into GPLv3 works. However,
> GPLv3 software cannot be included in Apache projects. The licenses are
> incompatible in one direction only, and it is a result of ASF's
> licensing philosophy and the GPLv3 authors' interpretation of
> copyright law.
>
> Which seems to be the opposite of the concern you are expressing.

The Apache 2 license is indeed compatible with the GPLv3, but the Git
project explicitly uses GPLv2 with no "or later" clause:

$ head -n 18 COPYING

 Note that the only valid version of the GPL as far as this project
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.

 HOWEVER, in order to allow a migration to GPLv3 if that seems like
 a good idea, I also ask that people involved with the project make
 their preferences known. In particular, if you trust me to make that
 decision, you might note so in your copyright message, ie something
 like

        This file is licensed under the GPL v2, or a later version
        at the discretion of Linus.

  might avoid issues. But we can also just decide to synchronize and
  contact all copyright holders on record if/when the occasion arises.

                        Linus Torvalds

Re: Will OpenSSL's license change impact us?

[Ævar Arnfjörð Bjarmason]

On Sat, Mar 25, 2017 at 10:43 AM, demerphq <demerphq@gmail.com> wrote:
>
>
> On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
> wrote:
>
> On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:
>> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> wrote:
>>> They're changing their license[1] to Apache 2 which unlike the current
>>> fuzzy compatibility with the current license[2] is explicitly
>>> incompatible with GPLv2[3].
>>
>> Are you sure there is an issue? From the Apache page on this:
>>
>> Apache 2 software can therefore be included in GPLv3 projects, because
>> the GPLv3 license accepts our software into GPLv3 works. However,
>> GPLv3 software cannot be included in Apache projects. The licenses are
>> incompatible in one direction only, and it is a result of ASF's
>> licensing philosophy and the GPLv3 authors' interpretation of
>> copyright law.
>>
>> Which seems to be the opposite of the concern you are expressing.
>
> The Apache 2 license is indeed compatible with the GPLv3, but the Git
> project explicitly uses GPLv2 with no "or later" clause
>
>
> Read the paragraph immediately (I think) after the one I quoted where they
> state the situation is the same with GPL v2.

My understanding of that paragraph is that it's still laying out
caveats about exactly how GPLv3 is compatible with Apache 2, when it
is, when it isn't etc. But then it goes on to say:

"""
Despite our best efforts, the FSF has never considered the Apache
License to be compatible with GPL version 2, citing the patent
termination and indemnification provisions as restrictions not present
in the older GPL license. The Apache Software Foundation believes that
you should always try to obey the constraints expressed by the
copyright holder when redistributing their work.
"""

So they're just deferring to the FSF saying it's incompatible, the
FSF's statement:
https://www.gnu.org/licenses/license-list.html#apache2 "this license
is not compatible with GPL version 2".

Anyway, I'm not a lawyer. Just thought I'd send some E-Mail about this
since I noticed it, if it's an issue (and we could e.g. get the SFC to
comment, Jeff?) we might need to add e.g. some checks / macros to
ensure we're not compiling against an incompatible OpenSSL.

>
> $ head -n 18 COPYING
>
>  Note that the only valid version of the GPL as far as this project
>  is concerned is _this_ particular version of the license (ie v2, not
>  v2.2 or v3.x or whatever), unless explicitly otherwise stated.
>
>  HOWEVER, in order to allow a migration to GPLv3 if that seems like
>  a good idea, I also ask that people involved with the project make
>  their preferences known. In particular, if you trust me to make that
>  decision, you might note so in your copyright message, ie something
>  like
>
>         This file is licensed under the GPL v2, or a later version
>         at the discretion of Linus.
>
>   might avoid issues. But we can also just decide to synchronize and
>   contact all copyright holders on record if/when the occasion arises.
>
>                         Linus Torvalds
>
>

Re: Will OpenSSL's license change impact us?

[demerphq]

On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Sat, Mar 25, 2017 at 10:43 AM, demerphq <demerphq@gmail.com> wrote:
>>
>>
>> On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
>> wrote:
>>
>> On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:
>>> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>> wrote:
>>>> They're changing their license[1] to Apache 2 which unlike the current
>>>> fuzzy compatibility with the current license[2] is explicitly
>>>> incompatible with GPLv2[3].
>>>
>>> Are you sure there is an issue? From the Apache page on this:
>>>
>>> Apache 2 software can therefore be included in GPLv3 projects, because
>>> the GPLv3 license accepts our software into GPLv3 works. However,
>>> GPLv3 software cannot be included in Apache projects. The licenses are
>>> incompatible in one direction only, and it is a result of ASF's
>>> licensing philosophy and the GPLv3 authors' interpretation of
>>> copyright law.
>>>
>>> Which seems to be the opposite of the concern you are expressing.
>>
>> The Apache 2 license is indeed compatible with the GPLv3, but the Git
>> project explicitly uses GPLv2 with no "or later" clause
>>
>>
>> Read the paragraph immediately (I think) after the one I quoted where they
>> state the situation is the same with GPL v2.
>
> My understanding of that paragraph is that it's still laying out
> caveats about exactly how GPLv3 is compatible with Apache 2, when it
> is, when it isn't etc. But then it goes on to say:
>
> """
> Despite our best efforts, the FSF has never considered the Apache
> License to be compatible with GPL version 2, citing the patent
> termination and indemnification provisions as restrictions not present
> in the older GPL license. The Apache Software Foundation believes that
> you should always try to obey the constraints expressed by the
> copyright holder when redistributing their work.
> """
>
> So they're just deferring to the FSF saying it's incompatible, the
> FSF's statement:
> https://www.gnu.org/licenses/license-list.html#apache2 "this license
> is not compatible with GPL version 2".
>
> Anyway, I'm not a lawyer. Just thought I'd send some E-Mail about this
> since I noticed it, if it's an issue (and we could e.g. get the SFC to
> comment, Jeff?) we might need to add e.g. some checks / macros to
> ensure we're not compiling against an incompatible OpenSSL.

Just for the record this what Apache says, with the part I was
referring to earlier in slash style italics, and a couple of a key
points in star style bold:

----quote----
Apache 2 software *can therefore be included in GPLv3 projects*,
because the GPLv3 license accepts our software into GPLv3 works.
However, GPLv3 software cannot be included in Apache projects. *The
licenses are incompatible in one direction only*, and it is a result
of ASF's licensing philosophy and the GPLv3 authors' interpretation of
copyright law.

This licensing incompatibility applies only when some Apache project
software becomes a derivative work of some GPLv3 software, because
then the Apache software would have to be distributed under GPLv3.
This would be incompatible with ASF's requirement that all Apache
software must be distributed under the Apache License 2.0.

We avoid GPLv3 software because merely linking to it is considered by
the GPLv3 authors to create a derivative work. We want to honor their
license. Unless GPLv3 licensors relax this interpretation of their own
license regarding linking, our licensing philosophies are
fundamentally incompatible. /This is an identical issue for both GPLv2
and GPLv3./
----quote----

I read that as saying that you can use Apache 2 code in GPL projects,
but you can't use GPL code in Apache projects. Which makes sense as
Apache 2 is more liberal than GPL.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Will OpenSSL's license change impact us?

[Ævar Arnfjörð Bjarmason]

On Sat, Mar 25, 2017 at 5:57 PM, demerphq <demerphq@gmail.com> wrote:
> On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>> On Sat, Mar 25, 2017 at 10:43 AM, demerphq <demerphq@gmail.com> wrote:
>>>
>>>
>>> On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
>>> wrote:
>>>
>>> On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:
>>>> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>>>> wrote:
>>>>> They're changing their license[1] to Apache 2 which unlike the current
>>>>> fuzzy compatibility with the current license[2] is explicitly
>>>>> incompatible with GPLv2[3].
>>>>
>>>> Are you sure there is an issue? From the Apache page on this:
>>>>
>>>> Apache 2 software can therefore be included in GPLv3 projects, because
>>>> the GPLv3 license accepts our software into GPLv3 works. However,
>>>> GPLv3 software cannot be included in Apache projects. The licenses are
>>>> incompatible in one direction only, and it is a result of ASF's
>>>> licensing philosophy and the GPLv3 authors' interpretation of
>>>> copyright law.
>>>>
>>>> Which seems to be the opposite of the concern you are expressing.
>>>
>>> The Apache 2 license is indeed compatible with the GPLv3, but the Git
>>> project explicitly uses GPLv2 with no "or later" clause
>>>
>>>
>>> Read the paragraph immediately (I think) after the one I quoted where they
>>> state the situation is the same with GPL v2.
>>
>> My understanding of that paragraph is that it's still laying out
>> caveats about exactly how GPLv3 is compatible with Apache 2, when it
>> is, when it isn't etc. But then it goes on to say:
>>
>> """
>> Despite our best efforts, the FSF has never considered the Apache
>> License to be compatible with GPL version 2, citing the patent
>> termination and indemnification provisions as restrictions not present
>> in the older GPL license. The Apache Software Foundation believes that
>> you should always try to obey the constraints expressed by the
>> copyright holder when redistributing their work.
>> """
>>
>> So they're just deferring to the FSF saying it's incompatible, the
>> FSF's statement:
>> https://www.gnu.org/licenses/license-list.html#apache2 "this license
>> is not compatible with GPL version 2".
>>
>> Anyway, I'm not a lawyer. Just thought I'd send some E-Mail about this
>> since I noticed it, if it's an issue (and we could e.g. get the SFC to
>> comment, Jeff?) we might need to add e.g. some checks / macros to
>> ensure we're not compiling against an incompatible OpenSSL.
>
> Just for the record this what Apache says, with the part I was
> referring to earlier in slash style italics, and a couple of a key
> points in star style bold:
>
> ----quote----
> Apache 2 software *can therefore be included in GPLv3 projects*,
> because the GPLv3 license accepts our software into GPLv3 works.
> However, GPLv3 software cannot be included in Apache projects. *The
> licenses are incompatible in one direction only*, and it is a result
> of ASF's licensing philosophy and the GPLv3 authors' interpretation of
> copyright law.
>
> This licensing incompatibility applies only when some Apache project
> software becomes a derivative work of some GPLv3 software, because
> then the Apache software would have to be distributed under GPLv3.
> This would be incompatible with ASF's requirement that all Apache
> software must be distributed under the Apache License 2.0.
>
> We avoid GPLv3 software because merely linking to it is considered by
> the GPLv3 authors to create a derivative work. We want to honor their
> license. Unless GPLv3 licensors relax this interpretation of their own
> license regarding linking, our licensing philosophies are
> fundamentally incompatible. /This is an identical issue for both GPLv2
> and GPLv3./
> ----quote----
>
> I read that as saying that you can use Apache 2 code in GPL projects,
> but you can't use GPL code in Apache projects. Which makes sense as
> Apache 2 is more liberal than GPL.

In GPLv3 projects only, not GPLv2 projects. The paragraphs you're
quoting all explicitly mention v3 only, so statements like
"incompatible in one direction" only apply to Apache 2 && GPLv3, but
don't at all apply to GPLv2, which is what we're using.

Re: Will OpenSSL's license change impact us?

[Theodore Ts'o]

On Sat, Mar 25, 2017 at 06:51:21PM +0100, Ævar Arnfjörð Bjarmason wrote:
> In GPLv3 projects only, not GPLv2 projects. The paragraphs you're
> quoting all explicitly mention v3 only, so statements like
> "incompatible in one direction" only apply to Apache 2 && GPLv3, but
> don't at all apply to GPLv2, which is what we're using.

It's complicated.

It's fair enough to say that the FSF adopts a copyright maximalist
position, and by their interpretation, the two licenses are
incompatible, and it doesn't matter whether the two pieces of code are
linked staticaly, dynamically, or one calls the other over an RPC
call.

Not everyone agrees with their legal analysis.  May I suggest that we
not play amateur lawyer on the mailing list, and try to settle this
here?  Each distribution can make its own decision, which may be based
on its legal advice, the local laws and legal precedents in which they
operate, etc.  And indeed, different distributions have already come
to different conclusions with respect to various license compatibility
issues.  (Examples: dynamically linking GPL programs with OpenSSL
libraries under the old license, distributing ZFS modules for Linux,
etc.)

We don't expect lawyers to debug edge cases in a compiler's code
generation.  Programmers shouldn't try to parse edge cases in the law,
or try to use a soldering iron, unless they have explicit training and
expertise to do so.  :-)

				- Ted

Re: Will OpenSSL's license change impact us?

[Ævar Arnfjörð Bjarmason]

On Sat, Mar 25, 2017 at 10:11 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Sat, Mar 25, 2017 at 06:51:21PM +0100, Ęvar Arnfjörš Bjarmason wrote:
>> In GPLv3 projects only, not GPLv2 projects. The paragraphs you're
>> quoting all explicitly mention v3 only, so statements like
>> "incompatible in one direction" only apply to Apache 2 && GPLv3, but
>> don't at all apply to GPLv2, which is what we're using.
>
> It's complicated.
>
> It's fair enough to say that the FSF adopts a copyright maximalist
> position, and by their interpretation, the two licenses are
> incompatible, and it doesn't matter whether the two pieces of code are
> linked staticaly, dynamically, or one calls the other over an RPC
> call.
>
> Not everyone agrees with their legal analysis.  May I suggest that we
> not play amateur lawyer on the mailing list, and try to settle this
> here?  Each distribution can make its own decision, which may be based
> on its legal advice, the local laws and legal precedents in which they
> operate, etc.  And indeed, different distributions have already come
> to different conclusions with respect to various license compatibility
> issues.  (Examples: dynamically linking GPL programs with OpenSSL
> libraries under the old license, distributing ZFS modules for Linux,
> etc.)
>
> We don't expect lawyers to debug edge cases in a compiler's code
> generation.  Programmers shouldn't try to parse edge cases in the law,
> or try to use a soldering iron, unless they have explicit training and
> expertise to do so.  :-)

Yeah fully agree with the internet lawyering. I'm not looking for
that, just seeing if someone knows if this might be an issue for at
least some distros, then it's something for us to keep an eye on if
OpenSSL's license changes, and a sane default for us to adopt might be
to e.g. require that some flag be passed to the Makefile declaring
"yes I'm OK with combining AL2 + GPLv2" if the OpenSSL version is
newer than so-and-so.

Re: Will OpenSSL's license change impact us?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Sat, Mar 25, 2017 at 12:51:52AM +0100, Ævar Arnfjörð Bjarmason wrote:
> They're changing their license[1] to Apache 2 which unlike the current
> fuzzy compatibility with the current license[2] is explicitly
> incompatible with GPLv2[3].
> 
> We use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.
> 
> This still hasn't happened, but given the lifetime of git versions
> packaged up by distros knowing sooner than later if this is going to
> be a practical problem would be good.
> 
> If so perhaps we could copy the relevant subset of the code int our
> tree, or libressl's, or improve block-sha1.

I think that most distros don't link against OpenSSL because they can't
take advantage of the system library exception.  I don't think that's
going to change.

If we want to consider performance-related concerns, I think the easier
solution is using Nettle, which is LGPL 2.1.  Considering that the
current opinions for a new hash function are moving in the direction of
SHA-3, which Nettle has, but OpenSSL does not, I think that might be a
better decision overall.  It was certainly the implementation I would
use if I were to implement it.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

Re: Will OpenSSL's license change impact us?

[Ævar Arnfjörð Bjarmason]

On Sat, Mar 25, 2017 at 10:44 PM, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> On Sat, Mar 25, 2017 at 12:51:52AM +0100, Ævar Arnfjörð Bjarmason wrote:
>> They're changing their license[1] to Apache 2 which unlike the current
>> fuzzy compatibility with the current license[2] is explicitly
>> incompatible with GPLv2[3].
>>
>> We use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.
>>
>> This still hasn't happened, but given the lifetime of git versions
>> packaged up by distros knowing sooner than later if this is going to
>> be a practical problem would be good.
>>
>> If so perhaps we could copy the relevant subset of the code int our
>> tree, or libressl's, or improve block-sha1.
>
> I think that most distros don't link against OpenSSL because they can't
> take advantage of the system library exception.  I don't think that's
> going to change.

"ldd -r" against git itself on my Debian testing doesn't return
libssl, but git-imap-send is dynamically linked to it:

$ ldd -r /usr/lib/git-core/git-imap-send|grep ssl
        libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
(0x00007f244b2f6000)
$ apt-cache show libssl1.0.2:amd64
Package: libssl1.0.2
Source: openssl1.0
Version: 1.0.2k-1
[...]
Homepage: https://www.openssl.org

> If we want to consider performance-related concerns, I think the easier
> solution is using Nettle, which is LGPL 2.1.  Considering that the
> current opinions for a new hash function are moving in the direction of
> SHA-3, which Nettle has, but OpenSSL does not, I think that might be a
> better decision overall.  It was certainly the implementation I would
> use if I were to implement it.

Yeah there's a lot of options open for just sha1-ing, but we also use
OpenSSL for TLS via imap-send.

Re: Will OpenSSL's license change impact us?

[Jeff King]

On Sat, Mar 25, 2017 at 10:52:47PM +0100, Ævar Arnfjörð Bjarmason wrote:

> > If we want to consider performance-related concerns, I think the easier
> > solution is using Nettle, which is LGPL 2.1.  Considering that the
> > current opinions for a new hash function are moving in the direction of
> > SHA-3, which Nettle has, but OpenSSL does not, I think that might be a
> > better decision overall.  It was certainly the implementation I would
> > use if I were to implement it.
> 
> Yeah there's a lot of options open for just sha1-ing, but we also use
> OpenSSL for TLS via imap-send.

These days imap-send has basically two implementations: one that speaks
imap itself (optionally using openssl), and one that just uses curl's
imap support.  If you build with NO_OPENSSL, the curl implementation
kicks in by default.

So I think any distro worried about licensing can just "make NO_OPENSSL"
today and get full functionality.

Curl may use openssl behind the scenes, of course, but distros already
have to deal with that (at least on Debian, you can drop-in gnutls).

-Peff