On 03.01.25 21:07, Morten Linderud wrote:
Yo,
Today I noticed that the "License package sources" RFC contained an amended 0BSD license that added a two paragraph exception for patch files and other auxiliary files. The purpose of this change is to ensure the license is not covering other files in the repository that the author can't license from the upstream.
See: https://rfc.archlinux.page/0040-license-package-sources/
While this is a practical problem that needs to be solved, we should not be doing that through additional text in a FSF- and OSI approved license. This essentially makes it a custom license that is not really going to detected as 0BSD from external sources, and runs against the original goal of removing legal uncertainty.
As the change, and by extension the problem itself, is not mentioned in the text it came as a surprise to me that it was done.
What I think is more proper is to remove these two lines from the proposed license file, and move this to a separate RFC that would cover a use of the REUSE specification, or SPDX license identifiers. This would serve the same purpose as the Debian `copyright` files, while also being standardized.
I have written a proposed amendment to the text that I hope people find okay.
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49
*Please note that any licenses already added to the repository needs to be amended.*
My goal is to write up a RFC for the REUSE/SPDX part of this before the current 3 month timeline where we'll start adding licenses to ensure we don't prolong the process.
If people are curious how this would look like, I annotated the `usd` package as an example.
https://gitlab.archlinux.org/foxboron/usd/-/tree/morten/reuse
See the spec for more details: https://reuse.software/spec-3.2/
Cheers!
Binary files, as well as any files describing changes ("patches") to
Any files containing a license notice are provided under the license terms defined in their respective notices. Files not matching the conditions above are provided under the 0BSD
Thanks for taking the initiative on this! I think REUSE is a solid option to solve the legal uncertainty posed by a custom license. I'll start with some things we should keep in mind when going that route. After that, I'm going to outline some context around the RFC as originally written, and provide an alternative path to fixing the problem. Adding REUSE.toml files to all package sources will be tricky to automate. With REUSE, we'll have to explicitly specify license and copyright for *all files* in the source repo [0]. We can maybe take the upstream license from the PKGBUILD, but the copyright statement will either have to be entered manually or omitted (which is forbidden the REUSE spec). Specifically, this might change the duration of the transition from a few days to multiple years where maintainers manually make changes to their packages. Adding a new tool and strict file format to the critical path for making changes to package sources also adds some complexity to the workflow, increasing the burden on devtools and package maintainers. This can definitely be worth it in some cases. However, in the specific situation of package sources, interest in the licensing situation is very low, so I'm not sure if providing fine-grained licensing information will actually result in benefits for concrete use-cases. When writing the RFC, we assumed that the low-interest nature of the topic would make the exclusion clause a non-issue, since no one would actually run automatic tooling to determine licenses, or do anything other than a cursory check to cover their legal status. However, I agree that this should have been communicated much better in the RFC, and I also agree that having a custom license will increase legal uncertainty. Let's consider going with a less explicit way to specify licensing info, and drastically reduce the work involved: - Add a LICENSES folder with the original 0BSD text inside - Instead of REUSE.toml, use the same piece of prose in every repo to specify which files are covered by the 0BSD, e.g. in the README: the software that is being built are provided under the license terms of the software they describe changes for. license. This would have the advantage of being easy to automate, and easy to implement for devtools maintainers and package maintainers. However, I see the advantages of solving this properly and in a standardized way. I don't want to block the REUSE approach, and I'd +1 that as well. I just wanted to point out an alternative that might save us a lot of work. Cheers, Rafael [0]: https://reuse.software/spec-3.3/#licensing-information