SPDX Normalizer?

[brettz9]

Hi @kemitchell ,

Sorry this may be off topic for this repo, but just wondering if I could just ask whether you have something in your SPDX constellation which can do normalizations along the lines of https://github.com/nexB/license-expression but for Node?

As per their example:

GPL-2.0 or (mit and LGPL 2.1) or bsd Or GPL-2.0 or (mit and LGPL 2.1)

...can be reduced (via simplify) down to:

BSD OR GPL-2.0 OR (LGPL 2.1 AND mit)

[kemitchell]

What's the use case?

[brettz9]

A couple...

1. In license-badger (for an example in use, see the two license badges at https://github.com/SVG-Edit/svgedit#-svg-edit ), I am listing out licenses that can't be categorized according to the https://github.com/delfrrr/npm-consider scheme. I'm actually hoping to parse and then drop the conjunctions for the categorizable licenses (each part of the AND can be added as is, and the side of the OR which is more permissive can be added), but for uncategorized AND or OR items, it'd be nice to list them out (btw, the reason some are uncategorized currently, like spdx-ranges is because npm-consider needs to get support for certain license types added).
2. I also hope to add the functionality later to license-badger of aggregating the items added to a file like this (currently requires manual maintenance, but it'd be nice if we could parse files for @license (such as we do with check-values in eslint-plugin-jsdoc but aggregating across files) and build that automatically): https://github.com/SVG-Edit/svgedit/blob/master/licenseInfo.json#L13-L21 . This map indicates the licenses within a project, and when combined together, it could be joined together with a defaultLicense property, to replace whatever is in license of package.json (a script could thus ensure the package.json license always reflects the actual contents). And it'd be nice for this not to be overly long.

[kemitchell]

Wow. That's pretty deep in the weeds.

Looks like the nexB repo you linked is Apache-licensed Python. If you'd like to port to JavaScript, we'd be happy to have it under the jslicense org if you think that's best for the project. I can't commit any time or attention to it without a use case of my own. But it's up to you.

[brettz9]

Ok, cool, thanks... And while I'm asking questions...

Would you like something like this added to spdx-expression-parse:

const stringifyLicense = (ast) => {
  if (ast.license) {
    return ast.license +
      // Todo: Is this correct?
      (ast.plus ? '-or-later' : '') +
      (ast.exception ? ('-with-' + ast.exception) : '');
  }
  return `(${stringifyLicense(ast.left)} ${ast.conjunction.toUpperCase()} ` +
      `${stringifyLicense(ast.right)})`;
};

(My implementation may be naive here in the plus handling, but just wondering on the idea.)

Of course, it's simple, but feel it would be a little cleaner for consumers who might need to serialize parsed modifications or portions back to string.

[kemitchell]

@brettz9 what does your code aim to do?

[brettz9]

Given a parsed license, e.g., say after splitting apart "(MIT OR GPL-3.0)" to get the chunks for "MIT" and "GPL-3.0", be able to reassemble them back together. (I'm using this currently in license-badger to stringify back entire parsed OR expressions (which we don't handle yet), while having no need to do so for AND or conjunction-less expressions.)

[kemitchell]

Both of your proposals sound like separate packages.