On Mon, May 23, 2022 at 4:29 PM Richard Fontana <rfontana(a)redhat.com> wrote:
On Mon, May 23, 2022 at 3:58 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> > I'm also wondering where the "required to document source licensing
> > 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.
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,
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. Outside of that, only crazy packages like Chromium wind up
having complex licensing. The rest are reasonably simple.
But if people think we should find ways of making license
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
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!