On 7/24/25 2:42 AM, [email protected] wrote:
Sven-Hendrik Haase <[email protected]> wrote:Hey all, With [RFC40][0] and [RFC52][1] merged, we're now going full steam to make sure the changes outlined in those RFCs are soon implemented. If you are a packager and only care about how this concerns you without the nitty gritty details, here's what you need to know in short: 1. PKGBUILDs and auxiliary files (e.g. config files, etc.) that Arch Linux contributors provided will be licensed under 0BSD. Full current list [here][3]. 2. Licensing information will be documented in a `REUSE.toml` file per repository and will be maintained by package maintainers going forward. 3. We will generate a `REUSE.toml` (using `pkgctl license setup`) for most packages. 4. You may have to make changes to your packages (details below)! 5. When moving package source repositories from the AUR, either contact past contributors and ask for consent to license under 0BSD, or rewrite the package sources. The changes introduced in [RFC40][0] and [RFC52][1] have a general impact on packaging work. To clearly document which licenses apply to which files, we are introducing REUSE [2], which provides a structured configuration file format (`REUSE.toml`) for mapping files to concrete licenses. In the near future, we will add these files to package source repos in an automated fashion using `pkgctl license setup`. While doing so, we will exclude some packages added after 2024-11-01, see [this issue][4] for further details.[4]: https://gitlab.archlinux.org/archlinux/packaging/licensing-package-sources/-/issues/149I get a 404.
This is expected, this GitLab issue is marked as "confidential" (due to its confidential content) and is therefore only visible by logged staff.
-- u34In some cases (around 750 out of 12462 repos), packager maintainers will need to manually perform some changes, as adding a `REUSE.toml` will not work out of the box. There will be a todo list on Arch web for those packages where manual action is required. The most common reasons for this are: 1. The package's license isn't specified in an SPDX conforming fashion (e.g. `GPL2` instead of `GPL-2.0-or-later`). There are open MRs on GitLab to make some packages SPDX conforming [5]. We will go through these and we'll try to merge all of these. 2. Multiple license identifiers are specified in the PKGBUILD and SRCINFO files and patch files are present in the package source repository. In this case, we can't automatically pick a suitable upstream license. By default, all files in package source repos must be licensed under 0BSD. 0BSD is very permissive and files licensed under its terms can be contributed upstream under their desired license. For some files, 0BSD might not be suitable, and contributors need to choose a different license depending on the situation. Here are some common cases: - Included files originating from contributors that have not agreed to the 0BSD license. If the files are available under a FOSS license, mark the files under that particular license in the `REUSE.toml`. If no license is provided, the files need to be rewritten or removed. - Patches taken from upstream and committed to the repository need to be annotated with the correct upstream license. `pkgctl license` will be available from devtools v1.4.0 onwards. After this release, you will encounter a warning when running `pkgctl release` if your package source repository isn't compliant. If there are any open questions with existing packages and the new reuse setup, reach out over the mailing list or in the packaging channel. Cheers, Rafael and Sven [0]: https://rfc.archlinux.page/0040-license-package-sources/ [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 [2]: https://reuse.software/ [3]: https://gitlab.archlinux.org/archlinux/devtools/-/blob/b8c475b3f402809fc65b7f43ffe82d2e6a9c7c16/src/lib/license/setup.sh#L185 [4]: https://gitlab.archlinux.org/archlinux/packaging/licensing-package-sources/-/issues/149 [5]: https://gitlab.archlinux.org/search?scope=merge_requests&search=spdx&state=opened
-- Regards, Robin Candau / Antiz
OpenPGP_0xFDC3040B92ACA748.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
