4 ms·

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.)
    - chimeracoder 11y ago
      > Quantify "messy" 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.
    - DannyBee 11y ago
      "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 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.)
  - chimeracoder 11y ago
    > Quantify "messy" 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.
  - DannyBee 11y ago
    "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.