Add relaxed option to allow invalid licenses and exception names

[motet-a]

Fix #11.

[kemitchell]

Thank you, @motet-a. I know it's work to make another PR.

I think there is more to discuss about this change. In a good way! I don't want #15 to wait.

[kemitchell]

The code changes look good at first glance!

I wonder a bit about whether this is a good idea, though. Or whether it should be a separate package, since this one is very clearly an implementation of standard SPDX. The expression grammar expressly applies to the defined license and exception lists. We have those lists as independent npm dependencies, and the scanner require()s them, like normal. As a grammar by itself, it's not very complex.

Is there a use case for this kind of relaxed parsing, other than allowing license identifiers that should not be allowed?

[motet-a]

I have written this patch only because I like this proposal and it was pretty easy to implement.

I don't have any other use cases in mind and I don't need this relaxed mode.

Do what you want, you are the judge ⚖️.

[motet-a]

Note this Python repository supports “relaxed parsing” and many other features and they are working on transpiling it to JS.

I don't think it can entirely replace spdx-expression-parse.js since it is much bigger (plus the overload of a transpilation to JS). But if their transpiled version is good, it may be a good idea to keep spdx-expression-parse.js as small, simple, strict, and spec-compliant as possible and use the Python-based license-expression for advanced operations and relaxed parsing.

[kemitchell]

Do what you want, you are the judge ⚖️.

We're a team now. Your thoughts count as much as mine. Or more, since you've done so much work lately!

There is more interest in this than I'd remembered. I definitely don't want to stand in the way.

[kemitchell]

@motet-a: I don't like holding this up, though I know there are still open questions in #20.

Feel free to land whatever version of this you think best at the moment, and publish SemVer-minor. We can always revisit (and bump versions) if SPDX goes one way or another.

[motet-a]

Sorry for the delay. I was quite busy lately.

I thought about this yesterday. Since strictness widely varies
between license expression parsers in the wild, it could be
interesting to use a whole different approach: loosen the parser
as much as possible and embed a linter inside
spdx-expression-parse.

We could get these features:

• Strict-by-default behavior: parse('unknown-license') will
  throw because the linter is enabled.

• Doesn't throw on lint errors in relaxed mode:
  parse('MIT and unknown', {relaxed: true}) will return the
  parsed AST and an array of lint errors. Users might filter the
  array to ignore some specific lint errors or simply ignore all of
  them and use the AST.

• Much more user-friendly errors in strict mode (“Forbidden space
  after (”, “AND must be written in uppercase”, …).

The linter might possibly lay in a separated repository.

I will write a prototype soon. Any thoughts?

[kemitchell]

Hmm. I should think about this a bit more---it's quite late here now.

My first impression is that I wouldn't take too much from other parsers. Best case, the standard would be clear, and this implementation would be Correct. The grammar we're talking about is also relatively simple. It should work for its specific purpose, and not reinforce or encourage more variation. We don't want to further dilute the standard.

[dabutvin]

in the current state you get this output

parse('MIT OR Commercial', {relaxed: true})

{
    left: {license: 'MIT'},
    conjunction: 'or',
    right: {license: 'Commercial'}
}

I feel like it may be helpful to signal that this is not in the spdx license list

parse('MIT OR Commercial', {relaxed: true})

{
    left: {license: 'MIT'},
    conjunction: 'or',
    right: {noassertion: 'Commercial'}
}

thoughts?