Thanks for your response! On Wed, Jan 4, 2023 at 4:46 AM Richard Fontana <rfontana@xxxxxxxxxx> 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 _______________________________________________ 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
