On Tue, Feb 21, 2017 at 7:55 AM, G. Sylvie Davies <sylvie@xxxxxxxxxxxxxxx> wrote: > On Wed, Feb 1, 2017 at 6:26 PM, Jeff King <peff@xxxxxxxx> wrote: >> As many of you already know, the Git project (as a member of Software >> Freedom Conservancy) holds a trademark on "Git". This email will try to >> lay out a bit of the history and procedure around the enforcement of >> that trademark, along with some open questions about policy. >> >> I'll use "we" in the text below, which will generally mean the Git >> Project Leadership Committee (PLC). I.e., the people who represent the >> Git project as part of Conservancy -- me, Junio Hamano, and Shawn >> Pearce. >> >> We approached Conservancy in Feb 2013 about getting a trademark on Git >> to ensure that anything calling itself "Git" remained interoperable with >> Git. Conservancy's lawyer drafted the USPTO application and submitted it >> that summer. The trademark was granted in late 2014 (more on that delay >> in a moment). >> >> Concurrently, we developed a written trademark policy, which you can >> find here: >> >> https://git-scm.com/trademark >> >> This was started from a template that Conservancy uses and customized by >> Conservancy and the Git PLC. >> >> 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. >> >> Another is that you can't use the mark in a way that implies association >> with or endorsement by the Git project. To some degree this is necessary >> to prevent dilution of the mark for other uses, but there are also cases >> we directly want to prevent. >> >> 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. >> >> Those are all fictitious examples (actually, there _are_ real projects >> that do each of those things, but they gave themselves much more unique >> names). But they're indicative of some of the cases we've seen. I'm >> intentionally not giving the real names here, because my point isn't to >> shame any particular projects, but to discuss general policy. >> >> 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". >> >> (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. >> >> If the "libgit2" project were starting from scratch today, we'd probably >> ask it to use a different name (because the name may imply that it's an >> official successor). However, we effectively granted permission for this >> use and it would be unfair to disrupt that. >> >> There's one other policy point that has come up: the written policy >> disallows the use of "Git" or the logo on merchandise. This is something >> people have asked about it (e.g., somebody made some Git stress balls, >> and another person was printing keycaps with a Git logo). We have always >> granted it, but wanted to reserve the right in case there was some use >> that we hadn't anticipated that would be confusing or unsavory. >> >> Enforcement of the policy is done as cases are brought to the attention >> of Conservancy and the Git PLC. Sometimes people mail Conservancy >> directly, and sometimes a use is noticed by the Git PLC, which mails >> Conservancy. In either case, Conservancy's lawyer pings the Git PLC, >> and we decide what to do about it, with advice from the lawyer. The end >> result is usually a letter from the lawyer politely asking them to stop >> using the trademark. >> >> So how does the Git PLC make decisions? We generally try to follow the >> policy in an equitable way, but there are a lot of corner cases. Here >> are some rules of thumb we've worked out: >> >> - Things that are only tangentially related to Git are out of policy >> (e.g., if you had a service which rewards bitcoin for people's >> commits, we'd prefer it not be branded GitRewards). >> >> - Anything that claims to be Git but does not interoperate is out. >> We haven't had to use that one yet. >> >> - Portmanteaus ("GitFoo" or "FooGit") are out. Most of the cases run >> into this rule. For instance, we asked GitHub to not to use "DGit" >> to refer to their replicated Git solution, and they[1] rebranded. >> We also asked "GitTorrent" not to use that name based on this rule. >> >> - Commands like "git-foo" (so you run "git foo") are generally OK. >> This is Git's well-known extension mechanism, so it doesn't really >> imply endorsement (on the other hand, you do not get to complain if >> you choose too generic a name and conflict with somebody else's use >> of the same git-foo name). >> >> - When "git-foo" exists, we've approved "Git Foo" as a matching >> project name, but we haven't decided on a general rule to cover this >> case. The only example here is "Git LFS". >> >> So that's more or less where we're at now. In my opinion, a few open >> questions are: >> >> 1. Is the portmanteau clause a good idea? GitTorrent is a possibly >> interesting case there. It's an open source project trying to >> make a torrent-like protocol for Git. That's something we'd like to >> have happen. But does the name imply more endorsement than we're >> willing to give (especially at an early stage)? >> >> 2. Is it a problem that the grandfathering of some names may create a >> branding advantage? Under the policy today, we wouldn't grant >> "GitHub" or "GitLab". Does that give an unfair advantage to the >> incumbents? >> >> I think the answer is "yes", but the Git PLC is also not sure that >> there is a good solution. If we'd thought about trademark issues >> much earlier, we would have been in different circumstances and >> probably would have made different decisions. But we didn't, so we >> have to live with how things developed in the meantime. >> >> Loosening now would be a mistake as it would cause a lot of >> confusion around the trademark and make it harder for us to stop >> the uses that we really care about stopping now. >> >> 3. Was granting "Git LFS" the right call? I think the project is a good >> one and has worked well with the greater Git community. But I think >> the name has implied some level of "officialness". We obviously >> need to allow "git-lfs" as a name. But should the policy have said >> "you can call this LFS, and the command is git-lfs, but don't say >> 'Git LFS'". I'm not sure. >> >> One option would have been to ask "git-foo" to prefer "Foo for Git" >> instead of "Git Foo" in their branding (it's too late now for "Git >> LFS", so this is a hypothetical question for future requests now). >> >> 4. I think the merchandise clause has worked fine, and in general the >> plan is to grant it in most cases. I have trouble thinking of an >> item I _wouldn't_ want the Git logo on, and I'd rather err on the >> side of permissiveness than be the arbiter of taste. And having the >> Git logo on merchandise generally raises awareness of Git. >> >> But perhaps people have stronger opinions (either about the type of >> item, or perhaps the practices of the manufacturer producing it). >> It's hard to predict how a particular item would impact how people >> see the Git brand. >> >> -Peff >> >> [1] I used "they" to refer to GitHub, but as many of you know, I am also >> employed by GitHub. If you are wondering how that works, I generally >> abstain from any decisions regarding GitHub (and that includes the >> "Git LFS" decision, which was a project started by GitHub). That >> leaves two voting PLC members for those decisions; Conservancy gets >> a tie-breaking vote, but it has never come up. > > > > Is "Gitter" allowed? (https://gitter.im/). > > More info here: > > https://en.wikipedia.org/wiki/Gitter > > Also, their twitter handle is @gitchat. > > Not sure I'd even classify "gitter" as a portmanteau. > As per Junio's earlier email today, "Re: Partnership with Git", sounds like questions of this sort go to git@xxxxxxxxxxxxxxxxx. CC'ing them. - Sylvie
