REUSE September 2020

reuse@lists.fsfe.org

2 participants
2 discussions

REUSE.yaml
by Max Mehl 22 Jun '21

22 Jun '21

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 directory. 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 tools. 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/*: SPDX-FileCopyrightText: - 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/*: license: 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. Best, Max [^1]: See the one of reuse-tool here as an example: https://github.com/fsfe/reuse-tool/blob/master/.reuse/dep5 -- 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

6 14

SPDX/REUSE Updates in KDE Land
by Andreas Cord-Landwehr 21 Sep '20

21 Sep '20

Hi, I would like to give a short update about what currently is happening in KDE regarding SPDX markers and REUSE. -- If this is not the right list, please tell me; but right now I assume that you are interested :) In KDE, with 24 years of source code files in our repositories, we have collected quite a zoo of different license headers over the years that are supposed to be cleaned up. Moreover, one product that we offer explicitly for usage by developers outside the KDE community are the KDE frameworks, which is a set of libraries on top of Qt that shall simplify the life of every Qt developer (all licensed as LGPL, contrary to the most other parts of KDE which are mostly GPL). During the last months we converted all of our KDE frameworks to REUSE compatible license information and copyright statements (at least those files that contain copyright information for now). A short status update is here: https://cordlandwehr.wordpress.com/2020/08/14/spdx-for-kf5-kf6-status-updat… During this conversion, I worked on two tools that might be also interested for people outside of KDE: 1. License-Digger: This small tool was developed to do automatic conversions of code bases to REUSE compatible license statements. Note that the approach is different to the Linux Kernel, which used two existing license detection tools, compared both results, generated a conversion table and had a script that applied these changes. My approach is to trust more in the (very intense unit tested) tool and do a direct conversion but be much more restrictive about how licenses are detected: https://invent.kde.org/sdk/licensedigger 2. Build-System-Tooling for Compatibility Testing: This is still an early version, but the idea is automatically generated unit tests for checking compatibility with outbound licenses of libraries/executables. Actually, is is meant as regressions testing that added source files do not prevent the legal distribution of a binary artifact with a specific outbound license (internally it runs "reuse spdx" and uses the generated BOM file): https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/21 Cheers, Andreas

3 4

2024

2023

2022

2021

2020

2019

2018

REUSE September 2020