Re: Amending RFC40 to remove custom 0BSD license
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
signature.asc
Description: PGP signature
Re: Amending RFC40 to remove custom 0BSD license
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 signature.asc Description: PGP signature
Issues with Libera.Chat and public access via Matrix
Hi all, back in October I have created channels for the buildbtw and signstar projects [1] which are meant to be publicly accessible for development and general user activities. While these work fine on the Libera.Chat side, the bridging via our private Matrix bridge causes friction: It is not possible to access the bridged rooms from Matrix without either being in the private Arch Linux staff space or being invited specifically to that room. This is due to the fact, that the official bridge has been shut down in August 2023 and eventually sunset entirely [2]. I raised this issue in the #archlinux-devops channel and after a chat with Jan the following possible scenarios materialized: - only use IRC (shut out Matrix users) - only use Matrix (shut out IRC users) - continue to invite interested people to bridged Matrix rooms manually (basically also shut out Matrix users) - switch to a different IRC network that is (still) accessible via a public Matrix bridge (e.g. oftc.net [3]) for public rooms I am not fond of the first three options as they either shut out user groups or require manual handholding of user additions, which in my mind does not scale. I'm raising this as a general note, because this is an issue when it comes to making public rooms available on Matrix beyond our own staff. For the ALPM project I have therefore chosen the path of least resistance and created #alpm on oftc.net for the time being. It would be great to find a less fragmenting solution for public rooms, so I'd be happy to get some input on this topic. Best, David [1]: https://lists.archlinux.org/archives/list/arch-proje...@lists.archlinux.org/thread/FN3PTFC7WLFCHUCXQIVS5QXPEPI7BRNI/ [2]: https://libera.chat/guides/matrix [3]: https://oftc.net -- https://sleepmap.de signature.asc Description: PGP signature
