{"thread":{"id":"45017","subject":"Git trademark status and policy","startedAt":"2017-02-02T02:27:10Z","lastAt":"2018-10-25T05:21:30Z","messageCount":12,"participants":["Jeff King","G. Sylvie Davies","David Aguilar","Christian Couder","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"310696","messageId":"20170202022655.2jwvudhvo4hmueaw@sigill.intra.peff.net","threadId":"45017","inReplyTo":null,"subject":"Git trademark status and policy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-02T02:26:56Z","receivedAt":"2017-02-02T02:27:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"As many of you already know, the Git project (as a member of Software\nFreedom Conservancy) holds a trademark on \"Git\".  This email will try to\nlay out a bit of the history and procedure around the enforcement of\nthat trademark, along with some open questions about policy.\n\nI'll use \"we\" in the text below, which will generally mean the Git\nProject Leadership Committee (PLC). I.e., the people who represent the\nGit project as part of Conservancy -- me, Junio Hamano, and Shawn\nPearce.\n\nWe approached Conservancy in Feb 2013 about getting a trademark on Git\nto ensure that anything calling itself \"Git\" remained interoperable with\nGit. Conservancy's lawyer drafted the USPTO application and submitted it\nthat summer. The trademark was granted in late 2014 (more on that delay\nin a moment).\n\nConcurrently, we developed a written trademark policy, which you can\nfind here:\n\n  https://git-scm.com/trademark\n\nThis was started from a template that Conservancy uses and customized by\nConservancy and the Git PLC.\n\nWhile the original idea was to prevent people from forking the\nsoftware, breaking compatibility, and still calling it Git, the policy\ncovers several other cases.\n\nOne is that you can't imply successorship. So you also can't fork the\nsoftware, call it \"Git++\", and then tell everybody your implementation\nis the next big thing.\n\nAnother is that you can't use the mark in a way that implies association\nwith or endorsement by the Git project. To some degree this is necessary\nto prevent dilution of the mark for other uses, but there are also cases\nwe directly want to prevent.\n\nFor example, imagine a software project which is only tangentially\nrelated to Git. It might use Git as a side effect, or might just be\n\"Git-like\" in the sense of being a distributed system with chained\nhashes. Let's say as an example that it does backups. We'd prefer it\nnot call itself GitBackups. We don't endorse it, and it's just using the\nname to imply association that isn't there. You can come up with similar\nhypotheticals: GitMail that stores mailing list archives in Git, or\nGitWiki that uses Git as a backing store.\n\nThose are all fictitious examples (actually, there _are_ real projects\nthat do each of those things, but they gave themselves much more unique\nnames). But they're indicative of some of the cases we've seen. I'm\nintentionally not giving the real names here, because my point isn't to\nshame any particular projects, but to discuss general policy.\n\nCareful readers among you may now be wondering about GitHub, GitLab,\nGitolite, etc. And now we get back to why it took over a year to get the\ntrademark granted.\n\nThe USPTO initially rejected our application as confusingly similar to\nthe existing trademark on GitHub, which was filed in 2008. While one\nmight imagine where the \"Git\" in GitHub comes from, by the time we\napplied to the USPTO, both marks had been widely used in parallel for\nyears.  So we worked out an agreement with GitHub which basically says\n\"we are mutually OK with the other trademark existing\".\n\n(There was another delay caused by a competing application from a\nproprietary version control company that wanted to re-brand portions of\ntheir system as \"GitFocused\" (not the real name, but similar in spirit).\nWe argued our right to the name and refused to settle; they eventually\nwithdrew their application).\n\nSo GitHub is essentially outside the scope of the trademark policy, due\nto the history. We also decided to explicitly grandfather some major\nprojects that were using similar portmanteaus, but which had generally\nbeen good citizens of the Git ecosystem (building on Git in a useful\nway, not breaking compatibility). Those include GitLab, JGit, libgit2,\nand some others. The reasoning was generally that it would be a big pain\nfor those projects, which have established their own brands, to have to\nswitch names. It's hard to hold them responsible for picking a name that\nviolated a policy that didn't yet exist.\n\nIf the \"libgit2\" project were starting from scratch today, we'd probably\nask it to use a different name (because the name may imply that it's an\nofficial successor). However, we effectively granted permission for this\nuse and it would be unfair to disrupt that.\n\nThere's one other policy point that has come up: the written policy\ndisallows the use of \"Git\" or the logo on merchandise. This is something\npeople have asked about it (e.g., somebody made some Git stress balls,\nand another person was printing keycaps with a Git logo). We have always\ngranted it, but wanted to reserve the right in case there was some use\nthat we hadn't anticipated that would be confusing or unsavory.\n\nEnforcement of the policy is done as cases are brought to the attention\nof Conservancy and the Git PLC. Sometimes people mail Conservancy\ndirectly, and sometimes a use is noticed by the Git PLC, which mails\nConservancy.  In either case, Conservancy's lawyer pings the Git PLC,\nand we decide what to do about it, with advice from the lawyer. The end\nresult is usually a letter from the lawyer politely asking them to stop\nusing the trademark.\n\nSo how does the Git PLC make decisions? We generally try to follow the\npolicy in an equitable way, but there are a lot of corner cases. Here\nare some rules of thumb we've worked out:\n\n  - Things that are only tangentially related to Git are out of policy\n    (e.g., if you had a service which rewards bitcoin for people's\n    commits, we'd prefer it not be branded GitRewards).\n\n  - Anything that claims to be Git but does not interoperate is out.\n    We haven't had to use that one yet.\n\n  - Portmanteaus (\"GitFoo\" or \"FooGit\") are out. Most of the cases run\n    into this rule. For instance, we asked GitHub to not to use \"DGit\"\n    to refer to their replicated Git solution, and they[1] rebranded.\n    We also asked \"GitTorrent\" not to use that name based on this rule.\n\n  - Commands like \"git-foo\" (so you run \"git foo\") are generally OK.\n    This is Git's well-known extension mechanism, so it doesn't really\n    imply endorsement (on the other hand, you do not get to complain if\n    you choose too generic a name and conflict with somebody else's use\n    of the same git-foo name).\n\n  - When \"git-foo\" exists, we've approved \"Git Foo\" as a matching\n    project name, but we haven't decided on a general rule to cover this\n    case.  The only example here is \"Git LFS\".\n\nSo that's more or less where we're at now.  In my opinion, a few open\nquestions are:\n\n  1. Is the portmanteau clause a good idea? GitTorrent is a possibly\n     interesting case there. It's an open source project trying to\n     make a torrent-like protocol for Git. That's something we'd like to\n     have happen. But does the name imply more endorsement than we're\n     willing to give (especially at an early stage)?\n\n  2. Is it a problem that the grandfathering of some names may create a\n     branding advantage? Under the policy today, we wouldn't grant\n     \"GitHub\" or \"GitLab\". Does that give an unfair advantage to the\n     incumbents?\n\n     I think the answer is \"yes\", but the Git PLC is also not sure that\n     there is a good solution. If we'd thought about trademark issues\n     much earlier, we would have been in different circumstances and\n     probably would have made different decisions. But we didn't, so we\n     have to live with how things developed in the meantime.\n\n     Loosening now would be a mistake as it would cause a lot of\n     confusion around the trademark and make it harder for us to stop\n     the uses that we really care about stopping now.\n\n  3. Was granting \"Git LFS\" the right call? I think the project is a good\n     one and has worked well with the greater Git community. But I think\n     the name has implied some level of \"officialness\". We obviously\n     need to allow \"git-lfs\" as a name. But should the policy have said\n     \"you can call this LFS, and the command is git-lfs, but don't say\n     'Git LFS'\". I'm not sure.\n\n     One option would have been to ask \"git-foo\" to prefer \"Foo for Git\"\n     instead of \"Git Foo\" in their branding (it's too late now for \"Git\n     LFS\", so this is a hypothetical question for future requests now).\n\n  4. I think the merchandise clause has worked fine, and in general the\n     plan is to grant it in most cases. I have trouble thinking of an\n     item I _wouldn't_ want the Git logo on, and I'd rather err on the\n     side of permissiveness than be the arbiter of taste. And having the\n     Git logo on merchandise generally raises awareness of Git.\n\n     But perhaps people have stronger opinions (either about the type of\n     item, or perhaps the practices of the manufacturer producing it).\n     It's hard to predict how a particular item would impact how people\n     see the Git brand.\n\n-Peff\n\n[1] I used \"they\" to refer to GitHub, but as many of you know, I am also\n    employed by GitHub. If you are wondering how that works, I generally\n    abstain from any decisions regarding GitHub (and that includes the\n    \"Git LFS\" decision, which was a project started by GitHub). That\n    leaves two voting PLC members for those decisions; Conservancy gets\n    a tie-breaking vote, but it has never come up.\n"},{"id":"312203","messageId":"CAAj3zPzrD+R6kDdqR3C7aYTDjaE+Y5zN+MfoXe5EuH4ZPxroHA@mail.gmail.com","threadId":"45017","inReplyTo":"20170202022655.2jwvudhvo4hmueaw@sigill.intra.peff.net","subject":"Re: Git trademark status and policy","fromName":"G. Sylvie Davies","fromEmail":"sylvie@bit-booster.com","sentAt":"2017-02-21T15:55:15Z","receivedAt":"2017-02-21T15:55:41Z","isPatch":false,"sender":{"key":"sylvie@bit-booster.com","avatar":"https://gravatar.com/avatar/eb5bda7d3fb1e3361252bbf100d1f355ffe9ff8d8b559a08e4c7bc17d6f949d5?d=mp&s=160"},"body":"On Wed, Feb 1, 2017 at 6:26 PM, Jeff King <peff@peff.net> wrote:\n> As many of you already know, the Git project (as a member of Software\n> Freedom Conservancy) holds a trademark on \"Git\".  This email will try to\n> lay out a bit of the history and procedure around the enforcement of\n> that trademark, along with some open questions about policy.\n>\n> I'll use \"we\" in the text below, which will generally mean the Git\n> Project Leadership Committee (PLC). I.e., the people who represent the\n> Git project as part of Conservancy -- me, Junio Hamano, and Shawn\n> Pearce.\n>\n> We approached Conservancy in Feb 2013 about getting a trademark on Git\n> to ensure that anything calling itself \"Git\" remained interoperable with\n> Git. Conservancy's lawyer drafted the USPTO application and submitted it\n> that summer. The trademark was granted in late 2014 (more on that delay\n> in a moment).\n>\n> Concurrently, we developed a written trademark policy, which you can\n> find here:\n>\n>   https://git-scm.com/trademark\n>\n> This was started from a template that Conservancy uses and customized by\n> Conservancy and the Git PLC.\n>\n> While the original idea was to prevent people from forking the\n> software, breaking compatibility, and still calling it Git, the policy\n> covers several other cases.\n>\n> One is that you can't imply successorship. So you also can't fork the\n> software, call it \"Git++\", and then tell everybody your implementation\n> is the next big thing.\n>\n> Another is that you can't use the mark in a way that implies association\n> with or endorsement by the Git project. To some degree this is necessary\n> to prevent dilution of the mark for other uses, but there are also cases\n> we directly want to prevent.\n>\n> For example, imagine a software project which is only tangentially\n> related to Git. It might use Git as a side effect, or might just be\n> \"Git-like\" in the sense of being a distributed system with chained\n> hashes. Let's say as an example that it does backups. We'd prefer it\n> not call itself GitBackups. We don't endorse it, and it's just using the\n> name to imply association that isn't there. You can come up with similar\n> hypotheticals: GitMail that stores mailing list archives in Git, or\n> GitWiki that uses Git as a backing store.\n>\n> Those are all fictitious examples (actually, there _are_ real projects\n> that do each of those things, but they gave themselves much more unique\n> names). But they're indicative of some of the cases we've seen. I'm\n> intentionally not giving the real names here, because my point isn't to\n> shame any particular projects, but to discuss general policy.\n>\n> Careful readers among you may now be wondering about GitHub, GitLab,\n> Gitolite, etc. And now we get back to why it took over a year to get the\n> trademark granted.\n>\n> The USPTO initially rejected our application as confusingly similar to\n> the existing trademark on GitHub, which was filed in 2008. While one\n> might imagine where the \"Git\" in GitHub comes from, by the time we\n> applied to the USPTO, both marks had been widely used in parallel for\n> years.  So we worked out an agreement with GitHub which basically says\n> \"we are mutually OK with the other trademark existing\".\n>\n> (There was another delay caused by a competing application from a\n> proprietary version control company that wanted to re-brand portions of\n> their system as \"GitFocused\" (not the real name, but similar in spirit).\n> We argued our right to the name and refused to settle; they eventually\n> withdrew their application).\n>\n> So GitHub is essentially outside the scope of the trademark policy, due\n> to the history. We also decided to explicitly grandfather some major\n> projects that were using similar portmanteaus, but which had generally\n> been good citizens of the Git ecosystem (building on Git in a useful\n> way, not breaking compatibility). Those include GitLab, JGit, libgit2,\n> and some others. The reasoning was generally that it would be a big pain\n> for those projects, which have established their own brands, to have to\n> switch names. It's hard to hold them responsible for picking a name that\n> violated a policy that didn't yet exist.\n>\n> If the \"libgit2\" project were starting from scratch today, we'd probably\n> ask it to use a different name (because the name may imply that it's an\n> official successor). However, we effectively granted permission for this\n> use and it would be unfair to disrupt that.\n>\n> There's one other policy point that has come up: the written policy\n> disallows the use of \"Git\" or the logo on merchandise. This is something\n> people have asked about it (e.g., somebody made some Git stress balls,\n> and another person was printing keycaps with a Git logo). We have always\n> granted it, but wanted to reserve the right in case there was some use\n> that we hadn't anticipated that would be confusing or unsavory.\n>\n> Enforcement of the policy is done as cases are brought to the attention\n> of Conservancy and the Git PLC. Sometimes people mail Conservancy\n> directly, and sometimes a use is noticed by the Git PLC, which mails\n> Conservancy.  In either case, Conservancy's lawyer pings the Git PLC,\n> and we decide what to do about it, with advice from the lawyer. The end\n> result is usually a letter from the lawyer politely asking them to stop\n> using the trademark.\n>\n> So how does the Git PLC make decisions? We generally try to follow the\n> policy in an equitable way, but there are a lot of corner cases. Here\n> are some rules of thumb we've worked out:\n>\n>   - Things that are only tangentially related to Git are out of policy\n>     (e.g., if you had a service which rewards bitcoin for people's\n>     commits, we'd prefer it not be branded GitRewards).\n>\n>   - Anything that claims to be Git but does not interoperate is out.\n>     We haven't had to use that one yet.\n>\n>   - Portmanteaus (\"GitFoo\" or \"FooGit\") are out. Most of the cases run\n>     into this rule. For instance, we asked GitHub to not to use \"DGit\"\n>     to refer to their replicated Git solution, and they[1] rebranded.\n>     We also asked \"GitTorrent\" not to use that name based on this rule.\n>\n>   - Commands like \"git-foo\" (so you run \"git foo\") are generally OK.\n>     This is Git's well-known extension mechanism, so it doesn't really\n>     imply endorsement (on the other hand, you do not get to complain if\n>     you choose too generic a name and conflict with somebody else's use\n>     of the same git-foo name).\n>\n>   - When \"git-foo\" exists, we've approved \"Git Foo\" as a matching\n>     project name, but we haven't decided on a general rule to cover this\n>     case.  The only example here is \"Git LFS\".\n>\n> So that's more or less where we're at now.  In my opinion, a few open\n> questions are:\n>\n>   1. Is the portmanteau clause a good idea? GitTorrent is a possibly\n>      interesting case there. It's an open source project trying to\n>      make a torrent-like protocol for Git. That's something we'd like to\n>      have happen. But does the name imply more endorsement than we're\n>      willing to give (especially at an early stage)?\n>\n>   2. Is it a problem that the grandfathering of some names may create a\n>      branding advantage? Under the policy today, we wouldn't grant\n>      \"GitHub\" or \"GitLab\". Does that give an unfair advantage to the\n>      incumbents?\n>\n>      I think the answer is \"yes\", but the Git PLC is also not sure that\n>      there is a good solution. If we'd thought about trademark issues\n>      much earlier, we would have been in different circumstances and\n>      probably would have made different decisions. But we didn't, so we\n>      have to live with how things developed in the meantime.\n>\n>      Loosening now would be a mistake as it would cause a lot of\n>      confusion around the trademark and make it harder for us to stop\n>      the uses that we really care about stopping now.\n>\n>   3. Was granting \"Git LFS\" the right call? I think the project is a good\n>      one and has worked well with the greater Git community. But I think\n>      the name has implied some level of \"officialness\". We obviously\n>      need to allow \"git-lfs\" as a name. But should the policy have said\n>      \"you can call this LFS, and the command is git-lfs, but don't say\n>      'Git LFS'\". I'm not sure.\n>\n>      One option would have been to ask \"git-foo\" to prefer \"Foo for Git\"\n>      instead of \"Git Foo\" in their branding (it's too late now for \"Git\n>      LFS\", so this is a hypothetical question for future requests now).\n>\n>   4. I think the merchandise clause has worked fine, and in general the\n>      plan is to grant it in most cases. I have trouble thinking of an\n>      item I _wouldn't_ want the Git logo on, and I'd rather err on the\n>      side of permissiveness than be the arbiter of taste. And having the\n>      Git logo on merchandise generally raises awareness of Git.\n>\n>      But perhaps people have stronger opinions (either about the type of\n>      item, or perhaps the practices of the manufacturer producing it).\n>      It's hard to predict how a particular item would impact how people\n>      see the Git brand.\n>\n> -Peff\n>\n> [1] I used \"they\" to refer to GitHub, but as many of you know, I am also\n>     employed by GitHub. If you are wondering how that works, I generally\n>     abstain from any decisions regarding GitHub (and that includes the\n>     \"Git LFS\" decision, which was a project started by GitHub). That\n>     leaves two voting PLC members for those decisions; Conservancy gets\n>     a tie-breaking vote, but it has never come up.\n\n\n\nIs \"Gitter\" allowed?   (https://gitter.im/).\n\nMore info here:\n\nhttps://en.wikipedia.org/wiki/Gitter\n\nAlso, their twitter handle is @gitchat.\n\nNot sure I'd even classify \"gitter\" as a portmanteau.\n\n\n\n- Sylvie\n"},{"id":"312233","messageId":"20170221223113.ibtnngj3dwbtovs7@sigill.intra.peff.net","threadId":"45017","inReplyTo":"CAAj3zPzrD+R6kDdqR3C7aYTDjaE+Y5zN+MfoXe5EuH4ZPxroHA@mail.gmail.com","subject":"Re: Git trademark status and policy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-21T22:31:13Z","receivedAt":"2017-02-21T22:31:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 21, 2017 at 07:55:15AM -0800, G. Sylvie Davies wrote:\n\n> Is \"Gitter\" allowed?   (https://gitter.im/).\n> \n> More info here:\n> \n> https://en.wikipedia.org/wiki/Gitter\n> \n> Also, their twitter handle is @gitchat.\n> \n> Not sure I'd even classify \"gitter\" as a portmanteau.\n\nI don't think the Git committee has discussed that one. I'll mention it\nthere.\n\nI wouldn't get hung up on the \"is it a strict portmanteau\" question. I\nthink the more important question is whether it creates confusion about\nendorsement or interoperability. The portmanteau thing is more of a rule\nof thumb there. (That's all IMHO, of course, and not an official\nstatement of the committee).\n\n-Peff\n"},{"id":"312267","messageId":"CAAj3zPx+mcfTU=iKC=GS53==+UP=ZxtCxrMx_zs=tDB9U76xAA@mail.gmail.com","threadId":"45017","inReplyTo":"CAAj3zPzrD+R6kDdqR3C7aYTDjaE+Y5zN+MfoXe5EuH4ZPxroHA@mail.gmail.com","subject":"Re: Git trademark status and policy","fromName":"G. Sylvie Davies","fromEmail":"sylvie@bit-booster.com","sentAt":"2017-02-22T01:01:49Z","receivedAt":"2017-02-22T01:01:57Z","isPatch":false,"sender":{"key":"sylvie@bit-booster.com","avatar":"https://gravatar.com/avatar/eb5bda7d3fb1e3361252bbf100d1f355ffe9ff8d8b559a08e4c7bc17d6f949d5?d=mp&s=160"},"body":"On Tue, Feb 21, 2017 at 7:55 AM, G. Sylvie Davies\n<sylvie@bit-booster.com> wrote:\n> On Wed, Feb 1, 2017 at 6:26 PM, Jeff King <peff@peff.net> wrote:\n>> As many of you already know, the Git project (as a member of Software\n>> Freedom Conservancy) holds a trademark on \"Git\".  This email will try to\n>> lay out a bit of the history and procedure around the enforcement of\n>> that trademark, along with some open questions about policy.\n>>\n>> I'll use \"we\" in the text below, which will generally mean the Git\n>> Project Leadership Committee (PLC). I.e., the people who represent the\n>> Git project as part of Conservancy -- me, Junio Hamano, and Shawn\n>> Pearce.\n>>\n>> We approached Conservancy in Feb 2013 about getting a trademark on Git\n>> to ensure that anything calling itself \"Git\" remained interoperable with\n>> Git. Conservancy's lawyer drafted the USPTO application and submitted it\n>> that summer. The trademark was granted in late 2014 (more on that delay\n>> in a moment).\n>>\n>> Concurrently, we developed a written trademark policy, which you can\n>> find here:\n>>\n>>   https://git-scm.com/trademark\n>>\n>> This was started from a template that Conservancy uses and customized by\n>> Conservancy and the Git PLC.\n>>\n>> While the original idea was to prevent people from forking the\n>> software, breaking compatibility, and still calling it Git, the policy\n>> covers several other cases.\n>>\n>> One is that you can't imply successorship. So you also can't fork the\n>> software, call it \"Git++\", and then tell everybody your implementation\n>> is the next big thing.\n>>\n>> Another is that you can't use the mark in a way that implies association\n>> with or endorsement by the Git project. To some degree this is necessary\n>> to prevent dilution of the mark for other uses, but there are also cases\n>> we directly want to prevent.\n>>\n>> For example, imagine a software project which is only tangentially\n>> related to Git. It might use Git as a side effect, or might just be\n>> \"Git-like\" in the sense of being a distributed system with chained\n>> hashes. Let's say as an example that it does backups. We'd prefer it\n>> not call itself GitBackups. We don't endorse it, and it's just using the\n>> name to imply association that isn't there. You can come up with similar\n>> hypotheticals: GitMail that stores mailing list archives in Git, or\n>> GitWiki that uses Git as a backing store.\n>>\n>> Those are all fictitious examples (actually, there _are_ real projects\n>> that do each of those things, but they gave themselves much more unique\n>> names). But they're indicative of some of the cases we've seen. I'm\n>> intentionally not giving the real names here, because my point isn't to\n>> shame any particular projects, but to discuss general policy.\n>>\n>> Careful readers among you may now be wondering about GitHub, GitLab,\n>> Gitolite, etc. And now we get back to why it took over a year to get the\n>> trademark granted.\n>>\n>> The USPTO initially rejected our application as confusingly similar to\n>> the existing trademark on GitHub, which was filed in 2008. While one\n>> might imagine where the \"Git\" in GitHub comes from, by the time we\n>> applied to the USPTO, both marks had been widely used in parallel for\n>> years.  So we worked out an agreement with GitHub which basically says\n>> \"we are mutually OK with the other trademark existing\".\n>>\n>> (There was another delay caused by a competing application from a\n>> proprietary version control company that wanted to re-brand portions of\n>> their system as \"GitFocused\" (not the real name, but similar in spirit).\n>> We argued our right to the name and refused to settle; they eventually\n>> withdrew their application).\n>>\n>> So GitHub is essentially outside the scope of the trademark policy, due\n>> to the history. We also decided to explicitly grandfather some major\n>> projects that were using similar portmanteaus, but which had generally\n>> been good citizens of the Git ecosystem (building on Git in a useful\n>> way, not breaking compatibility). Those include GitLab, JGit, libgit2,\n>> and some others. The reasoning was generally that it would be a big pain\n>> for those projects, which have established their own brands, to have to\n>> switch names. It's hard to hold them responsible for picking a name that\n>> violated a policy that didn't yet exist.\n>>\n>> If the \"libgit2\" project were starting from scratch today, we'd probably\n>> ask it to use a different name (because the name may imply that it's an\n>> official successor). However, we effectively granted permission for this\n>> use and it would be unfair to disrupt that.\n>>\n>> There's one other policy point that has come up: the written policy\n>> disallows the use of \"Git\" or the logo on merchandise. This is something\n>> people have asked about it (e.g., somebody made some Git stress balls,\n>> and another person was printing keycaps with a Git logo). We have always\n>> granted it, but wanted to reserve the right in case there was some use\n>> that we hadn't anticipated that would be confusing or unsavory.\n>>\n>> Enforcement of the policy is done as cases are brought to the attention\n>> of Conservancy and the Git PLC. Sometimes people mail Conservancy\n>> directly, and sometimes a use is noticed by the Git PLC, which mails\n>> Conservancy.  In either case, Conservancy's lawyer pings the Git PLC,\n>> and we decide what to do about it, with advice from the lawyer. The end\n>> result is usually a letter from the lawyer politely asking them to stop\n>> using the trademark.\n>>\n>> So how does the Git PLC make decisions? We generally try to follow the\n>> policy in an equitable way, but there are a lot of corner cases. Here\n>> are some rules of thumb we've worked out:\n>>\n>>   - Things that are only tangentially related to Git are out of policy\n>>     (e.g., if you had a service which rewards bitcoin for people's\n>>     commits, we'd prefer it not be branded GitRewards).\n>>\n>>   - Anything that claims to be Git but does not interoperate is out.\n>>     We haven't had to use that one yet.\n>>\n>>   - Portmanteaus (\"GitFoo\" or \"FooGit\") are out. Most of the cases run\n>>     into this rule. For instance, we asked GitHub to not to use \"DGit\"\n>>     to refer to their replicated Git solution, and they[1] rebranded.\n>>     We also asked \"GitTorrent\" not to use that name based on this rule.\n>>\n>>   - Commands like \"git-foo\" (so you run \"git foo\") are generally OK.\n>>     This is Git's well-known extension mechanism, so it doesn't really\n>>     imply endorsement (on the other hand, you do not get to complain if\n>>     you choose too generic a name and conflict with somebody else's use\n>>     of the same git-foo name).\n>>\n>>   - When \"git-foo\" exists, we've approved \"Git Foo\" as a matching\n>>     project name, but we haven't decided on a general rule to cover this\n>>     case.  The only example here is \"Git LFS\".\n>>\n>> So that's more or less where we're at now.  In my opinion, a few open\n>> questions are:\n>>\n>>   1. Is the portmanteau clause a good idea? GitTorrent is a possibly\n>>      interesting case there. It's an open source project trying to\n>>      make a torrent-like protocol for Git. That's something we'd like to\n>>      have happen. But does the name imply more endorsement than we're\n>>      willing to give (especially at an early stage)?\n>>\n>>   2. Is it a problem that the grandfathering of some names may create a\n>>      branding advantage? Under the policy today, we wouldn't grant\n>>      \"GitHub\" or \"GitLab\". Does that give an unfair advantage to the\n>>      incumbents?\n>>\n>>      I think the answer is \"yes\", but the Git PLC is also not sure that\n>>      there is a good solution. If we'd thought about trademark issues\n>>      much earlier, we would have been in different circumstances and\n>>      probably would have made different decisions. But we didn't, so we\n>>      have to live with how things developed in the meantime.\n>>\n>>      Loosening now would be a mistake as it would cause a lot of\n>>      confusion around the trademark and make it harder for us to stop\n>>      the uses that we really care about stopping now.\n>>\n>>   3. Was granting \"Git LFS\" the right call? I think the project is a good\n>>      one and has worked well with the greater Git community. But I think\n>>      the name has implied some level of \"officialness\". We obviously\n>>      need to allow \"git-lfs\" as a name. But should the policy have said\n>>      \"you can call this LFS, and the command is git-lfs, but don't say\n>>      'Git LFS'\". I'm not sure.\n>>\n>>      One option would have been to ask \"git-foo\" to prefer \"Foo for Git\"\n>>      instead of \"Git Foo\" in their branding (it's too late now for \"Git\n>>      LFS\", so this is a hypothetical question for future requests now).\n>>\n>>   4. I think the merchandise clause has worked fine, and in general the\n>>      plan is to grant it in most cases. I have trouble thinking of an\n>>      item I _wouldn't_ want the Git logo on, and I'd rather err on the\n>>      side of permissiveness than be the arbiter of taste. And having the\n>>      Git logo on merchandise generally raises awareness of Git.\n>>\n>>      But perhaps people have stronger opinions (either about the type of\n>>      item, or perhaps the practices of the manufacturer producing it).\n>>      It's hard to predict how a particular item would impact how people\n>>      see the Git brand.\n>>\n>> -Peff\n>>\n>> [1] I used \"they\" to refer to GitHub, but as many of you know, I am also\n>>     employed by GitHub. If you are wondering how that works, I generally\n>>     abstain from any decisions regarding GitHub (and that includes the\n>>     \"Git LFS\" decision, which was a project started by GitHub). That\n>>     leaves two voting PLC members for those decisions; Conservancy gets\n>>     a tie-breaking vote, but it has never come up.\n>\n>\n>\n> Is \"Gitter\" allowed?   (https://gitter.im/).\n>\n> More info here:\n>\n> https://en.wikipedia.org/wiki/Gitter\n>\n> Also, their twitter handle is @gitchat.\n>\n> Not sure I'd even classify \"gitter\" as a portmanteau.\n>\n\nAs per Junio's earlier email today, \"Re: Partnership with Git\", sounds\nlike questions of this sort go to git@sfconservancy.org.  CC'ing them.\n\n- Sylvie\n"},{"id":"358232","messageId":"20180916101520.GC18517@gmail.com","threadId":"45017","inReplyTo":"20170202022655.2jwvudhvo4hmueaw@sigill.intra.peff.net","subject":"Re: Git trademark status and policy","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2018-09-16T10:15:20Z","receivedAt":"2018-09-16T10:15:26Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"Hi Peff,\n\nOn Thu, Feb 02, 2017 at 03:26:56AM +0100, Jeff King wrote:\n> \n>   - Commands like \"git-foo\" (so you run \"git foo\") are generally OK.\n>     This is Git's well-known extension mechanism, so it doesn't really\n>     imply endorsement (on the other hand, you do not get to complain if\n>     you choose too generic a name and conflict with somebody else's use\n>     of the same git-foo name).\n> \n>   - When \"git-foo\" exists, we've approved \"Git Foo\" as a matching\n>     project name, but we haven't decided on a general rule to cover this\n>     case.  The only example here is \"Git LFS\".\n\nThe \"Git Cola\" project[1][2] provides two fully-featured Git porcelains,\n\"git-cola\" and \"git-dag\".  The DAG tool is never referred to as a\nseparate project, so shouldn't be a concern trademark wise.\n\nThe project dates back to 2007, while the \"Git Cola\" name dates back to 2008.\nFTR, the name \"Cola\" is also a shout-out to Linux (comp.os.linux.announce).\n\nCan we continue to use the name \"Git Cola\" going forward?\n\n\n> So that's more or less where we're at now.  In my opinion, a few open\n> questions are:\n> \n>   3. Was granting \"Git LFS\" the right call? I think the project is a good\n>      one and has worked well with the greater Git community. But I think\n>      the name has implied some level of \"officialness\". We obviously\n>      need to allow \"git-lfs\" as a name. But should the policy have said\n>      \"you can call this LFS, and the command is git-lfs, but don't say\n>      'Git LFS'\". I'm not sure.\n> \n>      One option would have been to ask \"git-foo\" to prefer \"Foo for Git\"\n>      instead of \"Git Foo\" in their branding (it's too late now for \"Git\n>      LFS\", so this is a hypothetical question for future requests now).\n> \n> -Peff\n\nIn my (biased) opinion, granting \"Git LFS\" was the right call.\n\nAs long as the project is clearly a separate, but primarily Git-centric,\nproject then it seems like the right approach to allow \"Git Foo\" for\nopen source projects that contribute positively to the Git ecosystem.\n\nLastly, due to time constraints, the Git Cola logo is a tweaked version\nof the Git logo, which may convey a level of \"officialness\" that might\nbe unwanted.  We can work on a replacement if desired.\n\nPart of keeping the logo/visual identity close to core Git is because\nthe tool was always meant to be strongly tied to Git's unique features.\nIt's probably the same reason why the git-lfs branding uses similar\norange/red palettes -- to convey cohesiveness.  I would prefer to keep\nthe visual identity as-is (including the logo).\n\nCan we continue to use the derivative logo for the time being until a\nreplacement is produced?  Alternatively, can we keep the logo as-is?\n\n\ncheers,\n\n[1] https://git-cola.github.io/\n[2] https://github.com/git-cola/git-cola\n-- \nDavid\n"},{"id":"358245","messageId":"20180917032101.GD22024@sigill.intra.peff.net","threadId":"45017","inReplyTo":"20180916101520.GC18517@gmail.com","subject":"Re: Git trademark status and policy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-17T03:21:01Z","receivedAt":"2018-09-17T03:21:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote:\n\n> On Thu, Feb 02, 2017 at 03:26:56AM +0100, Jeff King wrote:\n> > \n> >   - Commands like \"git-foo\" (so you run \"git foo\") are generally OK.\n> >     This is Git's well-known extension mechanism, so it doesn't really\n> >     imply endorsement (on the other hand, you do not get to complain if\n> >     you choose too generic a name and conflict with somebody else's use\n> >     of the same git-foo name).\n> > \n> >   - When \"git-foo\" exists, we've approved \"Git Foo\" as a matching\n> >     project name, but we haven't decided on a general rule to cover this\n> >     case.  The only example here is \"Git LFS\".\n> \n> The \"Git Cola\" project[1][2] provides two fully-featured Git porcelains,\n> \"git-cola\" and \"git-dag\".  The DAG tool is never referred to as a\n> separate project, so shouldn't be a concern trademark wise.\n> \n> The project dates back to 2007, while the \"Git Cola\" name dates back to 2008.\n> FTR, the name \"Cola\" is also a shout-out to Linux (comp.os.linux.announce).\n> \n> Can we continue to use the name \"Git Cola\" going forward?\n\nThanks for asking.\n\nAn official answer will have to involve opinions and a vote from the\nwhole PLC, but let me tell you what _I_ think:\n\n  - we mostly grandfathered good-faith names that predate the trademark,\n    even if we probably wouldn't grant them today. Searching my mail\n    archives, I see that git-cola did come up (along with a few others\n    like Gitolite and TortoiseGit). And we even ended up with written\n    agreements for some (at the very least GitLab and Gitolite), but I\n    think several (including git-cola) were never officially resolved in\n    anyway.\n\n  - In my opinion \"Git Cola\" is a lot less confusing than something like\n    \"Git Cloner\". Because there is little chance that somebody might say\n    \"Ah, the official Cola of Git!\". Whereas a generic operational term\n    like \"Cloner\" does introduce confusion (the \"Git\" is easily\n    interpreted as \"Git presents X\" and not \"this is an X for using with\n    Git\").\n\nSo my opinion is that it is not something the project should be worried\nabout. But like I said, do not take that as an official position at this\npoint.\n\n(Also, to be clear, this is all _only_ about \"Git Cola\". The \"git-cola\"\ncommand is explicitly OK in the policy because that's how commands\nwork).\n\n> > So that's more or less where we're at now.  In my opinion, a few open\n> > questions are:\n> > \n> >   3. Was granting \"Git LFS\" the right call? I think the project is a good\n> >      one and has worked well with the greater Git community. But I think\n> >      the name has implied some level of \"officialness\". We obviously\n> >      need to allow \"git-lfs\" as a name. But should the policy have said\n> >      \"you can call this LFS, and the command is git-lfs, but don't say\n> >      'Git LFS'\". I'm not sure.\n> > \n> >      One option would have been to ask \"git-foo\" to prefer \"Foo for Git\"\n> >      instead of \"Git Foo\" in their branding (it's too late now for \"Git\n> >      LFS\", so this is a hypothetical question for future requests now).\n> \n> In my (biased) opinion, granting \"Git LFS\" was the right call.\n> \n> As long as the project is clearly a separate, but primarily Git-centric,\n> project then it seems like the right approach to allow \"Git Foo\" for\n> open source projects that contribute positively to the Git ecosystem.\n\nYes, I have to admit that being a good citizen of the ecosystem counts\nfor a lot in my book. But it's often helpful to make these decisions\nearly on in the project's life (because name changes are awkward later\non), and we have to just guess at how things will play out. Git Cola is\nagain easier there because of the history.\n\n> Lastly, due to time constraints, the Git Cola logo is a tweaked version\n> of the Git logo, which may convey a level of \"officialness\" that might\n> be unwanted.  We can work on a replacement if desired.\n> \n> Part of keeping the logo/visual identity close to core Git is because\n> the tool was always meant to be strongly tied to Git's unique features.\n> It's probably the same reason why the git-lfs branding uses similar\n> orange/red palettes -- to convey cohesiveness.  I would prefer to keep\n> the visual identity as-is (including the logo).\n> \n> Can we continue to use the derivative logo for the time being until a\n> replacement is produced?  Alternatively, can we keep the logo as-is?\n\nI don't think this is a question we've ever really considered before.\n\nI had to actually dig a little to find any use of the logo, which\ndoesn't seem to be on most of your screenshots. :) For reference, this\nis the one I found:\n\n  https://github.com/git-cola/git-cola/blob/master/share/git-cola/icons/git-cola.svg\n\nI do think that's much more ambiguous than just the name when it comes\nto potentially confusing endorsement. If a random proprietary GUI client\nhad a logo like that, I think we'd probably ask them to change it. But I\nhave to admit that given the general good history of git-cola, the fact\nthat it's open-source, and the fact that its main developer is also a\nhelpful member of the Git development community, I'm less inclined to do\nso here.\n\nSo in that sense, I don't have any problem saying \"sure, let's make an\nexplicit exception here\". But I do wonder if we're better off trying to\nbe as even and impartial as possible, so as not to create funny\ndistortions (i.e., doing anything that endorses one over the other; I\ndon't really use any graphical interface around Git, and I don't have an\nopinion on the technical qualities).\n\nI'd be curious to hear what other people in the community think.\n\n-Peff\n"},{"id":"358247","messageId":"CAP8UFD2cC7VMu7Zp9NaXj4x0BMBPZ5CJ6prwEv+s24SuNG=7JA@mail.gmail.com","threadId":"45017","inReplyTo":"20180917032101.GD22024@sigill.intra.peff.net","subject":"Re: Git trademark status and policy","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-09-17T09:25:31Z","receivedAt":"2018-09-17T09:25:34Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Sep 17, 2018 at 5:21 AM, Jeff King <peff@peff.net> wrote:\n> On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote:\n\n>> The \"Git Cola\" project[1][2] provides two fully-featured Git porcelains,\n>> \"git-cola\" and \"git-dag\".  The DAG tool is never referred to as a\n>> separate project, so shouldn't be a concern trademark wise.\n>>\n>> The project dates back to 2007, while the \"Git Cola\" name dates back to 2008.\n>> FTR, the name \"Cola\" is also a shout-out to Linux (comp.os.linux.announce).\n\n[...]\n\n> An official answer will have to involve opinions and a vote from the\n> whole PLC, but let me tell you what _I_ think:\n>\n>   - we mostly grandfathered good-faith names that predate the trademark,\n>     even if we probably wouldn't grant them today. Searching my mail\n>     archives, I see that git-cola did come up (along with a few others\n>     like Gitolite and TortoiseGit). And we even ended up with written\n>     agreements for some (at the very least GitLab and Gitolite), but I\n>     think several (including git-cola) were never officially resolved in\n>     anyway.\n>\n>   - In my opinion \"Git Cola\" is a lot less confusing than something like\n>     \"Git Cloner\". Because there is little chance that somebody might say\n>     \"Ah, the official Cola of Git!\". Whereas a generic operational term\n>     like \"Cloner\" does introduce confusion (the \"Git\" is easily\n>     interpreted as \"Git presents X\" and not \"this is an X for using with\n>     Git\").\n>\n> So my opinion is that it is not something the project should be worried\n> about. But like I said, do not take that as an official position at this\n> point.\n\nI agree with that. I think that old projects that have been known for\na very long time and that don't have a confusing name should\ndefinitely be ok.\n\n> (Also, to be clear, this is all _only_ about \"Git Cola\". The \"git-cola\"\n> command is explicitly OK in the policy because that's how commands\n> work).\n\nI agree about \"git-cola\" though I wonder about \"git-dag\" as this is\nanother command used by the project that is more generic. For example\nI could imagine that, if we wanted to provide a shortcut for `git log\n--graph --decorate --oneline`, we might want to use `git dag`.\n\nI guess we can still recommend to change it if possible, though we can\nalso acknowledge that, as our recommendation comes very late (too\nlate?), it is just a \"weak\" recommendation.\n\n>> In my (biased) opinion, granting \"Git LFS\" was the right call.\n>>\n>> As long as the project is clearly a separate, but primarily Git-centric,\n>> project then it seems like the right approach to allow \"Git Foo\" for\n>> open source projects that contribute positively to the Git ecosystem.\n\nI agree especially as \"LFS\" is not generic.\n\n[...]\n\n>> Lastly, due to time constraints, the Git Cola logo is a tweaked version\n>> of the Git logo, which may convey a level of \"officialness\" that might\n>> be unwanted.  We can work on a replacement if desired.\n>>\n>> Part of keeping the logo/visual identity close to core Git is because\n>> the tool was always meant to be strongly tied to Git's unique features.\n>> It's probably the same reason why the git-lfs branding uses similar\n>> orange/red palettes -- to convey cohesiveness.  I would prefer to keep\n>> the visual identity as-is (including the logo).\n>>\n>> Can we continue to use the derivative logo for the time being until a\n>> replacement is produced?  Alternatively, can we keep the logo as-is?\n>\n> I don't think this is a question we've ever really considered before.\n>\n> I had to actually dig a little to find any use of the logo, which\n> doesn't seem to be on most of your screenshots. :) For reference, this\n> is the one I found:\n>\n>   https://github.com/git-cola/git-cola/blob/master/share/git-cola/icons/git-cola.svg\n\nThanks for digging and sending the link as I previously thought that\nthe logo was actually this:\n\nhttps://git-cola.github.io/images/logo-top.png\n\nwhich is on top of their homepage.\n\n> I do think that's much more ambiguous than just the name when it comes\n> to potentially confusing endorsement. If a random proprietary GUI client\n> had a logo like that, I think we'd probably ask them to change it. But I\n> have to admit that given the general good history of git-cola, the fact\n> that it's open-source, and the fact that its main developer is also a\n> helpful member of the Git development community, I'm less inclined to do\n> so here.\n>\n> So in that sense, I don't have any problem saying \"sure, let's make an\n> explicit exception here\". But I do wonder if we're better off trying to\n> be as even and impartial as possible, so as not to create funny\n> distortions (i.e., doing anything that endorses one over the other; I\n> don't really use any graphical interface around Git, and I don't have an\n> opinion on the technical qualities).\n>\n> I'd be curious to hear what other people in the community think.\n\nMy opinion on the logo is that they should probably make it clearer in\ngeneral what their visual identity is, as the 2 images on the above\nlinks are quite different. And if they do that, yeah, it would be nice\nif the logo that comes out is a bit less similar as the Git logo. In\ngeneral I think logos and visual identities are easier to change than\nnames.\n"},{"id":"358257","messageId":"xmqqd0tc9qek.fsf@gitster-ct.c.googlers.com","threadId":"45017","inReplyTo":"20180917032101.GD22024@sigill.intra.peff.net","subject":"Re: Git trademark status and policy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-09-17T13:58:43Z","receivedAt":"2018-09-17T13:58:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> (Also, to be clear, this is all _only_ about \"Git Cola\". The \"git-cola\"\n> command is explicitly OK in the policy because that's how commands\n> work).\n\nThese match my understanding.  Thanks for spelling them out.  That\nproject is an example of being a good ecosystem citizen whose name\nwe were happy to grand-father while discussing the trademark policy.\n\nI can undertand the sentiment that we may not want to appear drawing\nlines among friends, but ultimately the policy is about protecting\nour friends from non-friends, so whether we like it or not, we may\nhave to be more explicit about who's grandfathered and who's not\nthan before.\n"},{"id":"358410","messageId":"20180918182222.GA24448@sigill.intra.peff.net","threadId":"45017","inReplyTo":"CAP8UFD2cC7VMu7Zp9NaXj4x0BMBPZ5CJ6prwEv+s24SuNG=7JA@mail.gmail.com","subject":"Re: Git trademark status and policy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-18T18:22:22Z","receivedAt":"2018-09-18T18:22:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 17, 2018 at 11:25:31AM +0200, Christian Couder wrote:\n\n> > (Also, to be clear, this is all _only_ about \"Git Cola\". The \"git-cola\"\n> > command is explicitly OK in the policy because that's how commands\n> > work).\n> \n> I agree about \"git-cola\" though I wonder about \"git-dag\" as this is\n> another command used by the project that is more generic. For example\n> I could imagine that, if we wanted to provide a shortcut for `git log\n> --graph --decorate --oneline`, we might want to use `git dag`.\n> \n> I guess we can still recommend to change it if possible, though we can\n> also acknowledge that, as our recommendation comes very late (too\n> late?), it is just a \"weak\" recommendation.\n\nYeah, I agree with you, though I think it is a separate issue. \"git-dag\"\nis explicitly OK in the trademark policy, and they are not using \"Git\nDag\" in any recognizable way.\n\nSo I think there is no trademark issue, but \"git-dag\" is probably just\nnot a great idea in general, because the namespace is open and it is\nlikely to get stomped by some other project. Or git itself. Or it may\neven be annoying for users who have a \"git dag\" alias (on-disk commands\nalways override aliases).\n\nSo I think we should generally recommend against such generic names\nduring the naming phase. At this point, I'm not sure the pain of\nchanging now is any less than the pain of changing later if and when\nthere's a conflict.\n\nI think I'm actually violently agreeing with you, but I wanted to make\nit clear. :) (And everything else in your email seemed sensible, too).\n\n-Peff\n"},{"id":"358411","messageId":"20180918182450.GB24448@sigill.intra.peff.net","threadId":"45017","inReplyTo":"xmqqd0tc9qek.fsf@gitster-ct.c.googlers.com","subject":"Re: Git trademark status and policy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-09-18T18:24:51Z","receivedAt":"2018-09-18T18:24:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 17, 2018 at 06:58:43AM -0700, Junio C Hamano wrote:\n\n> I can undertand the sentiment that we may not want to appear drawing\n> lines among friends, but ultimately the policy is about protecting\n> our friends from non-friends, so whether we like it or not, we may\n> have to be more explicit about who's grandfathered and who's not\n> than before.\n\nYeah, I think it may simply come down to that. I think we may need to\nget some guidance from Conservancy on the best route forward. I.e., if\nwe want to bless \"Git Cola\" as a name, are we best to have some kind of\nwritten agreement, so it is \"we explicitly allow this\", and is not\ninterpreted as \"we did not bother to enforce, which weakens our\ntrademark\".\n\n-Peff\n"},{"id":"361382","messageId":"20181024075533.GA11043@gmail.com","threadId":"45017","inReplyTo":"20180918182222.GA24448@sigill.intra.peff.net","subject":"Re: Git trademark status and policy","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2018-10-24T07:55:33Z","receivedAt":"2018-10-24T07:55:39Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Sep 18, 2018 at 02:22:22PM -0400, Jeff King wrote:\n> On Mon, Sep 17, 2018 at 11:25:31AM +0200, Christian Couder wrote:\n> \n> > > (Also, to be clear, this is all _only_ about \"Git Cola\". The \"git-cola\"\n> > > command is explicitly OK in the policy because that's how commands\n> > > work).\n> > \n> > I agree about \"git-cola\" though I wonder about \"git-dag\" as this is\n> > another command used by the project that is more generic. For example\n> > I could imagine that, if we wanted to provide a shortcut for `git log\n> > --graph --decorate --oneline`, we might want to use `git dag`.\n> > \n> > I guess we can still recommend to change it if possible, though we can\n> > also acknowledge that, as our recommendation comes very late (too\n> > late?), it is just a \"weak\" recommendation.\n> \n> Yeah, I agree with you, though I think it is a separate issue. \"git-dag\"\n> is explicitly OK in the trademark policy, and they are not using \"Git\n> Dag\" in any recognizable way.\n> \n> So I think there is no trademark issue, but \"git-dag\" is probably just\n> not a great idea in general, because the namespace is open and it is\n> likely to get stomped by some other project. Or git itself. Or it may\n> even be annoying for users who have a \"git dag\" alias (on-disk commands\n> always override aliases).\n> \n> So I think we should generally recommend against such generic names\n> during the naming phase. At this point, I'm not sure the pain of\n> changing now is any less than the pain of changing later if and when\n> there's a conflict.\n> \n> I think I'm actually violently agreeing with you, but I wanted to make\n> it clear. :) (And everything else in your email seemed sensible, too).\n> \n> -Peff\n\n\nThanks for the recommendation.  I'm open to changing the name in a\nfuture major release.  For users that already use the short \"dag\" name,\nwe can transition over to something else if it's relatively short and\nsweet.\n\nMaybe a better name would be \"git-kcola\" (a nod to gitk), or \"git-vdag\"\nfor \"visual DAG\"?  Any sugs?  I'm terrible at naming things, but I do\nrefrain from using additional \"git-*\" names beyond these two for the\nproject.  I kinda like \"vdag\" since it's easy to type, and nearby the\nexisting \"dag\" name.\n\nThere's also one more script, but it's never installed in the users's\n$PATH and is more of an internal implementation detail.  Git Cola\nincludes a GIT_SEQUENCE_EDITOR-compatible \"git-xbase\" command that\nprovides a visual interactive rebase feature.  That command should\nprobably be renamed to \"cola-git-seq-editor\" to make that clearer, and\nalso to open up the possibility of installing it in bin/ in the future\nsince it is useful on its own.\n\nThe rationale for two commands is that worktree diff+commit and history\ninspection are our two primary use-cases.  Everything else is provided\nas a sub-command, \"git cola rebase\", \"git cola stash\", etc. so there's\nnot much pressure to add more top-level names, just these two.\n\nThoughts?\n-- \nDavid\n"},{"id":"361471","messageId":"20181025052127.GA11460@sigill.intra.peff.net","threadId":"45017","inReplyTo":"20181024075533.GA11043@gmail.com","subject":"Re: Git trademark status and policy","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-10-25T05:21:27Z","receivedAt":"2018-10-25T05:21:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 24, 2018 at 12:55:33AM -0700, David Aguilar wrote:\n\n> > So I think we should generally recommend against such generic names\n> > during the naming phase. At this point, I'm not sure the pain of\n> > changing now is any less than the pain of changing later if and when\n> > there's a conflict.\n> [...]\n> \n> Thanks for the recommendation.  I'm open to changing the name in a\n> future major release.  For users that already use the short \"dag\" name,\n> we can transition over to something else if it's relatively short and\n> sweet.\n\nGoing from my paragraph above, I think it is probably OK to just leave\nit for now (unless you prefer to use a major version boundary to do the\nchange rather than later possibly having to deal with it on a shorter\ntimeframe).\n\nI have no real opinion on a replacement name. :)\n\n> There's also one more script, but it's never installed in the users's\n> $PATH and is more of an internal implementation detail.  Git Cola\n> includes a GIT_SEQUENCE_EDITOR-compatible \"git-xbase\" command that\n> provides a visual interactive rebase feature.  That command should\n> probably be renamed to \"cola-git-seq-editor\" to make that clearer, and\n> also to open up the possibility of installing it in bin/ in the future\n> since it is useful on its own.\n\nYeah, agreed. If it's not in the PATH, then it doesn't need to be git-*\nat all, does it?\n\n> The rationale for two commands is that worktree diff+commit and history\n> inspection are our two primary use-cases.  Everything else is provided\n> as a sub-command, \"git cola rebase\", \"git cola stash\", etc. so there's\n> not much pressure to add more top-level names, just these two.\n\nMakes sense.\n\n> Thoughts?\n\nEverything you said seems pretty reasonable to me. Thanks for being\nconscientious about the naming issues.\n\n-Peff\n"}]}