On Mon, Jul 11, 2022 at 10:08 AM Maxwell G <gotmax(a)e.email> wrote:
Jul 10, 2022 9:39:36 PM Richard Fontana <rfontana(a)redhat.com>:
> If I understand
> correctly (I have passing familiarity with Go and close to zero
> understanding of how Go projects are built and packaged for Fedora)
> the yq rpm would contain a binary that is statically linked against
> golang-github-timtadh-data-structures, but the source package of the
> yq rpm will not itself contain the source code of
> golang-github-timtadh-data-structures (i.e. it won't be "vendored"
> [bleh]), which however will be separately packaged in Fedora. Is that
> accurate or am I misunderstanding?
Yes, that is correct. There are some go packages in Fedora that use bundled dependencies,
but the package in question is not one of them.
> Surely this sort of question has
> come up before for Fedora Go packages... or has it?
In general, I think packagers could use more guidance/documentation about this issue, but
here is the current situation:
I believe similar issues have been discussed on this ML, but more so related to rust.
(Rust binaries are also statically linked and built against unbundled dependencies in
Fedora.) The Rust Packaging Guidelines require that rust binaries' License tags
account for the licenses of their respective dependencies. AFAIK, rust packages that
contain binaries don't include the license *files* for their dependencies, though.
: The "dependencies" (rust crates) are only required at buildtime, again,
due to static linkage.
Most, if not all, unbundled go packages only account for the license of the code
contained in that SRPM.
I see. So in the Rust case I assume it is not too burdensome to figure
out the license tag by taking into account separately-packaged
dependencies (if I remember correctly there is a tool that does this).
I imagine it wouldn't be any more difficult for Golang packages? If
that's so, then it probably makes sense for Go packages to follow the
same approach as Rust packages.
I'm not too concerned about the license file issue at the moment but
that's partly because we're intentionally putting it off until we deal
with the license tag issue. Ultimately, if the Go and Rust cases are
very similar, they should be using similar rules for the license file
There's a separate but related important issue here which has to do
with the GPL concept of complete corresponding source code, and
Fedora's approach to license compliance regardless of applicable FOSS
license, but I have to think about that some more.