Skip to content

Add HPND-Markus-Kuhn and LicenseRef-scancode-efsl-2.0 #101

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

Merged
willebra merged 2 commits into from
Mar 4, 2026
Merged

Add HPND-Markus-Kuhn and LicenseRef-scancode-efsl-2.0 #101

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ef06ee6
Add HPND-Markus-Kuhn
willebra Mar 2, 2026
e860c6d
Add LicenseRef-scancode-efsl-2.0
willebra Mar 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions license-classifications.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1502,6 +1502,11 @@ categorizations:
- "property:include-in-notice-file"
- "include-in-notice-file"

# https://spdx.org/licenses/HPND-Markus-Kuhn.html
- id: "HPND-Markus-Kuhn"
categories:
- "permissive"
Copy link
Copy Markdown
Member

@sschuberth sschuberth Mar 4, 2026

Choose a reason for hiding this comment

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

This matches https://scancode-licensedb.aboutcode.org/markus-kuhn-license.html 👍🏻


# https://spdx.org/licenses/HPND-sell-variant.html
- id: "HPND-sell-variant"
categories:
Expand Down Expand Up @@ -2905,6 +2910,14 @@ categorizations:
- "property:include-in-notice-file"
- "include-in-notice-file"

# https://scancode-licensedb.aboutcode.org/efsl-2.0.html
- id: "LicenseRef-scancode-efsl-2.0"
categories:
- "proprietary-free"
Copy link
Copy Markdown
Member

@sschuberth sschuberth Mar 4, 2026

Choose a reason for hiding this comment

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

This matches https://scancode-licensedb.aboutcode.org/efsl-2.0.html 👍🏻

- "property:include-in-notice-file"
- "include-in-notice-file"
- "property:no-modifications"
Copy link
Copy Markdown
Member

@sschuberth sschuberth Mar 4, 2026

Choose a reason for hiding this comment

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

Is this really correct? The license says "you are granted the right to create modifications", and the further restrictions only seem to apply to specifications or standards:

NOTWITHSTANDING THE FOREGOING, the creation or publication of derivative works of the Document or portions of the Document for use as a specification or standard is expressly prohibited.

Copy link
Copy Markdown
Member Author

@willebra willebra Mar 4, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

So the logic here is that we catch the most onerous/limiting term in the license into the classification. The license has a term that prohibits modifications in some situations, so that should be recorded. It is not unusual that these packages do carry the actual specifications. Also the license text defines Document as:

By using the file or document that incorporates this License (the "Document"), you (the licensee) agree

So the prohibition could equally apply to some code. Regardless, we do not usually make distinctions between the types of content. If any content that could come with the license, may not be modified, then the "property:no-modifications" is/should be used.

There is some wiggle room here, we also have "modification-related-obligations", but that is normally used for (otherwise) open source licenses, which have obligations that relate to modifications that are more onerous than just marking of modifications.

In this particular case, this is a proprietary-free license, so it will be raised as a rule violation in Double Open Compliance in default cases anyhow, which in principle gives some further wiggle room. But I think this is quite clear.

Copy link
Copy Markdown
Member

@sschuberth sschuberth Mar 4, 2026

Choose a reason for hiding this comment

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

So the logic here is that we catch the most onerous/limiting term in the license into the classification.

Ok, so we're being conservative here, makes sense.

If any content that could come with the license, may not be modified, then the "property:no-modifications" is/should be used.

But isn't it so that the question of modifications is tied to the use-case, not to the (code) content? I.e. it does not matter how you modify the code, but if you use your modifications as part of standards or specifications (in contrast to distributing the modified software otherwise), then you're not allow to to that.

Anyway, as the answer to that question is unrelated to the classification outcome because (as mentioned above) we use the most limiting term as the basis, I'll approve.


- id: "LicenseRef-scancode-ekioh"
categories:
- "permissive"
Expand Down