Refactor/compare complex expressions #18
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This change focuses on two aspects:
second
argument, following this comment and based on this change.Our main goal is to make both approaches compatible, so users can decide whether to compare SPDX expressions or an allowed list of licenses.
Related Issue
#14
Motivation and Context
The main problem right now is that the library doesn't function properly when comparing certain SPDX expressions, such as
satisfies("MIT", "MIT AND Apache-2.0")
. In this case, the function should returnfalse
.With the following example
MIT AND Apache-2.0 OR GPL-1.0+
, theexpand
function returns the following:This implies that the elements in the outer array are alternatives based on the
OR
operator. The licenses in the inner arrays are grouped based on theAND
operator. Ifsecond
wereMIT OR GPL-2.0
, the result would be:In our opinion, the algorithm should check if there's any inner element within the outer array of
first
that is satisfied by any inner element ofsecond
.When comparing
["MIT", "Apache-2.0"]
and["MIT"]
, the result is negative. Similarly, when comparing["MIT", "Apache-2.0"]
and["GPL-2.0"]
, as well as["GPL-1.0+"]
and["MIT"]
, the result is again negative. However, when comparing["GPL-1.0+"]
and["GPL-2.0"]
, the result is positive sincefirst
should beMIT AND Apache-2.0
OR
GPL-1.0+
, which we understand is correct.On the other hand, we believe that the suggestion mentioned in this comment and this change can be compatible with
second
as an SPDX expression. This way, backwards compatibility is ensured because there may be users who expect to usesatisfies
with two expressions, while other users expectsecond
as anallowList
.We have interpreted that the licenses in
second
would be alternatives thatfirst
should comply with. So the following usages would be equivalent:In the event that the interpretation of
second
as anallowList
implies that the licenses are not alternatives but requirements thatfirst
must fulfill, the PR would need a slight modification. In that case, the following examples would be equivalent:@kemitchell please, let us know which of the above approaches you have in mind. Thanks
cc/ @inigomarquinez @nanotower