Crypto optimizations for Go from CloudFlare/Intel blocked by licensing issues
groups.google.com
groups.google.com
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.
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 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
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.
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.
Citation? The license listed on their website at http://golang.org/LICENSE is is the 3-Clause BSD license (see: http://opensource.org/licenses/BSD-3-Clause) with the one exception that "THE COPYRIGHT HOLDER" was changed to "THE COPYRIGHT OWNER" in the final paragraph.
Additionally, on that page there is a requirement for a standard copyright header, specifying "The Go Authors" as the copyright holders.
I mean, here's what I turned up for the "Go license", and it's almost verbatim 3-clause BSD:
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.
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.)
Having to add multiple headers in my code that reuses crypto.go specifically, rather than using the same header that I use when reusing every other piece of code in the Go standard library.
> People have been combining BSD and "other" stuff for decades.
Yes, though not without practical implications, as described in the link I posted in my previous comment.
> They just shipped it. The license says they can, and they did.
They license says they can as long as they follow the terms of the license. If they do not include the correct header in all derivatives, they are no longer complying with the terms of the license.
I am willing to bet that the vast majority of projects out there that use BSD-licensed code do not actually comply with the terms of the BSD license. They're usually small and the licensors don't notice (or care), so they get away with it. But that doesn't make it right for the licensees to do so, either ethically or legally, and they could easily find themselves in legal hot water if the original licensors wanted to make their lives difficult[0].
> (And FWIW: the fourth clause was considered bad because it put a restriction on how the software was distributed and communicated about.
It was also considered bad because it was complicated to comply with in practice. From the page I linked in my previous comment:
> When people put many such programs together in an operating system, the result is a serious problem. Imagine if a software system required 75 different sentences, each one naming a different author or group of authors.
[0] And in this case, the "original licensor" in question would be Intel. If Intel wants to make your life difficult, they can make your life difficult.
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.
Where am I missing the logic here? Or are you offering symmetric contributor agreements to everyone that asks?
(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)
>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.
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.
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.
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.
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.
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.
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.
// Copyright 2015 Intel Corporation
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.