Create a script that automatically add/update license header in all files available in repositories

[fepitre]

We lack license field in a huge amount of files. We need to have a script that would add and update the license entry yearly based on git authors.

[iacore]

I don't think this is useful. Just having LICENSE in the git repo is enough. You don't even need to provide the whole license text; a URL to a webpage of the license full text is enough to be legally binding (at least if the copyright offender and you both live in the US). By default (without any license), no one can use the project. However, Github's terms says that by being hosted publicly on Github, anyone can fork and use it freely for personal use.

I hate projects with license in every single source file, and even taking up huge space in minified Javascript files for deployment. If someone like AWS wants to steal a open-source project, they will do it anyway.

If we want to give contributors fame, it's better to put that on the Qubes OS website instead in source code.

[marmarek]

The very LICENSE file you refer to mandates those comments:

            How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.

  To do so, attach the following notices to the program.  It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.

More on that here: https://www.gnu.org/licenses/gpl-faq.html#LicenseCopyOnly

[fepitre]

I hate projects with license in every single source file, and even taking up huge space in minified Javascript files for deployment. If someone like AWS wants to steal a open-source project, they will do it anyway.

We care about legal stuff and the issue is about updating those mandatory fields and notably copyright entries.

[ProfessorManhattan]

Hey @fepitre @marmarek @locriacyber @andrewdavidwong -- excited to be a first time contributor doing something that I personally think matters a lot. At first I thought this would be a 30 minute Node.js script but there's actually quite a bit that will be involved with a proper implementation. Here's the rundown:

1. We can use an automated tool to automatically insert the notice in each file (at first - more on why we cannot completely automate the process below). I created a configuration for a Rust CLI tool that seemed to fit here: notken12/licensesnip@fa1956d -- I realize the project only has a couple stars.. there are a couple NPM modules we can piece together that will accomplish the same thing as well.
2. Second, what do we put in the header of each file? With my 4 hour dive into source code license stamping standards, I determined that SPDX is the way to go - it's an ISO standard and used by the Linux kernel project as well. It will make Qubes OS source code easy to read for both humans and machines.
3. How do we format that header? Basically, according to this blog article - we should format it like this:

SPDX-FileCopyrightText: © {$year_of_file_creation} {$name_of_copyright_holder} <{$contact}>

SPDX-License-Identifier: {$SPDX_license_name}

4. The article points out that its source is Reuse. Reuse's standard is utilized by https://github.com/torvalds/linux. Basically, you include the above formatted comment in all the files and additionally create a LICENSES/ folder in the root of each repository that contains all the different licenses that are utilized the project. All of our code should be GPL-v2-only but since we're going this far, we might as well design the system to accomodate for things like fonts, images, copied code that should be identified with its proper license. Reuse is available via pipx and all the Linux package managers.
5. In 2019, Reuse was trying to get GitHub to adopt its standard but I assume that lost traction. In order to make the GitHub add the license badge to search results, we need to include the Qubes OS license in the traditional LICENSE file in the root of the repository. This means we would have two identical license files - one at LICENSE and one at LICENSES/GPL-v2-only.txt. The Linux kernel source code repository does not include this file - perhaps for a good reason because in the case of multi-license repositories, GitHub will convey to the user that the repository is using a specific license. We might want to take a hybrid approach and include the LICENSES/ folder if there is more than one license used by the files in the repository and use the LICENSE file if there is only one. I'll leave this up to you guys --- I can implement however you want it.
6. At first, we can do a bulk SPDX copyright injection but after that, each file will have to have the comment properly added to the top of the file since this system is meant to account for the cases where multiple types of licenses are used across different files. However, we can incorporate Reuse's linter as a pre-commit hook or a GitHub CI step.

Finally, I think the following notice (or something roughly equivalent) should be added to the bottom of each README.md file for all the repositories we want to cover with this system:

---

License

The original source code contained within this repository is licensed under GPL-2.0-only.

In some cases, Qubes OS projects include other works that use a different license. All of the licenses that this particular project is licensed under are located in the LICENSES/ folder. If multiple licenses are present in the LICENSES/ folder, you can determine the license used by a particular file by inspecting each file's SPDX identifier located at the top of the source code.

Copyright © 2012 - 2022 The Qubes OS Project and others

[ProfessorManhattan]

Please provide some feedback and I can create a POC on a repo with various file types.

Also, the Qubes OS license reference on the website just points to documentation on how to write a license. We should fill out the template, hire a legal professional on Upwork to skim over it, and run it by whoever is legally responsible for Qubes. We can then use that license for all the repositories that share the same GPL license. There's also the case of a couple repositories being marked as LGPL -- I'm not sure what to make of that at this point.

I also don't think it makes sense to include contributors in each file - I think citing "The Qubes OS Project" as the author will be taken more seriously