On Wed, Jun 28, 2023 at 4:44 PM h-k-81@hotmail.com wrote:
I am in the process of reviewing this package [1]. The author of the pacakge mentions "A lot of the code in this package was based on Julien Schmidt's httprouter." in the documentation and includes the license file of httprouter. The thing is that httprouter is written in Go and the library, that is being packaged, is written in Rust.
So the question here is, does the Rust library have to include and mention the license of httprouter?
I think you may be asking one of more of the following questions:
1. Given that httprouter is written in Go, can we assume that the license of httprouter doesn't apply to this Rust crate?
2. Does the binary package need to install the httprouter license file?
3. Should the httprouter license be included in the spec file License: field?
As to 1: I don't think we can assume that, no. The upstream project says it's based on httprouter and it could be that some of it is a close translation from Go to Rust. While the BSD licenses are not entirely clear on this issue I think you should assume that the Rust crate copies from httprouter in such a way that the httprouter license requirements are triggered.
As to 2: We still don't have updated standards around how to deal with installation of license files and (in my opinion) the existing packaging guidelines on that topic don't entirely make sense. In this case I'd take a conservative approach and assume the httprouter license needs to be installed along with the rust-matchit project license.
As to 3, this follows from 1: you should assume the License: field should include `BSD-3-Clause` as appropriate.
Richard
On Wed, Jun 28, 2023 at 11:13 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 28, 2023 at 4:44 PM h-k-81@hotmail.com wrote:
I am in the process of reviewing this package [1]. The author of the pacakge mentions "A lot of the code in this package was based on Julien Schmidt's httprouter." in the documentation and includes the license file of httprouter. The thing is that httprouter is written in Go and the library, that is being packaged, is written in Rust.
So the question here is, does the Rust library have to include and mention the license of httprouter?
I think you may be asking one of more of the following questions:
- Given that httprouter is written in Go, can we assume that the
license of httprouter doesn't apply to this Rust crate?
Does the binary package need to install the httprouter license file?
Should the httprouter license be included in the spec file License: field?
As to 1: I don't think we can assume that, no. The upstream project says it's based on httprouter and it could be that some of it is a close translation from Go to Rust. While the BSD licenses are not entirely clear on this issue I think you should assume that the Rust crate copies from httprouter in such a way that the httprouter license requirements are triggered.
As to 2: We still don't have updated standards around how to deal with installation of license files and (in my opinion) the existing packaging guidelines on that topic don't entirely make sense. In this case I'd take a conservative approach and assume the httprouter license needs to be installed along with the rust-matchit project license.
As to 3, this follows from 1: you should assume the License: field should include `BSD-3-Clause` as appropriate.
Thanks for the explanations! (I submitted the package in question for review.)
I only have one remaining question:
The upstream project's metadata uses the SPDX expression "MIT" for the project's license, but includes both the license text for MIT (which covers the "matchit" project) and the one for BSD-3-Clause (which is the license of the "httprouter" project, which "matchit" is based on).
Following the logic from points 1 and 3, should the upstream project's metadata use "MIT AND BSD-3-Clause" for the project license? I assume similar reasons apply to the tarballs that the upstream project distributes as would to the RPM packages that Fedora distributes.
Should this discrepancy (i.e. license texts for both licenses included, but license in metadata does not) be reported / fixed in the upstream project as well?
Fabio
The upstream project's metadata uses the SPDX expression "MIT" for the project's license, but includes both the license text for MIT (which covers the "matchit" project) and the one for BSD-3-Clause (which is the license of the "httprouter" project, which "matchit" is based on).
Following the logic from points 1 and 3, should the upstream project's metadata use "MIT AND BSD-3-Clause" for the project license? I assume similar reasons apply to the tarballs that the upstream project distributes as would to the RPM packages that Fedora distributes.
Should this discrepancy (i.e. license texts for both licenses included, but license in metadata does not) be reported / fixed in the upstream project as well?
I checked crates.io and couldn't find any guidelines on license metadata. I don't think I personally would bother if I were the Fedora packager but I think you've previously explained that for Rust packages having the upstream metadata match the Fedora metadata would have some benefits on the Fedora side. So it may be worth a try. The upstream maintainer may be sympathetic to this given how they emphasize the httprouter license.
Richard
On Wed, Jun 28, 2023 at 6:18 PM Fabio Valentini decathorpe@gmail.com wrote:
On Wed, Jun 28, 2023 at 11:13 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 28, 2023 at 4:44 PM h-k-81@hotmail.com wrote:
I am in the process of reviewing this package [1]. The author of the pacakge mentions "A lot of the code in this package was based on Julien Schmidt's httprouter." in the documentation and includes the license file of httprouter. The thing is that httprouter is written in Go and the library, that is being packaged, is written in Rust.
So the question here is, does the Rust library have to include and mention the license of httprouter?
I think you may be asking one of more of the following questions:
- Given that httprouter is written in Go, can we assume that the
license of httprouter doesn't apply to this Rust crate?
Does the binary package need to install the httprouter license file?
Should the httprouter license be included in the spec file License: field?
As to 1: I don't think we can assume that, no. The upstream project says it's based on httprouter and it could be that some of it is a close translation from Go to Rust. While the BSD licenses are not entirely clear on this issue I think you should assume that the Rust crate copies from httprouter in such a way that the httprouter license requirements are triggered.
As to 2: We still don't have updated standards around how to deal with installation of license files and (in my opinion) the existing packaging guidelines on that topic don't entirely make sense. In this case I'd take a conservative approach and assume the httprouter license needs to be installed along with the rust-matchit project license.
As to 3, this follows from 1: you should assume the License: field should include `BSD-3-Clause` as appropriate.
Thanks for the explanations! (I submitted the package in question for review.)
I only have one remaining question:
The upstream project's metadata uses the SPDX expression "MIT" for the project's license, but includes both the license text for MIT (which covers the "matchit" project) and the one for BSD-3-Clause (which is the license of the "httprouter" project, which "matchit" is based on).
Following the logic from points 1 and 3, should the upstream project's metadata use "MIT AND BSD-3-Clause" for the project license? I assume similar reasons apply to the tarballs that the upstream project distributes as would to the RPM packages that Fedora distributes.
Should this discrepancy (i.e. license texts for both licenses included, but license in metadata does not) be reported / fixed in the upstream project as well?
Fabio
Dne 29. 06. 23 v 14:54 Richard Fontana napsal(a):
The upstream project's metadata uses the SPDX expression "MIT" for the project's license, but includes both the license text for MIT (which covers the "matchit" project) and the one for BSD-3-Clause (which is the license of the "httprouter" project, which "matchit" is based on).
Following the logic from points 1 and 3, should the upstream project's metadata use "MIT AND BSD-3-Clause" for the project license? I assume similar reasons apply to the tarballs that the upstream project distributes as would to the RPM packages that Fedora distributes. Should this discrepancy (i.e. license texts for both licenses included, but license in metadata does not) be reported / fixed in the upstream project as well?
I checked crates.io and couldn't find any guidelines on license metadata. I don't think I personally would bother
This is surprising position.
Why it should be based on crates.io guidelines? I think that most of us struggling with licenses. Fedora is struggling with licenses. I am quite sure crates.io is struggling with licenses.
So maybe the Fedora position should be at minimum to recommend to fix it upstream if the time was already spent on the analysis.
Vít
if I were the Fedora packager but I think you've previously explained that for Rust packages having the upstream metadata match the Fedora metadata would have some benefits on the Fedora side. So it may be worth a try. The upstream maintainer may be sympathetic to this given how they emphasize the httprouter license.
Richard
On Wed, Jun 28, 2023 at 6:18 PM Fabio Valentini decathorpe@gmail.com wrote:
On Wed, Jun 28, 2023 at 11:13 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jun 28, 2023 at 4:44 PM h-k-81@hotmail.com wrote:
I am in the process of reviewing this package [1]. The author of the pacakge mentions "A lot of the code in this package was based on Julien Schmidt's httprouter." in the documentation and includes the license file of httprouter. The thing is that httprouter is written in Go and the library, that is being packaged, is written in Rust.
So the question here is, does the Rust library have to include and mention the license of httprouter?
I think you may be asking one of more of the following questions:
- Given that httprouter is written in Go, can we assume that the
license of httprouter doesn't apply to this Rust crate?
Does the binary package need to install the httprouter license file?
Should the httprouter license be included in the spec file License: field?
As to 1: I don't think we can assume that, no. The upstream project says it's based on httprouter and it could be that some of it is a close translation from Go to Rust. While the BSD licenses are not entirely clear on this issue I think you should assume that the Rust crate copies from httprouter in such a way that the httprouter license requirements are triggered.
As to 2: We still don't have updated standards around how to deal with installation of license files and (in my opinion) the existing packaging guidelines on that topic don't entirely make sense. In this case I'd take a conservative approach and assume the httprouter license needs to be installed along with the rust-matchit project license.
As to 3, this follows from 1: you should assume the License: field should include `BSD-3-Clause` as appropriate.
Thanks for the explanations! (I submitted the package in question for review.)
I only have one remaining question:
The upstream project's metadata uses the SPDX expression "MIT" for the project's license, but includes both the license text for MIT (which covers the "matchit" project) and the one for BSD-3-Clause (which is the license of the "httprouter" project, which "matchit" is based on).
Following the logic from points 1 and 3, should the upstream project's metadata use "MIT AND BSD-3-Clause" for the project license? I assume similar reasons apply to the tarballs that the upstream project distributes as would to the RPM packages that Fedora distributes.
Should this discrepancy (i.e. license texts for both licenses included, but license in metadata does not) be reported / fixed in the upstream project as well?
Fabio
legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Jun 29, 2023 at 9:37 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 29. 06. 23 v 14:54 Richard Fontana napsal(a):
The upstream project's metadata uses the SPDX expression "MIT" for the project's license, but includes both the license text for MIT (which covers the "matchit" project) and the one for BSD-3-Clause (which is the license of the "httprouter" project, which "matchit" is based on).
Following the logic from points 1 and 3, should the upstream project's metadata use "MIT AND BSD-3-Clause" for the project license? I assume similar reasons apply to the tarballs that the upstream project distributes as would to the RPM packages that Fedora distributes. Should this discrepancy (i.e. license texts for both licenses included, but license in metadata does not) be reported / fixed in the upstream project as well?
I checked crates.io and couldn't find any guidelines on license metadata. I don't think I personally would bother
This is surprising position.
Why it should be based on crates.io guidelines? I think that most of us struggling with licenses. Fedora is struggling with licenses. I am quite sure crates.io is struggling with licenses.
So maybe the Fedora position should be at minimum to recommend to fix it upstream if the time was already spent on the analysis.
I think Jilayne might agree with this. My concern is that different packaging systems may (legitimately) have different standards for how to document licenses in metadata, even if superficially they use the same syntax (increasingly, SPDX). Fedora's current (and historical) standards at least in theory are based on this binary/source distinction, but that may not make sense for other systems. There's no universal standard for what package license metadata should signify. To a large extent I think the question is about what license information should/can be *ignored* despite it being detectable somehow in the source code of a package. SPDX could probably provide this but I don't think it wants to.
Richard
Dne 29. 06. 23 v 16:42 Richard Fontana napsal(a):
On Thu, Jun 29, 2023 at 9:37 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 29. 06. 23 v 14:54 Richard Fontana napsal(a):
The upstream project's metadata uses the SPDX expression "MIT" for the project's license, but includes both the license text for MIT (which covers the "matchit" project) and the one for BSD-3-Clause (which is the license of the "httprouter" project, which "matchit" is based on).
Following the logic from points 1 and 3, should the upstream project's metadata use "MIT AND BSD-3-Clause" for the project license? I assume similar reasons apply to the tarballs that the upstream project distributes as would to the RPM packages that Fedora distributes. Should this discrepancy (i.e. license texts for both licenses included, but license in metadata does not) be reported / fixed in the upstream project as well?
I checked crates.io and couldn't find any guidelines on license metadata. I don't think I personally would bother
This is surprising position.
Why it should be based on crates.io guidelines? I think that most of us struggling with licenses. Fedora is struggling with licenses. I am quite sure crates.io is struggling with licenses.
So maybe the Fedora position should be at minimum to recommend to fix it upstream if the time was already spent on the analysis.
I think Jilayne might agree with this. My concern is that different packaging systems may (legitimately) have different standards for how to document licenses in metadata, even if superficially they use the same syntax (increasingly, SPDX). Fedora's current (and historical) standards at least in theory are based on this binary/source distinction, but that may not make sense for other systems. There's no universal standard for what package license metadata should signify. To a large extent I think the question is about what license information should/can be *ignored* despite it being detectable somehow in the source code of a package. SPDX could probably provide this but I don't think it wants to.
I vaguely remember, that the Rust packaging automation was approved based on the condition, that there are SPDX licenses listed in metadata. I don't think and Cargo licensing guidelines were evaluated along the way. But if the was different standard for Cargo licenses in metadata, then in Fedora, Rust packaging automation should be disabled, because we cannot trust the license information.
Being member of Ruby community, I don't think there is any suggestion to what the tag in the metadata really means. It just happens there is the metadata, because it was requested. It is there by evolution not by design. I believe that Fedora (or SPDX / LF) lead in this area would be useful (BTW there is no difference to license information in general, based on our work, the upstreams are much more knowledgeable about licenses. I have already lost my count how many "missing license" discussion with upstream I had, but there are less such cases then used to be).
Vít
On Fri, Jun 30, 2023 at 11:22 AM Vít Ondruch vondruch@redhat.com wrote:
(snip)
I vaguely remember, that the Rust packaging automation was approved based on the condition, that there are SPDX licenses listed in metadata. I don't think and Cargo licensing guidelines were evaluated along the way. But if the was different standard for Cargo licenses in metadata, then in Fedora, Rust packaging automation should be disabled, because we cannot trust the license information.
I don't know what you're talking about here, but this might predate my time at the Rust SIG (or you do indeed vaguely mis-remember). ;)
The creation of spec files for Rust crates is automated to varying degrees with rust2rpm, and the tool pre-fills the License tag with metadata from the upstream project, just like it prefills Name, Summary, and %description. But that does not absolve the packager from checking that this information is actually correct. If this were not the case, this thread would not exist.
Fabio
-
Fabio Valentini -
Richard Fontana -
Vít Ondruch