On Tue, Jul 12, 2022, 05:40 Richard Fontana <rfontana@redhat.com> wrote:
On Mon, Jul 11, 2022 at 10:08 AM Maxwell G <gotmax@e.email> wrote:
>
>
> Jul 10, 2022 9:39:36 PM Richard Fontana <rfontana@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[1], though.
>
> [1]: 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
issue.

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.

Richard
_______________________________________________
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


There is no tool/automation for it. There is no website with a proper API to query the licences (though it has been asked). One binary package can pull up 600 Go libraries due to cascading chain of dependencies. 

Best regards, 

Robert-André