declared-license-mapping: Add LGPL-2.1 mapping #3960
Conversation
Found "GNU Lesser General Public License v2 (LGPLv2)" in [1]. [1]: https://github.com/PyCQA/astroid/blob/v2.5.6/setup.cfg#L15 Signed-off-by: Thomas Steenbergen <thomas.steenbergen@here.com>
| @@ -252,6 +252,7 @@ | |||
| "GNU Lesser General Public License 2.1": LGPL-2.1-only | |||
| "GNU Lesser General Public License Version 2.1": LGPL-2.1-only | |||
| "GNU Lesser General Public License Version 2.1, February 1999": LGPL-2.1-only | |||
| "GNU Lesser General Public License v2 (LGPLv2)": LGPL-2.1-only | |||
There was a problem hiding this comment.
Shouldn't this be LGPL-2.0-only instead?
There was a problem hiding this comment.
To me it seems this again is an ambiguous case, so cannot be added from correctness point of view?!
There was a problem hiding this comment.
Indeed. Only because the license file states "Version 2.1" we cannot assume that everybody who declares "License v2" actually means version 2.1.
There was a problem hiding this comment.
It not an ambiguous case case in the community LGPL-2.0-only is a rare license for OSS projects as when FSF released it in 1991 they quickly superseded in the same year with LGPL-2.1-only when it was renamed the GNU Lesser General Public License to reflect the FSF's position that not all libraries should use it. When people say LGPLv2 they mean 99.99% of the time LGPL-2.1-only and not LGPL-2.0-only.
There was a problem hiding this comment.
I'd say 99.99% is not enough for our newly stated goal to make the contents of this file 100% correct in all cases. And we need 100% correctness as the goal was to outsource / share this file with https://github.com/spdx/package-licenses-mapping.
There was a problem hiding this comment.
I don't recall when we agreed upon the 100% correctness target as I see 100% right for each mapping as an impossible target - no compliance tool is 100% right. In my view this is also not a desired balance between the level of automation and an acceptable compliance level desired by most ORT users especially those who are doing OSS compliance at scale. Plus consider the facts that the declared license can be wrong compared to the project's main license.
I would actually like to propose a different approach to mapping ambiguous declared licenses - introduce an option in ORT to let it map automatically all ambiguous cases and then throw an issue if during scanning the main license files or if no main license files are present all source code excluding package metadata files reveals a different license.
Example - PyPI::pytest-cov declares itself as MIT and BSD License. Under my proposal, ORT would map BSD License to BSD-3-Clause but after the scanner is run ORT detects only MIT in the LICENSE so then would throw an error/warning issue with message 'Mapped BSD License to BSD-3-Clause for package PyPI::pytest-cov:2.11.1 but scan results do not support this mapping. Recommend to add a curation to clarify this package licensing.'
By having ORT "guess" the SPDX id for an ambiguous declared license and then "correct itself" when "wrong" would save ORT users a lot of effort of having to manually add declared license mapping for a lot of packages (which is something we are now forced to do thanks to #3857).
I realize that not all ORT users are using ort scan but I bet even those users would like to have this guessing option either to save having to create curations or simply because they don't care whether a declared BSD means BSD-2-Clause, BSD-3-Clause or any of the other 20+ BSDs. In ORT's export to https://github.com/spdx/package-licenses-mapping we would simply not share all ambiguous mappings or on the SPDX we could add an special label for ambiguous mappings.
There was a problem hiding this comment.
I don't recall when we agreed upon the 100% correctness target
Meanwhile, see #5127 in that context.
I see 100% right for each mapping as an impossible target
Well, I believe it is possible if we restrict ourselves to the indisputable cases, like mapping "Apache v2.0" to "Apache-2.0" etc.
|
Closing this in favor of the approach discussed in the community meeting on 2022-11-24. |
Found "GNU Lesser General Public License v2 (LGPLv2)" in 1.
Signed-off-by: Thomas Steenbergen thomas.steenbergen@here.com