NGI - Updating licensing aspects according to REUSE

[lnceballosz]

Hello,

I work for the Free Software Foundation Europe (FSFE), and we have been working with the NGI framework, helping projects with their licensing and copyright management. After a quick check on your repository, I would like to propose some updates regarding copyright and licensing information. REUSE is an FSFE-developed initiative intended to make licensing easier by establishing a single way to display all copyright and licensing information through comment headers on source files that can be human- and machine-readable.

REUSE Features:

Copyright and Licensing Information in each file

One of the main features of REUSE is that each file in the repository contains copyright and license information with the help of a comment header. To serve as a guideline and a practical example of how REUSE looks, I have added the header to some of the files in your repository, but some directories such as src/feditest/templates/ still need such info. I've taken the copyright information from the file pyproject.toml So, please double-check that the personal information in the headers is correct and consistent, otherwise, please update that information in the headers. In case you want to license certain files under a different license, special attention should also be paid to that aspect and such files should contain the appropriate SPDX tag.

And, please remember that you can also change the year in the headers depending on your preference.

Please note that REUSE has also an option to add this legal information for binary and uncommentable files, as well as for insignificant files - no copyrightable files such as .gitignore. An appropriate license for the documentation files in your repository is also encouraged.

LICENSES directory in the root of the project with the licenses used on the repository:

I included in this directory a file with the text of the MIT license. I did not do anything with the existing LICENSE file in the root of the directory. It is up to you if you want to keep it or delete it, however, this won't affect the REUSE specification. Please also be aware, that if some pieces of your project use a different license, such license text should be added to the LICENSES/ directory as well as to the specific files.

Please feel free to check the REUSE documentation and the helper tool , and if you are interested in making your project REUSE compliant, please add the legal information to the missing files. I am also available if you want support with the process.

Wide range of tools

In case you find REUSE useful, we offer other tools to help you continuously check and display compliance with the REUSE guidelines. For instance, you can automatically run reuse lint on every commit as a pre-commit hook for Git. And, it can be easily integrated into your existing CI/CD processes to continuously test your repository and its changes for REUSE compliance

Hope that helps and thank you very much for the amazing job!

[jernst]

Based on some community feedback: could you explain what exact problem this solves? We can see this can solve some problems for some projects, but how exactly does this apply to FediTest?

[lnceballosz]

Based on some community feedback: could you explain what exact problem this solves? We can see this can solve some problems for some projects, but how exactly does this apply to FediTest?

The goal of the specification is to have comprehensive, unambiguous, human- and machine-readable copyright and licensing information for each individual file in a project. Ideally, this information is embedded into every file, so that the information is preserved when the file is copied and reused by third parties.

REUSE exists to help the people who DO dig into the source, and don't just use a project as a dependency. It allows third parties to easily copy (read: reuse) your code with all licensing information intact, without having to make any inferences from external files.

Furthermore, if done well, REUSE keeps a much more accurate and closer-to-reality metadata aggregate of copyright and licensing. If all you have is a LICENSE file, then you kind of have to make the inference that whatever this file implies is true for the entirety of the project. But this is often NOT TRUE. Very very often, some outside code or work will end up in a software project that does NOT match the licence of the project, and even more often, outside contributions will have a different copyright holder than the one declared sometimes somewhere in the projects. So, this is the problem that REUSE is aiming to solve.

[mexon]

I am, prima facie, opposed to this change. From my POV, I see noise being added to source files without contributing any value. Reading a LICENSE file seems to me not an onerous ask for developers considering wholesale lifting entire directory trees of other people's source code. Whereas for a developer like me working on a project, it's a pain to have to engage with yet another toolchain, interfering with my ability to get stuff done. It fails the cost/benefit test.

Building the habit of proper machine-readable SBOMs is important, both for technical reasons (log4j) and legal reasons (left-pad). I welcome initiatives in this area. I think the problems here are: 1. Feditest is not a good candidate for an early adopter, 2. putting a header in every file is not a good technical solution, and 3. the approach to engagement, basically dropping in unannounced with a PR, is inappropriate.

Note that src/feditest/utils.py contains code I wrote, but I am not credited as a copyright owner. Presumably that's because Johannes merged the change, so git blame puts his name on those lines. Of course I don't care about that, it's an insignificant amount of code, and I've never paid attention to how my copyright is treated. My point is that on the face of it, REUSE is only making attribution murkier here. Presumably it would be up to Johannes to untangle whatever mess is left over.

I am no expert on these topics. But equally, I don't feel comfortable just taking your word. FSFE is an opinionated organisation and not automatically in the right.

So here are my questions:

1. How many other projects are you targeting?
2. What criteria did you apply for choosing those projects?
3. What proportion of those projects decided to accept your change? (And what proportion rejected, what proportion ignored?)
4. What proportion of those projects decided to actively adopt the idea, e.g. incorporating automated github actions?
5. Is there a forum for targeted projects where we can all compare notes, rather than rehashing the same old arguments?

All that said: I have precisely nothing at stake in this apart from the lingering trauma from previous arguments about copyright headers (*shudder*). It's entirely up to Johannes whether he accepts this change.

[Ryuno-Ki]

Hey there 👋

as was mentioned above, this PR was brought to the associated Matrix room.

Since I follow https://github.com/fsfe/reuse-tool loosely I have seen some projects adopting REUSE already.

I personally maintain https://codeberg.org/Anvil/Anvil - which is also funded by NGI0.

From my understanding, the biggest drawback here is the perception of a maintenance burden.
By adding REUSE you force every contributor to deal with another thing on top which could turn away some.

Therefore I would suggest to take a small step back: add a REUSE.toml file which basically reflects the LICENSE. In a future iteration the code comnents could be gradually added.

You might have another PR that warns when reuse lint fails to raise awareness before flipping it to fail PRs.

I feel more education is needed to get buy-in by the people here.

Would that work for you?

[lnceballosz]

To clarify a few points, as I mentioned in the text of the PR, this is simply a guideline for your project to consider— it is entirely up to you whether you choose to implement it or not.

We've reached out with this PR, as Feditest is currently receiving funding in the NGI0 Core initiative. Our involvement with Free Software projects like yours is directly tied to your participation in this EU-funded program and is well-documented in your funding package.

Feditest is a relatively young project and doesn’t have an overwhelming number of files, which would simplify the legal clarification process. Many high-profile projects, including, curl, SAP, KDE, public institutions like DLR, and large parts of the Linux Kernel have adopted REUSE. If you need more guidance on the rationale behind the legal issues that REUSE is trying to resolve, you can refer to REUSE FAQ.

You are correct that I overlooked your copyright contribution @mexon. But that only underscores the very issue REUSE is designed to address. When legal information isn’t clearly visible, it’s easy to miss, just as I did. To me, this highlights the need for clearer copyright and license declarations. I have in this PR simply provided a guideline for your consideration, and should you choose to adopt it, you should refine and ensure that the information contained in the headers is accurate.

Ultimately, how—or if—you adopt REUSE is entirely your decision based on your project’s needs. Nevertheless, I urge you to consider the wider implications of adopting the specification, and the downstream benefits of copyright and licensing clarity will provide by reducing legal and procedural mistakes in the wider Free Software ecosystem. I leave it to you to decide how you wish to proceed.

[mexon]

Thanks for the clarifications Lina. In that case I think following André's suggestion of just having a REUSE.toml file would be the way to go.

[jernst]

Given the conversation, it seems this PR needs an update.