Packages with no SPDX licence cause a build to fail

[sebaspf]

Enhancement

When building using dependencies with no SPDX license, the complete build fails as the check in this line fails generating an error. This behavior may be sometimes a problem when using many of these packages or when a different team handles the build configs. A possible solution could be to exclude them, but it requires an intervention for every new dependency.

Anew option handleNonSPDX with the flowing values would be very handy for many applications:

• reject: default, current behavior
• ignore: do not list these packages in the output
• warning: Add them to the output and show a warning.

[codepunkt]

Imagine your new option set to ignore and an important dependency mistakenly switching from "Apache-2.0" to "Apache 2.0" in a new version. This new version would then silently be excluded from the build output.

For reasons like this, implicitly excluding packages from the output is not something I'll likely ever support. If something is to be excluded from the output, it has to be explicitly defined with excludedPackageTest option.

I'm not entirely against allowing to choose error or warning semantics for packages with non-SPDX identifiers. However, you're the first to bring this up so I'll definitely wait for more feedback from other users before I add another option to the plugin.

May I ask what non-SPDX packages you're encountering and why you're using many of them?

[sebaspf]

In regard to the non-SPDX dependencies, an example are the Font Awesome pro Icons, which have a "license": "UNLICENSED", in its package.json. Also other private dependencies have licenses like My-Company-License_v1.2.3 or some other strings. Mostly commercial or private packages.

For the same reasons you mention above, I personally would only use warning and never ignore, I just added it for completeness.

I also thought of calling the flag acceptNonSPDX and making it boolean: default false as it is now and when true emit a warning.

A third possibility would be to extend excludedPackageTest. Using the boolean return options works like now, but returning something like accept, ignore, reject, or warn gives the user the full control over all dependencies. The callback may also require the license.

Here an example of this third option:

import * as validate from 'spdx-expression-validate' 

module.exports = {
  // ...
  plugins: [
    new LicensePlugin({
      excludedPackageTest: (packageName, version, license) => {
        if (!validate(license)) {
          return 'warning‘
        }
        return 'accept’
      }
    })
  ]
}

By the way nice Project :+1:

[codepunkt]

Thanks 🤗

If you know what's happening with your internal packages, you need neither warnings nor errors. I suggest publishing internal packages in a specific namespace and then ignore those via excludedPackageTest option altogether. After all, they're both part of the software you're distributing and built by you or your company. In terms of open source licensing, there should be no difference to the source code you wrote on your project yourself.

Commercial packages are not open source either. You can choose to not list them in your oss-licenses.json file, or set them to a suitable license name using the licenseOverrides option.

Hope this helps!

[sebaspf]

Overriding a private license with some SPDX license would be a license violation and excluding the package from the list would implies I need to keep track of those dependencies separately with a second tool, increasing the maintenance work.

I think you mention an important point that was not really clear for me. The fact that "Commercial packages are not open source [...]" and that the default output file name is oss-licences.json makes me conclude that the philosophy of the plugin is to manage only the OSS included in the build and not all of the dependencies. This point is mentioned in the Key Features section of the README. If this is so, we will probably never reach a consensus.

[codepunkt]

You are right. This plugin is supposed to manage open source licenses to ease open source license compliance.

If you have commercial software that you include in your build output, you're probably paying for a license and have the right to use it in your project, so open source license compliance obligations do not apply.