> The USPTO initially rejected our application as confusingly similar to
the existing trademark on GitHub, which was filed in 2008. While one
might imagine where the "Git" in GitHub comes from, by the time we
applied to the USPTO, both marks had been widely used in parallel for
years. So we worked out an agreement with GitHub which basically says
"we are mutually OK with the other trademark existing".
> (There was another delay caused by a competing application from a
proprietary version control company that wanted to re-brand portions of
their system as "GitFocused" (not the real name, but similar in spirit).
We argued our right to the name and refused to settle; they eventually
withdrew their application).
> So GitHub is essentially outside the scope of the trademark policy, due
to the history. We also decided to explicitly grandfather some major
projects that were using similar portmanteaus, but which had generally
been good citizens of the Git ecosystem (building on Git in a useful
way, not breaking compatibility). Those include GitLab, JGit, libgit2,
and some others. The reasoning was generally that it would be a big pain
for those projects, which have established their own brands, to have to
switch names. It's hard to hold them responsible for picking a name that
violated a policy that didn't yet exist.
wow... reading the git trademark policy now, it's... surprising:
> While the original idea was to prevent people from forking the software, breaking compatibility, and still calling it Git, the policy covers several other cases.
> One is that you can't imply successorship. So you also can't fork the software, call it "Git++", and then tell everybody your implementation is the next big thing.
This seems like a massive violation of the spirit of GPL... explicitly disallowing official endorsement is one thing (since that would be lying), but you shouldn't be able to stop someone going and doing their own thing and calling it git-something.
The GPL says nothing about branding though. The GPL is about user freedom, the ability to let the user improve (and share improved version of) the software.
In general, people tend to confuse copyright/patent with branding. The former is about using, while the later is about naming. You can totally make the next git-killer, and base it on git. What you cannot do is name it "GitSomething" (regardless of whether it uses git behind the scenes), as that would be a trademark violation.
I personally think the policy makes sense, but I also understand that there might be reasonable arguments either side. But framing it as an "anti-GPL" thing seems disingenuous to me.
> In general, people tend to confuse copyright/patent with branding
I understand how trademark laws work, I'm talking about why this policy is wrong and against how OSS projects work in general. The original purpose (as stated by the policy itself) was supposedly to protect confusing forks of the same name or prevent pseudo successors, but it goes way beyond this to attack anything with git in the name.
> For example, imagine a software project which is only tangentially related to Git. It might use Git as a side effect, or might just be "Git-like" in the sense of being a distributed system with chained hashes. Let's say as an example that it does backups. We'd prefer it not call itself GitBackups. We don't endorse it, and it's just using the name to imply association that isn't there. You can come up with similar hypotheticals: GitMail that stores mailing list archives in Git, or GitWiki that uses Git as a backing store.
They reason this issue as "endorsement"... yet it's so common to have an ecosystem around a popular piece of software where project names are a derivative of the name of the core software it builds upon, I doubt anyone ever got confused or even cared much about endorsement, instead I think enforcement of this policy will just make the relationship and purpose of software built for use with git more opaque to users.
That may be so, there's probably also a whole bunch of people out there who think that Bill Gates invented the computer, it doesn't matter... it's a fools errand to try to eradicate ignorance of outsiders at the cost of disregarding any relationship that is not official and "endorsed" as invalid, i'd go as far as saying it's toxic.
Endorsement is not the only valid relationship between pieces of software, and it's definitely not the most important one. As an example of how bad this can be, git asked gitTorrent to change it's name to remove "git" - how absurd is that, git's protocols are modular, they are intended to be extended, this adds a torrent type protocol to git, it's for git... what the fuck else would you call it:
This "policy" completely disregards this as a valid relationship... why does it have to be endorsed, no one cares, they care about names that clearly communicate their purpose. gitTorrent and a thousand other extensions to git probably aren't going to be as popular as git itself, they aren't going to have enough presence that naming them something completely unique and obscure is going to be useful to users.
[edit]
I just want to say (and then I'll stop ranting), as much as this policy obviously irritates me... I love git, and so was pretty disappointed to find this, it doesn't make me love git any less, but It makes me more wary of people who "manage" open source projects.
> I guess Richard Stallman violated the "spirit of the GPL" when he made MicroGnuEmacs change their name.
No, because he asked them to remove "GNU" and It is not part of or for GNU, does not use GPL and is not a fork (it uses a combination of public domain and BSD licenses)... if he asked them to remove "Emacs" from the name then this would be the same issue - but it's not.
I am not familiar with the details of that discussion but I doubt many people would argue against me when I say it's very likely RMS was against them using GNU in the name of public domain and BSD licensed software due to significant differences in implied licensing, this is completely different reasoning to git's where it disapproves of _any_ implied relationship that is _not_ endorsed.
Also note that the focus of my comment is explicitly on the details of the significant implications to related software that is _not_ a fork or clone.
I don't think it violates the GPL, as the GPL doesn't really care about names. You still have every right to fork git, but have to call it a different name. So if you call your fork "treengler" or whatever, you'd be fine. As far as I can see, you could also still say on your website "Treengler is a fork of Git, that adds/modifies/improves... it in the following way, ...".
To me that seems to be compatible with the text as well as the spirit of the GPL. I think a similar discussion came up in the Debian project with the Firefox trademark at some point. Debian is quite picky about what it means for software to be free, and they seem to be fine with derivatives not being allowed to modify Firefox without changing the name. (At least, I think that was the end status of this discussion.)
Not against the spirit of GPL or free software at all. Governing the use of language and branding to promote software freedom is core to the movement.
The steward of git defining what does and does not have the git nature is completely in line with this. You want your own take on git? Go ahead, you explicitly have the four freedoms to do so, but don't muddy the waters by calling it git if you don't represent the project.
> You want your own take on git? Go ahead, you explicitly have the four freedoms to do so, but don't muddy the waters by calling it git if you don't represent the project.
That was the original intent of the policy and not what I have issue with, but it goes much further than that, see my other comments for details.
Keeping this relevant: GitPub is not trying to replace git obviously.
The GPL exists to preserve the rights of downstream users. In doing so, it restricts the rights of downstream developers and distributors from restricting the rights of their users.
But we could go on and on back and forth about this. I just wanted to make sure the opposing view from yours is present in the thread near your claim.
That's essentially a historical accident. From the same email[1]:
> The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing".
> GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist.
There's also some further discussion about how it probably gives them an unfair advantage, but that's the policy they've chosen to persue regardless.
If it's only portmanteaus specifically then... why, (that seems weird), and i'm sure I can find an arbitrary lab and hub name to violate them.