Incorrect license conjunction match

[chinyeungli]

Sample 1

{
  "name": "json-schema",
  "version": "0.4.0",
  "author": "Kris Zyp",
  "description": "JSON Schema validation and specifications",
  "maintainers":[
        {"name": "Kris Zyp", "email": "kriszyp@gmail.com"}],
  "keywords": [
    "json",
    "schema"
  ],
  "files": [
    "lib"
  ],
  "license": "(AFL-2.1 OR BSD-3-Clause)",
  "repository": {
    "type":"git",
    "url":"http://github.com/kriszyp/json-schema"
  },
  "directories": { "lib": "./lib" },
  "main": "./lib/validate.js",
  "devDependencies": { "vows": "*" },
  "scripts": { "test": "vows --spec test/*.js" }
}

For the above package.json file, the package scan returns afl-2.1 OR bsd-new correctly. However, the license scan returns afl-2.1 AND bsd-new which is incorrect.

Sample 2:

{
  "name": "rc",
  "version": "1.2.8",
  "description": "hardwired configuration loader",
  "main": "index.js",
  "browser": "browser.js",
  "scripts": {
    "test": "set -e; node test/test.js; node test/ini.js; node test/nested-env-vars.js"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/dominictarr/rc.git"
  },
  "license": "(BSD-2-Clause OR MIT OR Apache-2.0)",
  "keywords": [
    "config",
    "rc",
    "unix",
    "defaults"
  ],
  "bin": "./cli.js",
  "author": "Dominic Tarr <dominic.tarr@gmail.com> (dominictarr.com)",
  "dependencies": {
    "deep-extend": "^0.6.0",
    "ini": "~1.3.0",
    "minimist": "^1.2.0",
    "strip-json-comments": "~2.0.1"
  }
}

For the above package.json file, the package scan returns bsd-simplified OR mit OR apache-2.0 correctly. However, the license scan returns (bsd-simplified OR apache-2.0) AND (mit OR apache-2.0) which is incorrect.

[mjherzog]

This issue is similar to #4359

[AyanSinhaMahapatra]

In the short term I'm fixing this with rules at #4405

But longer term, this is tracked in #3024 where we would use a bit of smart logic to override the file license detection with package license detection in case they are coming from the same matched text. See #3024 (comment) for details

We want to process it this way instead of adding rules for everycase because in the vast majority of cases where the license statement is a valid license expression, we parse it as an expression and this works nicely, falling back on rules in case this is not a valid expression. For file license detection there is extra words (like: license) which are hard to remove so the expression parsing does not work.

Now if we used rules instead we have to add rules for virtually all the combinations of licenses being used in conjunction out there which is not what we want to do.