On Mon, May 23, 2022 at 4:29 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > > On Mon, May 23, 2022 at 3:58 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > > I'm also wondering where the "required to document source licensing for > > > bundled stuff" is documented? Can you point to that? > > > > > > > It was something we were told to do years ago for Rust/Go stuff. I'm > > not sure I can find a specific reference for it. I have mentioned it > > before though[1]. > > > > [1]: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx/thread/POAC4FDCIPU3W24DGY2LCDTDC7WYBNPN/ > > Leaving aside the specifics of the bundling/Rust cases, one of the > questions here is whether we want to have License: fields that state > something relatively complex like > > License: ASL 2.0 and (ASL 2.0 or Boost) and (ASL 2.0 or MIT) and ISC > and MIT and ((MIT or ASL 2.0) and BSD) and (Unlicense or MIT) > or its equivalent in SPDX which if anything might seem slightly more > complex depending on the details. > > The assumption I've been making is that we basically can't avoid > having complex license expressions in the general case, and that is > (for me) a major justification for switching from Callaway to SPDX, > since SPDX is a somewhat richer and more coherent expression language > for complex licensing details. > That might be the case in the container circus, but in the RPM world, we mostly get to avoid complex licensing details. The weirdest license expression is the one for perl-Exporter-Tidy[1], which requires us to evaluate the entire list of acceptable licenses and export them to the License tag since the license terms state as such[2]. Outside of that, only crazy packages like Chromium wind up having complex licensing. The rest are reasonably simple. [1]: https://src.fedoraproject.org/rpms/perl-Exporter-Tidy [2]: https://metacpan.org/pod/Exporter::Tidy#LICENSE > But if people think we should find ways of making license expressions > simpler, that doesn't mean not using SPDX or something that seems > syntactically/symbolically identical to SPDX for the representation of > the resulting simplified expressions. > > I think this also goes to how "licenses of the contents of the binary > RPM" is ambiguous. It might mean, for example: > * Every identifiable license in a source file that is included (in > compiled form or otherwise) in the binary RPM -- I think we see some > packages that attempt this > * A simplified representation of those licenses based on application > of common / seemingly noncontroversial FOSS (often > GPL-community-specific) folkloric legal conventions. Two examples: > 1) an executable program built from GPLv2+ and MIT licensed source > files gets represented simply as "GPLv2+" (GPL-2.0-or-later in SPDX) > 2) an executable program built from GPLv2+ source files but which > dynamically links against a GPLv3+ separately-packaged library (also > distributed in Fedora) gets represented as "GPLv3+" > I think there are many examples of 1) and I know of one example of 2), > but I think neither of those kinds of cases are handled consistently > across Fedora packages today (not saying that we need absolute > consistency) > > Are simpler or more complex license expressions preferable, even if > simpler expressions mean some loss of useful information or accuracy? > That's one issue that is connected to Jilayne's question. > The point of the License tag in Fedora is to provide good guidance on leveraging the software. If you want total accuracy, then you need per-file license metadata. That's even *more* prone to errors, and isn't even useful in most cases. I would prefer simpler, understandable expressions than crazy accurate ones. For example, if we changed to per-file accuracy, we'd need to start documenting all the autotools bundled licensing, which we've never done. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
