6 ms·

Crypto optimizations for Go from CloudFlare/Intel blocked by licensing issues

125 points by dawkins 11y ago

jgrahamc 11y ago
Not sure this needs to be on the top of HN. It's a licensing issue that I'm sure we can work out between CloudFlare, Google and Intel.
- striking 11y ago
  If it makes anyone feel any better, it's really between Google and Intel as the last post notes: >I'm afraid that, without Intel's permission, it doesn't appear that this change can move forward. What I don't get is this: >Intel do not wish to publish this code under the Go license and having bits of the Go repo under different licenses is sufficient unpleasant that counsel didn't want to entertain the idea. What makes the Go license different than the BSD under which Intel has published their code? HN is a place for things that make people think. This made me think, so I gave it an upvote.
  - jgrahamc 11y ago
    I agree, but CloudFlare wants to do whatever we can to make sure this stuff gets into Go.
  - DannyBee 11y ago
    "What makes the Go license different than the BSD under which Intel has published their code? " The go license is not different than the BSD license. Both the intel and the go stuff is bsd licensed. However, the BSD license requires you reproduce the copyright notices attached to it the top of the license. If you do not, you are in violation of the license (which in the US, is usually copyright infringement). By using "the go authors" as the copyright notice, go ensures you only ever have to reproduce one notice. If it says "copyright intel", now you have to reproduce A. The go notice when you use go without the stuff that is copyright intel B. The go notice and the intel notice when you use go and the stuff that is copyright intel. C. The intel notice when you use the intel stuff without anything else that is copyright go. Now, when 3 other companies decide they want their notices in there too (after all, if intel is special, why isn't broadcom, or whoever), and only add it to some files, imagine the fun that results for users. There are other issues, too, but succinctly, you don't want to live in this world. It leads to shipping things which reproduce 100's of pages of notices in documentation.
- briansmith 11y ago
  I'm glad y'all are working it out. The licensing for that stuff really is confusing, and discourages the use of that code. It's worse in OpenSSL because the x86 and ARM adaptations are licensed under the OpenSSL/Cryptograms licenses instead of BSD/Apache. Big chunks are labeled as transliterations of the X64 code, so I'd expect them to also be BSD/Apache licensed. Also, it isn't clear what Andy Polyakov's significant improvements of the the X64 code mean for the copyright, licensing, and re-licensing from Apache to dual BSD/Apache. In other words, it seems the copyright lines should, at a minimum, mention Andy's copyright, and it should be made clearer whether Andy agrees to dual license his contributions under the BSD/Apache dual license.
- justonepost 11y ago
  I disagree, it is relevant for HN: it's open source. I'm really curious as to why we can't just use it anywhere given the BSD license.
  - jacquesm 11y ago
    That's why larger companies (and smart smaller ones) will ask their lawyers before accepting commits like these lest some SCO/Novell/Microsoft like demon jumps at them at some unspecified but presumably inconvenient time in the future. It's actually a really nice illustration of how hairy such stuff can be even with all the parties meaning well and as such it definitely is relevant for HN.
  - hyperion2010 11y ago
    BSD header must stay on the code. Council doesn't want BSD headers in the GO code. Not clear there is actually any way forward unless someone can find a way to convince them that it is manageable to put BSD code into the repo. Another good reminder that cooking your own license is a bad idea.
    - chimeracoder 11y ago
      > Another good reminder that cooking your own license is a bad idea. I don't know what you're referring to here, since nobody has made their own license. The problem as I understand it is that (some of) the code in the patch is covered by a BSD license from Intel, which is not the same as the rest of the Go code, which is covered by a BSD license from the Go authors. The text of the BSD licenses themselves is mutually compatible, but because the licenses credit different sources ("Go authors" vs. "Intel Corporation"), that makes them different licenses. It is legally possible to combine them, but practically annoying for anyone else who may want to reuse the code later.
      - hyperion2010 11y ago
        Hrm. I think you're right. I had gone and looked at the GO license and was rather confused because it looked like the bsd 3 clause to me except for a change directly inserting Google's name into the 3rd clause. Could that be the source of the incompatibility?
bri3d 11y ago
I thought this was going to be some sort of crazy patent issue or something to do with Intel's proprietary compilers, but instead it's a simple license incompatibility where authors are trying to transfer code (that's been BSD/Apache dual-licensed in OpenSSL) into Go, which uses its own license.
- hyperion2010 11y ago
  Title should probably s/licensing/license because it is actually a license issue not a licensing issue.
- teraflop 11y ago
  More to the point, if I understand correctly: mixing these licenses is legally permissible for the Go team (or anyone else who wishes to apply to the patch) but the resulting codebase is no longer uniformly governed by Go's CLA. Intel doesn't want to relicense their code (which would AFAICT not meaningfully change the terms of the license, but would result in its authorship being lumped together with the rest of "The Go Authors" for licensing purposes) and the Go team's legal counsel apparently has some reason for being unwilling to accept the resulting mixed-license state.
  - chimeracoder 11y ago
    > apparently has some reason for being unwilling to accept the resulting mixed-license state. As someone who writes a lot of Go, I can understand the reason for this. If I reuse a function from the standard library, I don't want to have to check which headers happen to pertain to that. I'd much rather know that all Go code is covered by the same license, and therefore the same header. For what it's worth, all Go code so far is under the same license[0]. Even the Go-specific parts of gccgo are under the same license as gc (though when distributed with gccgo, the combined package is distributed under the GPL). [0] http://golang.org http://golang.org lists these as the only exceptions to the BSD licensing for code and CC-BY licensing for non-code, which basically just means the obvious Google brand-specific stuff. https://developers.google.com/site-policies#restrictions https://developers.google.com/site-policies#restrictions
  - 11y ago
eastdakota 11y ago
For the record: we (at CloudFlare) are happy to support any Go-compatible license for the code. Hopefully we can convince Intel to do the same.
- ajross 11y ago
  Can someone explain why the existing license (dual Apache and 3-clause BSD I believe?) is not Go-compatible? I mean, here's what I turned up for the "Go license", and it's almost verbatim 3-clause BSD: https://golang.org/LICENSE https://golang.org/LICENSE What more could Google Legal possibly want here beyond a full copyright assignment? What possible risk is there merging two 3-clause BSD code bases?
  - chimeracoder 11y ago
    > What more could Google Legal possibly want here beyond a full copyright assignment? What possible risk is there merging two 3-clause BSD code bases? The two BSD headers aren't literally the same (one credits "The Go Authors" and the other credits Intel Corporation). Put another way, the licenses share the same type, but the value of the "licenser" field differs. Adding more licenses to the same codebase makes it really messy for people to use, because it means they have to actually check which parts of the codebase they're citing in order to know which headers to include in their code. This last part is similar to the reason that the 4-clause BSD license is considered problematic, for what it's worth[0]. In this case, it's a practical issue, not a strictly legal one. [0] https://www.gnu.org/philosophy/bsd.en.html https://www.gnu.org/philosophy/bsd.en.html
    - ajross 11y ago
      No, it really doesn't. People have been combining BSD and "other" stuff for decades. How many systems shipped with the TCP stack (or zlib, or libjpeg, or...) linked right into their binaries? How many of them ran into "really messy to use" license problems? They just shipped it. The license says they can, and they did. This just seems extraordinarily meta to me. What is the actual risk here? Quantify "messy" and "be safe". (And FWIW: the fourth clause was considered bad because it put a restriction on how the software was distributed and communicated about. None of the licenses we're talking about in this thread include the advertising clause, or anything like it.)
parennoob 11y ago
It is not immediately obvious to me where Intel comes into this. The submission says it is the Cloudflare author's own work. Is it because the co-author of the mentioned paper (Shay Gueron) is from Intel? The commit doesn't explicitly say he also co-authored the code, though -- maybe that should be clearer.
- jacquesm 11y ago
  It is because the patch contained a line that reads // Copyright 2015 Intel Corporation Without further clarification.
- bcseeati 11y ago
  https://github.com/openssl/openssl/commit/4d3fa06fce52682bfbc503c7ded2d0289e3f8cde https://github.com/openssl/openssl/commit/4d3fa06fce52682bfb... https://rt.openssl.org/Ticket/Display.html?id=3149&user=guest&pass=guest https://rt.openssl.org/Ticket/Display.html?id=3149&user=gues... Looks like the patch is derived from OpenSSL and the OpenSSL part was developed by Shay Gueron and Vlad Krasnov.
jerf 11y ago
Perhaps someone needs to bypass Intel's lawyers and talk to some engineers or marketers, so they can circle back around and explain the situation to the lawyers; I see no way in which it is not advantageous to Intel to ensure the license is compatible, so they can sell more server chips with AES instructions to more people. It sort of sounds like the Intel lawyers are giving the default lawyer "no" rather than a considered answer. :)
rlguarino 11y ago
Non-mobile link: https://groups.google.com/forum/#!msg/golang-codereviews/m5QTnSUZU6c/Jc5yaMyF2_QJ https://groups.google.com/forum/#!msg/golang-codereviews/m5Q...

125 points by dawkins 11y ago

Not sure this needs to be on the top of HN. It's a licensing issue that I'm sure we can work out between CloudFlare, Google and Intel.

striking 11y ago
If it makes anyone feel any better, it's really between Google and Intel as the last post notes: >I'm afraid that, without Intel's permission, it doesn't appear that this change can move forward. What I don't get is this: >Intel do not wish to publish this code under the Go license and having bits of the Go repo under different licenses is sufficient unpleasant that counsel didn't want to entertain the idea. What makes the Go license different than the BSD under which Intel has published their code? HN is a place for things that make people think. This made me think, so I gave it an upvote.
- jgrahamc 11y ago
  I agree, but CloudFlare wants to do whatever we can to make sure this stuff gets into Go.
- DannyBee 11y ago
  "What makes the Go license different than the BSD under which Intel has published their code? " The go license is not different than the BSD license. Both the intel and the go stuff is bsd licensed. However, the BSD license requires you reproduce the copyright notices attached to it the top of the license. If you do not, you are in violation of the license (which in the US, is usually copyright infringement). By using "the go authors" as the copyright notice, go ensures you only ever have to reproduce one notice. If it says "copyright intel", now you have to reproduce A. The go notice when you use go without the stuff that is copyright intel B. The go notice and the intel notice when you use go and the stuff that is copyright intel. C. The intel notice when you use the intel stuff without anything else that is copyright go. Now, when 3 other companies decide they want their notices in there too (after all, if intel is special, why isn't broadcom, or whoever), and only add it to some files, imagine the fun that results for users. There are other issues, too, but succinctly, you don't want to live in this world. It leads to shipping things which reproduce 100's of pages of notices in documentation.
briansmith 11y ago
I'm glad y'all are working it out. The licensing for that stuff really is confusing, and discourages the use of that code. It's worse in OpenSSL because the x86 and ARM adaptations are licensed under the OpenSSL/Cryptograms licenses instead of BSD/Apache. Big chunks are labeled as transliterations of the X64 code, so I'd expect them to also be BSD/Apache licensed. Also, it isn't clear what Andy Polyakov's significant improvements of the the X64 code mean for the copyright, licensing, and re-licensing from Apache to dual BSD/Apache. In other words, it seems the copyright lines should, at a minimum, mention Andy's copyright, and it should be made clearer whether Andy agrees to dual license his contributions under the BSD/Apache dual license.
justonepost 11y ago
I disagree, it is relevant for HN: it's open source. I'm really curious as to why we can't just use it anywhere given the BSD license.
- jacquesm 11y ago
  That's why larger companies (and smart smaller ones) will ask their lawyers before accepting commits like these lest some SCO/Novell/Microsoft like demon jumps at them at some unspecified but presumably inconvenient time in the future. It's actually a really nice illustration of how hairy such stuff can be even with all the parties meaning well and as such it definitely is relevant for HN.
- hyperion2010 11y ago
  BSD header must stay on the code. Council doesn't want BSD headers in the GO code. Not clear there is actually any way forward unless someone can find a way to convince them that it is manageable to put BSD code into the repo. Another good reminder that cooking your own license is a bad idea.
  - chimeracoder 11y ago
    > Another good reminder that cooking your own license is a bad idea. I don't know what you're referring to here, since nobody has made their own license. The problem as I understand it is that (some of) the code in the patch is covered by a BSD license from Intel, which is not the same as the rest of the Go code, which is covered by a BSD license from the Go authors. The text of the BSD licenses themselves is mutually compatible, but because the licenses credit different sources ("Go authors" vs. "Intel Corporation"), that makes them different licenses. It is legally possible to combine them, but practically annoying for anyone else who may want to reuse the code later.
    - hyperion2010 11y ago
      Hrm. I think you're right. I had gone and looked at the GO license and was rather confused because it looked like the bsd 3 clause to me except for a change directly inserting Google's name into the 3rd clause. Could that be the source of the incompatibility?

bri3d 11y ago

I thought this was going to be some sort of crazy patent issue or something to do with Intel's proprietary compilers, but instead it's a simple license incompatibility where authors are trying to transfer code (that's been BSD/Apache dual-licensed in OpenSSL) into Go, which uses its own license.

hyperion2010 11y ago
Title should probably s/licensing/license because it is actually a license issue not a licensing issue.
teraflop 11y ago
More to the point, if I understand correctly: mixing these licenses is legally permissible for the Go team (or anyone else who wishes to apply to the patch) but the resulting codebase is no longer uniformly governed by Go's CLA. Intel doesn't want to relicense their code (which would AFAICT not meaningfully change the terms of the license, but would result in its authorship being lumped together with the rest of "The Go Authors" for licensing purposes) and the Go team's legal counsel apparently has some reason for being unwilling to accept the resulting mixed-license state.
- chimeracoder 11y ago
  > apparently has some reason for being unwilling to accept the resulting mixed-license state. As someone who writes a lot of Go, I can understand the reason for this. If I reuse a function from the standard library, I don't want to have to check which headers happen to pertain to that. I'd much rather know that all Go code is covered by the same license, and therefore the same header. For what it's worth, all Go code so far is under the same license[0]. Even the Go-specific parts of gccgo are under the same license as gc (though when distributed with gccgo, the combined package is distributed under the GPL). [0] http://golang.org http://golang.org lists these as the only exceptions to the BSD licensing for code and CC-BY licensing for non-code, which basically just means the obvious Google brand-specific stuff. https://developers.google.com/site-policies#restrictions https://developers.google.com/site-policies#restrictions
- 11y ago

eastdakota 11y ago

For the record: we (at CloudFlare) are happy to support any Go-compatible license for the code. Hopefully we can convince Intel to do the same.

ajross 11y ago
Can someone explain why the existing license (dual Apache and 3-clause BSD I believe?) is not Go-compatible? I mean, here's what I turned up for the "Go license", and it's almost verbatim 3-clause BSD: https://golang.org/LICENSE https://golang.org/LICENSE What more could Google Legal possibly want here beyond a full copyright assignment? What possible risk is there merging two 3-clause BSD code bases?
- chimeracoder 11y ago
  > What more could Google Legal possibly want here beyond a full copyright assignment? What possible risk is there merging two 3-clause BSD code bases? The two BSD headers aren't literally the same (one credits "The Go Authors" and the other credits Intel Corporation). Put another way, the licenses share the same type, but the value of the "licenser" field differs. Adding more licenses to the same codebase makes it really messy for people to use, because it means they have to actually check which parts of the codebase they're citing in order to know which headers to include in their code. This last part is similar to the reason that the 4-clause BSD license is considered problematic, for what it's worth[0]. In this case, it's a practical issue, not a strictly legal one. [0] https://www.gnu.org/philosophy/bsd.en.html https://www.gnu.org/philosophy/bsd.en.html
  - ajross 11y ago
    No, it really doesn't. People have been combining BSD and "other" stuff for decades. How many systems shipped with the TCP stack (or zlib, or libjpeg, or...) linked right into their binaries? How many of them ran into "really messy to use" license problems? They just shipped it. The license says they can, and they did. This just seems extraordinarily meta to me. What is the actual risk here? Quantify "messy" and "be safe". (And FWIW: the fourth clause was considered bad because it put a restriction on how the software was distributed and communicated about. None of the licenses we're talking about in this thread include the advertising clause, or anything like it.)

parennoob 11y ago

It is not immediately obvious to me where Intel comes into this. The submission says it is the Cloudflare author's own work. Is it because the co-author of the mentioned paper (Shay Gueron) is from Intel? The commit doesn't explicitly say he also co-authored the code, though -- maybe that should be clearer.

jacquesm 11y ago
It is because the patch contained a line that reads // Copyright 2015 Intel Corporation Without further clarification.
bcseeati 11y ago
https://github.com/openssl/openssl/commit/4d3fa06fce52682bfbc503c7ded2d0289e3f8cde https://github.com/openssl/openssl/commit/4d3fa06fce52682bfb... https://rt.openssl.org/Ticket/Display.html?id=3149&user=guest&pass=guest https://rt.openssl.org/Ticket/Display.html?id=3149&user=gues... Looks like the patch is derived from OpenSSL and the OpenSSL part was developed by Shay Gueron and Vlad Krasnov.

jerf 11y ago

Perhaps someone needs to bypass Intel's lawyers and talk to some engineers or marketers, so they can circle back around and explain the situation to the lawyers; I see no way in which it is not advantageous to Intel to ensure the license is compatible, so they can sell more server chips with AES instructions to more people. It sort of sounds like the Intel lawyers are giving the default lawyer "no" rather than a considered answer. :)

rlguarino 11y ago

Non-mobile link: https://groups.google.com/forum/#!msg/golang-codereviews/m5QTnSUZU6c/Jc5yaMyF2_QJ https://groups.google.com/forum/#!msg/golang-codereviews/m5Q...