list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <>
To: Jeff King <>
Cc: David Aguilar <>, git <>,
Subject: Re: Git trademark status and policy
Date: Mon, 17 Sep 2018 11:25:31 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Sep 17, 2018 at 5:21 AM, Jeff King <> wrote:
> On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote:

>> The "Git Cola" project[1][2] provides two fully-featured Git porcelains,
>> "git-cola" and "git-dag".  The DAG tool is never referred to as a
>> separate project, so shouldn't be a concern trademark wise.
>> The project dates back to 2007, while the "Git Cola" name dates back to 2008.
>> FTR, the name "Cola" is also a shout-out to Linux (comp.os.linux.announce).


> An official answer will have to involve opinions and a vote from the
> whole PLC, but let me tell you what _I_ think:
>   - we mostly grandfathered good-faith names that predate the trademark,
>     even if we probably wouldn't grant them today. Searching my mail
>     archives, I see that git-cola did come up (along with a few others
>     like Gitolite and TortoiseGit). And we even ended up with written
>     agreements for some (at the very least GitLab and Gitolite), but I
>     think several (including git-cola) were never officially resolved in
>     anyway.
>   - In my opinion "Git Cola" is a lot less confusing than something like
>     "Git Cloner". Because there is little chance that somebody might say
>     "Ah, the official Cola of Git!". Whereas a generic operational term
>     like "Cloner" does introduce confusion (the "Git" is easily
>     interpreted as "Git presents X" and not "this is an X for using with
>     Git").
> So my opinion is that it is not something the project should be worried
> about. But like I said, do not take that as an official position at this
> point.

I agree with that. I think that old projects that have been known for
a very long time and that don't have a confusing name should
definitely be ok.

> (Also, to be clear, this is all _only_ about "Git Cola". The "git-cola"
> command is explicitly OK in the policy because that's how commands
> work).

I agree about "git-cola" though I wonder about "git-dag" as this is
another command used by the project that is more generic. For example
I could imagine that, if we wanted to provide a shortcut for `git log
--graph --decorate --oneline`, we might want to use `git dag`.

I guess we can still recommend to change it if possible, though we can
also acknowledge that, as our recommendation comes very late (too
late?), it is just a "weak" recommendation.

>> In my (biased) opinion, granting "Git LFS" was the right call.
>> As long as the project is clearly a separate, but primarily Git-centric,
>> project then it seems like the right approach to allow "Git Foo" for
>> open source projects that contribute positively to the Git ecosystem.

I agree especially as "LFS" is not generic.


>> Lastly, due to time constraints, the Git Cola logo is a tweaked version
>> of the Git logo, which may convey a level of "officialness" that might
>> be unwanted.  We can work on a replacement if desired.
>> Part of keeping the logo/visual identity close to core Git is because
>> the tool was always meant to be strongly tied to Git's unique features.
>> It's probably the same reason why the git-lfs branding uses similar
>> orange/red palettes -- to convey cohesiveness.  I would prefer to keep
>> the visual identity as-is (including the logo).
>> Can we continue to use the derivative logo for the time being until a
>> replacement is produced?  Alternatively, can we keep the logo as-is?
> I don't think this is a question we've ever really considered before.
> I had to actually dig a little to find any use of the logo, which
> doesn't seem to be on most of your screenshots. :) For reference, this
> is the one I found:

Thanks for digging and sending the link as I previously thought that
the logo was actually this:

which is on top of their homepage.

> I do think that's much more ambiguous than just the name when it comes
> to potentially confusing endorsement. If a random proprietary GUI client
> had a logo like that, I think we'd probably ask them to change it. But I
> have to admit that given the general good history of git-cola, the fact
> that it's open-source, and the fact that its main developer is also a
> helpful member of the Git development community, I'm less inclined to do
> so here.
> So in that sense, I don't have any problem saying "sure, let's make an
> explicit exception here". But I do wonder if we're better off trying to
> be as even and impartial as possible, so as not to create funny
> distortions (i.e., doing anything that endorses one over the other; I
> don't really use any graphical interface around Git, and I don't have an
> opinion on the technical qualities).
> I'd be curious to hear what other people in the community think.

My opinion on the logo is that they should probably make it clearer in
general what their visual identity is, as the 2 images on the above
links are quite different. And if they do that, yeah, it would be nice
if the logo that comes out is a bit less similar as the Git logo. In
general I think logos and visual identities are easier to change than

  reply	other threads:[~2018-09-17  9:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02  2:26 Git trademark status and policy Jeff King
2017-02-21 15:55 ` G. Sylvie Davies
2017-02-21 22:31   ` Jeff King
2017-02-22  1:01   ` G. Sylvie Davies
2018-09-16 10:15 ` David Aguilar
2018-09-17  3:21   ` Jeff King
2018-09-17  9:25     ` Christian Couder [this message]
2018-09-18 18:22       ` Jeff King
2018-10-24  7:55         ` David Aguilar
2018-10-25  5:21           ` Jeff King
2018-09-17 13:58     ` Junio C Hamano
2018-09-18 18:24       ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).