{"thread":{"id":"45507","subject":"Will OpenSSL's license change impact us?","startedAt":"2017-03-24T23:52:28Z","lastAt":"2017-03-26T04:43:23Z","messageCount":11,"participants":["Ævar Arnfjörð Bjarmason","demerphq","Theodore Ts'o","brian m. carlson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"315358","messageId":"CACBZZX6F47uC9jLxppgkUnwVpGV2jpzzP4kwTuqKgayCevomeA@mail.gmail.com","threadId":"45507","inReplyTo":null,"subject":"Will OpenSSL's license change impact us?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-24T23:51:52Z","receivedAt":"2017-03-24T23:52:28Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"They're changing their license[1] to Apache 2 which unlike the current\nfuzzy compatibility with the current license[2] is explicitly\nincompatible with GPLv2[3].\n\nWe use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.\n\nThis still hasn't happened, but given the lifetime of git versions\npackaged up by distros knowing sooner than later if this is going to\nbe a practical problem would be good.\n\nIf so perhaps we could copy the relevant subset of the code int our\ntree, or libressl's, or improve block-sha1.\n\nWe also use OpenSSL for git-imap-send, AFAICT with no fallback other\nthan \"don't use ssl\" or \"use stunnel\".\n\n1. https://www.openssl.org/blog/blog/2017/03/20/license/\n2. https://www.openssl.org/docs/faq.html#LEGAL2\n3. https://www.apache.org/licenses/GPL-compatibility.html\n"},{"id":"315377","messageId":"CANgJU+UCJ9qR-pi9w3+oYjEwDdhbtNX9Nv6brj31VXvt-k-3Lw@mail.gmail.com","threadId":"45507","inReplyTo":"CACBZZX6F47uC9jLxppgkUnwVpGV2jpzzP4kwTuqKgayCevomeA@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2017-03-25T08:40:12Z","receivedAt":"2017-03-25T08:40:20Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> They're changing their license[1] to Apache 2 which unlike the current\n> fuzzy compatibility with the current license[2] is explicitly\n> incompatible with GPLv2[3].\n\nAre you sure there is an issue? From the Apache page on this:\n\nApache 2 software can therefore be included in GPLv3 projects, because\nthe GPLv3 license accepts our software into GPLv3 works. However,\nGPLv3 software cannot be included in Apache projects. The licenses are\nincompatible in one direction only, and it is a result of ASF's\nlicensing philosophy and the GPLv3 authors' interpretation of\ncopyright law.\n\nWhich seems to be the opposite of the concern you are expressing.\n\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"315378","messageId":"CACBZZX7dXsdu0bwt4Rznregw4=v=Sc3cFTQbxJcb-ynf3HXq3Q@mail.gmail.com","threadId":"45507","inReplyTo":"CANgJU+UCJ9qR-pi9w3+oYjEwDdhbtNX9Nv6brj31VXvt-k-3Lw@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-25T09:18:08Z","receivedAt":"2017-03-25T09:20:58Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:\n> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>> They're changing their license[1] to Apache 2 which unlike the current\n>> fuzzy compatibility with the current license[2] is explicitly\n>> incompatible with GPLv2[3].\n>\n> Are you sure there is an issue? From the Apache page on this:\n>\n> Apache 2 software can therefore be included in GPLv3 projects, because\n> the GPLv3 license accepts our software into GPLv3 works. However,\n> GPLv3 software cannot be included in Apache projects. The licenses are\n> incompatible in one direction only, and it is a result of ASF's\n> licensing philosophy and the GPLv3 authors' interpretation of\n> copyright law.\n>\n> Which seems to be the opposite of the concern you are expressing.\n\nThe Apache 2 license is indeed compatible with the GPLv3, but the Git\nproject explicitly uses GPLv2 with no \"or later\" clause:\n\n$ head -n 18 COPYING\n\n Note that the only valid version of the GPL as far as this project\n is concerned is _this_ particular version of the license (ie v2, not\n v2.2 or v3.x or whatever), unless explicitly otherwise stated.\n\n HOWEVER, in order to allow a migration to GPLv3 if that seems like\n a good idea, I also ask that people involved with the project make\n their preferences known. In particular, if you trust me to make that\n decision, you might note so in your copyright message, ie something\n like\n\n        This file is licensed under the GPL v2, or a later version\n        at the discretion of Linus.\n\n  might avoid issues. But we can also just decide to synchronize and\n  contact all copyright holders on record if/when the occasion arises.\n\n                        Linus Torvalds\n"},{"id":"315394","messageId":"CACBZZX4Haah8JmSG6BbfpdOA1aAxtjiuYirLH4=jt01kHL4eQA@mail.gmail.com","threadId":"45507","inReplyTo":"CANgJU+UG1JGYomyQa1FgyN8Q6SkPeEtGKEJfNETrkbtGwrMn9g@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-25T16:35:53Z","receivedAt":"2017-03-25T16:36:45Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Mar 25, 2017 at 10:43 AM, demerphq <demerphq@gmail.com> wrote:\n>\n>\n> On 25 Mar 2017 10:18 a.m., \"Ævar Arnfjörð Bjarmason\" <avarab@gmail.com>\n> wrote:\n>\n> On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:\n>> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>> wrote:\n>>> They're changing their license[1] to Apache 2 which unlike the current\n>>> fuzzy compatibility with the current license[2] is explicitly\n>>> incompatible with GPLv2[3].\n>>\n>> Are you sure there is an issue? From the Apache page on this:\n>>\n>> Apache 2 software can therefore be included in GPLv3 projects, because\n>> the GPLv3 license accepts our software into GPLv3 works. However,\n>> GPLv3 software cannot be included in Apache projects. The licenses are\n>> incompatible in one direction only, and it is a result of ASF's\n>> licensing philosophy and the GPLv3 authors' interpretation of\n>> copyright law.\n>>\n>> Which seems to be the opposite of the concern you are expressing.\n>\n> The Apache 2 license is indeed compatible with the GPLv3, but the Git\n> project explicitly uses GPLv2 with no \"or later\" clause\n>\n>\n> Read the paragraph immediately (I think) after the one I quoted where they\n> state the situation is the same with GPL v2.\n\nMy understanding of that paragraph is that it's still laying out\ncaveats about exactly how GPLv3 is compatible with Apache 2, when it\nis, when it isn't etc. But then it goes on to say:\n\n\"\"\"\nDespite our best efforts, the FSF has never considered the Apache\nLicense to be compatible with GPL version 2, citing the patent\ntermination and indemnification provisions as restrictions not present\nin the older GPL license. The Apache Software Foundation believes that\nyou should always try to obey the constraints expressed by the\ncopyright holder when redistributing their work.\n\"\"\"\n\nSo they're just deferring to the FSF saying it's incompatible, the\nFSF's statement:\nhttps://www.gnu.org/licenses/license-list.html#apache2 \"this license\nis not compatible with GPL version 2\".\n\nAnyway, I'm not a lawyer. Just thought I'd send some E-Mail about this\nsince I noticed it, if it's an issue (and we could e.g. get the SFC to\ncomment, Jeff?) we might need to add e.g. some checks / macros to\nensure we're not compiling against an incompatible OpenSSL.\n\n>\n> $ head -n 18 COPYING\n>\n>  Note that the only valid version of the GPL as far as this project\n>  is concerned is _this_ particular version of the license (ie v2, not\n>  v2.2 or v3.x or whatever), unless explicitly otherwise stated.\n>\n>  HOWEVER, in order to allow a migration to GPLv3 if that seems like\n>  a good idea, I also ask that people involved with the project make\n>  their preferences known. In particular, if you trust me to make that\n>  decision, you might note so in your copyright message, ie something\n>  like\n>\n>         This file is licensed under the GPL v2, or a later version\n>         at the discretion of Linus.\n>\n>   might avoid issues. But we can also just decide to synchronize and\n>   contact all copyright holders on record if/when the occasion arises.\n>\n>                         Linus Torvalds\n>\n>\n"},{"id":"315397","messageId":"CANgJU+WR4L-7-r97od7ids6VK9QyO-QzAntbg7SazmPGj0yWXA@mail.gmail.com","threadId":"45507","inReplyTo":"CACBZZX4Haah8JmSG6BbfpdOA1aAxtjiuYirLH4=jt01kHL4eQA@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2017-03-25T16:57:43Z","receivedAt":"2017-03-25T16:57:51Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> On Sat, Mar 25, 2017 at 10:43 AM, demerphq <demerphq@gmail.com> wrote:\n>>\n>>\n>> On 25 Mar 2017 10:18 a.m., \"Ævar Arnfjörð Bjarmason\" <avarab@gmail.com>\n>> wrote:\n>>\n>> On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:\n>>> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>> wrote:\n>>>> They're changing their license[1] to Apache 2 which unlike the current\n>>>> fuzzy compatibility with the current license[2] is explicitly\n>>>> incompatible with GPLv2[3].\n>>>\n>>> Are you sure there is an issue? From the Apache page on this:\n>>>\n>>> Apache 2 software can therefore be included in GPLv3 projects, because\n>>> the GPLv3 license accepts our software into GPLv3 works. However,\n>>> GPLv3 software cannot be included in Apache projects. The licenses are\n>>> incompatible in one direction only, and it is a result of ASF's\n>>> licensing philosophy and the GPLv3 authors' interpretation of\n>>> copyright law.\n>>>\n>>> Which seems to be the opposite of the concern you are expressing.\n>>\n>> The Apache 2 license is indeed compatible with the GPLv3, but the Git\n>> project explicitly uses GPLv2 with no \"or later\" clause\n>>\n>>\n>> Read the paragraph immediately (I think) after the one I quoted where they\n>> state the situation is the same with GPL v2.\n>\n> My understanding of that paragraph is that it's still laying out\n> caveats about exactly how GPLv3 is compatible with Apache 2, when it\n> is, when it isn't etc. But then it goes on to say:\n>\n> \"\"\"\n> Despite our best efforts, the FSF has never considered the Apache\n> License to be compatible with GPL version 2, citing the patent\n> termination and indemnification provisions as restrictions not present\n> in the older GPL license. The Apache Software Foundation believes that\n> you should always try to obey the constraints expressed by the\n> copyright holder when redistributing their work.\n> \"\"\"\n>\n> So they're just deferring to the FSF saying it's incompatible, the\n> FSF's statement:\n> https://www.gnu.org/licenses/license-list.html#apache2 \"this license\n> is not compatible with GPL version 2\".\n>\n> Anyway, I'm not a lawyer. Just thought I'd send some E-Mail about this\n> since I noticed it, if it's an issue (and we could e.g. get the SFC to\n> comment, Jeff?) we might need to add e.g. some checks / macros to\n> ensure we're not compiling against an incompatible OpenSSL.\n\nJust for the record this what Apache says, with the part I was\nreferring to earlier in slash style italics, and a couple of a key\npoints in star style bold:\n\n----quote----\nApache 2 software *can therefore be included in GPLv3 projects*,\nbecause the GPLv3 license accepts our software into GPLv3 works.\nHowever, GPLv3 software cannot be included in Apache projects. *The\nlicenses are incompatible in one direction only*, and it is a result\nof ASF's licensing philosophy and the GPLv3 authors' interpretation of\ncopyright law.\n\nThis licensing incompatibility applies only when some Apache project\nsoftware becomes a derivative work of some GPLv3 software, because\nthen the Apache software would have to be distributed under GPLv3.\nThis would be incompatible with ASF's requirement that all Apache\nsoftware must be distributed under the Apache License 2.0.\n\nWe avoid GPLv3 software because merely linking to it is considered by\nthe GPLv3 authors to create a derivative work. We want to honor their\nlicense. Unless GPLv3 licensors relax this interpretation of their own\nlicense regarding linking, our licensing philosophies are\nfundamentally incompatible. /This is an identical issue for both GPLv2\nand GPLv3./\n----quote----\n\nI read that as saying that you can use Apache 2 code in GPL projects,\nbut you can't use GPL code in Apache projects. Which makes sense as\nApache 2 is more liberal than GPL.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"315400","messageId":"CACBZZX5bK=emjaQ80J7QuTHXHm=nT3G80zq4xogMqC7Eq9Bs+g@mail.gmail.com","threadId":"45507","inReplyTo":"CANgJU+WR4L-7-r97od7ids6VK9QyO-QzAntbg7SazmPGj0yWXA@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-25T17:51:21Z","receivedAt":"2017-03-25T18:03:36Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Mar 25, 2017 at 5:57 PM, demerphq <demerphq@gmail.com> wrote:\n> On 25 March 2017 at 17:35, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>> On Sat, Mar 25, 2017 at 10:43 AM, demerphq <demerphq@gmail.com> wrote:\n>>>\n>>>\n>>> On 25 Mar 2017 10:18 a.m., \"Ævar Arnfjörð Bjarmason\" <avarab@gmail.com>\n>>> wrote:\n>>>\n>>> On Sat, Mar 25, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:\n>>>> On 25 March 2017 at 00:51, Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>>>> wrote:\n>>>>> They're changing their license[1] to Apache 2 which unlike the current\n>>>>> fuzzy compatibility with the current license[2] is explicitly\n>>>>> incompatible with GPLv2[3].\n>>>>\n>>>> Are you sure there is an issue? From the Apache page on this:\n>>>>\n>>>> Apache 2 software can therefore be included in GPLv3 projects, because\n>>>> the GPLv3 license accepts our software into GPLv3 works. However,\n>>>> GPLv3 software cannot be included in Apache projects. The licenses are\n>>>> incompatible in one direction only, and it is a result of ASF's\n>>>> licensing philosophy and the GPLv3 authors' interpretation of\n>>>> copyright law.\n>>>>\n>>>> Which seems to be the opposite of the concern you are expressing.\n>>>\n>>> The Apache 2 license is indeed compatible with the GPLv3, but the Git\n>>> project explicitly uses GPLv2 with no \"or later\" clause\n>>>\n>>>\n>>> Read the paragraph immediately (I think) after the one I quoted where they\n>>> state the situation is the same with GPL v2.\n>>\n>> My understanding of that paragraph is that it's still laying out\n>> caveats about exactly how GPLv3 is compatible with Apache 2, when it\n>> is, when it isn't etc. But then it goes on to say:\n>>\n>> \"\"\"\n>> Despite our best efforts, the FSF has never considered the Apache\n>> License to be compatible with GPL version 2, citing the patent\n>> termination and indemnification provisions as restrictions not present\n>> in the older GPL license. The Apache Software Foundation believes that\n>> you should always try to obey the constraints expressed by the\n>> copyright holder when redistributing their work.\n>> \"\"\"\n>>\n>> So they're just deferring to the FSF saying it's incompatible, the\n>> FSF's statement:\n>> https://www.gnu.org/licenses/license-list.html#apache2 \"this license\n>> is not compatible with GPL version 2\".\n>>\n>> Anyway, I'm not a lawyer. Just thought I'd send some E-Mail about this\n>> since I noticed it, if it's an issue (and we could e.g. get the SFC to\n>> comment, Jeff?) we might need to add e.g. some checks / macros to\n>> ensure we're not compiling against an incompatible OpenSSL.\n>\n> Just for the record this what Apache says, with the part I was\n> referring to earlier in slash style italics, and a couple of a key\n> points in star style bold:\n>\n> ----quote----\n> Apache 2 software *can therefore be included in GPLv3 projects*,\n> because the GPLv3 license accepts our software into GPLv3 works.\n> However, GPLv3 software cannot be included in Apache projects. *The\n> licenses are incompatible in one direction only*, and it is a result\n> of ASF's licensing philosophy and the GPLv3 authors' interpretation of\n> copyright law.\n>\n> This licensing incompatibility applies only when some Apache project\n> software becomes a derivative work of some GPLv3 software, because\n> then the Apache software would have to be distributed under GPLv3.\n> This would be incompatible with ASF's requirement that all Apache\n> software must be distributed under the Apache License 2.0.\n>\n> We avoid GPLv3 software because merely linking to it is considered by\n> the GPLv3 authors to create a derivative work. We want to honor their\n> license. Unless GPLv3 licensors relax this interpretation of their own\n> license regarding linking, our licensing philosophies are\n> fundamentally incompatible. /This is an identical issue for both GPLv2\n> and GPLv3./\n> ----quote----\n>\n> I read that as saying that you can use Apache 2 code in GPL projects,\n> but you can't use GPL code in Apache projects. Which makes sense as\n> Apache 2 is more liberal than GPL.\n\nIn GPLv3 projects only, not GPLv2 projects. The paragraphs you're\nquoting all explicitly mention v3 only, so statements like\n\"incompatible in one direction\" only apply to Apache 2 && GPLv3, but\ndon't at all apply to GPLv2, which is what we're using.\n"},{"id":"315406","messageId":"20170325211135.62sa76hlvyiexvje@thunk.org","threadId":"45507","inReplyTo":"CACBZZX5bK=emjaQ80J7QuTHXHm=nT3G80zq4xogMqC7Eq9Bs+g@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2017-03-25T21:11:35Z","receivedAt":"2017-03-25T21:12:34Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Mar 25, 2017 at 06:51:21PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> In GPLv3 projects only, not GPLv2 projects. The paragraphs you're\n> quoting all explicitly mention v3 only, so statements like\n> \"incompatible in one direction\" only apply to Apache 2 && GPLv3, but\n> don't at all apply to GPLv2, which is what we're using.\n\nIt's complicated.\n\nIt's fair enough to say that the FSF adopts a copyright maximalist\nposition, and by their interpretation, the two licenses are\nincompatible, and it doesn't matter whether the two pieces of code are\nlinked staticaly, dynamically, or one calls the other over an RPC\ncall.\n\nNot everyone agrees with their legal analysis.  May I suggest that we\nnot play amateur lawyer on the mailing list, and try to settle this\nhere?  Each distribution can make its own decision, which may be based\non its legal advice, the local laws and legal precedents in which they\noperate, etc.  And indeed, different distributions have already come\nto different conclusions with respect to various license compatibility\nissues.  (Examples: dynamically linking GPL programs with OpenSSL\nlibraries under the old license, distributing ZFS modules for Linux,\netc.)\n\nWe don't expect lawyers to debug edge cases in a compiler's code\ngeneration.  Programmers shouldn't try to parse edge cases in the law,\nor try to use a soldering iron, unless they have explicit training and\nexpertise to do so.  :-)\n\n\t\t\t\t- Ted\n\n"},{"id":"315413","messageId":"CACBZZX6smBoWg1KKAT=dc0Bn1n4E2chtRyO6xVisACrtGuHzEw@mail.gmail.com","threadId":"45507","inReplyTo":"20170325211135.62sa76hlvyiexvje@thunk.org","subject":"Re: Will OpenSSL's license change impact us?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-25T21:50:06Z","receivedAt":"2017-03-25T21:50:49Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Mar 25, 2017 at 10:11 PM, Theodore Ts'o <tytso@mit.edu> wrote:\n> On Sat, Mar 25, 2017 at 06:51:21PM +0100, Ęvar Arnfjörš Bjarmason wrote:\n>> In GPLv3 projects only, not GPLv2 projects. The paragraphs you're\n>> quoting all explicitly mention v3 only, so statements like\n>> \"incompatible in one direction\" only apply to Apache 2 && GPLv3, but\n>> don't at all apply to GPLv2, which is what we're using.\n>\n> It's complicated.\n>\n> It's fair enough to say that the FSF adopts a copyright maximalist\n> position, and by their interpretation, the two licenses are\n> incompatible, and it doesn't matter whether the two pieces of code are\n> linked staticaly, dynamically, or one calls the other over an RPC\n> call.\n>\n> Not everyone agrees with their legal analysis.  May I suggest that we\n> not play amateur lawyer on the mailing list, and try to settle this\n> here?  Each distribution can make its own decision, which may be based\n> on its legal advice, the local laws and legal precedents in which they\n> operate, etc.  And indeed, different distributions have already come\n> to different conclusions with respect to various license compatibility\n> issues.  (Examples: dynamically linking GPL programs with OpenSSL\n> libraries under the old license, distributing ZFS modules for Linux,\n> etc.)\n>\n> We don't expect lawyers to debug edge cases in a compiler's code\n> generation.  Programmers shouldn't try to parse edge cases in the law,\n> or try to use a soldering iron, unless they have explicit training and\n> expertise to do so.  :-)\n\nYeah fully agree with the internet lawyering. I'm not looking for\nthat, just seeing if someone knows if this might be an issue for at\nleast some distros, then it's something for us to keep an eye on if\nOpenSSL's license changes, and a sane default for us to adopt might be\nto e.g. require that some flag be passed to the Makefile declaring\n\"yes I'm OK with combining AL2 + GPLv2\" if the OpenSSL version is\nnewer than so-and-so.\n"},{"id":"315414","messageId":"CACBZZX6=zEHkYUZ3qOQLmB+6658YN1Hy+3TY8zLAxjpUtivQpA@mail.gmail.com","threadId":"45507","inReplyTo":"20170325214427.f3kdxgrldpnar4ag@genre.crustytoothpaste.net","subject":"Re: Will OpenSSL's license change impact us?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-03-25T21:52:47Z","receivedAt":"2017-03-25T21:53:21Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Mar 25, 2017 at 10:44 PM, brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n> On Sat, Mar 25, 2017 at 12:51:52AM +0100, Ævar Arnfjörð Bjarmason wrote:\n>> They're changing their license[1] to Apache 2 which unlike the current\n>> fuzzy compatibility with the current license[2] is explicitly\n>> incompatible with GPLv2[3].\n>>\n>> We use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.\n>>\n>> This still hasn't happened, but given the lifetime of git versions\n>> packaged up by distros knowing sooner than later if this is going to\n>> be a practical problem would be good.\n>>\n>> If so perhaps we could copy the relevant subset of the code int our\n>> tree, or libressl's, or improve block-sha1.\n>\n> I think that most distros don't link against OpenSSL because they can't\n> take advantage of the system library exception.  I don't think that's\n> going to change.\n\n\"ldd -r\" against git itself on my Debian testing doesn't return\nlibssl, but git-imap-send is dynamically linked to it:\n\n$ ldd -r /usr/lib/git-core/git-imap-send|grep ssl\n        libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2\n(0x00007f244b2f6000)\n$ apt-cache show libssl1.0.2:amd64\nPackage: libssl1.0.2\nSource: openssl1.0\nVersion: 1.0.2k-1\n[...]\nHomepage: https://www.openssl.org\n\n> If we want to consider performance-related concerns, I think the easier\n> solution is using Nettle, which is LGPL 2.1.  Considering that the\n> current opinions for a new hash function are moving in the direction of\n> SHA-3, which Nettle has, but OpenSSL does not, I think that might be a\n> better decision overall.  It was certainly the implementation I would\n> use if I were to implement it.\n\nYeah there's a lot of options open for just sha1-ing, but we also use\nOpenSSL for TLS via imap-send.\n"},{"id":"315415","messageId":"20170325214427.f3kdxgrldpnar4ag@genre.crustytoothpaste.net","threadId":"45507","inReplyTo":"CACBZZX6F47uC9jLxppgkUnwVpGV2jpzzP4kwTuqKgayCevomeA@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2017-03-25T21:44:27Z","receivedAt":"2017-03-25T21:53:40Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sat, Mar 25, 2017 at 12:51:52AM +0100, Ævar Arnfjörð Bjarmason wrote:\n> They're changing their license[1] to Apache 2 which unlike the current\n> fuzzy compatibility with the current license[2] is explicitly\n> incompatible with GPLv2[3].\n> \n> We use OpenSSL for SHA1 by default unless NO_OPENSSL=YesPlease.\n> \n> This still hasn't happened, but given the lifetime of git versions\n> packaged up by distros knowing sooner than later if this is going to\n> be a practical problem would be good.\n> \n> If so perhaps we could copy the relevant subset of the code int our\n> tree, or libressl's, or improve block-sha1.\n\nI think that most distros don't link against OpenSSL because they can't\ntake advantage of the system library exception.  I don't think that's\ngoing to change.\n\nIf we want to consider performance-related concerns, I think the easier\nsolution is using Nettle, which is LGPL 2.1.  Considering that the\ncurrent opinions for a new hash function are moving in the direction of\nSHA-3, which Nettle has, but OpenSSL does not, I think that might be a\nbetter decision overall.  It was certainly the implementation I would\nuse if I were to implement it.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"315450","messageId":"20170326044308.7hxiqsgrzvxmsfnh@sigill.intra.peff.net","threadId":"45507","inReplyTo":"CACBZZX6=zEHkYUZ3qOQLmB+6658YN1Hy+3TY8zLAxjpUtivQpA@mail.gmail.com","subject":"Re: Will OpenSSL's license change impact us?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-26T04:43:09Z","receivedAt":"2017-03-26T04:43:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 25, 2017 at 10:52:47PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> > If we want to consider performance-related concerns, I think the easier\n> > solution is using Nettle, which is LGPL 2.1.  Considering that the\n> > current opinions for a new hash function are moving in the direction of\n> > SHA-3, which Nettle has, but OpenSSL does not, I think that might be a\n> > better decision overall.  It was certainly the implementation I would\n> > use if I were to implement it.\n> \n> Yeah there's a lot of options open for just sha1-ing, but we also use\n> OpenSSL for TLS via imap-send.\n\nThese days imap-send has basically two implementations: one that speaks\nimap itself (optionally using openssl), and one that just uses curl's\nimap support.  If you build with NO_OPENSSL, the curl implementation\nkicks in by default.\n\nSo I think any distro worried about licensing can just \"make NO_OPENSSL\"\ntoday and get full functionality.\n\nCurl may use openssl behind the scenes, of course, but distros already\nhave to deal with that (at least on Debian, you can drop-in gnutls).\n\n-Peff\n"}]}