REUSE October 2020

reuse@lists.fsfe.org

3 participants
3 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

How to comply to FSF Free Software Directory?
by Rijk Ravestein 20 Oct '20

20 Oct '20

Hi, I made all projects at https://gitlab.com/savapage REUSE compliant. As I understood, the COPYING file in the root directory is not needed anymore, because it is replaced by the /LICENSES directory. Also, the LICENSE.spdx file contains "PackageLicenseDeclared: AGPL-3.0-or-later". Therefore I removed the COPYING file from each project. Now, the admin of the https://directory.fsf.org who is evaluating SavaPage submission, states: "1. please create a text file named COPYING inside the root of each module, fill it with an integral copy of the license under which its shipped. The file must contain only a license, unaltered;" Above that ... "2. please ensure all hidden files are under the same license of the package and if not change the headers; 3. please ensure that /LICENSES/ contains only free software licenses and only the licenses used in the module;" Since I made sure that all projects passed the "reuse lint" test, I am in doubt how to (additionally?) comply to the FSF Free Software Directory requirements. What is best practice? -- Kind regards, Rijk Ravestein, Technical Lead https://www.savapage.org

2 1

Handling of template licenses (think BSD, MIT)
by Kai Köhne 08 Oct '20

08 Oct '20

Hi, I'm currently evaluating if we can adapt Reuse also for the Qt Project (qt.io), but want to understand Reuse better before proposing it to the whole project. Is there some best practice to handle template licenses like BSD-3-clause, that have parts that is more often than not adapted by individual authors? https://spdx.org/licenses/BSD-3-Clause.html The red parts mark text snippets that are often adapted, but still allow the whole license to be qualified as BSD-3-clause. So while the conditions of the BSD-3-clause are obviously the same, it seems to me that each and every of these variants create a slightly different license, and I'm not sure it's ok to just ignore these variants - especially if they are not just about an added comma, or the way paragraphs are enumerated, but about e.g. company names instead of 'COPYRIGHT HOLDERS AND CONTRIBUTORS'. Is there any common practice to handle this? I could think of A) Creating variants like LicenseRef-BSD-3-Clause-xxx.txt that exactly match the original text. B) Keeping the original text in the source files, and have a SPDX-LicenseIdentifier: BSD-3-clause line in addition. C) Just ignoring the 'data loss' IMO A) arguably defeats the purpose of the Reuse standard. B) preserves all information, but then consumers might still need to parse the source files ... Does Reuse have any recommendations regarding this? Thanks! Kai -- Kai Köhne, Director R&D | The Qt Company The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

2 1

2024

2023

2022

2021

2020

2019

2018

REUSE October 2020