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.

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

Allow for custom non SPDX-expression licenses (including content) #3366

Open
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

HeyeOpenSource
Copy link

@HeyeOpenSource HeyeOpenSource commented Oct 22, 2024

Description

Implements support for custom licenses.
Should probably be reviewed by @wagoodman and / or @spiffcs.

Type of change

  • New feature (non-breaking change which adds functionality)

Checklist:

  • I have added unit tests that cover changed behavior
  • I have tested my code in common scenarios and confirmed there are no regressions
  • I have added comments to my code, particularly in hard-to-understand sections
  • I have run make test locally without receiving any failures
  • 'Validations' workflow returns no errors

HeyeOpenSource and others added 11 commits October 17, 2024 10:33
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
…available.

Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
…tion in order to avoid incompatibilities (and multiple instances of the same license).

Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>

# Conflicts:
#	internal/licenses/parser.go
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
@HeyeOpenSource HeyeOpenSource changed the title Allow for custom licenses (including content) Allow for custom non SPDX licenses (including content) Oct 23, 2024
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
…tic analysis.

Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
@github-actions github-actions bot added json-schema Changes the json schema and removed json-schema Changes the json schema labels Oct 23, 2024
This reverts commit beda1b6.

Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
This reverts commit 9b90378.

Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
Signed-off-by: HeyeOpenSource <opensource@heye-international.com>
@@ -29,6 +29,7 @@ type License struct {
Type license.Type
URLs []string `hash:"ignore"`
Locations file.LocationSet `hash:"ignore"`
Contents string `hash:"ignore"` // The optional binary contents of the license file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we add support for this we should make this configurable. It could be a simple on/off (collect or do not collect contents) but there is some argument for more options here. Specifically, when we can get the ID from contents and we have a high degree of confidence that it matches then including the contents is redundant / not necessary (one of multiple possible middle of the road options).

I think the default for this option should either be "off" or the middle of the road option.

Copy link
Author

@HeyeOpenSource HeyeOpenSource Oct 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My implementation only ever fills the Contents field if a non-empty file identified as potential license file (by name) exists and no SPDX-expression can be determined for it with the required confidence.
Otherwise the status quo implementation is retained.

Hence I would assume that the option as you describe it is currently "middle of the road" by default. 😉

Copy link
Author

@HeyeOpenSource HeyeOpenSource Oct 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would advocate for a later implementation of the configurability, as my current implementation mitigates the fact, that packages with an identified (but non-SPDX-expression-compatible) license file will be erroneously handled as unlicensed. (cf. #3412)

@HeyeOpenSource
Copy link
Author

The Validations workflow finally throws no more errors at me. 👍
cf. Validations #22

@HeyeOpenSource
Copy link
Author

HeyeOpenSource commented Oct 25, 2024

The implementation of this pull request mitigates the fact, that packages with an identified (but non-SPDX-compatible) license file will be erroneously handled as unlicensed. (cf. #3412)

@HeyeOpenSource HeyeOpenSource changed the title Allow for custom non SPDX licenses (including content) Allow for custom non SPDX-expression licenses (including content) Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
json-schema Changes the json schema
Projects
None yet
2 participants