embarkstudios / spdx Goto Github PK

Elastic-2.0 has become a valid spdx identifier on February 3, 2021.

I would like to submit a PR that adds it to the identifiers with the 0x0 flag.

Edit:

I just updated spdx locally, using 3.18, and I can also add a changelog entry and update the readme, but I would totally understand if you would rather do it yourself.

Let me know if you would like a PR :)

Cargo/crates-io is not strict about SPDX syntax, so it allows crates with licenses such as "MIT/Apache".

Currently this crate parses SPDX strictly, so many "Cargo-flavored" can't be parsed.

Would you be interested in expanding the parser to be more relaxed about the syntax and allow / as a synonym for OR and fix incomplete SPDX identifiers?

Is your feature request related to a problem? Please describe.

Thank you for creating such a useful library. We're using it in the CycloneDX SBOM Rust implementation. One rough edge we've come across is that we want to be able to accept mostly-correct SPDX identifiers (e.g. the "MIT/Apache-2.0" convention that's present in several crates), but we want to ensure that we're only producing valid SPDX expressions in our output, to maximize ecosystem tooling compatibility.

Describe the solution you'd like

It would be useful for the Expression type that is generated via parse_mode with ParseMode::LAX to be able to output as a valid SPDX identifier. Currently, it stores the original string and just outputs that when to_string is called. Changing the output to_string would be a breaking change, so maybe there could be an additional function named render or something similar?

Describe alternatives you've considered

Currently, we have a temporary solution that replaces / with OR, but a proper solution would be more robust.

Additional context

If this change is welcome, I might have time to implement this myself and submit a PR over the next few weeks.

As of 0.2.0 we now retrieve the OSI Approved and FSF/Free Libre flags from the SPDX data, but a flag that isn't available from the SPDX data itself but would be extremely useful is a flag that denotes if the license is Copyleft.

I'm not sure if you consider this a bug or not (people seem to have differing opinions on the interaction between changing minimum supported Rust version and semver) but I thought I'd point it out.

The 0.3.1 patch release introduced the use of #[non_exhaustive], which means it will now only compile on stable Rust 1.40.0.

Describe the bug
License code GFDL-1.1-invariants-or-later fails to parse

To Reproduce
Trying to parse license string GPL-3.0-or-later AND GFDL-1.1-invariants-or-later, the following error is encountered:

thread 'main' panicked at 'Unable to find root GNU license', <...>/spdx-0.4.1/src/lib.rs:259:30
stack backtrace:
   0: rust_begin_unwind
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:92:14
   2: core::option::expect_failed
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/option.rs:1321:5
   3: <spdx::LicenseReq as core::convert::From<spdx::LicenseId>>::from
   4: spdx::expression::parser::<impl spdx::expression::Expression>::parse_mode
   5: spdx::expression::parser::<impl spdx::expression::Expression>::parse
   6: <calling code>

Expected behavior
GFDL-1.1-invariants-or-later is a valid SPDX code so should be parsed OK.

Device:

• OS: Ubuntu (docker container) 18.04

Additional context
Problem appears to be that the code raising that error in lib.rs strips off the -or-later and expects the result to be a valid SPDX code, but GFDL-1.1-invariants by itself is not a valid SPDX code. So this may need a special case of a special case :-)

Embark uses a standard set of lints across all repositories. We just upgraded
to version 0.3 of these lints, and this repository needs to be updated to
the new set of lints with any warnings fixed.

Steps

1. Copy the contents of the lints.rs file from
   EmbarkStudios/rust-ecosystem and replace the old list of lints in the
   src/lib.rs and/or src/main.rs files with the new list.
2. Run cargo clippy
3. Update and fix any code that now triggers a new warning.

Is your feature request related to a problem? Please describe.
I was considering using cargo-deny to help with packaging crates for a distro, which while incredibly helpful, would be made even more so by including the isOsiApproved field available in the SPDX data.

Where this would be helpful is I could make a service on OBS, and set a series of restrictions such as "must be isOsiApproved and in the approved list" or similar. It would help to select a broad range of licenses quickly.

Describe the solution you'd like
Either add this as an additional field in the existing license data, or parse the SPDX (perhaps pub const DATA = include!("licenses.json"); ?). I guess you'd need to weigh up the pros/cons of including a large text file in the binary vs just the required data. Or perhaps use a build.rsto parse it, and spit out anidentifiers.rs` with only the required data.

ParseError is currently complicated with a lifetime which makes it annoying to consume, and it also means that a successful parsing always heap allocates a clone of the original input, even if on the caller's side they already have an owned string that they actually aren't going to use after parsing anyways.