You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
While scanning ur_client_library the error
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.
The text was updated successfully, but these errors were encountered: