Geyer-Blaumeiser Lars (IOC/PDL4) Lars.Geyer-Blaumeiser at bosch.io
Tue Jul 21 06:44:03 UTC 2020

Hello Max et al.,

I like the idea, but just a thought. There is the new yaml format in SPDX 2.2, and we are thinking around using this format to mark certain folders as open source component, so identifying components in a repository is eased for open source compliance management. Might be worth to look into the standard whether this is also suitable for your proposed use case before deciding on a format. What do you think?

Mit freundlichen Grüßen / Best regards

Dr. Lars Geyer-Blaumeiser

Project Delivery - Open Source Services (IOC/PDL4)
Bosch.IO GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch.io
Mobil +49 172 4815079 | lars.geyer-blaumeiser at bosch.io

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

Von: REUSE <reuse-bounces at lists.fsfe.org> im Auftrag von Max Mehl <max.mehl at fsfe.org>
Gesendet: Montag, 20. Juli 2020 17:51:24
Betreff: [REUSE] REUSE.yaml

Hi all,

I am starting a new thread, summarising a wild idea we've had when
discussing how to combine the different ideas and expectations that have
been raised in the threads regarding folder.license files and the
deprecation of the DEP5 file.

Our suggestion would be to implement a new file: REUSE.yaml.

# Basic concept

The purpose would be quite similar to what we already do with DEP5 files
[^1]: communicate copyright/licensing information for a whole
(sub)directory, or also just a certain pattern, e.g. all .png files in a

The first downside of DEP5 is that the tags are different from the
normal SPDX/REUSE tags, and that it requires some other meta information
out of REUSE's scope. The second downside is that the DEP5 file has to
be stored in the .reuse/ folder, quite unintuitive and far away from the
actual files.

As the name suggests, REUSE.yaml would follow the YAML syntax which is
easy to read and write for humans, but it also pretty easy to parse in

Another difference would be that there could be multiple REUSE.yaml
files. Each one could only define the directory it is stored in, or also
subdirectories or certain file patterns. So it can also serve as an
alternative to the suggested folder.license files.

This would make things easier for devs and reusers alike: given that a
repo contains a directory with hundreds of binary files (e.g. images),
the maintainers could create a REUSE.yaml file in it. This way,
copyright and licensing information is close by, but the maintainers
would not have to create $file.license files for every single image, or
store the bulk-information in a far-away file.

# Syntax

Now, if we went that route, we would need a rather fool-proof and easy
way how to mark the REUSE information for a directory, subdirectory, or
pattern. Here are four variants how to do that in YAML, but only one
should be mandated by REUSE in the end:

1. Short Array:
- src/*:
    SPDX-FileCopyrightText: [ "2020 me", "© 2017 you" ]
    SPDX-License-Identifier: MIT

2. Short List:
- src/*:
      - 2020 Me
      - © 2017 You
    SPDX-License-Identifier: MIT

3. Short String:
- src/*: |
    SPDX-FileCopyrightText: 2020 Me
SPDX-FileCopyrightText: © 2017 You
    SPDX-License-Identifier: MIT

4. Long:
- src/*:
      SPDX-License-Identifier: MIT
    copyright: |
      SPDX-FileCopyrightText: 2020 Me
      SPDX-FileCopyrightText: © 2017 You

Please help us here: what could possibly go wrong with any of these
variants? Is there tooling for which you know that it would misbehave?
What would make most sense to you as a user?

Also, in general, I would be pleased to learn what you think about a
REUSE.yaml file that would be a preferred way how to bulk-license files.


[^1]: See the one of reuse-tool here as an example:

Max Mehl - Programme Manager - Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl | @mxmehl
Become a supporter of software freedom:  https://fsfe.org/join
REUSE mailing list
REUSE at lists.fsfe.org

This mailing list is covered by the FSFE's Code of Conduct. All
participants are kindly asked to be excellent to each other:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/reuse/attachments/20200721/ee323237/attachment.htm>

More information about the REUSE mailing list