Fix SPDX FileCopyrightText for .xcf file

[ferdnyc]

Presumably it was auto-extracted (by reuse?), but the usbview.spdx file contained a corrupted FileCopyrightText string for the usbview_logo.xcf file, with binary line-noise embedded into the field and some unbalanced closing markup at the end. Stripped all that out.

[gregkh]

The .spdx file is auto-generated by the reuse tool, we don't go and modify it by hand. So any changes done here would be overwritten the next time we update the .spdx file.

I'll look into what reuse is doing here, and the file is old, maybe newer versions can handle this properly. I'll leave this open until I figure that out, thanks for reporting it!

[ferdnyc]

The .spdx file is auto-generated by the reuse tool, we don't go and modify it by hand. So any changes done here would be overwritten the next time we update the .spdx file.

I'll look into what reuse is doing here, and the file is old, maybe newer versions can handle this properly. I'll leave this open until I figure that out, thanks for reporting it!

My guess is, reuse just doesn't support .xcf files (and never will), so it's doing the equivalent of a grep -a -i copyright usbview_logo.xcf and grabbing the first match it finds.

(Which would, in fact, be...)

$ grep -a -i copyright usbview_logo.xcf
[...]
                    ~��>�U����U>�U��q���UU*�8�8	�q�q�qƍ��8�8	�U8��Uq�U������+�8�����U���8���U�8�8�UUƍU������8���8�����U������8��UU~�vS;)�Copyright (C) 1999-2012 ...�!?�     "
 

�%$����#����*�gimp-text-layer�(markup "<markup><span size=\"12288\"><span font=\"Bitter\">Copyright (C) 1999-2012\nGreg Kroah-Hartman &lt;greg@kroah.com&gt;</span></span></markup>")

The way to give reuse usable copyright and license metadata for that file would be to create either a usbview_logo.xcf.license file containing SPDX-FileCopyrightText: and SPDX-License-Identifier: strings, or encoding those values into a REUSE.toml file (which replaced the .reuse/dep5 file a few releases ago).

Then, reuse should use that data when generating the .spdx file, instead of digging around inside the .xcf binary blob it has no idea how to parse.

(The REUSE.toml format would be... (as documented in reuse-convert-dep5(1), and probably other places)

[[annotations]]
path = "usbview_logo.xcf"
precedence = "override"
SPDX-FileCopyrightText = "(...copyright statement...)"
SPDX-License-Identifier = "(SPDX-license-expression)"

[ferdnyc]

REUSE.toml can also host a header with general package metadata, which is probably also of use in generating .spdx files:

version = 1
SPDX-PackageName = "Some project"
SPDX-PackageSupplier = "Jane Doe"
SPDX-PackageDownloadLocation = "https://example.com/"
SPDX-PackageComment = "Some rights reserved"

[ferdnyc]

...Needless to say, if the .spdx file is being treated as a generated file, rules for generating it should probably also be added to the Makefile.am.

Since, right now, there's nothing in the repo — other than some statements at the top of the .spdx file itself — to indicate that the file is generated, how, or by what. And there's definitely no process, automated or manual, that can be used to generate the file anew.

(Edit: And now that I'm looking at it, the .spdx file contains an SHA1 FileChecksum: for each file in the repo, so really it needs to be regenerated after every commit.)

[gregkh]

Yes, the .spdx file needs to be generated all the time, but really, I only do it when a release happens as that's the only important time it is needed.

I'll be moving this to use meson instead of autoutils "soon" like was done for usbutils and when that happens, I'll add the same .spdx generation like was done there.

[ferdnyc]

I'll be moving this to use meson instead of autoutils "soon"

Thank f*ck! \o/ (No, I'm not biased at all. ...Actually, I'm personally more comfortable/familiar with CMake, but Meson is great. Certainly better than autotools. Then again, two rusty nails shoved in a potato...)

[ferdnyc]

Yes, the .spdx file needs to be generated all the time, but really, I only do it when a release happens as that's the only important time it is needed.

It strikes me that maybe the .spdx file can be treated more like the (departing) compiled configure script: it gets generated for release tarballs, but otherwise doesn't live in the repo?

(If it's not accurate to the current state, seems like there's little point, since git is ultimately the authority on file identity for the checked-in code.)

[gregkh]

Thanks for the discussion, I'll take this for now and hopefully notice when/if it gets auto-regenerated by reuse in the future.

And when configure goes away, we'll still need to generate this file somehow, in an automated way, I'll ask the reuse people about it...