On Tue, May 17 2022 at 10:25, Max Mehl wrote:
> ~ Thomas Gleixner [2022-05-16 20:59 +0200]:
>> There is also an argument to be made whether we really need to have SPDX
>> identifiers on trivial files:
>>
>> #include <someheader.h>
>> <EOF>
>>
>> Such files are not copyrightable by any means. So what's the value of
>> doubling the line count to add an SPDX identifier? Just to make nice
>> statistics?
>
> We agree that such files are not copyrightable. But where is the
> threshold? Lines of code? Creativity? Number of used functions? And how
> to embed this threshold in tooling? So instead of fuzzy exclusion of
> such files in tools like spdxcheck or REUSE, it makes sense to treat
> them as every other file with the cost of adding two comment lines.
>
> This clear-cut rule eases maintaining and growing the effort you and
> others did because developers would know exactly what to add to a new
> file (license + copyright) without requiring looking up the thresholds
> or a manual review by maintainers who can interpret them.
Seriously no. I'm outright refusing to add my copyright to a trivial
file with one or two includes or a silly comment like '/* empty because */.
There is nothing copyrightable there.
I'm not going to make myself a fool just to make tools happy, which can
figure out on their own whether there is reasonable content in the vast
majority of cases.
Also you need some exclude rules in any case. Why?
- How do you tell a tool that a file is generated, e.g. in the kernel
the default configuration files?
Yes, the file content depends on human input to the generator tool,
but I'm looking forward for the explanation how this is
copyrightable especially with multiple people updating this file
over time where some of the updates are just done by invoking the
generator tool itself.
- How do you tell a tool that a file contains licensing documentation?
Go and look what license scanners make out of all the various
license-rules.rst files.
- ....
Do all scanners have to grow heuristics for ignoring the content past
the topmost SPDX License identifier in certain files or for figuring
out what might be generated content?
You also might need to add information about binary blobs, which
obviously cannot be part of the binary blobs themself.
The exclude rules I added are lazy and mostly focussed on spdxcheck, but
I'm happy to make them more useful and let them carry information about
the nature of the exclude or morph them into a general scanner info
which also contains binary blob info and other helpful information. But
that needs a larger discussion about the format and rules for such a
file.
That said, I'm all for clear cut rules, but rules just for the rules
sake are almost as bad as no rules at all.
As always you have to apply common sense and look at the bigger picture
and come up with solutions which are practicable, enforcable and useful
for the larger eco-system.
Your goal of having SPDX ids and copyright notices in every file of a
project is honorable, but impractical for various reasons.
See above.
Aside of that you cannot replace a full blown license scanner by REUSE
even if your project is SPDX and Copyright notice clean at the top level
of a file. You still need to verify that there is no other information
in a 'clean' file which might be contradicting or supplemental. You
cannot add all of this functionality to REUSE or whatever.
Thanks,
tglx
