* Richard Fontana:
I assume we *wouldn't* want the vast majority of such packages
include `AND GPL-3.0-or-later WITH GCC-exception-3.1` . . . or would
We'd need to include a different specifier (TBD) for the glibc startup
code, which is also statically linked.
In the revamped documentation we were mostly trying to carry over
and restate (with some rationalization) the principles under the
Callaway system, and clearly in that system most packages did not
account for libgcc code by adding `and GPLv3+ with exceptions`. I
thought this was also true of the Rust and Go cases, that we were
restating a Callaway principle rather than creating some new rule. I
remember when we were formulating the new documentation there were
some comments here from Fedora Rust and Go packagers but IIRC no one
seemed to object to the basic expectation that you represent all
statically linked Rust/Go libraries in the License: field beyond some
concerns about the adequacy of tools to facilitate this.
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
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.
Maybe the libgcc case can be distinguished because (1) it covers I
guess nearly all non-noarch packages, not just packages associated
with a particular language like Rust or Go,
Right, as such it adds very little information.
and (2) the license in question is actually saying 'in this
you have no obligations' (whereas for an arbitrary case of the license
of a statically linked Rust or Go component that wouldn't be the
I'm worried about (2). Are we certain the the exception applies to
Ocaml and other compilers we ship? To me, this is very uncertain
territory and it is clearly effective licensing analysis.