Hi all
The REUSE FAQ states that some people "miss the long legal blurbs at the
tops of files, miss the |COPYING|/|LICENSE| file in the root of the
repository, think that |.license| files clutter the directory, or find
it very strange that even insignificant non-code files get licensing
headers. The different-ness of REUSE can seem peculiar in that way."
I definitely don't miss those blurbs. In that way, REUSE automation is
an excellent thing.
However, I wonder if this might cause people to fail to apply the MPL
2.0 license. Section 1.4 of the MPL 2.0 license[2] states that
"Covered Software" "means Source Code Form to which the initial
Contributor has attached the notice in Exhibit A, the Executable Form of
such Source Code Form, and Modifications of such Source Code Form, in
each case including portions thereof."
Exhibit A is this statement: "This Source Code Form is subject to the
terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was
not distributed with this file, You can obtain one at
https://mozilla.org/MPL/2.0/."
Normally, this is interpreted as meaning that this statement should be
included in headers, however "if it is not possible or desirable to put
the notice in a particular file, then You may include the notice in a
location (such as a LICENSE file in a relevant directory) where a
recipient would be likely to look for such a notice".
If you attach the SPDX headers indicating "MPL 2.0", however, this
notice appears exactly NOWHERE in the repository except in the license
file itself, where it only serves the purpose of specifying the
requirement and thus cannot be said to be attached to each file in the
repository. There's a question on StackExchange discussing a similar
issue.[3]
The question is if this particular requirement in MPL 2.0, that actively
*demands* the inclusion of a specific text in order to apply, means
that REUSE's current standard check is insufficient for the MPL and that
the MPL Exhibit A text should be included somewhere? (Like, in a file
called ".reuse/MPL2.0-Exhibit-A.txt".
Best,
Carsten
[1]: https://reuse.software/faq/#tradition
[2]: https://www.mozilla.org/en-US/MPL/2.0/
[3]:
https://opensource.stackexchange.com/questions/7736/is-question-25-from-mpl…
Hello,
I have encountered what certainly appears to be a bug in version 3.0.1
of the `reuse` tool. I am reporting it here because I don't use GitHub
(and thank you for working towards getting REUSE off of it.)
The bug has something to do with having multiple entries in the
.reuse/dep5 file, and spaces in filenames. It manifests as reporting
that the file distribution is REUSE 3.0-compliant when in fact some
files contain no license or copyright information. I have not yet
ascertained whether the flaw is in the `debian.copyright` library that
loads the dep5 file, or in the `reuse` code itself.
A nearly minimal example which triggers it can be found here:
https://codeberg.org/cpressey/reuse-failure-case
Thank you,
-Chris
Hi all!,
I have released version 3.0.0 of the reuse tool today. It's not a
massively interesting release---just a heap of bug fixes and tiny
features. The biggest user-facing change is that the tool will propose
recommendations in `reuse lint` if you get something wrong.
The API will soon be updated as well, but I ran into a small sysadmin
issue that is preventing a swift update.
The change log is copied below for your reading convenience.
Yours with kindness,
Carmen
## 3.0.0 - 2024-01-17
This release contains a lot of small improvements and changes without anything
big per se. Rather, it is made in advance of a release which will contain a
single feature: [REUSE.toml](https://github.com/fsfe/reuse-tool/issues/779), a
replacement for `.reuse/dep5`. `.reuse/dep5` will still be supported as a
deprecated feature for some time.
That future 3.1 release will have some alpha testing in advance.
### Added
- Implement handling LicenseRef in `download` and `init`. (#697)
- Declared support for Python 3.12. (#846)
- More file types are recognised:
- TCL (`.tcl`) (#871)
- Julia (`.jl`) (#815)
- Modern Fortran (`.f90`) (#836)
- Bazel (`.bzl`) (#870)
- GNU Linker script (`.ld`) (#862)
- Assembly code (`.s`) (#862)
- Empty placeholders (`.empty`) (#862)
- ShellCheck configuration (`.shellcheckrc`) (#862)
- Pylint in-project configuration (`pylintrc`) (#862)
- Lisp schemes (`.sld`, `.sls`, `.sps`) (#875)
- Added comment styles:
- `csingle` for Zig (`.zig`) and Hare (`.ha`) (#889)
- Display recommendations for steps to fix found issues during a lint. (#698)
- Add support for Pijul VCS. Pijul support is not added to the Docker image.
(#858)
- When running `annotate` on a file with an unrecognised file path, the tool
currently exits early. To automatically create a .license file for
unrecognised files, `--fallback-dot-license` has been added. (#823, #851,
#853, #859; this took a while to get right.)
- Ignore `.sl` directory as used by [Sapling SCM](https://sapling-scm.com/).
(#867)
### Changed
- Alpine Docker image now uses 3.18 as base. (#846)
- The Git submodule detection was made less naïve. Where previously it detected
a directory with a `.git` file as a submodule, it now uses the git command to
detect submodules. This helps detect (quoted from Git man page)
"[repositories] that were cloned independently and later added as a submodule
or old setups", which "have the submodule's git directory inside the submodule
instead of embedded into the superproject's git directory". (#687)
- No longer scan binary or uncommentable files for their contents in search of
REUSE information. (#825)
- `--force-dot-license` and `--skip-unrecognised` are now mutually exclusive on
`annotate`. (#852)
- No longer create and publish `-extra` Docker images. The `openssh-client`
package is now in the main image. (#849)
- No longer create and publish `dev` Docker images. (#849)
- The `-debian` Docker image is now based off debian:12-slim. It used to be
based on the python:slim image, which used debian:slim under the hood. (#849)
### Removed
- Removed deprecated `--explicit-license`. (#851)
- Removed deprecated `addheader`. (#851)
- No longer depend on `sphinx-autodoc-typehints` for documentation. (#772)
### Fixed
- Syntax errors in .reuse/dep5 now have better error handling. (#841)
- Reduced python-debian minimum version to 0.1.34. (#808)
- Fix issue in `annotate` where `--single-line` and `--multi-line` would not
correctly raise an error with an incompatible comment style. (#853)
- Fix parsing existing copyright lines when they do not have a year (#861)
- Better handling of Lisp comment styles. Now, any number of ";" characters is
recognised as the prefix to a Lisp comment, and ";;;" is used when inserting
comment headers, as per
<https://www.gnu.org/software/emacs/manual/html_node/elisp/Comment-Tips.html>.
(#874)
Hi,
I just discovered a bug at https://api.reuse.software/register.
When one registers multiple new projects with the same confirmation
email address and an open, not yet confirmed request already exists
using the same email address, the same token gets mailed for both projects.
When clicking on the link, an "Internal Server Error" is shown after
"Click to confirm" without additional information. On subsequent tries,
"No such pending confirmation ID" is shown instead of the error.
It does not help to try it again. Even if the token changes, the
"Internal Server Error" persists. I hope I can register in 24 hours.
I discovered this when I added REUSE data to two repositories and wanted
to register both projects in a row:
> Please confirm your request by clicking on the link below:
>
> https://forms.fsfe.org/confirm?id=a5e9e0f9-ac5d-4f27-ba7e-ab20a402e14c
>
> The link is valid for the next 24 hours. If you do not confirm your
> email address, your project will not be checked for REUSE compliance.
>
> After successful confirmation, you will be able to see the REUSE status
> on https://api.reuse.software/info/github.com/foundata/chocolatey-sendmousecli….
and
> Please confirm your request by clicking on the link below:
>
> https://forms.fsfe.org/confirm?id=a5e9e0f9-ac5d-4f27-ba7e-ab20a402e14c
>
> The link is valid for the next 24 hours. If you do not confirm your
> email address, your project will not be checked for REUSE compliance.
>
> After successful confirmation, you will be able to see the REUSE status
> on https://api.reuse.software/info/github.com/foundata/chocolatey-sendkeys.ext….
PS: I hope the mailinglist is the right way to report, I did not find an
issue tracker at https://github.com/fsfe/reuse-api or
https://git.fsfe.org/reuse/api
--
Regards,
Andreas Haerter
foundata GmbH
Steinhäuserstr. 20
76135 Karlsruhe
Sitz der Gesellschaft: Karlsruhe
Registergericht: Amtsgericht Mannheim, HRB 714807
Geschäftsführer: Andreas Haerter
USt-IdNr.: DE284122682