* Florian Weimer: > The following quotes are from > <https://docs.fedoraproject.org/en-US/legal/license-field/>. > > | The License: field is meant to provide a simple enumeration of the > | licenses found in the source code that are reflected in the binary > | package. > > | Since Rust applications are statically linked and contain code from > | all their dependencies, the License: field for the subpackage > | containing the built binary must contain the individual licenses of > | all dependencies in accordance with these guidelines. > > To me, these paragraphs contradict each other. > > Do we need to perform effective license analysis based on static linking > or not? > > The current practice seems to be to ignore static linking in most cases, > otherwise most arch-ful would have to carry “GPL-3.0+ WITH > GCC-exception-3.1” due to the statically linked libgcc startup code. (That should probably be “GPL-3.0-or-later WITH GCC-exception-3.1”.) > Today, static linking analysis places a significant burden on package > maintainers because there is no proper automation. It's not merely > about direct dependencies (implicit or in BuildRequires:); with tools > like pkg-config, statically linked objects can come from indirect > dependencies. > > Thanks, > Florian _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
