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

Licenses declared as part of an SPDX file should be inherited by nested projects #3509

Open
sschuberth opened this issue Jan 19, 2021 · 2 comments
Labels
analyzer About the analyzer tool enhancement Issues that are considered to be enhancements to triage Issues that need triaging

Comments

@sschuberth
Copy link
Member

sschuberth commented Jan 19, 2021

When using a project.spdx.yml file to declare a license for a directory, that declared license should by default also apply to nested projects in that directory. Example: The SPDX file declares "MIT" for directory "./external/lib", then ORT should not complain about a nested "./external/lib/python/requirements.txt" "./external/lib/python/setup.py" to not have any license declared.

@sschuberth sschuberth added enhancement Issues that are considered to be enhancements analyzer About the analyzer tool labels Jan 19, 2021
@tsteenbe
Copy link
Member

@sschuberth you can't declare a license for python's requirements.txt so this is a bug in ORT. Licenses for Python can be declared in setup.py or setup.cfg. Recommend you file a separate ticket to fix ORT's requirements.txt handling.

@sschuberth
Copy link
Member Author

Then requirements.txt was just a badly chosen example; I could have used setup.py as well. The point is that in the SPDX case, which internally rather operates on a directory level than on a project level, what you usually want is to declare a directory, including all its contents, to be under a certain license. So ORT should not complain about a nested setup.py which does not declare a license, but inherit / amend the license declared via SPDX.

@sschuberth sschuberth added the to triage Issues that need triaging label May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer About the analyzer tool enhancement Issues that are considered to be enhancements to triage Issues that need triaging
Projects
None yet
Development

No branches or pull requests

2 participants