That’s changing today with the launch of the Gitness open-source Git repository and the Harness Code Repository, the hosted and managed version of Gitness.
> In addition, you may not use any of the Marks as a syllable in a new word or as part of a portmanteau (e.g., "Gitalicious", "Gitpedia") used as a mark for a third-party product or service without Conservancy's written permission. For the avoidance of doubt, this provision applies even to third-party marks that use the Marks as a syllable or as part of a portmanteau to refer to a product or service's use of Git code.
You might be right, but there are already many products out there that have been violating that trademark policy for quite some time, e.g. GitLab, GitKraken, SmartGit, ...
My guess is that Software Freedom Conservancy (a nonprofit) has more important things to do than go after those projects for trademark policy violations.
Some of those were specifically grandfathered in to the policy [0]:
Careful readers among you may now be wondering about GitHub, GitLab,
Gitolite, etc. And now we get back to why it took over a year to get the
trademark granted.
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".
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.
Seems weird to still go for that policy knowing that GitHub would be immune to it. I get wanting to defend the trademark but once the cat is out of the bag (which in this case means GitHub's name being immune to said trademark), it just ends up leading to a pretty unfair market advantage for them no?
I'm sure their reasoning makes sense and that this has been taken into consideration by the git project at the time though, so I'll have to look into it!
In general, in open source, we try to respect the wishes of the developers who make our project possible regardless of whether said developers could or would pursue litigation. If a project fails to do so that's a bad sign for the future.
Comments
Wouldn’t this violate the git trademark policy?
https://git-scm.com/about/trademark
From that link:
You might be right, but there are already many products out there that have been violating that trademark policy for quite some time, e.g. GitLab, GitKraken, SmartGit, ...
My guess is that Software Freedom Conservancy (a nonprofit) has more important things to do than go after those projects for trademark policy violations.
Some of those were specifically grandfathered in to the policy [0]:
[0] https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
Seems weird to still go for that policy knowing that GitHub would be immune to it. I get wanting to defend the trademark but once the cat is out of the bag (which in this case means GitHub's name being immune to said trademark), it just ends up leading to a pretty unfair market advantage for them no?
I'm sure their reasoning makes sense and that this has been taken into consideration by the git project at the time though, so I'll have to look into it!
That's kind of an unfair advantage for github.
I'm pretty sure that many beginners think that git == github.
Wonder how that would have shaken out, had MS bought GH in 2013 instead of 2018.
You can put whatever you like in your policy documents. Doesn't mean other people have to care, or that it's legally enforceable.
In general, in open source, we try to respect the wishes of the developers who make our project possible regardless of whether said developers could or would pursue litigation. If a project fails to do so that's a bad sign for the future.