Max Mehl

I renamed this issue to track the effort of adding the functionality that we've had since #416 also for `addheader`. Currently there is no sanity check at all.

Phew, in order to make that work we'd need 1. A list of files/extensions that defines these optional syntaxes that can, but usually are not edited directly 2. A flag...

Hm, but then it would also be possible to enforce comments e.g. in JSON files which would break their syntax. I am afraid that this could lead to unwanted results...

Interesting thoughts! One way to bring this issue on SPDX' table could be to write an email to the spdx-tech mailing list (https://lists.spdx.org/g/spdx-tech) and perhaps have this as a topic...

In today's maintainers call, we agreed that we want to have this in the next release. What we agreed on: * The focus shall be on `lint` first. Perhaps in...

We had another meeting in which we've discussed the remaining questions and also the relation to other topics linked with the `lint` subcommand. The decisions we've made: * The JSON...

> I could add a flag along the lines of reuse --only-header lint, in which case only the header comment would be parsed for SPDX info, but this would break...

TBH I am not sure whether we want to burden ourselves with maintaining this logic. The three of us can't think of more examples for when this might go wrong,...

Thanks for the suggestion. I see these issues: * The proposed SPDX tags – and license identifiers in particular – frees to from the burden to write these license notices....

@TechnologyClassroom Thank you for your suggestion. However, I'd prefer not to. We follow the latest SPDX license identifiers and expressions – which is totally crucial – but I would not...