Declare subprojects and support them

[carmenbianca]

Related to #163, maybe supersedes it.

When we've finished the switch to REUSE.yaml, we could add an tag in the root REUSE.yaml to declare subprojects. Those subprojects would then (recursively?) have their own, independent REUSE configuration.

[mxmehl]

So you mean that a REUSE.yaml could describe a submodule?

Would it suffice to make the submodule REUSE-compliant (with whatever annotation method we support) and run the lint with the --include-submodules flag?

The issue you linked to seems to originate from the problem that the linter does not take the submodule's dep5 file as a source for information, but the parent project's one, right?

[carmenbianca]

Not really. This is separate from Git submodules and Meson subprojects, although we could probably generalise those into this proposal.

Rather, this aims to tackle mono-repos with subprojects. See, for example, https://github.com/OCA/partner-contact/. Every subdirectory in the root directory (except setup/) is its own project that should have its own LICENSES/ directory etc etc etc. In short, each directory should be treated as its own project/repository, and I think we can configure that using REUSE.yaml. In the future.

Of course, if the world were a better place, all those projects would have their own repository, but that's not the world we live in.

[pmhahn]

We have a similar issue with Univention Corporate Server (UCS): it is a mono-repository consisting of 128+ sub-packages, each in its own 2-level deep sub-directory. As UCS is based on Debian GNU/Linux each sub-package is its own Debian package having a valid dep5-compliant debian/copyright file for the files of that sub-package.
While reuse already has the capability to bulk describe licences using a single .reuse/dep5 file, that would require merging those files into one file and prefixing each pattern with the original sub-directory-path. That would lead to duplicating the information, which then needs to be maintained in two locations and easily gets out-of-sync. Removing the 128 debian/copyright files is not an option as they are required for Debian packages.

A mechanism to include sub-files like include */*/debian/copyright with automatic path mangling would be appreciated.

[carmenbianca]

@pmhahn To set expectations, it'll be a little while before we tackle this. There's a lot of plumbing that needs to be done before work can be started on this.

But thank you for your example use-case!