Amending RFC40 to remove custom 0BSD license
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!
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:
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. 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
On 06.01.25 16:10, Morten Linderud wrote:
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.
Okay, I think we agree on all important points here, and I think we have a solid plan for fixing the issues you brought up as well as a good long-term vision. The one thing I'd like to discuss further is the interim solution we'll put in place. If I've understood correctly, the plan is to put an unmodified 0BSD license text into either some, or all repositories. If we put the license into all repositories, but leave out the interim statement which clarifies that this license only applies to certain files, this could be interpreted as the license covering all files in each repo, including patches. We have explicitly excluded these files from the licensing notification mails we sent out, so this might be problematic in various ways. If we put the license into only those repositories that don't contain patches, we won't completely remove the legal uncertainties surrounding package source licensing, and will only remove those uncertainties once the REUSE RFC has been implemented. This is why I agree with kpcyrd that the additional statement is not only cruft but serves a necessary purpose. Maybe we can find another interim solution to exclude patches from the new license that's easier to remove when a REUSE.toml file is introduced, e.g. a separate file containing only the additional statement? Cheers, Rafael
On Tue, Jan 07, 2025 at 01:37:04PM +0100, Rafael Epplée wrote:
[...snipping thread...]
Okay, I think we agree on all important points here, and I think we have a solid plan for fixing the issues you brought up as well as a good long-term vision.
The one thing I'd like to discuss further is the interim solution we'll put in place. If I've understood correctly, the plan is to put an unmodified 0BSD license text into either some, or all repositories.
If we put the license into all repositories, but leave out the interim statement which clarifies that this license only applies to certain files, this could be interpreted as the license covering all files in each repo, including patches. We have explicitly excluded these files from the licensing notification mails we sent out, so this might be problematic in various ways.
This is not ideal, but the RFC clearly states these files are not covered by the license, both with the old text and my proposal. I don't think this is problematic as the LICENSE text in the repository is a convention by the FOSS community, and does not necessarily on it's own imply anything legally binding. We are amending the RFC to be clear, and we are including statements in our official communication about it. It is quite clearly communicated what does and doesn't apply here.
If we put the license into only those repositories that don't contain patches, we won't completely remove the legal uncertainties surrounding package source licensing, and will only remove those uncertainties once the REUSE RFC has been implemented.
This is why I agree with kpcyrd that the additional statement is not only cruft but serves a necessary purpose.
If just adding a notice in the repository counts as valid declaration, pointing at the RFC text should be equally valid as well?
Maybe we can find another interim solution to exclude patches from the new license that's easier to remove when a REUSE.toml file is introduced, e.g. a separate file containing only the additional statement?
Should this be figured out as part of the RFC40 amendments, or the REUSE RFC? -- Morten Linderud PGP: 9C02FF419FECBE16
On 1/6/25 3:49 PM, Rafael Epplée wrote:
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.
I think this is a reasonable approach. I don't think this qualifies as cruft, if we consider it necessary to put a LICENSE file into every PKGBUILD repository, this file would be equally valid. It clarifies the copyright situation with the same level of authority as the LICENSE file does. Including a LICENSE and README file into each PKGBUILD repository in the first place (vs. archlinux/state.git or elsewhere) is something we could also revisit of course, but I also strongly think we shouldn't use a custom license text. I think implementing REUSE for an entire operating system is enough work to warrant an interim solution. I've been doing this kind of copyright annotation work for Debian for just shy of about 300 packages and it's a heroic amount of work to do this for the entire operating system. cheers, kpcyrd
On Mon, Jan 06, 2025 at 04:42:08PM +0100, kpcyrd wrote:
On 1/6/25 3:49 PM, Rafael Epplée wrote:
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.
I think this is a reasonable approach. I don't think this qualifies as cruft, if we consider it necessary to put a LICENSE file into every PKGBUILD repository, this file would be equally valid. It clarifies the copyright situation with the same level of authority as the LICENSE file does.
Including a LICENSE and README file into each PKGBUILD repository in the first place (vs. archlinux/state.git or elsewhere) is something we could also revisit of course, but I also strongly think we shouldn't use a custom license text.
I think implementing REUSE for an entire operating system is enough work to warrant an interim solution. I've been doing this kind of copyright annotation work for Debian for just shy of about 300 packages and it's a heroic amount of work to do this for the entire operating system.
Debian mirrors sources and we do not need to do the same amount of work for this. I annotated your packages quickly to gauge. So you maintain 145 packages, and `pkgctl clone --maintainer kpcyrd` gave me ~138 repositories. I then wrote a quick script that stuff a baseline REUSE.toml config into each of your repositories and made it output all failing lints. Out of 138 source repoes it listed 21 repositories to have additional work. The example REUSE.toml is below. Please note I took the liberty of including the vendored `Cargo.lock` files to include, as they are generated and maintained by us(?). version = 1 [[annotations]] path = [ "PKGBUILD", ".SRCINFO", ".nvchecker.toml", "*.install", "Cargo.lock", "keys/**", "*.sysusers", "*.tmpfiles" ] SPDX-FileCopyrightText = "Arch Linux contributors" SPDX-License-Identifier = "0BSD" Running the same on my packages gave 39 repositories out of 202 git repositories. I don't think this is an unreasonable amount of work if we are estimating that between 1 in 4 repositories needs some entries to be covered. -- Morten Linderud PGP: 9C02FF419FECBE16
I've now posted the REUSE RFC and slightly updated the proposed amendment to RFC40. RFC: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 Proposed amendment of RFC40: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/49 It would be nice to clarify the situation as we are approaching the 3 month deadline for the licensing of our package sources. Jelle has also brought up another aspect we haven't considered in the original RFC. Debian apparently license patches *and* some auxillary files (think tmpfiles.d or sysusers.d) under the license of the upstream sources. This would allow us to upstream additional files to the relevant upstream if needed without having to seek relicensing of the files from the original author. While we have patches mentioned in RFC40, and properly licensed under the proposed RFC52, we haven't really considered the additional files. Some thoughts there would be nice. -- Morten Linderud PGP: 9C02FF419FECBE16
participants (6)
-
Campbell Jones
-
Jakub Klinkovský
-
kpcyrd
-
Morten Linderud
-
Rafael Epplée
-
Sven-Hendrik Haase