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.
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.
> 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).
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.
The CLA is not a term of the license; it's a term of Google's stewardship of the code. If you fork Go and keep the BSD license, you can do as you like. Many projects of many varying license types use CLAs. The Linux kernel deliberately uses the fact it doesn't have one to ensure that nobody could ever un-GPL2 it because there's no possibility that you could ever reach every contributor for a license change.
> 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.
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.)
"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.
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?
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.
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)
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.
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. :)
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.
"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.
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.
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.
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.
> 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.
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?
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.
It's not that the subject is irrelevant (it is), it's just that the issue is trivial and will be resolved by the parties involved; right now the title gives the false impression that this was a very final thing.
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.
