REUSE December 2020

reuse@lists.fsfe.org

2 participants
4 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

CodePen License
by Ashkar Dev 29 Dec '20

29 Dec '20

This website provides codes the public codes are MIT licensed, and MIT license gives permission to sublicense means adding my own license to the used codes, but they say these: 1- what does this mean from the terms (Public Pens you build on CodePen are MIT licensed <https://opensource.org/licenses/MIT>, meaning other people are free to use it for whatever they like as long as that is also MIT licensed.) 2- what does this mean from the licensing (Anyone can use the code you put on CodePen for whatever they wish – but if they do – that code also must have this same license. This is to encourage open sharing of code.) Terms page: https://blog.codepen.io/documentation/terms-of-service/ License page: https://blog.codepen.io/documentation/licensing/ If I use a public pen code in my project and modify it, they require that the modified code also must be MIT licensed?

1 0

reuse-tool version 0.12 available
by Max Mehl 17 Dec '20

17 Dec '20

Hi all, Just a quick heads-up: we've released the 0.12 branch of the REUSE helper tool. It contains a few interesting new features and fixes. Highlights contain more supported files names and types for the `addheader` subcommand, and a broad preset of different styles for copyright lines aside from the recommended "SPDX-FileCopyrightText". Feel free to read the changelog for all details: https://github.com/fsfe/reuse-tool/blob/master/CHANGELOG.md You can get the tool from PyPI, download the Docker images, build it from source, or get it via package managers [^1]. As always, issues and pull request are highly appreciated! Best, Max [^1]: https://github.com/fsfe/reuse-tool#install -- 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

1 0

In-depth look into how KDE adopted REUSE
by Max Mehl 15 Dec '20

15 Dec '20

Dear all, I hope this email finds you well. More and more communities and companies include the REUSE best practices into their policies. Just with the REUSE API there are currently 336 projects registered as compliant [^1]. At the FSFE, we wanted to have a closer look at how communities manage and experience the adoption process. Therefore, I am pleased to share an interview with Andreas Cord-Landwehr with you that we've published today. He drove the process of making the KDE frameworks REUSE compliant, with code that is partly older than some of the project's contributors. https://fsfe.org/news/2020/news-20201215-01.html He also shares a few interesting ideas about how the REUSE ecosystem could evolve. I would be thrilled to learn about your opinions on this, and generally whether you can relate to Andreas' experiences. Best, Max [^1]: https://api.reuse.software/projects -- 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

1 0

2024

2023

2022

2021

2020

2019

2018

REUSE December 2020