Introducing licenses.json to account for unknown/missing license names in packages #818
Conversation
This is a list of licenses in JSON format, to be used when packages being scanned do not provide license names, only URLs. Is that case we can find license name by URL reference, if exists. This is not a final/comprehensive list, but could be a good starting point.
|
@vr333dev Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
|
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
|
@xtreme-shane-lattanzio ok PR created... not sure if I should "Update branch" and/or required to sign Contributor License Agreement? Thanks |
|
@vr333dev Thank you for signing the Contributor License Agreement! |
|
Hey @vr333dev . The list looks good. Will there be code to actually use this list or is it intended that an application that uses license finder would have that logic? |
|
Hello, I understood that LicenseFinder returns license names as output, in which case it would be a change in LicenseFinder logic (no one on our team is ruby "literate", unfortunately). But if I should create a GitLab ticket in order to diagnose License-Compliance job, and see if license names are somehow derived in a GitLab template or a container, then I will need to take a different turn to resolve the issue we are experiencing. |
|
@vr333dev What I thought we were talking about was when a nuget scan was done, the name was not found but the URL can be. In this case I would expect logic in LF to take that URL and use the newly created JSON to assign the name correctly so that the output is not unknown. I would expect that this logic would only be used for nuget at this point and then potentially expanded in the future. Either way, LF would need to use the new json in some way to fill in missing information. Did I understand that correctly? |
|
Yes that's correct. |
|
Our pipelines were having issue which we seemed to have fixed this morning. So your PR is currently being validated in our pipelines. |
|
@vr333dev I am fine with merging this json but since it is not used anywhere, I am not sure of the point. Is the code being built to use this json going to be in LF or will it be in your own repos? Either way we can have this but it may be helpful to drop a note in the readme about this or it will just be forgotten |
|
@xtreme-jason-smith this JSON is meant to be absorbed by the LF itself (if possible), since there is nothing I see us accomplishing with it when License-Compliance task runs in GitLab CI (where license names are being looked up by LF). Unless there are other ideas? |
|
@vr333dev Sorry for taking so long to get back to you. This makes sense yes but I am wondering if it will be part of this PR or a separate one? |
|
Hey @vr333dev ! Im still wondering if a change should be done for this or just a readme update. If I don't hear from you in the next little while, I'm going to go ahead a close this for now so let me know what you think! |
xtreme-shane-lattanzio
force-pushed
the
master
branch
from
5673f2b
to
fc71740
Compare
|
Closing due to inactivity |
This is a list of licenses in JSON format, to be used when packages being scanned do not provide license types, only URLs. In that case we can find license name by URL reference, if exists. This is not a final/comprehensive list, but could be a good starting point.