Aliases

[connorshea]

Is it possible to add an alias to, e.g. some gems are "LGPL-2.1+" and I'd like to add that as an alias for LGPL. I can't find any other issues about this, and it doesn't seem to be documented anywhere.

Thanks, Connor

[wayne-luminal]

+1 This would be nice

[flavorjones]

Hi, @connorshea.

Thanks for opening this issue. I'm not sure I totally understand, can you be more specific by what you mean by 'alias'? Are you asking for the emitted license name to be different in reports? Or are you asking for different whitelist behavior?

[connorshea]

@flavorjones essentially, instead of having to whitelist "LGPLv2", "LGPL version 2", "LGPLv2+", "Lesser General Public License version 2", etc. separately I'd like to be able to whitelist multiple at once using "aliases".

Instead of

- - :whitelist
  - LGPLv2
  - :who: Connor Shea
    :why: http://www.gnu.org/licenses/license-list.html#LGPLv2.1
    :versions: []
    :when: 2016-05-02 05:32:48.645841000 Z
- - :whitelist
  - LGPLv2+
  - :who: Connor Shea
    :why: http://www.gnu.org/licenses/license-list.html#LGPLv2.1
    :versions: []
    :when: 2016-05-02 05:32:48.645841000 Z
- - :whitelist
  - LGPL version 2
  - :who: Connor Shea
    :why: http://www.gnu.org/licenses/license-list.html#LGPLv2.1
    :versions: []
    :when: 2016-05-02 05:32:48.645841000 Z

It could be

- - :whitelist
  - LGPLv2, LGPLv2+, LGPL version 2, Lesser General Public License version 2
  - :who: Connor Shea
    :why: http://www.gnu.org/licenses/license-list.html#LGPLv2.1
    :versions: []
    :when: 2016-05-02 05:32:48.645841000 Z

Essentially the problem is that right now in GitLab we've had to make repetitive additions to our decisions YML file because they spelled the license ever so differently even though we already approved of the license in question.

Other than that license_finder has been great! Thank you so so much for the gem, I was actually putting together a manual list of all the gems we were using (hundreds) that didn't have certain licenses before I found this gem. I felt like a real dunce :D

[connorshea]

Alternatively, since I'm sure some licenses have commas in their name:

- - :whitelist
  - "LGPLv2", "LGPLv2+", "LGPL version 2", "Lesser General Public License version 2"
  - :who: Connor Shea
    :why: http://www.gnu.org/licenses/license-list.html#LGPLv2.1
    :versions: []
    :when: 2016-05-02 05:32:48.645841000 Z

or

- - :whitelist
  - LGPLv2
  - LGPLv2+
  - LGPL version 2
  - Lesser General Public License version 2
  - :who: Connor Shea
    :why: http://www.gnu.org/licenses/license-list.html#LGPLv2.1
    :versions: []
    :when: 2016-05-02 05:32:48.645841000 Z

[flavorjones]

Ah, that totally makes sense, thanks for explaining.

I've had this problem internally at Pivotal as well, and we also fixed it in an ad-hoc manner, and I actually feel bad about not trying to push this kind of cleanup back into the gem. Because packages and package managers all do this differently, it's actually not solvable without introducing human knowledge of what licenses are called.

What I'd like to propose is to introduce a "mapping" of license appellations, which would contain:

• a "canonical" name for a license, preferably an abbreviation (e.g., "LGPLv2")
• a set of strings that map to that license (e.g., "LGPL version 2", "Lesser ...")

and this file would have to be maintained by humans as we learn and explore the space of "what are licenses called?".

An example data file that could represent that mapping:

LGPLv2:
  - "LGPL version 2"
  - "Lesser General Public License version 2"

and of course I'm sure we'll all bikeshed whether "LGPLv2+" is the same thing as "LGPLv2", but at least we'll have a place to record a consensus.

What do you think?

[CyrusWadia]

All - This makes a lot of sense.

The Software Package Data Exchange (SPDX) specification is a standard format for communicating the components, licenses and copyrights associated with a software package. Companies are lining up behind this because of the problems caused by variations in naming throughout the supply chain for software. SPDX has a list of standard licenses http://spdx.org/licenses/ with the license text.

So I'd think we could start here with these as the list of Canonical names, and then fill out the strings for the variations we see [Dave - seems like something Quislex may be able to do for us rather than our tooling team].

[connorshea]

@flavorjones that works for me! :)

Glad to know others have the same problem, and shame on you for not fixing it! :P

[mainej]

I like the idea of making aliases configurable. But in this case, there's a shorter term fix. First you could add lgpl v2 to license/definitions.rb. Then you can use the 'other_names' attribute of the license to store the aliases. License finder will treat anything with those names as the same license, which means you can approve them in bulk. On Wed, Jun 15, 2016 at 8:25 AM Connor Shea [email protected] wrote:

@flavorjones https://github.com/flavorjones that works for me! :)

— You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub https://github.com/pivotal/LicenseFinder/issues/218#issuecomment-226222814, or mute the thread https://github.com/notifications/unsubscribe/AAAadqG-QJoa36EZTveSn7y7lbRDRk0dks5qMBlvgaJpZM4IVIgu .

[flavorjones]

Ah, @mainej is totally right, this was my misunderstanding of the current functionality here:

https://github.com/pivotal/LicenseFinder/blob/master/lib/license_finder/license/definitions.rb#L83

There is a bigger question here around the legal opinion we need to properly bucket "long names" under a "canonical name", and I'm not totally sure that our current bucket named "LGPL" shouldn't be changed.

Internally at my company, we currently classify LGPL2.0, LGPL2.1, and LGPL3 as separate things.

@CyrusWadia is it worth resolving how LicenseFinder buckets licenses with how Pivotal is classifying licenses? It probably is. I'll reach out to schedule a chat.

/cc @dannyzen and @davidjahn

[flavorjones]

Hey, there's actually a standards body for this:

https://spdx.org/licenses/

and there's also a Ruby gem that provides license metadata in json format:

https://github.com/domcleal/spdx-licenses

and so I'd like to propose we use that gem and that data as the Source of Truth™ with respect to license names (and possibly license content).

[connorshea]

@flavorjones sounds good to me!

[timbru31]

Besides that it would be nice if the full SPDX syntax is correctly handled. E.g. we have some dual licensed dependencies like (MIT OR BSD), so either adding BSD or MIT to the whitelist should not display this dependency again.

[CyborgMaster]

I would love to see alias being configurable.

@timbru31 I've also seen it listed as BSD-3-Clause AND MIT, so it would be great if AND was recognized as well

[xlgmokha]

I'm curious to know if anyone has started work on incorporating spdx-licenses into this project. If not, I would love to give it a try or help whoever is working on it.