I think the forker here just crossed one of those invisible lines by a collection of actions that smell bad when seen as a whole.
He forked, stripped attribution and history [+] (license violation, but on its own probably just rises to the level of minor dickishness and is often a misunderstanding)
He started advertising his fork to replace the originally forked repo (a bit rude).
If the original library was unmaintained or unused, this probably would have been a big nothing-burger. But apparently the library that was quietly forked had a fairly big install base and contributing to that library first would have been a better choice.
What is missing from the discussion (and often unaccounted for in licenses themselves) is that there's a massive personal value to having a library used by large numbers of people.
[+] EDIT (to clarify): as gcr points out, this was not a standard github-style fork but rather a copy and re-commit as original history.
>> there's a massive personal value to having a library used by large numbers of people.
I have no experience with this - would you kindly explain that value? I am guessing that it has something to do with personal brand (my library is popular => I am good at this, hire me) - am I on the right track? Is there more?
That's exactly it. As someone else in this comment section described, there's "clout" from being the maintainer of a popular library and this particular action could be seen as "clout-chasing".
It's terrible that clout is such a thing in open-source, but there are complex incentive issues that led to this point.
FWIW, I don't see anything wrong with stripping the git history. I think it's stupid and short-sighted, but whatever, it's allowed. One use case I've seen, sometimes you want to pull a single file from another project without a bunch of baggage.
Your license should cover the history, in that every source file should bear a license header, going back to the first commit.
I fully agree with that. Stripping licenses is a Bad Thing™.
When I've imported foreign files from other projects that don't have license headers, I give them license headers and also append their LICENSE or COPYRIGHT file into mine; I like belts and suspenders.
Removing history, itself, is not especially problematic. History is for maintenance, merges, and downstream compatibility issues.
> it's somewhat interesting that we don't consider the source code history in our OSS licenses
I think it would be too restrictive. It might prevent you from working differently for no clear benefits. However, keeping the history is an easy way to track who contributed what so you probably should keep the history of projects with more than one contributors or you lose precise attribution in practice (apart for the other obvious reasons to keep the history).
> it's somewhat interesting that we don't consider the source code history in our OSS licenses
Developing is in the burden of the single developer/project and which kind of version control system is used to produce releases can hardly be mandated by copyright law.
It is only one reason to use a F/L/OS/S license for contributing back, that is taking part in the development project. So on the other hand, it sort of does consider that, but it's merely then in the social interaction.
What so hurtfully happened here is that a collaborator tried to break the ties (forcefully) and was powerful enough to do so.
Sure, this renders the OSS license less effective, and I guess this can be seen or felt by many developers.
> Tangentially: it's somewhat interesting that we don't consider the source code history in our OSS licenses...
IIUC, IANAL, we don't have to worry about it.
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.
As far as I know, if you replace every instance of "version" in the previous paragraph with "commit", it still applies.
I think this means that every commit is under a specific license, and therefore, the entire history is under one or more licenses.
> 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.
He forked, stripped attribution and history [+] (license violation, but on its own probably just rises to the level of minor dickishness and is often a misunderstanding)
He started advertising his fork to replace the originally forked repo (a bit rude).
If the original library was unmaintained or unused, this probably would have been a big nothing-burger. But apparently the library that was quietly forked had a fairly big install base and contributing to that library first would have been a better choice.
What is missing from the discussion (and often unaccounted for in licenses themselves) is that there's a massive personal value to having a library used by large numbers of people.
[+] EDIT (to clarify): as gcr points out, this was not a standard github-style fork but rather a copy and re-commit as original history.