Hi Arnout,

thank you for your assessment.

The LICENSES/ directory basically replaces THIRDPARTY.txt. It has the same contents, but better organized (one file per license rather than all licenses put together).

Are there tools to automatically determine the (nested) licenses based on files like * pyproject.toml * requirements.txt * package.json and download them to the LICENSES directory?

What I found so far is the download option of the reuse tool for individual files: https://git.fsfe.org/reuse/tool#cli

download --- Download the specified license into the LICENSES/ directory.

If no such tool exists, the way to go might be to first generate THIRDPARTY files with

https://github.com/ftpsolutions/python-third-party-license-file-generator (python) https://www.npmjs.com/package/generate-license-file (JavaScript)

and then split and copy the licenses to the LICENSES folder?

The LICENSES folder gives an overview of the unique licenses. The THIRDPARTY file gives an overview of the libraries (and links them to their licenses).

Sunny regards,

Stefan

-----Original Message----- From: Arnout Vandecappelle arnout@mind.be Sent: Donnerstag, 11. Januar 2024 10:11 To: Eidelloth, Stefan Stefan.Eidelloth@isi.fraunhofer.de; reuse@lists.fsfe.org Subject: Re: [REUSE] Relation of REUSE Compliance to THIRDPARTY license information file

Hi Stefan,

On 10/01/2024 17:38, Eidelloth, Stefan wrote:

Hello,

I would like to use REUSE Compliance and generate a THIRDPARTY.txt license information file as

• used here:

https://github.com/SAP/openui5/blob/master/THIRDPARTY.txt https://github.com/SAP/openui5/blob/master/THIRDPARTY.txt

• discussed here

https://softwareengineering.stackexchange.com/questions/234511/what-is -the-best-practice-for-arranging-third-party-library-licenses-paperwor k https://softwareengineering.stackexchange.com/questions/234511/what-i s-the-best-practice-for-arranging-third-party-library-licenses-paperwo rk

Back then, there was no standard way of doing things that you could comply with. Now we have the REUSE specification, which formalizes practices that already existed elsewhere.

Unfortunately, a lot of existing software doesn't comply with the REUSE specification.

• could be generated with

https://github.com/ftpsolutions/python-third-party-license-file-genera tor https://github.com/ftpsolutions/python-third-party-license-file-gener ator

That's a PIP-specific tool so won't help that much in general. If your vendored dependencies are not REUSE-compliant, it will anyway take a lot of manual figuring out to make the whole thing REUSE-compliant.

I saw that the reuse project itself does not use a THIRDPARTY file (also sometimes called LICENSE-3RD-PARTY.txt etc.):

https://github.com/fsfe/reuse-tool https://github.com/fsfe/reuse-tool

https://github.com/fsfe/reuse-example https://github.com/fsfe/reuse-example

=> Should I use a THIRDPARTY.txt file in addition to the LICENSES folder of REUSE Compliance?

Or do I not need such a file if my project is already REUSE compliant?

The LICENSES/ directory basically replaces THIRDPARTY.txt. It has the same contents, but better organized (one file per license rather than all licenses put together).

It can be useful to add a top-level LICENSE.md or COPYRIGHT.md or something that mentions the main license as well as summarizing the third party licenses (referring to the LICENSES/ directory for the full text of each license).

I wish there were a format that is both human-readable and machine readable for that "summary file", but alas, SPDX is not human readable :-).

Regards, Arnout

Sunny regards

Stefan

---

REUSE mailing list REUSE@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse

This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct

Hi,

Am 11.01.24 um 14:29 schrieb Carmen Bianca BAKKER:

For projects that vendor 3rd-party code, for which REUSE isn't incredibly well-suited, that may or may not be the case. Specifically, REUSE doesn't convey some of the metadata contained within that file, chiefly the name of the component.

While I am looking forward to the upcoming features you are working on, I would not underestimate the already existing value of REUSE here because of the "Comment:" key. We decided to use REUSE for our projects also because of this as a side effect.

As you can add additional stanzas when using multiple licenses and/or third-party components in the same project, this is good enough for nearly all of our projects by pointing to the dep5, especially in combination with highlighting top contributions/third parties for the sake of politeness.

A THIRDPARTY.md is no better and the effort to maintain it in parallel not worth the effort (IMHO).

SAP's OpenUI5 .reuse/dep5 file[1] is a good real-world example of how to do so with many third-party libraries and good usage of "Comment:" (even though they generate it with additional tooling).

[1] https://github.com/SAP/openui5/blob/26f313e55bc88229623d8437f2a85855f9aadd65/.reuse/dep5#L297-L300