Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Handling of deprecated SPDX License Identifiers by ORT #9896

Open
gubechto opened this issue Feb 5, 2025 · 5 comments
Open

Handling of deprecated SPDX License Identifiers by ORT #9896

gubechto opened this issue Feb 5, 2025 · 5 comments
Labels
spdx-utils About the SPDX utility library

Comments

@gubechto
Copy link

gubechto commented Feb 5, 2025

What is the existing functionality and how should it be enhanced?

ORT transforms some deprecated SPDX License Identifiers to valid SPDX License IDs what should be enhanced that ORT handles all deprecated SPDX License Identifiers.

What is the use-case for your enhancement?

In the file https://github.com/oss-review-toolkit/ort/blob/main/utils/spdx/src/main/kotlin/SpdxLicense.kt all current deprecated SPDX License Identifiers are identified correctly. If deprecated SPDX License Identifiers are entered directly to ORT for example by the field “licenseDeclared” in a SPDX document some but not all deprecated SPDX License Identifiers are transformed to valid SPDX License Identifiers. Another comparable scenario would by metadata from package managers. Examples of transformed and not transformed deprecated License Identifiers are shown in the following list (taken from the tab table of an ORT Scan Report):

Transformation to valid SPDX IDs  deprecated SPDX License IDs
Declared Licenses                 Unprocessed Declared Licenses
                                  eCos-2.0
GPL-3.0-only                      GPL-3.0
LGPL-2.1-or-later                 LGPL-2.1+
                                  Nunit
                                  wxWindows

Additional context

License information in source code files is interpreted by ScanCode and handed over to ORT by SPDX license expressions. Testing license information which would result in deprecated SPDX License Identifiers show that ScanCode can handle the current deprecated SPDX License Identifiers correctly. With selected files from ecos-3.0.i386linux.tar.bz2, NUnit-2.5.0.9122-src.zip and wxWidgets-3.2.6.zip ScanCode provides the following results with valid SPDX License Identifiers:

Value             Path                      Start End  Text Relevant for License Identification by ScanCode
                                            Line  Line
GPL-2.0-or-later  ecos-3.0/packages/          8    38  // ####ECOSGPLCOPYRIGHTBEGIN####                                            
WITH eCos-        io/fileio/v3_0/                      // -------------------------------------------
exception-2.0     src/socket.cxx                       // This file is part of eCos, the Embedded Configurable...

zlib-             NUnit-2.5.0.9122/src/       2     2  // This is free software licensed under the NUnit license.
acknowledgement   NUnitFramework/framework/
                  AssertionException.cs

LGPL-2.0-or-later src/generic/bmpsvg.cpp      8     8  // Licence:     wxWindows licence
WITH WxWindows-
exception-3.1
@gubechto gubechto added enhancement to triage Issues that need triaging labels Feb 5, 2025
@sschuberth
Copy link
Member

Examples of transformed and not transformed deprecated License Identifiers are shown in the following list (taken from the tab table of an ORT Scan Report):

Can you please share the ORT analyzer result file the report was generated from?

@sschuberth sschuberth added needs info An issue where further information is required spdx-utils About the SPDX utility library and removed to triage Issues that need triaging labels Feb 10, 2025
@sschuberth
Copy link
Member

sschuberth commented Feb 10, 2025 •
edited
Loading

Unfortunately, SPDX does not maintain a machine-readable list to which (non-deprecated) license a deprecated license maps so, i.e. what its successor is. That's why ORT maintains such mappings as part of deprecated-license-mapping.yml.

At the example of eCos-2.0, it seems that should be an exception called eCos-exception-2.0 now. But for e.g. Nunit it's unclear to me what the non-deprecated successor should be.

@sschuberth sschuberth removed needs info An issue where further information is required enhancement labels Feb 10, 2025
@gubechto
Copy link
Author

gubechto commented Feb 10, 2025 via email

@sschuberth
Copy link
Member

there is a unique resolution for the deprecated SPDX License IDs.

Then please share your wisdom with us by providing a table of deprecated -> non-deprecated license mappings that are missing in ORT.

ScanCode does it right. I thought you were cooperating with the ScanCode team.

I believe you have a wrong understand of both the level of cooperation, and the way that ScanCode works. ScanCode is not able to map deprecated license IDs to non-deprecated license IDs. What it does is to associate (non-deprecated) license IDs to license texts it identifies. That is, given the license ID string "Nunit", ScanCode cannot tell you directly that the non-deprecated ID for that is "zlib-acknowledgement".

In your examples you're also comparing apples to oranges, as your first table is about declared licenses (that come without a license text), but the additional context is about detected licenses (that do not involve a deprecated license ID at all).

Additionally, there seems to be a display issue in the web-app report as every "Unprocessed Declared License" should always have a corresponding (processed) "Declared License".

@gubechto
Copy link
Author

gubechto commented Feb 12, 2025 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
spdx-utils About the SPDX utility library
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sschuberth @gubechto