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@xxxxxxxxxx>: > > > 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure