Make license information machine readable

[Jake-Shadle]

Currently, ring's top level LICENSE file spells out the licensing terms, which is great, except it makes it hard for tools such as askalono to reliably gather licensing information due to it being a concatenation of several licenses, as well as inline text describing the licensing and why it is how it is.

As far as I can tell, if the license field in Cargo.toml was specified as ISC AND MIT AND OpenSSL then this would reflect the terms under which others can license ring, without changing the LICENSE file as it stands, and allow tools and automated processes to handle ring.

[Jake-Shadle]

Going to close this as no one else seems to care.

[briansmith]

I do care about this and I do want it to be done. However, there are a lot of layers to slog through and it will unfortunately be a bit of a non-transparent process until it is closer to being done.

[Jake-Shadle]

Glad to hear that! Sorry for my short close comment.

[gdesmott]

I'm suffering the same problem. On my dep is using ring which triggers cargo deny check license:

   ┌── ring 0.13.5 (registry+https://github.com/rust-lang/crates.io-index):2:9 ───
   │
 2 │ name = "ring"
   │         ^^^^ a valid license expression could not be retrieved for the crate
   ·
 4 │ license = ""
   │            - license expression was not specified

[briansmith]

The documentation for cargo deny has an example of how to deal with ring specifically.

[gdesmott]

Oh indeed, perfect, thanks! 👍

[Veetaha]

@briansmith this is unfortunate that ring has become an example of license.clarify clause of cargo-deny and indeed I've stumbled with the warning too.
Why not adding license = "ISC AND MIT AND OpenSSL" or what SPDX expression you see more appropriate to Cargo.toml.
I think it is easier done than discussed....

[briansmith]

I do now maintain a deny.toml to use for ring at https://github.com/briansmith/ring/blob/main/deny.toml.

[briansmith]

@briansmith this is unfortunate that ring has become an example of license.clarify clause of cargo-deny and indeed I've stumbled with the warning too.
Why not adding license = "ISC AND MIT AND OpenSSL" or what SPDX expression you see more appropriate to Cargo.toml.
I think it is easier done than discussed....

As soon as I am sure what SPDX expression to use, I will do so. My goal is to first reduce the chance that the SPDX expression would be wrong by reducing the amount of code where the license isn't obvious, and then after that figure out the appropriate SPDX expression. I worry about using or recommending a wrong or misleading SPDX expression for people to use that is over-simplified and/or otherwise wrong.

The issue is simply that the slogging through refactoring the code takes a long time.

[briansmith]

An example of a complication that I'm not yet prepared to resolve yet, that I encountered in the webpki project. The spdx.org website says the BSD 3-clause license has a warranty disclaimer that uses the term "COPYRIGHT HOLDER." Yet the license text Google used for Chromium says "COPYRIGHT OWNER" instead. So what SPDX expression covers that? No clue.

[briansmith]

An example of a complication that I'm not yet prepared to resolve yet, that I encountered in the webpki project. The spdx.org website says the BSD 3-clause license has a warranty disclaimer that uses the term "COPYRIGHT HOLDER." Yet the license text Google used for Chromium says "COPYRIGHT OWNER" instead. So what SPDX expression covers that? No clue.

That's now https://github.com/briansmith/webpki/issues/148.

[cipriancraciun]

I'm also interested in this issue, because after using the CycloneDX tool for SBOM generation (https://github.com/CycloneDX/cyclonedx-rust-cargo), ring is my only dependency for which no license in detected.

At the moment I can just patch-it myself, however, given how high profile ring is, and perhaps how important SBOM's will become in the near future, properly specifying a license would be very welcome.

[kamulos]

+1

At my company we are using cargo-deny to ensure that all dependencies fit in the a pre-selected list of allowed licensed. With rustls we are intending to pull ring and webpki in our dependencies.

The fact, that the licenses are not automatically checkable is making everyone nervous. To be honest we currently have no clue how to proceed here except hand-checking each ring and webpki update.

[MarijnS95]

@kamulos Fwiw cargo-deny has a special license.clarify section. This includes a checksum of the license file so that the manual clarification/checking only remains valid for as long as that file doesn't change.

[kamulos]

@MarijnS95 thanks, for clarifying 😁 This makes it basically painless 👍

[kamulos]

Note that it is easy for this file to get out of sync with the licenses in the source code files. It's recommended to compare the licenses in the source code with what's mentioned here.

This is still a tough one 😅 No idea how to solve it though...

[kpcyrd]

Is there an update on this? :) In the project I tested cargo-deny with, ring is the only dependency that has no machine readable license. Over in #1487 in seems consensus the license of the project is:

license = "ISC AND MIT AND OpenSSL"

This expression would be valid as long as no further licenses are being introduced, the specific attribution/licensing shouldn't matter since the expression says you need to be compliant with all three of them anyway.

[gitmalong]

Any update on this?

[briansmith]

Some thoughts:

• What does "OpenSSL" mean in SPDX? There are actually two different OpenSSL licenses in use; one is SSLeay and the other is the OpenSSL license. Answered at https://spdx.org/licenses/OpenSSL.html: "The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit." So I guess "OpenSSL" does cover what we need.
• license = "ISC AND MIT AND OpenSSL" is technically a compatibility-breaking change, if people have explicitly disallowed OpenSSL (or ISC or MIT) as a license. But I am OK with this.

Is there any CI tooling that exists that can help us enforce that license = "ISC AND MIT AND OpenSSL" is the actual correct SPDX expression, by having some kind of job in CI check that every file has a license header with one of those licenses in it?

[briansmith]

With PR #2397 merged, I believe it is now practical to do this.

[briansmith]

PR #2402 proposes to merge the BoringSSL change of its license to Apache 2.0. It also adds a license = "APACHE AND (APACHE OR MIT) AND ISC" to the Cargo.toml for the contents of the published crate. I will go through things again. I would appreciate it if people could look at that PR and provide suggestions. Especially regarding the license = "APACHE AND (APACHE OR MIT) AND ISC" and how to deal with the LICENSE file and how to reference the licenses of the things we use code from.

[briansmith]

PR #2402 was merged. PR #2406 further clarifies some of the licensing, as I noticed GitHub's UI was showing weirdness.

[briansmith]

PR #2413 attempts to further clarify cases where LICENSE-BoringSSL doesn't apply.

[briansmith]

I have to admit I don't fully understand all the implications of switching from license-file to license, so I think I'm going to switch back to license-file until I get some help. Probably we should have some license-header scanning tool in CI that:

• verifies that the LICENSE and related files are accurate by looking at the license header of each file.
• verifies license in Cargo.toml is consistent with LICENSE-*

I suspect I won't get to that myself any time soon.

[briansmith]

:sigh: switching back to license-file would be a PITA. I guess I won't.

[briansmith]

This was mostly done in 0.17.10.