* Björn Persson:
Florian Weimer wrote:
> I could be persuaded by an argument along these lines: The Rust and Go
> cases are different because for its Rust and Go dependencies, there
> would not be a trace in the installed system of the licenses of those
> source-only dependencies.
That can also be the case with static libraries in other languages, and
so-called header-only libraries in C++. I always found it strange that
the license field policy singles out Rust, as I don't see how static
Rust libraries are legally different from other static libraries.
Right.
In cases where a library (in C or whatever) is packaged in both
shared
and static forms, installing a statically linked program won't pull in
any library package. The shared library package with the license may or
may not be present depending on what else is installed.
Yes, but that doesn't apply to the three libraries I listed.
> The situation with glibc, libgcc and libstdc++ is different
because they
> are also installed separately, so their license information is always
> part of the installation.
Because the statically linked code is only a part of the library, and
the rest of the library is dynamically linked and thus pulled in as a
package with a license field? It seems to me that that argument would
also apply to inlined subroutines, generics, templates and similar code
snippets that get compiled into the using program. I believe many shared
libraries have such inlined snippets, and my impression is that they're
usually not reflected in the license field of programs that use the
library.
Yes, that would be effective licensing analysis, and it would need
toolchain support for correctness and efficiency.
Thanks,
Florian