Closed silverhook closed 5 years ago
Further discussed here:
What could be useful is to come with a common approach to ignore certain files and/or qualify and classify certain files. Something like a "ignore"/"gitignore" file with a few extra thing such as facets/classification... I need this in ScanCode and this is needed for ClearlyDefined too and most likely by any tool.
Usage-wise, this means this could be:
@pombredanne, I disagree. This would make it way easy to work around the spec. The convenience it offers, is IMHO not worth the risk.
I think the way to go would be to get the user to at least consciously write a DEP-5 and declare that such files are CC0-1.0/Unlicense/whatever_waiver_or_DP_you_prefer. That way, the downstream can depend more on the info than guessing whether a file with no info is understood as “public domain” or the legal default of full copyright applies.
@mxmehl, @carmenbianca, can you please move the content from https://git.fsfe.org/reuse/reuse/issues/69 here? I assume FSFE still has some backup of the issues somewhere.
@mxmehl should have those. The current link to that page is https://git.fsfe.org/reuse/tool, but there are no issues there.
@silverhook re
I disagree. This would make it way easy to work around the spec. The convenience it offers, is IMHO not worth the risk.
I think you misunderstood what I meant by using a .gitignore-like file: I am NOT saying that files should be ignored!
Just that a file could be stored in a repo side-by-side with the code (like a .gitignore file is stored there) and list the paths stating what is the purpose of such path or file (build script, etc). So this would be a way for authors to provide a hint about the classification of their code.
@silverhook btw re
when it is commonly agreed that they are not a work of authorship and copyrightable?
I think that part will be really hard to agree on, so what I am saying instead is that it is better to provide a hint on the purpose of certain files and let the user decide if this is copyrightable or not. And if some file are considered CC0 or else, then this should be explicit alright, as you suggested. But then why reinvent something new with an extra DEP5 file? this could be best treated as any other file IMHO.
Just that a file could be stored in a repo side-by-side with the code (like a .gitignore file is stored there) and list the paths stating what is the purpose of such path or file (build script, etc).
I know that https://clearlydefined.io/ wants to do something like this. But for the sake of simplicity, @mxmehl and I kind of agreed that this is outside of the realm of REUSE. REUSE sets a very tangible goal, and we don't want to move the goalposts.
@pombredanne, I suspect you and me are of closer general understanding than it might seem…
But then why reinvent something new with an extra DEP5 file? this could be best treated as any other file IMHO.
I’m confused as to what you mean with reinventing the wheel with DEP5.
REUSE already excludes what is in .gitignore
, as those things don’t get pushed into the repo (how that could be abused is a separate topic).
The other way is to mass-declare a bunch of files with using DEP5 and its wildcard/globbing.
Perhaps you could illustrate with an example what kind of file you are looking for?
REUSE already excludes what is in .gitignore, as those things don’t get pushed into the repo (how that could be abused is a separate topic).
Technically the tool ignores everything that is ignored by Git. If you git add
a file that is in .gitignore
, the tool will pick up on the file ;) Formally that is a deviation from the spec, but I reckon it works as intended.
Do you want me to account for this edge case in the spec?
The tutorial explains when and how to mark such files properly, e.g. under CC0-1.0
Often a code repository will include files that are not a work of authorship – e.g.
.git/
, some build scripts, CI/CD scripts, setting files etc., many of which machine generated.How should we handle these files, when it is commonly agreed that they are not a work of authorship and copyrightable?
OTOH some options, to start the discussion:
reuse
linter