On Fri, Jul 14, 2023 at 7:05 AM Florian Weimer <fweimer@xxxxxxxxxx> 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/LicenseRef-Not-Copyrightable.txt). 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 _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-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/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
