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
Say I am using a Meson subproject with a wrap file gotten from Meson's WrapDB. reuse requires me to add licensing and copyright info about that file.
What isn't clear is how to ascertain that information. Many projects that generate files don't explicitly say the output of the project is licensed and copyrighted in some form or fashion.
Ideally it would be nice to just have a way for reuse to ignore these files since getting the info out of the project maintainers is not always easy nor is it explicit as is the case with the GNU Compiler Collection for instance.
The text was updated successfully, but these errors were encountered:
I am not sure whether I entirely understood your proposal, so please excuse me if I got it wrong.
If the tool ignored these files and they were copyrightable and under a certain license, this would basically invalidate the whole idea of REUSE. The tool cannot know the licensing and copyright status of a file, no matter whether it's created by a human, a machine, or both. I could write a one-line tool that downloads a file either under GPL-3.0-only or 0BSD.
It's up to the REUSE adopter to clarify the licensing. Which often is not trivial, I absolutely understand that. But having reuse lint warn you about a newly created and unannotated file is excactly the idea: developers shall be aware about the licensing and copyrights they add to their repo, and communicate this transparently.
Say I am using a Meson subproject with a wrap file gotten from Meson's WrapDB.
reuse
requires me to add licensing and copyright info about that file.What isn't clear is how to ascertain that information. Many projects that generate files don't explicitly say the output of the project is licensed and copyrighted in some form or fashion.
Ideally it would be nice to just have a way for reuse to ignore these files since getting the info out of the project maintainers is not always easy nor is it explicit as is the case with the GNU Compiler Collection for instance.
The text was updated successfully, but these errors were encountered: