Ring: 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! :+1:

[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.