- REUSE - FSFE Mailinglists

REUSE goes to space! - Interview with the German Aerospace Center
by Lina Ceballos 03 Nov '23

03 Nov '23

Hi everyone, We have great news! The German Aerospace Center (DLR) has adopted the REUSE(https://reuse.software) specification in some of its projects. We have talked to Tobias Schlauch, research software engineer at the DLR, about the role of Free Software for research, innovation, and the importance of a clear understanding and displaying of the legal information of software projects. You can read the whole interview here, as well as check the short video where he talks about what he likes the most about REUSE. https://fsfe.org/news/2023/news-20231102-01.html Best, Lina -- Lina Ceballos - Policy Project Manager Free Software Foundation Europe Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290 Registered at Amtsgericht Hamburg, VR 17030 | https://fsfe.org/support

2 1

LicenseRef Alternatives
by duluxoz 31 Jul '23

31 Jul '23

Hi All, A quick question: when using "|# SPDX-License-Identifier: LicenseRef-MyLicense|" does the next actually ***have*** to be that, or can it be something else, such as "|# SPDX-License-Identifier: LicenseRef-LicenseForExampleApp|" Cheers Dulux-Oz

2 2

Fwd: [pietervdvn/MapComplete] adding copyright and license SPDX comment headers for several files (PR #1495)
by Jithendra Palepu 27 Jul '23

27 Jul '23

Hello all! I just got this query from one of the Ngi clients. Would be great if anyone has a solution to this. Thanks much! -------- Forwarded Message -------- Subject: Re: [pietervdvn/MapComplete] adding copyright and license SPDX comment headers for several files (PR #1495) Date: Thu, 27 Jul 2023 05:13:54 -0700 From: Pieter Vander Vennet <notifications(a)github.com> Reply-To: pietervdvn/MapComplete <reply+BALM6FQC6KAJNZTGRON7ES6CZ6JAFEVBNHHGVIVIJQ(a)reply.github.com> To: pietervdvn/MapComplete <MapComplete(a)noreply.github.com> CC: Jit-p <jithendra(a)fsfe.org>, Author <author(a)noreply.github.com> Hi Jithendra, I have generated license files based on the already available license-info and fixed up information about all the other files (most of them through the dep5-file) Some questions remain: 1. Is there a way to add a pointer to the original source in SPDX? 2. A few files are logo's or used with permission and thus /not/ under a free license. I did add a clarifying license for this, but |reuse lint| still refuses those as 'bad licenses'. I understand that this makes the repo not completely free, but it will take a lot of work to separate out these parts. Is there a flag to ignore this? — Reply to this email directly, view it on GitHub <https://github.com/pietervdvn/MapComplete/pull/1495#issuecomment-1653495045>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BALM6FSZ4X55WNVONC6HDG3XS…>. You are receiving this because you authored the thread.Message ID: <pietervdvn/MapComplete/pull/1495/c1653495045(a)github.com>

1 0

Handling of NOTICE files of Apache-2.0-licensed code?
by Hoeppler Christian (CR/ADX1.1) 20 Jun '23

20 Jun '23

Hi all, Apache-2.0 stipulates that if a project contains a NOTICE file, then any derivative work must include a readable copy. Let’s assume I integrate a piece of Apache-2.0 licensed software into a codebase. The REUSE Spec v3 is pretty clear in how to attribute copyright and where to put the license file. I didn’t quite get though, how you handle the NOTICE file. Of course one could just merge all applicable notices from different NOTICE files into the project’s NOTICE file (if it is also Apache-2.0 licensed) as suggested by the license, but considering maintainability it would be easier to keep them separate, I think. In that case, should a NOTICE file also be put in the licenses folder and be associated with the the code it applies to via some naming convention? Or should it be added to a dep5-file? Or is this still to be specified…? Thanks for any pointers, Chris Mit freundlichen Grüßen / Best regards Dr. Christian Hoeppler CR Open Source Officer (CR/ADX1.1 CR-OSO) Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com Tel. +49 711 811-43624 | Mobile +49 1525 8813463 | Christian.Hoeppler(a)de.bosch.com Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 14000; Chairman of the Supervisory Board: Prof. Dr. Stefan Asenkerschbaumer; Managing Directors: Dr. Stefan Hartung, Dr. Christian Fischer, Dr. Markus Forschner, Stefan Grosch, Dr. Markus Heyn, Dr. Tanja Rückert

1 0

Re: [REUSE] Support / repurpose central LICENSE file
by Matthias Kirschner 01 Jun '23

01 Jun '23

Hello all, I agree with Carmen on option 2. The reason to think about the LICENSE file is because it is common. Changing the smeantics on the file will not improve the situation, because people do not like the LICENSE file in root because it is such a nice thing, but because they are used to it and in the end the content of the file matters, so changing the content should not be an option. When it comes to option 1 it is simply a convenience and it makes specifications much more likeable if they make themselves as convenient as possible. Perhaps it is a simple bugfix for GitHub but for the bugfix in the brains of users this is not as easy 😊. What makes the LICENSE file in the root folder convenient is the simple asosciation with the file is in the root so it applies to everything in that root folder. If it is in a sub folder, this is an additional mental step to associate the file with the brother and sister folders of its parent, so it "feels" better. I understand that more complext situations are better handled in its own box aka. folder, but for easy cases it helps to grasp the situation faster. In the end the place only matters for human readers, because tools can easily adapt and from the way, license and copyright scanners work, they simply detect the license texts, whereever they are hidden in the folder structure, again it is then the human being who has to assess the information retrieved by the scanner who has to make the associations. 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(a)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(a)lists.fsfe.org> im Auftrag von Carmen Bianca Bakker <carmenbianca(a)fsfe.org> Gesendet: Donnerstag, 5. März 2020 16:37:43 An: reuse(a)lists.fsfe.org Betreff: Re: [REUSE] Support / repurpose central LICENSE file Hi all, In general I disfavour option 2 (using LICENSE to summarise the licensing situation). This should already happen in the README of a project, so it is a duplicated effort. Moreover, keeping the summary up-to-date can be challenging. At least if it's in the README, you encounter the summary every now and then, and can file a bug report if it's out-of-date. The chances that you would randomly read LICENSE are nil. It has a few more issues: - The reason that a lot of people want to keep the LICENSE file is because GitHub auto-detects the file. A summary cannot be auto- detected. + Last I heard, this is still a known issue at GitHub. GitHub wants to support the detection of multi-licensed projects at some point. - A lot of tools (and humans) might assume that the license text is in LICENSE, and neglect to verify. That is obviously not what we want. - REUSE is really cool because it introduces a machine-readable way of doing copyright and licensing. I cannot envision an easy way in which to make this suggested LICENSE summary machine-readable. --- I feel more ambivalent about option 1. I'm erring towards no because it would complicate the specification for no good reason. Having a directory covers all cases. Having a LICENSE file adds a ton of complications as listed in the cons. I know two reasons to do it anyway, but I don't find them very convincing: 1. GitHub (and/or other tools) don't recognise the LICENSES/ directory. 2. Having a single LICENSE file is easier/nicer/whatever. Point 1 requires a simple bugfix. Point 2 is tabs-vs-spaces. I am devoutly convinced that there is a correct answer to the tabs-vs-spaces debate (hint: it's spaces), but the rational part of my brain says that it just doesn't matter. The spec is stronger when it suggests one---and only one---obvious way to do it. --- So I wouldn't change anything in this department. Of course, if we don't change anything, it'll never really be a closed debate. Ah well. 🙆 Yours with kindness, Carmen _______________________________________________ REUSE mailing list REUSE(a)lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct Hello all, I agree with Carmen on option 2. The reason to think about the LICENSE file is because it is common. Changing the smeantics on the file will not improve the situation, because people do not like the LICENSE file in root because it is such a nice thing, but because they are used to it and in the end the content of the file matters, so changing the content should not be an option. When it comes to option 1 it is simply a convenience and it makes specifications much more likeable if they make themselves as convenient as possible. Perhaps it is a simple bugfix for GitHub but for the bugfix in the brains of users this is not as easy 😊. What makes the LICENSE file in the root folder convenient is the simple asosciation with the file is in the root so it applies to everything in that root folder. If it is in a sub folder, this is an additional mental step to associate the file with the brother and sister folders of its parent, so it "feels" better. I understand that more complext situations are better handled in its own box aka. folder, but for easy cases it helps to grasp the situation faster. In the end the place only matters for human readers, because tools can easily adapt and from the way, license and copyright scanners work, they simply detect the license texts, whereever they are hidden in the folder structure, again it is then the human being who has to assess the information retrieved by the scanner who has to make the associations. 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(a)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(a)lists.fsfe.org> im Auftrag von Carmen Bianca Bakker <carmenbianca(a)fsfe.org> Gesendet: Donnerstag, 5. März 2020 16:37:43 An: reuse(a)lists.fsfe.org Betreff: Re: [REUSE] Support / repurpose central LICENSE file Hi all, In general I disfavour option 2 (using LICENSE to summarise the licensing situation). This should already happen in the README of a project, so it is a duplicated effort. Moreover, keeping the summary up-to-date can be challenging. At least if it's in the README, you encounter the summary every now and then, and can file a bug report if it's out-of-date. The chances that you would randomly read LICENSE are nil. It has a few more issues: - The reason that a lot of people want to keep the LICENSE file is because GitHub auto-detects the file. A summary cannot be auto- detected. + Last I heard, this is still a known issue at GitHub. GitHub wants to support the detection of multi-licensed projects at some point. - A lot of tools (and humans) might assume that the license text is in LICENSE, and neglect to verify. That is obviously not what we want. - REUSE is really cool because it introduces a machine-readable way of doing copyright and licensing. I cannot envision an easy way in which to make this suggested LICENSE summary machine-readable. --- I feel more ambivalent about option 1. I'm erring towards no because it would complicate the specification for no good reason. Having a directory covers all cases. Having a LICENSE file adds a ton of complications as listed in the cons. I know two reasons to do it anyway, but I don't find them very convincing: 1. GitHub (and/or other tools) don't recognise the LICENSES/ directory. 2. Having a single LICENSE file is easier/nicer/whatever. Point 1 requires a simple bugfix. Point 2 is tabs-vs-spaces. I am devoutly convinced that there is a correct answer to the tabs-vs-spaces debate (hint: it's spaces), but the rational part of my brain says that it just doesn't matter. The spec is stronger when it suggests one---and only one---obvious way to do it. --- So I wouldn't change anything in this department. Of course, if we don't change anything, it'll never really be a closed debate. Ah well. 🙆 Yours with kindness, Carmen _______________________________________________ REUSE mailing list REUSE(a)lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct _______________________________________________ REUSE mailing list REUSE(a)lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/reuse This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct -- Matthias Kirschner - President - 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) Contact (fsfe.org/about/kirschner) Weblog k7r.eu/blog.html Ada & Zangemann - A Tale of Software, Skateboards, and Raspberry Ice cream - For everyone from 6 - 106 years - ada.fsfe.org

1 0

projects registered with API last week (friday) are still say "checking..."
by Kevin Broch 23 May '23

23 May '23

Last week, I registered several projects: - https://api.reuse.software/info/github.com/rivosinc/cove - https://api.reuse.software/info/github.com/rivosinc/crosspkgs - https://api.reuse.software/info/github.com/rivosinc/riscv-code-samples - https://api.reuse.software/info/github.com/rivosinc/Zisslpcfi-sw All continue to say "The initial check for REUSE compliance has not yet been finished. Please refresh the page in a few seconds." I have previously registered projects without a problem ex: https://api.reuse.software/info/github.com/rivosinc/salus I'm wondering if there is a backlog or a problem with the API server? Best, /<evin

2 3

projects registered with API last week (friday) are still say "checking..."
by Kevin Broch 22 May '23

22 May '23

Last week, I registered several projects: - https://api.reuse.software/info/github.com/rivosinc/cove - https://api.reuse.software/info/github.com/rivosinc/crosspkgs - https://api.reuse.software/info/github.com/rivosinc/riscv-code-samples - https://api.reuse.software/info/github.com/rivosinc/Zisslpcfi-sw All continue to say "The initial check for REUSE compliance has not yet been finished. Please refresh the page in a few seconds." I have previously registered projects without a problem ex: https://api.reuse.software/info/github.com/rivosinc/salus I'm wondering if there is a backlog or a problem with the API server? Best, /<evin

1 0

Re: [REUSE] REUSE not installing on RHEL9 and Alma Linux 9 with python 3.9
by Linus Sehn 26 Apr '23

26 Apr '23

Hi Marco, > Good morning, > I'm using REUSE in a project, I'm moving from EL7 to EL9 and I'm trying to build a container for testing and release building and I'm unable to install REUSE. > I followed the instructions on https://reuse.readthedocs.io/en/latest/readme.html#install and I'm getting an error during the pipx/pip installation. > > I started from either registry.access.redhat.com/ubi9/ubi or almalinux:9 (docker hub) > I installed these RPMs: > yum install -y rpm-build python3-devel python3-cryptography git make openssl-devel gcc gcc-c++ > > Both pipx and pip fail to install reuse (see below). I'm not sure if I'm doing something wrong, I'm missing some required RPM or if reuse is incompatible with RHEL9. > > Thank you, > Marco I just downloaded the same Docker container and was able to fix the problem by running ``` yum install -y gettext ``` Then, pipx installs `reuse` without any problems. I hope this fixes your issue! All the best, -- Linus Sehn >>> System Hacker @ Free Software Foundation Europe matrix: @linus:fsfe.org | git@fsfe: https://git.fsfe.org/linus Become a supporter of software freedom > https://fsfe.org/join

1 0

REUSE not installing on RHEL9 and Alma Linux 9 with python 3.9
by Marco Mambelli 24 Apr '23

24 Apr '23

Good morning, I'm using REUSE in a project, I'm moving from EL7 to EL9 and I'm trying to build a container for testing and release building and I'm unable to install REUSE. I followed the instructions on https://reuse.readthedocs.io/en/latest/readme.html#install and I'm getting an error during the pipx/pip installation. I started from either registry.access.redhat.com/ubi9/ubi or almalinux:9 (docker hub) I installed these RPMs: yum install -y rpm-build python3-devel python3-cryptography git make openssl-devel gcc gcc-c++ Both pipx and pip fail to install reuse (see below). I'm not sure if I'm doing something wrong, I'm missing some required RPM or if reuse is incompatible with RHEL9. Thank you, Marco * Error using pipx: [locuser@692d4624870d decisionengine]$ pipx run reuse lint Fatal error from pip prevented installation. Full pip output in file: /home/locuser/.local/pipx/logs/cmd_2023-04-20_22.44.49_pip_errors.log pip failed to build package: reuse Some possibly relevant errors from pip install: error: subprocess-exited-with-error [Errno 2] No such file or directory: '-o.po' subprocess.CalledProcessError: Command '['/usr/bin/msgfmt.py', 'po/de.po', '-o', 'build/lib/reuse/locale/de/LC_MESSAGES/reuse.mo']' returned non-zero exit status 1. subprocess.CalledProcessError: Command '['/home/locuser/.local/pipx/.cache/f81f2f2c701e6fa/bin/python', '_build.py']' returned non-zero exit status 1. Error installing reuse. * Error using pip: [locuser@692d4624870d decisionengine]$ pip3 install --user reuse Collecting reuse Using cached reuse-1.1.2.tar.gz (225 kB) Installing build dependencies ... done Getting requirements to build wheel ... done Preparing wheel metadata ... done Collecting Jinja2<4.0.0,>=3.0.0 Using cached Jinja2-3.1.2-py3-none-any.whl (133 kB) Collecting python-debian!=0.1.45,!=0.1.46,!=0.1.47,<0.2.0,>=0.1.38 Using cached python_debian-0.1.49-py3-none-any.whl (132 kB) Requirement already satisfied: setuptools in /usr/lib/python3.9/site-packages (from reuse) (53.0.0) Collecting license-expression>=1.0 Using cached license_expression-30.1.0-py3-none-any.whl (100 kB) Collecting boolean.py>=3.8 Using cached boolean.py-4.0-py3-none-any.whl (25 kB) Collecting binaryornot<0.5.0,>=0.4.4 Using cached binaryornot-0.4.4-py2.py3-none-any.whl (9.0 kB) Collecting chardet>=3.0.2 Using cached chardet-5.1.0-py3-none-any.whl (199 kB) Collecting MarkupSafe>=2.0 Using cached MarkupSafe-2.1.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (25 kB) Building wheels for collected packages: reuse Building wheel for reuse (PEP 517) ... error ERROR: Command errored out with exit status 1: command: /usr/bin/python3 /usr/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /tmp/tmpysg2hum7 cwd: /tmp/pip-install-6540489r/reuse_16ae74697fb74696bd2997a89983d912 Complete output (39 lines): [Errno 2] No such file or directory: '-o.po' Traceback (most recent call last): File "/tmp/pip-install-6540489r/reuse_16ae74697fb74696bd2997a89983d912/_build.py", line 103, in <module> build() File "/tmp/pip-install-6540489r/reuse_16ae74697fb74696bd2997a89983d912/_build.py", line 88, in build cmd.run() File "/tmp/pip-install-6540489r/reuse_16ae74697fb74696bd2997a89983d912/_build.py", line 60, in run self.make_file( File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/setuptools/_distutils/cmd.py", line 432, in make_file self.execute(func, args, exec_msg, level) File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/setuptools/_distutils/cmd.py", line 339, in execute util.execute(func, args, msg, dry_run=self.dry_run) File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/setuptools/_distutils/util.py", line 337, in execute func(*args) File "/tmp/pip-install-6540489r/reuse_16ae74697fb74696bd2997a89983d912/_build.py", line 54, in <lambda> compile_func = lambda msgfmt, in_file, out: subprocess.run( File "/usr/lib64/python3.9/subprocess.py", line 528, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '['/usr/bin/msgfmt.py', 'po/de.po', '-o', 'build/lib/reuse/locale/de/LC_MESSAGES/reuse.mo']' returned non-zero exit status 1. Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 349, in <module> main() File "/usr/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 331, in main json_out['return_val'] = hook(**hook_input['kwargs']) File "/usr/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 248, in build_wheel return _build_backend().build_wheel(wheel_directory, config_settings, File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/poetry/core/masonry/api.py", line 56, in build_wheel return WheelBuilder.make_in( File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/poetry/core/masonry/builders/wheel.py", line 85, in make_in wb.build(target_dir=directory) File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/poetry/core/masonry/builders/wheel.py", line 120, in build self._build(zip_file) File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/poetry/core/masonry/builders/wheel.py", line 169, in _build self._run_build_script(self._package.build_script) File "/tmp/pip-build-env-t75ec6sl/overlay/lib/python3.9/site-packages/poetry/core/masonry/builders/wheel.py", line 229, in _run_build_script subprocess.check_call([self.executable.as_posix(), build_script]) File "/usr/lib64/python3.9/subprocess.py", line 373, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/usr/bin/python3', '_build.py']' returned non-zero exit status 1. ---------------------------------------- ERROR: Failed building wheel for reuse Failed to build reuse ERROR: Could not build wheels for reuse which use PEP 517 and cannot be installed directly

1 0

How to use public domain works
by Xavier B. 12 Apr '23

12 Apr '23

Hi, I want to use this [1] work which is relased as public domain. But reuse software cannot annotate this (there is no such license to apply) Any hints? Thanks, Xavier [1] https://ca.wikipedia.org/wiki/Fitxer:Parallellopipedum.png

4 3

2024

2023

2022

2021

2020

2019

2018

REUSE