- REUSE - FSFE Mailinglists

REUSE badge for non-default branch of a git repository
by Peter Moser 29 Apr '21

29 Apr '21

Hi all, I have started to use the REUSE API for some projects to show the badge in the README.md file. See https://github.com/noi-techpark/webcomp-mountain-area for example The problem now is, that currently I have the .reuse and LICENSES folder only on our "development" branch. https://github.com/noi-techpark/webcomp-mountain-area/tree/development On my local machine "reuse lint" gives green light for REUSE compliance, but the badge shows non-compliant, because it seems to always check the main branch of each registered repository. Is there a possibility to automatically check the current branch? Cheers, Peter -- Digital Technologies ICT Peter Moser T +39 0471 066 672 p.moser(a)noi.bz.it NOI Techpark Südtirol / Alto Adige A.-Volta-Straße / Via A. Volta, 13A I-39100 Bozen / Bolzano https://www.noi.bz.it

3 2

Bug in the subscribe form of this mailing list
by Sebastian 18 Apr '21

18 Apr '21

Dear all, I've just subscribed to this list, and am looking forward to participating in some of the discussions regarding the REUSE specification and its associated tooling. However, I came up against an issue with the web form for subscribing to this list. Upon entering the correct information into the form, I got an error message saying "The form is tool old. Please GET it again." - a screenshot of this message is attached. This wasn't resolved by merely refreshing the page; but I managed to subscribe by selecting the digest mode on the form and changing that back in the Mailman settings once successfully subscribed. I have to admit that I'm rather intrigued by this error - I would expect such a form to be using a POST request. Is the form being fetched from some sort of reverse proxy cache, maybe? I hope this report is useful! Best wishes, Sebastian

2 2

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

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

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

Your input on potential REUSE specification improvements
by Max Mehl 20 Jul '20

20 Jul '20

Dear all, With this thread we would like to open the discussion for a few possible improvements of the REUSE specification (currently v3.0, see repository [^1]). While we did not experience any large failures, there might be spots where some tweaking will make it easier for developers and other compliance efforts to adopt REUSE. I will write a separate email per suggestion and would like to ask you to reply to them individually if you want to provide input to one or multiple suggestions directly. For your convenience, here's an overview: * Support / repurpose central LICENSE file * Introduce folder.license file * Handle copyright and licensing of snippets * Default handling of submodules If you have additional suggestions, please open a separate thread on this mailing list. Please note that all of these are *suggestions* which might be modified or even completely dropped if they are not convincing enough for stakeholders and/or the REUSE team. Your input will be highly appreciated and help us draft an incremental update of the specification. Thank you! Best regards, Max [^1]: https://github.com/fsfe/reuse-docs -- 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

10 27

License folder hack?
by Lucas Lasota 13 Jun '20

13 Jun '20

Dear REUSE people, the FSFE is part of the the NGIO initiative, presenting REUSE for projects which want to simplify their copyright and licensing notices. One topic that has been quite recurrent among projects is the fact that Git Hub expects a root level LICENSE file to be present in a repository, whereas REUSE mandates putting the license files into the LICENSES folder. Since Git Hub is quite important for those projects, they fear implementing the REUSE specs and be tagged as unlicensed, which is clearly a red flag for them. One of the projects reached us with a question, with something that seems to work. The project could have a LICENSE file at root and a LICENSES folder? Kubernetes seems to be doing that: https://github.com/kubernetes/kubernetes Although not technically REUSE compliant, it could be admitted as a temporary hack? Please share your thoughts. Thank you very much Lucas -- Lucas Lasota - Legal Team - Free Software Foundation Europe Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290 Registered at Amtsgericht Hamburg, VR 17030 |(fsfe.org/support)

2 1

2024

2023

2022

2021

2020

2019

2018

REUSE