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.
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
* 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
On Fri, Jul 14, 2023 at 7:05 AM Florian Weimer fweimer@redhat.com wrote:
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.
I see what you mean. I think the assumption there was that "the source code" includes the source code of separately packaged statically linked dependencies as in the Rust and Go cases.
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's a good point which I believe no one has brought up before.
I assume we *wouldn't* want the vast majority of such packages to include `AND GPL-3.0-or-later WITH GCC-exception-3.1` . . . or would we? 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.
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, and (2) the license in question is actually saying 'in this scenario 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 case). It's perhaps a little like what I've been calling "true public domain" which was inconsistently represented as "Public Domain" under the Callaway system (along with the kinds of stuff we've been putting under `LicenseRef-Fedora-Public-Domain`) but we've basically been saying doesn't have to be represented in the License: field unless otherwise the License: field would be empty, although I think a case like that hasn't come up yet because we don't have an official Fedora identifier for "true public domain" (see my stab at what something like that could look like: https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/LICENSES/Lic...).
I've been concerned for some time that the "enumerate the licenses of the binary" rule is problematic, but no one has directly complained about it or suggested an alternative.
One possibility that has occurred to me is that we shouldn't have the License: field use our umbrella custom-defined identifiers `LicenseRef-Fedora-Public-Domain` and `LicenseRef-Fedora-UltraPermissive`. But these both correspond closely to Callaway names `Public Domain` (as it was most commonly used) and `Freely redistributable without restriction`. The three strongest objections to that would be (1) but we've spent so much effort so far in gathering things into those categories and encouraging package maintainers to use them, (2) the expectation that they be represented encourages package maintainers not to overlook them (because the underlying licenses still need to be approved for use in Fedora and we don't have any system in place to encourage this procedurally other than through the License: field requirement), and (3) this would change how things were done under the Callaway system, which is not the goal. (1) is basically a form of sunk cost fallacy I guess.
Richard
* Richard Fontana:
I assume we *wouldn't* want the vast majority of such packages to include `AND GPL-3.0-or-later WITH GCC-exception-3.1` . . . or would we?
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 source-only dependencies.
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 scenario 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 case).
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.
Thanks, Florian
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.
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.
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.
Björn Persson
* 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
-
Björn Persson -
Florian Weimer -
Richard Fontana