Usage in Scancode Workbench for arbitrary expressions?

[pombredanne]

Hi Lasse!

Thanks for this library which works nicely with expression that do not use SPDX license keys!

@OmkarPh wants to use it in Scancode Workbench. There we use SPDX expressions and also other license keys that are not from SPDX.

I maintain the Python library at https://github.com/nexB/license-expression/ and it would be awesome if we can have similar features in your library (and we will try to help as much as we can)

Some other features of interest:

• having a function to extract the flat list of license keys and exceptions
• being to render an expression with a string template, for instance to have an href/link to each license in the expression
• optionally validating against a provided list of license and expression keys

[OmkarPh]

yeah, the option to get a flat list of keys & exceptions would be a great help

[OmkarPh]

Hi @lkoskela
Is there any way to parse like this
apache-1.1 -> { license: 'apache-1.1' } instead of the default { license: 'Apache-1.1' }
lgpl-2.1 -> { license: 'lgpl-2.1' } instead of default { license: 'LGPL-2.1-only' }

[lkoskela]

@OmkarPh

Hi @lkoskela
Is there any way to parse like this
apache-1.1 -> { license: 'apache-1.1' } instead of the default { license: 'Apache-1.1' }
lgpl-2.1 -> { license: 'lgpl-2.1' } instead of default { license: 'LGPL-2.1-only' }

#105 makes the "upgrade" configurable (and changes the default behaviour to not upgrading). Does that match what you're looking for?

[lkoskela]

@OmkarPh

yeah, the option to get a flat list of keys & exceptions would be a great help

This would be quite doable since license-expressions already contains that data (pulled from SPDX Workgroup's data files at build time).

Do you have an idea of what the API would ideally look like from your point of view?

[OmkarPh]

@OmkarPh

Hi @lkoskela
Is there any way to parse like this
apache-1.1 -> { license: 'apache-1.1' } instead of the default { license: 'Apache-1.1' }
lgpl-2.1 -> { license: 'lgpl-2.1' } instead of default { license: 'LGPL-2.1-only' }

#105 makes the "upgrade" configurable (and changes the default behaviour to not upgrading). Does that match what you're looking for?

yeah this looks like what we expected
At AboutCode, we have licenses other than SPDX too, so we want to parse the components as they are without any changes
or SPDX verification
Can you provide a parse option that suits this

[OmkarPh]

@OmkarPh

yeah, the option to get a flat list of keys & exceptions would be a great help

This would be quite doable since license-expressions already contains that data (pulled from SPDX Workgroup's data files at build time).

Do you have an idea of what the API would ideally look like from your point of view?

we just need a list, nothing else, for example parse('gpl-2.0-plus WITH ada-linking-exception', { some option here })
should return an array of strings i.e. ["gpl-2.0-plus", "ada-linking-exception"]

[lkoskela]

@OmkarPh I published 0.6.0, which includes the --upgrade option to enable "upgrading" from a deprecated license (such as GPL-3.0) to the respective non-deprecated version (e.g. GPL-3.0-only).

[OmkarPh]

hi @lkoskela , sorry for late reply
i tried latest 0.6.0, but still am getting results like earlier

console.log(parse('GPL-3.0+'));
console.log(parse('apache-1.1', { strictSyntax: false, upgradeGPLVariants: false }));
console.log(parse('lgpl-2.1'));

Expected something like this:

{ license: 'GPL-3.0+' }
{ license: 'apache-1.1' }
{ license: 'lgpl-2.1' }

[lkoskela]

hi @lkoskela , sorry for late reply i tried latest 0.6.0, but still am getting results like earlier

console.log(parse('GPL-3.0+'));
console.log(parse('apache-1.1', { strictSyntax: false, upgradeGPLVariants: false }));
console.log(parse('lgpl-2.1'));

Expected something like this:

{ license: 'GPL-3.0+' }
{ license: 'apache-1.1' }
{ license: 'lgpl-2.1' }

Right. It looks like our thoughts went in different directions regarding the desired behavior. To try and clarify things, which of the following behaviours would you like to have?

1. Disabling ambiguous corrections/transformations. (For example, LGPL-2.1 would not be coerced into neither LGPL-2.1-only nor LGPL-2.1-or-later because we don't know for certain which of the two did the licensor intend when they wrote down "LGPL-2.1".)
2. Disabling unambiguous corrections/transformations. (For example, For example, apache-1.1 would not be uppercased into its official form of Apache-1.1, GPL-3.0+ would not be coerced into GPL-3.0-or-later, and GPLv3 would not be coerced into GPL-3.0.)
3. Disabling any corrections/transformations whatsoever.
4. Something else?

The upgradeGPLVariants option added in version 0.6.0 actually only does 1. (Although its name implies it might be doing a bit of 2. as well, correcting the common misspellings/typos of GPL family license identifiers)

I'm now thinking you want 3. i.e. no transformations on the license identifiers whatsoever. Do correct me if I'm wrong.

[OmkarPh]

I'm now thinking you want 3. i.e. no transformations on the license identifiers whatsoever. Do correct me if I'm wrong.

Yes that's correct
Also, you can make this behaviour optional, keep the default behaviour as it suits for you