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