[Reuse] How to handle non-compliant files in tarballs?
Matija Šuklje
matija at suklje.name
Thu May 16 12:43:37 UTC 2019
TL;DR:
• for source code VCS – REUSE already works as intended
• for source code tarballs – reuse already works as intended, but
we might want to mention that they should double-check if the
tarballs have all the needed info in it as well
• for packages of any other sort – outside the scope of REUSE
Die 18. 04. 19 et hora 18:38 Max Mehl scripsit:
> We currently have the problem that the REUSE tool which you can
> download from pypi [^1] actually is not REUSE compliant
> although the source code itself is. This might also be true for
> many other projects who distribute their releases through
> similar services.
>
> The reason is that by compilation files are being created, e.g.
> binaries or documentation, which do not carry license
> information nor are accompanied with corresponding .license
> files. How shall we deal with those?
This will be a common and probably inevitable problem with all
packaging and building.
In general, I would say that the biggest question is to what do we
want the REUSE spec to apply to.
I think we aleardy established, that its goal is to apply to
source code. So binary packages are not a target.
I don’t remember REUSE being limited to just VCS repositories.
Sure, the “REUSE compliant” badge would show on the repo, but in
the real world, that badge would likely be tied to a CI/CD anyway,
so it would be dependent on the repo.
For source tarballs, no-one is preventing anyone to add extra
REUSE info when they add extra files. Maybe we should just put it
in the FAQ that if they change the tarball, they need to double-
check if they need to update the info required by REUSE.
For other packages (source-ish, or binary), one could implement
hooks into the build system to look at the REUSE-compliant source
code that they are building and then generating the needed extra
info for the output build.
Such build tool would be a wet dream for many compliance officer,
but I think it’s far from what REUSE needs to concentrate on right
now. What REUSE wants to ensure is that the source code – which is
the input for everything else – carries all the needed info. Then
others – SPDX, others tools – can build on top of that. In fact, I
would think this is exactly where REUSE stops and SPDX takes over.
We are not trying to duplicate work here.
I like the link to (ultimate upstream) source code repo idea in
general for different reasons. But it will carry the same problem
as the “attribution through VCS” in SFLC best practices – namely,
that history teaches us that the repo URL is likely to change in
the future. So that’s not going to be a reliable source in the
long term. (still useful info in the short term though)
cheers,
Matija
--
gsm: +386 41 849 552
www: http://matija.suklje.name
xmpp: matija.suklje at gabbler.org
sip: matija_suklje at ippi.fr
More information about the Reuse
mailing list