-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a utility to map originator defined license strings to SPDX license format #106
Comments
@nishakm Thank you! This is indeed useful but such a mapping would be most useful in the context of a certain package manifest and type and its actual raw license declaration data and IMHO in the context of license detection. As such the mappings from ORT are generic and would better if they were package-type specific (e.g. capturing the conventions of npms, Maven, etc). But my main point is that I am not sure there is a place in this library where I could make use of this data. When you craft SPDX documents, you need to have already the proper normalized licenses ids and license expressions so there would not be a place to plug this in. This would have to be done/used before. Therefore I think this is something that could be best used in two places:
Feedback welcomed! |
@sschuberth btw, this mapping is not right: https://github.com/heremaps/oss-review-toolkit/blob/518e17c0b1385cc403960cfdfdff69e76240cb27/spdx-utils/src/main/kotlin/SpdxDeclaredLicenseMapping.kt#L120 |
Thanks @pombredanne for the hint, @mnonnenmacher any comments? |
Agreed. It would be a much larger undertaking then :)
The use case is basically translating what looks like the appropriate license declared somewhere in the artifact into the license expression. So I'm not sure how a license expression parser would help here.
I'd like it to be independent of scancode-toolkit because other projects who want the same thing can use it as well. But if there are already mappings in here, where in the project might I find it?
|
Thanks to @pombredanne for pointing out at [1] that "/" usually refers to dual licensing and as such expresses a license option. [1] spdx/tools-python#106 (comment) Signed-off-by: Sebastian Schuberth <[email protected]>
Thanks to @pombredanne for pointing out at [1] that "/" usually refers to dual licensing and as such expresses a license option. [1] spdx/tools-python#106 (comment) Signed-off-by: Sebastian Schuberth <[email protected]>
Thanks to @pombredanne for pointing out at [1] that "/" usually refers to dual licensing and as such expresses a license option. [1] spdx/tools-python#106 (comment) Signed-off-by: Sebastian Schuberth <[email protected]>
@nishakm how about creating language-agnostic license mappings in JSON / YAML format that are initially populated with the existing mappings from ORT / the ones that nexB has, and put them in a "neutral" place like probably a new repository at https://github.com/spdx? |
This sounds good to me if @kestewart and @goneall are OK with creating an independent repo under the spdx github namespace. I am not a license geek but I already feel like a 1:1 mapping is not going to get all the way there. There needs to be some kind of string formatting or downstream processing from there. But a 1:1 mapping to start off would be great! |
@sschuberth re:
I was exactly talking about this yesterday about this very ticket of @nishakm @nishakm re:
The right approach would be indeed not to have a 1:1 mapping but something imho which would be this way:
Let me create the repo :) |
@nishakm @sschuberth there it is: https://github.com/spdx/package-licenses-mapping |
See spdx/package-licenses-mapping#1 which is the continuation for this ticket |
@nishakm one of the reason that having a separate repo is better is that it could be reused in many places beyond this Python tool repo. |
It's what I asked for initially. It was suggested that I file an issue here :) |
@nishakm that's fine, you could have made it clear in the ticket |
@nishakm re:
This would be important to validate that the license expressions are correct and in a canonical form. That's a something to add as a test of sorts |
Just catching up on the issue . I recall discussing this on one of the SPDX calls and I do recall talking about adding the issue to the tools. I also agree with the above comments that we should have a separate data mapping repo along with tools implementations that support the mapping. I don't recall the discussion precisely, but I don't think anyone had a concern with a neutral mapping repo - just a concern about adding it to the spec since the mapping may be updated quite frequently. I like the idea of the mapping repo and can use this in the SPDX Java Tools as well. |
Package managers or text files may declare a license string that may not be an SPDX license format. For example, many projects declare their license as
BSD
but it is unclear whichBSD
.oss-review-toolkit has an implementation that comes reasonably close.
https://github.com/heremaps/oss-review-toolkit/blob/490c2da69435182db19c6dbdebad863de41a7108/spdx-utils/src/main/kotlin/SpdxLicenseAliasMapping.kt
https://github.com/heremaps/oss-review-toolkit/blob/518e17c0b1385cc403960cfdfdff69e76240cb27/spdx-utils/src/main/kotlin/SpdxDeclaredLicenseMapping.kt
This is written in kotlin but it looks reasonably straightforward to convert it to python2/3
This would be useful for tools that are reading user-declared licenses.
cc @tsteenbe @goneall @kestewart
The text was updated successfully, but these errors were encountered: