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.