On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote:
> On Thu, Feb 02, 2017 at 03:26:56AM +0100, Jeff King wrote:
> >
> > - 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".
>
> 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).
>
> Can we continue to use the name "Git Cola" going forward?
Thanks for asking.
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.
(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).
> > So that's more or less where we're at now. In my opinion, a few open
> > questions are:
> >
> > 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).
>
> 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.
Yes, I have to admit that being a good citizen of the ecosystem counts
for a lot in my book. But it's often helpful to make these decisions
early on in the project's life (because name changes are awkward later
on), and we have to just guess at how things will play out. Git Cola is
again easier there because of the history.
> 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:
https://github.com/git-cola/git-cola/blob/master/share/git-cola/icons/git-cola.svg
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.
-Peff
