nbdkit VS bfg-repo-cleaner

This is correct, but doesn't quite explain why. It's because when you accept contributions from a variety of authors, without using a CLA, then your code base ends up with a patchwork of copyright, making relicensing practically impossible as you have to get buy-in from every author or else determine that author's contributions and remove/rewrite them.

GPL/LGPL are excellent licenses, but this patchwork of copyright can apply for any license you use. For a small project we wrote which was under BSD, we recently had to make a small (non-functional) change to the license, and we got buy-in from all the authors to do this which took quite a long time: https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

That second link is wrong, should be: https://gitlab.com/nbdkit/nbdkit/-/commit/a956e2e75d6c88eeef...

I think an exception might be made for a plain "C-like" struct that doesn't initialize members or contain anything except basic types. In the specific example[0] the code is actually surrounded by extern "C" { ... } so I suppose that the compiler "knows" this is a plain C struct?

[0] https://gitlab.com/nbdkit/nbdkit/-/blob/cd761c9bf770b23f678f...

We relicensed[1] a project which had 10 contributors, and we got every single one of them to do an Acked-by (by email) which took some weeks. That was the advice from our lawyers. Can't imagine the impossible hassle of doing the same for something like Linux.

[1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

So, this is a PSA that you can't simply delete the file and commit that. You must either use a tool like BFG Repo Cleaner which can scrub files out of your commit history or you could simply delete your repository and recreate it (easier, but you lose your commit history).

It shouldn't take a lot of time to modify. There is even a tool just for this scenario https://rtyley.github.io/bfg-repo-cleaner/

You need to git out the BFG: https://rtyley.github.io/bfg-repo-cleaner/

This method requires changes to be committed as usual in the regular project repository, and then committed again in the -docs repository. This is inelegant, but it provides clear distinction between private and public content. You cannot publish your regular repository without using git-filter-branch or some Git history rewriting software like BFG Repo-Cleaner. This would rewrite every commit in the history of the repo, removing all changes to the paths you don't wish to publish. This would change all the commit hashes and possibly other metadata – in short, it wouldn't be the same repository.

GFG Repo-Cleaner

You could use a repo filtering tool (e.g. BFG Repo-Cleaner) to clean up unintended information leak from your Git repository -- which retains the history timeline, but I believe it would rehash all the commits and render everything unsigned, which is probably not the desired outcome.