6:55 p.m.
Hi all,
With the update to the regex-syntax crate package that I'm building
right now, the license will change from "MIT OR Apache-2.0" to "(MIT
OR Apache-2.0) AND Unicode-DFS-2016".
The project includes code that is derived from Unicode data files, and
it already shipped a license text for the Unicode-DFS-2016 license for
this reason - but the SPDX license string in upstream crate metadata
doesn't reflect this fact. It also appears that the inclusion of the
additional license file was made after the package was initially
reviewed for Fedora, and as a result, previous versions of this
package didn't include the Unicode license in its License tag.
I have also opened an upstream discussion about this, since I believe
that the upstream license specifier is wrong (i.e. missing " ... AND
Unicode-DFS-2016"), but upstream developers don't appear convinced
(even though similar changes were already made in equivalent cases for
other Rust projects):
https://github.com/rust-lang/regex/discussions/933
This change will probably have at least some "ripple effect" across
Rust packages in Fedora once they are rebuilt against this new
version, since basically everything depends on the "regex" crate
(which depends on regex-syntax), either directly, or indirectly.
I'm pretty sure that this package now has the the correct license tag
(i.e. project has two parts: first part is dual-licensed "MIT OR
Apache-2.0", second part is derived from Unicode data and is licensed
"Unicode-DFS-2016", so the license tag should reflect *both* parts),
but if I am wrong about this, please get my attention, so I can revert
this change in a timely manner.
Fabio
1:46 p.m.
On Tue, Dec 13, 2022 at 1:55 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
Hi all,
With the update to the regex-syntax crate package that I'm building
right now, the license will change from "MIT OR Apache-2.0" to "(MIT
OR Apache-2.0) AND Unicode-DFS-2016".
The project includes code that is derived from Unicode data files, and
it already shipped a license text for the Unicode-DFS-2016 license for
this reason - but the SPDX license string in upstream crate metadata
doesn't reflect this fact. It also appears that the inclusion of the
additional license file was made after the package was initially
reviewed for Fedora, and as a result, previous versions of this
package didn't include the Unicode license in its License tag.
I have also opened an upstream discussion about this, since I believe
that the upstream license specifier is wrong (i.e. missing " ... AND
Unicode-DFS-2016"), but upstream developers don't appear convinced
(even though similar changes were already made in equivalent cases for
other Rust projects):
https://github.com/rust-lang/regex/discussions/933
This change will probably have at least some "ripple effect" across
Rust packages in Fedora once they are rebuilt against this new
version, since basically everything depends on the "regex" crate
(which depends on regex-syntax), either directly, or indirectly.
I'm pretty sure that this package now has the the correct license tag
(i.e. project has two parts: first part is dual-licensed "MIT OR
Apache-2.0", second part is derived from Unicode data and is licensed
"Unicode-DFS-2016", so the license tag should reflect *both* parts),
but if I am wrong about this, please get my attention, so I can revert
this change in a timely manner.
Somebody asked the Rust Foundation to clarify the equivalent case as
it applies to the Rust compiler and standard library itself:
https://github.com/rust-lang/rust/issues/98116#issuecomment-1359471815
As far as I understand it, their legal counsel's conclusion is that
crates must include the license *text* for the Unicode license, but
not to include the SPDX license identifier for it in crate metadata.
To me, this seems like "cheating" - why include the license text, but
not include the license in metadata?
As far as I understand, it's also in contradiction with what Red Hat
legal asks Fedora packagers to do for our redistributables (RPM
packages vs. Rust libraries) - which is to list all applicable
licenses in the package metadata.
Applying two separate legal standards to Rust libraries in upstream
projects vs. Fedora packages would be extremely tedious, as we
generally rely on upstream license metadata (SPDX expression) to be
correct, and automatically use upstream SPDX license expressions
verbatim for RPM packages' License tags in Fedora (unless the upstream
license metadata is believed to be "wrong", in which case manual
intervention is required).
Fabio
9:45 p.m.
New subject: rust-regex-syntax package license change: added Unicode-DFS-2016 license
On Tue, Dec 20, 2022 at 2:47 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Tue, Dec 13, 2022 at 1:55 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
>
> Hi all,
>
> With the update to the regex-syntax crate package that I'm building
> right now, the license will change from "MIT OR Apache-2.0" to "(MIT
> OR Apache-2.0) AND Unicode-DFS-2016".
>
> The project includes code that is derived from Unicode data files, and
> it already shipped a license text for the Unicode-DFS-2016 license for
> this reason - but the SPDX license string in upstream crate metadata
> doesn't reflect this fact. It also appears that the inclusion of the
> additional license file was made after the package was initially
> reviewed for Fedora, and as a result, previous versions of this
> package didn't include the Unicode license in its License tag.
>
> I have also opened an upstream discussion about this, since I believe
> that the upstream license specifier is wrong (i.e. missing " ... AND
> Unicode-DFS-2016"), but upstream developers don't appear convinced
> (even though similar changes were already made in equivalent cases for
> other Rust projects):
> https://github.com/rust-lang/regex/discussions/933
>
> This change will probably have at least some "ripple effect" across
> Rust packages in Fedora once they are rebuilt against this new
> version, since basically everything depends on the "regex" crate
> (which depends on regex-syntax), either directly, or indirectly.
>
> I'm pretty sure that this package now has the the correct license tag
> (i.e. project has two parts: first part is dual-licensed "MIT OR
> Apache-2.0", second part is derived from Unicode data and is licensed
> "Unicode-DFS-2016", so the license tag should reflect *both* parts),
> but if I am wrong about this, please get my attention, so I can revert
> this change in a timely manner.
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. :)
Somebody asked the Rust Foundation to clarify the equivalent case as
it applies to the Rust compiler and standard library itself:
https://github.com/rust-lang/rust/issues/98116#issuecomment-1359471815
As far as I understand it, their legal counsel's conclusion is that
crates must include the license *text* for the Unicode license, but
not to include the SPDX license identifier for it in crate metadata.
To me, this seems like "cheating" - why include the license text, but
not include the license in metadata?
I mean, the Rust Foundation counsel isn't wrong. This "hide some of
the licenses" tendency in FOSS is a pretty deeply rooted cultural
practice. There's a form of it in Fedora, which we're trying to move
beyond.
As far as I understand, it's also in contradiction with what Red
Hat
legal asks Fedora packagers to do for our redistributables (RPM
packages vs. Rust libraries) - which is to list all applicable
licenses in the package metadata.
They are definitely different standards for license metadata, but the
standards are non-uniform across all the various project, packaging
and distribution communities.
Applying two separate legal standards to Rust libraries in upstream
projects vs. Fedora packages would be extremely tedious, as we
generally rely on upstream license metadata (SPDX expression) to be
correct, and automatically use upstream SPDX license expressions
verbatim for RPM packages' License tags in Fedora (unless the upstream
license metadata is believed to be "wrong", in which case manual
intervention is required).
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.
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.
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.
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.
Richard
12:42 p.m.
New subject: rust-regex-syntax package license change: added Unicode-DFS-2016 license
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
1:11 p.m.
New subject: rust-regex-syntax package license change: added Unicode-DFS-2016 license
On Wed, Jan 4, 2023 at 1:43 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
> 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.
Ah, now I understand!
Richard
471
days inactive
493
days old
4 comments
2 participants
participants (2)
-
Fabio Valentini -
Richard Fontana