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

Dual License #56

Open
vkrizan opened this issue Apr 9, 2024 · 7 comments
Open

Dual License #56

vkrizan opened this issue Apr 9, 2024 · 7 comments
Assignees

Comments

@vkrizan
Copy link

vkrizan commented Apr 9, 2024

Hello,

I've noticed that this project seems to be dual licensed, however it is not evident from the project's LICENSE file nor from Readme.

The original code is under LGPL-3.0 license, however the new CVSSv4 is under BSD-2-Clause license.

This might have an impact when packaging this to Fedora Project.

Thank you for helping with this.

EDIT: Pypi also has incomplete information wrt license https://pypi.org/project/cvss/

@vkrizan
Copy link
Author

vkrizan commented Apr 9, 2024

Note to self: This might be a case of multiple licensing: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios

@skontar
Copy link
Collaborator

skontar commented Apr 9, 2024

So, the CVSSv4 code is a port from https://github.com/RedHatProductSecurity/cvss-v4-calculator which is BSD-2-Clause. I have actually no idea how to do this correctly.

@vkrizan
Copy link
Author

vkrizan commented Apr 9, 2024

Me neither. Fedora packaging guidelines suggests this for multiple licensing:

If your package contains files which are under multiple, distinct, and independent licenses, then the spec must reflect this by using "and" as a separator. Fedora maintainers are highly encouraged to avoid this scenario whenever reasonably possible, by dividing files into subpackages (subpackages can each have their own License: field).

Pypi might have different guideline.

Separation into subpackages would not be possible as the Python module is directly tied through __init__.py.

@skontar
Copy link
Collaborator

skontar commented Apr 9, 2024

I am thinking if we could be able to dual-license the original code and change it here to be just one license through whole code base.

@vkrizan
Copy link
Author

vkrizan commented Apr 9, 2024

Dual license might have similar challenges.

Maybe this might help: https://peps.python.org/pep-0639/ + https://peps.python.org/pep-0639/appendix-user-scenarios/#my-package-includes-other-code-under-different-licenses

I think that either dual or multiple licenses should be mentioned in Readme and have LICENSE files provided.

@skontar
Copy link
Collaborator

skontar commented Apr 9, 2024

I thought if we dual license the original Javascript code, we could change the code in this codebase to be consistent. But I guess I need to talk to some legal people.

@jobselko jobselko self-assigned this May 9, 2024
@jobselko
Copy link
Collaborator

jobselko commented May 9, 2024

I will look into it, discussed with @skontar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants