Relaxed parsing? #11
Description
The structure of the ABNF documented in Appendix IV of SPDX 2.1 makes it impossible to recover from an expression like (MIT OR BSD) using a tool like spdx-correct. Would it be reasonable to assume that all license-id tokens are a subset of all valid id-string tokens so we could apply validation optionally at the parse phase instead of the lex phase?
That is, could we do something like this:
var parse = require('spdx-expression-parse');
var assert = require('assert');
assert.deepEqual(
parse('(MIT OR BSD)', { relax: true }),
{
left: { license: 'MIT' },
conjunction: 'or',
right: { license: 'BSD' }
}
);Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Participants
Activity
danielmoore commentedon Nov 20, 2016
bump
kemitchell commentedon Nov 21, 2016
Thanks for this PR. I'm not sure why I didn't see a notification the first time. I'm not usually a fan of bumps, but I'm thankful for this one!
It's certainly possible to write a parser that works that way. Just drop an identifier-like pattern in for the static lists of standardized IDs and exception IDs in the grammar. There isn't really much to the syntax after that. Parentheses,
AND,OR,WITH, and+, IIRC.However, I don't think that's what this package should be. Certainly for npm upstream, the main concern is single, invalid identifiers like
BSDorApache 2.0. Typos. Folks who aren't aware of the standard list. Gently nudging folks toward a cleaner package ecosystem.Just FYI, non-list identifiers have certainly come up before. npm considered various "escape hatches" for custom and non-SPDX licenses, settling eventually on
SEE LICENSE IN ____as a validlicensepatternpackage.json, completely distinct from SPDX. A few users chimed in for something like(MiT OR OTHER), withOTHERindicating the other prong of a dual-license offering. Spec-styleLicenseRef-____was also considered. All of these were issues on npm/npm, if you care to dig them up.This parser actually retains support for
LicenseRefandDocumentRef. Wrapper code between this package and npm CLI flags valid SPDX expressions withLicenseRefs as invalidpackage.jsonlicense properties.danielmoore commentedon Nov 21, 2016
I definitely agree with that sentiment and my request is in service to that. More specifically, I'd like to be able to show users where their license expression is incorrect and suggest how to fix it. You might think of this as spdx-correct on steroids:
But I can't do that without an AST, and I can't get an AST if the license token lexemes are literally the license list. I suppose I could write my own library, but that would seem like poor reuse. At the same time, I think the default behavior should be as-is, where invalid licenses raise errors.
kemitchell commentedon May 26, 2017
You're not going to bother me writing any new code, or even taking what I've written and turning it into your own package.
Add `relaxed` option to allow invalid licenses and exception names
relaxedoption to allow invalid licenses and exception names #16Add `relaxed` option to allow invalid licenses and exception names
kemitchell commentedon Jun 25, 2017
@danielmoore, you may be interested in jslicense/spdx-correct.js#19, and especially @motet-a's work in #16.
I'd also like to hear about your use case, if you can share. I'm seeing more complex expressions in issues than I expected to.
Add `relaxed` option to allow invalid licenses and exception names