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
signature.asc
Description: PGP signature
