On 5/27/23 08:33, Fabio Valentini wrote:
This doesn't explicitly mention statically linked binaries / header-only libraries, but it's clear that this rule applies to these situations as well (after all, binaries *are* built from project sources that have distinct licenses). I don't see how C/C++ header-only libraries (or Go packages, fwiw) should be treated differently than Rust crates.
I agree that C/C++ header-only libraries are effectively the same case as Rust crates. I do think it is fair to point out that the distinction between "header” and “source” files in C and C++ is mostly cultural rather than technical, and that header-only libraries represent a somewhat arbitrary line in the sand when it comes to considering the licenses of headers. I’m not complaining about that arbitrariness; it’s probably necessary.
I doubt that anyone expects it would be practical, or useful to end-users, to consider every header used in the build in the license expression, yet header-only libraries are not technically a special case. The headers of C++ and even C shared-library packages may contain just as much template or inline code as header-only libraries. Just look at the standard library implementations of both languages for an example. This code is compiled into the caller just as a header-only library would be, but it’s my understanding that we don’t consider it in the license expression as long as the dependency also has a dynamically-linked portion.
Asking packagers to manually track licenses of all included headers (which may change without any change to the package’s spec file or sources) seems like it would be ridiculously burdensome; so does asking them to assess some kind of measure of “triviality.” We are left with considering only header-only libraries (and static libraries, which are discouraged but occasionally necessary), not because this exactly reflects the objective truth, but because it seems to be the last plausibly reasonable step before a descent into madness.
I am not sure that it is possible for Fedora’s policy in this area to be both practically usable and perfectly logically consistent. It would certainly be useful to document it a little more clearly.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
