-
-
Notifications
You must be signed in to change notification settings - Fork 550
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
RFC: Primary License. Create and maintain a primary declared_license_expression field. #2065
Comments
One key question is whether we try to capture this idea with parends or a multi-level approach where we call out the "summary" vs "detail" license data in separate fields - i.e. collect the base data and then optionally report a summary. |
Alternative implementation idea: Proposed new relationship operator in license expression: PLUS. Everything to the left of the PLUS is a "core" (aka "primary") license expression, typically found in a root level file in a project (such as LICENSE, NOTICE, README, etc.) or a package manifest or similar. Everything to the right of the PLUS belongs to the group of "other" licenses that can be found in the lower level files of a software package. Such an enhancement must of course be coordinated with updates to the license expression libraries. (tickets needed) For compatibility purposes the PLUS operator can be simply translated to an AND operator when exporting information to another application. (a bit of analysis needed here) How does the PLUS get into the expression? scancode-toolkit should be able to figure it out when it scans a project.
|
See also aboutcode-org/license-expression#50 |
Return LicenseDetection in packages and rename license attribute names. Reference: #2065 Signed-off-by: Ayan Sinha Mahapatra <[email protected]>
pending resolution of some other related issues to complete this |
So we have file level license field name changes here in this commit and all the package level field name changes are here in this commit. But the later one is WIP as there are a lot of other related changes and improvements that I'm working on. |
Return LicenseDetection in packages and rename license attribute names. Reference: #2065 Signed-off-by: Ayan Sinha Mahapatra <[email protected]>
* Rename `declared_license` to `extracted_license_statement` * Add `license_detections` * Rename `license_expressions` to `declared_license_expression` * Add `detected_license_expression_spdx` Also add related functions to populate these fields after package parsing. Reference: #2065 Signed-off-by: Ayan Sinha Mahapatra <[email protected]>
For package licenses, we have a PR in progress to use "declared_license_expression" and "declared_license_expression_spdx", but for Debian license (and the long list we get from copyright files) have a specific problem: primary vs. other or "secondary licenses"
After a chat, we agreed to use |
This is not yet merged but completed in the #2961 PR |
- Add `other_license_expression` attribute - Add `other_license_expression_spdx` attribute - Add `other_license_detections` attribute For debian copyright files `declared_license_expression` is set to the primary license, if present, and other licenses are set to the `other_license_expression` introduced here. Reference: #2065 Signed-off-by: Ayan Sinha Mahapatra <[email protected]>
- Add `other_license_expression` attribute - Add `other_license_expression_spdx` attribute - Add `other_license_detections` attribute For debian copyright files `declared_license_expression` is set to the primary license, if present, and other licenses are set to the `other_license_expression` introduced here. Reference: #2065 Signed-off-by: Ayan Sinha Mahapatra <[email protected]>
We have this merged, closing! |
Note that package.declared_license can be any data structure. It has been confusing to several because "declared license" is used differently by other orgs, such as SPDX.
Rename to: extracted_license_statement
The original text and data structure in a software package manifest that indicates the applicable license. This value is not necessarily a key to any license list, and it is not validated.
package.license_expression is A single detected license expression using our keys.
Rename to: package.declared_license_expression
This is the primary license expression as determined from the declaration(s) of the authors of the package.
create a parallel field called
package.declared_license_expression_spdx
where the expression will use SPDX identifiers.
We should also update the license field names on the Resource model to reflect the changes we are making to the license field names on the Package model. This would mean that:
Resource.licenses should be renamed to Resource.license_detections
Resource.license_expressions should be renamed Resource.detected_license_expressions
Resource.detected_license_expressions_spdx should be added. This field contains the the same data as Resource.detected_license_expressions but with SPDX identifiers.
There is also a new codebase-level field we should add named
license_references
. This would be a list of unique license records detected during a scan.Older comments here:
It may be an good idea to keep track of the primary license for a package.
For instance,
a package is under
mit
but contain test/not-deployed code which is under gpl-2.0.It may be a good idea to report this package's primary license as
mit
instead ofmit AND gpl-2.0
OR better,
mit AND (gpl-2.0)
so that users know the primary license is mit and the secondary is gpl-2.0 (meaning code that don't affect the primary license).Another example,
think of a debian copyright file:
adwaita-icon-theme/copyright
As we can see from the above example, we should capture the primary license and report as, for instance,
CC-BY-SA-3.0 or LGPL-3 (GPL-unspecified AND GFDL-1.2+ or CC-BY-SA-3.0-Unported or CC-BY-SA-2.0-IT, and CC-BY-3.0-US AND CC-BY-SA-3.0-Unported)
instead of reported all theso that user get easily identify which is the primary license for the package.
The text was updated successfully, but these errors were encountered: