[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