Thanks for your response!
On Wed, Jan 4, 2023 at 4:46 AM Richard Fontana <rfontana(a)redhat.com> wrote:
The only reason why you might be "wrong" is if it should be concluded
that the Unicode license doesn't really apply to *anything* here. I'm
reluctant to reach that conclusion in this case, but I feel it ought
to be mentioned. This is ultimately Unicode's fault for attempting to
impose its view of intellectual property on the rest of the world. :)
That was my impression as well, but I don't feel qualified to say
whether it matters or not.
The only thing I *do* know is that the library ships code derived from
Unicode data, which is clearly covered by Unicode-DFS-2016, and this
code is enabled in the default configuration.
(snip)
I have some thoughts relating to this because I've recently been
looking at the licensing and license metadata of a large number of
Rust crates (for something having nothing to do with Fedora or
Fedora-derived packages). In general, FOSS license metadata is not
great quality, in my opinion. Again, there's a culture of "hide some
of the licenses" for (and this is what's most annoying) generally
non-well-articulated reasons, but also there's been a tradition of
using license symbols to have highly imprecise meanings. That is
partly what has motivated these recent changes in Fedora: we are
trying to do something to improve the situation. I think my attitude
used to be that this was an unimportant problem because license
metadata was unimportant, but I don't think that is tenable anymore.
In the *Rust* case, things are typically not so bad, because these
Rust projects are typically so small and simple and are fairly young
(my non-technical impression), and there also is apparently a sort of
license monoculture that dominates Rust project development (e.g. I
found one GPL crate out of about 200 or so in what I was looking at).
So they don't have the complexity (both structurally and license-wise)
seen in some of the relatively old Fedora packages, particularly of
projects written in C and so forth.
True. I hope things don't get more complicated over time, because they
are already painful to deal with in some cases ...
I looked at your package, and what surprised me is that you patched
the Cargo.toml file to "correct" the upstream license metadata, given
that the upstream project has rejected the change.
The downstream patch to the crate metadata is only there because we
use crate metadata to automatically collect licenses of dependencies
for statically linked binaries.
I.e. the crate metadata should reflect the license of the Fedora
package, otherwise the method to collect licenses of dependencies
would be wrong.
I guess partly why I have made those remarks on Rust is that while I
see how it is tedious to deal with two different standards of license
metadata, it really isn't *that* bad in the Rust case (most of the
time). If the tediousness is because you can't just take the upstream
metadata, assume it must be correct, and just automate the populating
of the RPM metadata ... well, think about what the Fedora package
maintainers of things like krb5 or Webkit2GTK will have to deal with.
Even in the Rust case, assuming the upstream metadata is accurate
seems unjustified, given the standard of accuracy Fedora is striving
for. It's more like, you can reasonably assume it's accurate enough in
most cases that you don't have to examine things too deeply or
critically, and you can certainly rely on the upstream metadata as a
good starting point.
True. It's just in this case that it was fairly obvious that something
is "weird", because there are files for all three license texts (MIT
and Apache-2.0 and Unicode-DFS-2016) in the library sources, but only
two of them are reflected in the crate metadata.
I guess there is also an argument that it is inefficient to carry
downstream license metadata patches that result from the existence of
different license metadata systems. This argument seems like it can
only make sense if it looks like the two systems are both based on the
same symbolic system, which is arguably true for Rust and Fedora since
both communities are attempting to use SPDX identifiers. I'm
sympathetic to this, but it is essentially saying "if Rust projects
hide some of the licenses, Fedora should do so too". Which doesn't
feel quite right to me.
Right ... I don't think "let's just sweep this under the rug" is a
good strategy here ... which is why I decided to use the "correct"
license for the Fedora package.
Fabio