> Versions of software can have different licenses, and the license for each version is the license that the repo was under when that version was committed.
Not particularly wrong, just adding: There can even be additional licensing terms that aren't documented in the git history so they wouldn't be visible there.
And there is another sticky detail:
So if the original copy would have violated any of the licensing terms of the revision/release being copied (e.g. by removing copyright/authoring information), any more of these copies may become tainted if that resulted in a broken license chain. At this stage it is already regardless which licensing is announced in the new repository (and at which commit).
This poses some problems on very public systems like Github as it may not be directly visible any longer.
One way to deal with it is to block the violating user on Github. It's not perfect but can help with bookkeeping.
And in general you normally should just do Github forks to file pull requests, not to actually fork projects. Not saying that you can't - you can perfectly - but more on the level of day to day operations. For a full fork, you should have actual reasons. Otherwise its ruining the benefits of copying code.
None that I can think of. History of projects is by the people who do/participate.
If you want to remove the right to modify the project (which includes the history if shared as common on Github) it is not open source (free/libre) software any longer.
In this case such a license wouldn't be needed either honestly. There would be no win with it, b/c it would have been similarly easily violated and that's it. Don't hope for a strong "legal" thing here, it won't help to solve these kind of problems (IMHO).
And for the license troll:
Instead declare the repository on Github as Database Work. Put it under a proprietary license. Github _might_ falsely read a license from a software stored in that database as the database's license, but you can easily leave an "all rights reserved" in the project description that is more prominently visible than that.
Not particularly wrong, just adding: There can even be additional licensing terms that aren't documented in the git history so they wouldn't be visible there.
And there is another sticky detail:
So if the original copy would have violated any of the licensing terms of the revision/release being copied (e.g. by removing copyright/authoring information), any more of these copies may become tainted if that resulted in a broken license chain. At this stage it is already regardless which licensing is announced in the new repository (and at which commit).
This poses some problems on very public systems like Github as it may not be directly visible any longer.
One way to deal with it is to block the violating user on Github. It's not perfect but can help with bookkeeping.
And in general you normally should just do Github forks to file pull requests, not to actually fork projects. Not saying that you can't - you can perfectly - but more on the level of day to day operations. For a full fork, you should have actual reasons. Otherwise its ruining the benefits of copying code.