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! -- Morten Linderud PGP: 9C02FF419FECBE16
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!
As per the discussion on IRC, I think this suggestion makes sense. I agree that the custom 0BSD change should have been called out in the RFC. I'm ok with changing the RFC text since it's kind of an implementation detail to make sure we are in line with the original intent of the RFC. However, we need to make sure people are on-board with this as not a trivial RFC change and I don't think we've done this before. Thanks for doing the mockup on usd, really helps to visualize how this would look.
On January 3, 2025 3:00:06 PM CST, Sven-Hendrik Haase <svenstaro@archlinux.org> wrote:
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!
As per the discussion on IRC, I think this suggestion makes sense. I agree that the custom 0BSD change should have been called out in the RFC.
I'm ok with changing the RFC text since it's kind of an implementation detail to make sure we are in line with the original intent of the RFC. However, we need to make sure people are on-board with this as not a trivial RFC change and I don't think we've done this before.
Thanks for doing the mockup on usd, really helps to visualize how this would look.
I second this. The usd mockup looks good as well. Campbell
On 03.01.25 at 21:07 (UTC+0100), 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!
I think changing the license text in the RFC is ok. It does not change anything from the perspective of contributors as the same conditions apply to their contributions. I have one question about REUSE: does the specification allow wildcards, such as `path = ["*.patch"]`? It would be nice if we could set it up just once per project and not have to think about it when adding or removing patches. Cheers, Jakub
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
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
participants (5)
-
Campbell Jones
-
Jakub Klinkovský
-
Morten Linderud
-
Rafael Epplée
-
Sven-Hendrik Haase