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

Failure: There must be at most one license tag without source-files #21

Closed
fmauch opened this issue Jul 12, 2023 · 2 comments
Closed

Failure: There must be at most one license tag without source-files #21

fmauch opened this issue Jul 12, 2023 · 2 comments

Comments

@fmauch
Copy link
Contributor

fmauch commented Jul 12, 2023

While scanning ur_client_library the error

LicenseTagExistsCheck
 FAILURE PackageException: There must be at most one license tag without source-files.
LicenseTagIsInSpdxListCheck
 SUCCESS All license tags are in SPDX list of licenses.
LicenseTextExistsCheck
 SUCCESS All license tags have a valid license text file.
LicensesInCodeCheck
 FAILURE AssertionError: License tag must have source-files attribute.

was raised. Does ros_license_toolkit already enforce the suggestion from ros-infrastructure/rep#347? I'm not saying this is necessarily bad, I was just surprised. And if things are implemented as suggested in ros-infrastructure/rep#347 it would probably be good to tread package.xml versions below 4 differently.

Also, enforcing SPDX identifiers might be causing trouble for some packages. Theoretically, packages (or parts from packages) could be released under custom licenses having no official SPDX identifier.


Issue edited, as I was too stupid to read the output correctly yesterday.

@ct2034
Copy link
Member

ct2034 commented Jul 14, 2023

Yes, currently we already enforce the changes. I was hoping that the pr was merged by the time this tool was finished.
The enforcing of SPDX is a thing that should really be turned into a warning. But before I can do that, I need to support warnings in the tool in general.

@fmauch
Copy link
Contributor Author

fmauch commented Jul 18, 2023

That clarifies things for me, so I would be ok with closing this. However it might be good to keep this as a reference for other users / include a notice about this / a link to the REP-149 PR in the README.

@ct2034 ct2034 closed this as completed Jul 20, 2023
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

2 participants