Re: Will OpenSSL's license change impact us?
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
Re: Will OpenSSL's license change impact us?
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 signature.asc Description: PGP signature
Re: Will OpenSSL's license change impact us?
On Sat, Mar 25, 2017 at 10:44 PM, brian m. carlson 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 (0x7f244b2f6000) $ 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?
On Sat, Mar 25, 2017 at 10:11 PM, Theodore Ts'o 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?
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?
On Sat, Mar 25, 2017 at 5:57 PM, demerphq wrote: > On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason wrote: >> On Sat, Mar 25, 2017 at 10:43 AM, demerphq wrote: >>> >>> >>> On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason" >>> wrote: >>> >>> On Sat, Mar 25, 2017 at 9:40 AM, demerphq wrote: On 25 March 2017 at 00:51, Æ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]. 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?
On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason wrote: > On Sat, Mar 25, 2017 at 10:43 AM, demerphq wrote: >> >> >> On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason" >> wrote: >> >> On Sat, Mar 25, 2017 at 9:40 AM, demerphq wrote: >>> On 25 March 2017 at 00:51, Æ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]. >>> >>> 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?
On Sat, Mar 25, 2017 at 10:43 AM, demerphq wrote: > > > On 25 Mar 2017 10:18 a.m., "Ævar Arnfjörð Bjarmason" > wrote: > > On Sat, Mar 25, 2017 at 9:40 AM, demerphq wrote: >> On 25 March 2017 at 00:51, Æ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]. >> >> 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?
On Sat, Mar 25, 2017 at 9:40 AM, demerphq wrote: > On 25 March 2017 at 00:51, Æ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]. > > 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?
On 25 March 2017 at 00:51, Æ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]. 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/"
