$ find -name '*LICENSE*' -exec ninka {} ';' ./go-protobuf-1.2.0/src/github.com/golang/protobuf/vendor/golang.org/x/sync/LICENSE;spdxBSD3;1;6;1;1;0;Copyright,-1,6 ./go-protobuf-1.2.0/src/github.com/golang/protobuf/vendor/golang.org/x/net/LICENSE;spdxBSD3;1;6;1;1;0;Copyright,-1,6 ./go-protobuf-1.2.0/src/github.com/golang/protobuf/vendor/google.golang.org/genproto/LICENSE;Apache-2;1;5;0;1;42;UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,UNKNOWN,Copyright,5 ./go-protobuf-1.2.0/src/github.com/golang/protobuf/LICENSE;spdxBSD3;1;6;1;1;0;Copyright,-1,6 Apache-2.0 is missing from LICENSE.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1566d697bc10e27212734d6c430a1f00d0cc5465 commit 1566d697bc10e27212734d6c430a1f00d0cc5465 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-09-14 22:01:59 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-09-14 22:02:46 +0000 package.mask: Last rite dev-go/go-protobuf Bug: https://bugs.gentoo.org/694392 Signed-off-by: Zac Medico <zmedico@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
I'm not precisely sure what the output of `ninka` signifies, but this tool does have a LICENSE file, and appears to be a standard BSD 3-clause. This tool is critical in the process of generating Go code from protobufs, and it would be a shame to see it go, seeing as this seems to be a false-positive.
(In reply to RB from comment #2) > I'm not precisely sure what the output of `ninka` signifies, but this tool > does have a LICENSE file, and appears to be a standard BSD 3-clause. See the Apache-2.0 license in the vendored google.golang.org/genproto package. The issue can be easily resolved by adding Apache-2.0 to the ebuild LICENSE variable. > This tool is critical in the process of generating Go code from protobufs, > and it would be a shame to see it go Is there a good reason to install this package on the system rather than have go projects include it via go.mod? For example, etcd includes it via go.mod: https://github.com/etcd-io/etcd/blob/master/go.mod
(In reply to Zac Medico from comment #3) > Is there a good reason to install this package on the system rather than > have go projects include it via go.mod? For example, etcd includes it via > go.mod: That's a fairly unique use, IME. Developers and CI toolchains use it to generate Go code from protobuf definitions, whether on the fly or statically. See the sibling dev-java/protobuf-java and dev-python/protobuf-python packages. All of these are used by the "protoc" tool from dev-libs/protobuf-c to produce the relevant language-specific interfaces. This isn't the only way to get the application on the machine, but having it managed (rather than using the pip-like `go install`) is useful.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34d82750f764e059c104ff51b8443878f3206ba0 commit 34d82750f764e059c104ff51b8443878f3206ba0 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-10-03 00:53:38 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-10-03 00:55:37 +0000 dev-go/go-protobuf: Remove old version with incomplete LICENSE Closes: https://bugs.gentoo.org/694392 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: Zac Medico <zmedico@gentoo.org> dev-go/go-protobuf/Manifest | 4 --- dev-go/go-protobuf/go-protobuf-1.2.0.ebuild | 51 ----------------------------- profiles/package.mask | 5 --- 3 files changed, 60 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9eca4c85ecc3ccfbb925fcfb39e09d0e059d42ec commit 9eca4c85ecc3ccfbb925fcfb39e09d0e059d42ec Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-10-03 00:50:04 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-10-03 00:55:37 +0000 dev-go/go-protobuf: Bump to version 1.3.2 LICENSE omits licenses for EGO_VENDOR packages, since those are only test dependencies which are not used at runtime. Bug: https://bugs.gentoo.org/694392 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: Zac Medico <zmedico@gentoo.org> dev-go/go-protobuf/Manifest | 6 ++++ dev-go/go-protobuf/go-protobuf-1.3.2.ebuild | 47 +++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+)
(In reply to RB from comment #4) > (In reply to Zac Medico from comment #3) > > Is there a good reason to install this package on the system rather than > > have go projects include it via go.mod? For example, etcd includes it via > > go.mod: > > That's a fairly unique use, IME. Developers and CI toolchains use it to > generate Go code from protobuf definitions, whether on the fly or > statically. See the sibling dev-java/protobuf-java and > dev-python/protobuf-python packages. All of these are used by the "protoc" > tool from dev-libs/protobuf-c to produce the relevant language-specific > interfaces. > > This isn't the only way to get the application on the machine, but having it > managed (rather than using the pip-like `go install`) is useful. Thanks for the explanation. I've removed the old ebuild with incomplete LICENSE and added version 1.3.2 which has a pure BSD license (EGO_VENDOR dependencies are needed only for unit tests).
