
Crypto optimizations for Go from CloudFlare/Intel blocked by licensing issues - dawkins
https://groups.google.com/forum/m/#!msg/golang-codereviews/m5QTnSUZU6c/Jc5yaMyF2_QJ
======
bri3d
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.

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

~~~
mordocai
One of the reasons the GO legal council insists on all code being under the
CLA is that if google ever wants to change the license of the go codebase they
can do it without asking the contributors. If any code is not under the CLA,
changing the license becomes complicated.

~~~
DannyBee
As "the legal council in question", this is actually not the problem at all :)

There are actually remarkably simpler problem than this:

For starters,

Everyone in the world, using go, would now have to reproduce _two_ copyright
notices, instead of one.

If they messed up, intel could sue them :)

Exporting that liability to the rest of the world would be irresponsible.

In any case, it's not just about mixed licenses. In a good open source
project, everyone contributes on the same terms. Period.

~~~
mordocai
You are unlikely to read this at this point, but I was going through my old
comments and just saw your reply.

In any case, I was commenting on the purpose of the CLA in general. I believe
my comment still applies accurately to that.

As far as the specific issue goes, I agree that everyone should be
contributing under the same license.

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

~~~
DannyBee
"No, it really doesn't. People have been combining BSD and "other" stuff for
decades. "

hopefully, with proper notices :)

"This just seems extraordinarily meta to me. What is the actual risk here?
Quantify "messy" and "be safe". " Okay.

The risk is: If you don't reproduce the copyright notice, and Intel doesn't
like you, they could come after you for copyright infringement.

Just because you don't hear about it on reddit or hacker news doesn't mean
people don't have private enforcement actions over this stuff.

Shocking, I know.

Now, don't get me wrong, Intel is a wonderful company and I love them, but
exporting that kind of possible liability onto the rest of the world would be
pretty irresponsible, regardless of how nice a company Intel is.

Past that, the other part is "everyone should be contributing on the same
terms to an open source project".

Otherwise, you'll soon have a million copyright different notices to
reproduce.

~~~
ajross
So... how is it conceivably "safe" to use Go in my own work, which is provided
to me with the same (literally verbatim!) polluting copyright requirement. I
love Google, but like you said, all it takes is for me to forget the copyright
attribution and you guys are going to sue me into jelly.

Where am I missing the logic here? Or are you offering symmetric contributor
agreements to everyone that asks?

~~~
DannyBee
So, for starters, let me point out that Google's CLA (which would require for
contributions like this) grants rights from contributors directly to you. So
if Intel signed the CLA and contributed this code, even if you forgot the
notice, they would have no recourse.

([https://cla.developers.google.com/about/google-
corporate](https://cla.developers.google.com/about/google-corporate), clause
2)

This leaves "Google itself". In that case, the problem you raise is one true
of _all_ BSD licensed stuff, not just Go.

So yeah, you should be careful with notices, no matter who they are from,
google or anyone. You are trusting that if you mess up, you won't get screwed
by those people. It seems highly unlikely google would ever sue anyone, but
like i said, you are trusting it won't happen if you screw up. (I try to be
straight with people about stuff like this).

Your only solution to this in toto would be "don't use BSD licensed software"
in your works.

Note that this is true of plenty of other open sourvce licenses as well (IE if
you screw up GPL compliance minorly, you are trusting the copyright author
won't sue you). One of the only ones that doesn't require attribution for
binaries is the zlib license. Statutory damages for intentional copyright
infringement are quite high, and they don't actually even have to prove they
lost profits or whatever.

As for Go, one of the _other_ reasons we don't want to accept other-licensed
code and code not under a CLA is so we can fix this problem by changing the
runtime library license to not require attribution (but this will take a bit
longer for various reasons) :).

(There are certain other languages that know they have this problem with the
runtime license, but have decided they don't care if they are likely to make
accidental/intentional copyright infringers of large classes of people. I will
leave it to the crowd to figure out which these are :P)

------
jerf
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. :)

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

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

~~~
hyperion2010
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
> 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
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?

~~~
sangnoir
I am not a lawyer, forgive any inaccuracies. These are 2 instances of the
same/similar license type - they remain 2 different licenses with different
conditions that have to be met individually even if the code is merged.

The licenses are compatible. However, for the Go team (and downstream lib
users) to satisfy Intel's license, they'd have to credit Intel as authors, in
addition to "the Go Team". This can become unwieldy if code is pulled from
many different sources (code authors would need to check the authors of the
various parts of the Go Standard libs they are using to give the correct
attribution).

This can be avoided if Intel itself makes the contribution & make use of a CLA
(Contributor License Agreement) that assigns the necessary rights to the Go
Team - meaning there is one license to be satisfied for the whole standard
lib.

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

~~~
bcseeati
[https://github.com/openssl/openssl/commit/4d3fa06fce52682bfb...](https://github.com/openssl/openssl/commit/4d3fa06fce52682bfbc503c7ded2d0289e3f8cde)

[https://rt.openssl.org/Ticket/Display.html?id=3149&user=gues...](https://rt.openssl.org/Ticket/Display.html?id=3149&user=guest&pass=guest)

Looks like the patch is derived from OpenSSL and the OpenSSL part was
developed by Shay Gueron and Vlad Krasnov.

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

