On Tue, Jul 12, 2022, 05:40 Richard Fontana <[email protected]> wrote:
> On Mon, Jul 11, 2022 at 10:08 AM Maxwell G <[email protected]> wrote: > > > > > > Jul 10, 2022 9:39:36 PM Richard Fontana <[email protected]>: > > > > > 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > 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é > >
_______________________________________________ legal mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
