On Mon, Jan 06, 2025 at 03:49:09PM +0100, Rafael Epplée wrote:
Thanks for taking the initiative on this!
No worries!
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.
No, that is not the intention here and not the outcome of this proposal. The idea here is to write an RFC for the REUSE part of this problem before we license the repositories. This is to avoid the custom license and have something to point towards for future work. Once the RFC is (most likely) accepted, the license plan continues without any concern of the REUSE RFC. The license stuff can happen, and the REUSE part can be completed on another schedule. We are not aiming for perfect here, just slowly progressing away from the unoptimal situation we have today. I don't see any reason for why this would prolong the license RFC timeline.
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:
Binary files, as well as any files describing changes ("patches") to the software that is being built are provided under the license terms of the software they describe changes for. 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 license.
This would have the advantage of being easy to automate, and easy to implement for devtools maintainers and package maintainers.
Then we would have 12k README.md files that would be obsolete by the RESUME RFC at some point between now and when it's done. I don't think this is elegant is just adding more cruft to the package repositories. We don't have to complete the REUSE stuff on the same timeline as the repo licensing. All of this can happen independently of each other.
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.
Fwiw, the goal is to be pragmatic about the solution here. The alternative proposed here doesn't actually save us any time and doesn't inherently solve the problem. It's a crutch that is already covered by the proposed modification I have in the linked MR. It's better to just do this properly and on a timeline that doesn't tie into the repo licensing. Adding 0BSD license to the repositories is going to cover most of our repositories, then we need to work out the remaining 10% which have additional auxillary files in the repos. -- Morten Linderud PGP: 9C02FF419FECBE16