Using SPDX license identifiers with custom logic operators seems odd

[dcbaker]

Why not just use the full SPDX logic of AND, OR, and WITH? There's already parsers that understand that, and especially for users who need to evaluate licenses with external tools (I'm thinking things like blackduck) which already understand SPDX it probably makes more sense to write "Apache-2.0 OR GPL-2.0-only" than ["Apache-2.0", "GPL-2.0-only"], which doesn't require someone to transform the CPS specific form into the standardized SPDX form (which has been submitted as an ISO standard).

[mwoehlke]

Using a single string with AND/OR means users must now implement another text parser. Using JSON structure means the JSON parser has already done the semantic parsing.

[dcbaker]

I'm not sure why a build system would want to do anything with the license information beyond anding licenses together, which is not any more difficult to do with one than the other: ['GPL-2.0-only', 'MIT'] vs 'GPL-2.0-only AND MIT'. I don't need a parser or any real semantic because I'm not doing anything with it beyond saying "this depends on A and B, here are their licenses". If I did, SPDX itself provides command line tools, as well as python, java, golang, and JS libraries. A quick search shows that such tools also exist for ruby and rust.

I have a bunch of concerns about inventing another format, when there is a well speced format that is growing in acceptance, and is widely supported outside of CPS. Using nested lists to denote semantic meaning is not immediately obvious when reading. A well meaning person is absolutely going to see [['GPL-2.0-only', 'Apache']] and think that the extra braces is a typo, a well meaning maintainer who doesn't know better who will merge that patch. Now the license has been changed to mean AND, which is impossible to fulfill. No one is going to look at GPL-2.0-only OR Apache and make the same mistake. This is super important because screwing up licensing gets lawyers involved.

SPDX is also in common use, it's an ISO standard. Looking around briefly, it appears that Rust's Cargo, Python's PIP, and NPM, all require their licensing information to be in SPDX format. Ruby's GEM format and build2's package format strongly guide one to use SPDX. Meson strongly recommends it (we used to have a very similar bracketed format but deprecated it in part because people were confused by it), and in 2.0 we will require SPDX.

As a build system implementer I'm simply going to collect the license information and pass that along to another tool like blackduck. In fact, with my Intel hat on, doing SBOM work is part of my job. Our tools natively understand SPDX (or maybe with a plug-in, but it's not something I have to think about), but they don't understand CPS's nested list, so now I actually do have to implement a tool that can convert from this one off format to SPDX so my tooling can consume it, which means I both need to understand the semantics of CPS and I need to understand the semantics of SPDX.

[mwoehlke]

Per prior comment, I am hesitant to change the specification in a way that increases implementation burden without a better understanding of how this particular tag is likely to be used in practice. Accordingly, I am tagging this as needing further discussion/investigation.