From: Christian Couder <email@example.com> To: Jeff King <firstname.lastname@example.org> Cc: David Aguilar <email@example.com>, git <firstname.lastname@example.org>, email@example.com Subject: Re: Git trademark status and policy Date: Mon, 17 Sep 2018 11:25:31 +0200 Message-ID: <CAP8UFD2cC7VMu7Zp9NaXj4x0BMBPZ5CJ6prwEv+s24SuNG=7JA@mail.gmail.com> (raw) In-Reply-To: <20180917032101.GD22024@sigill.intra.peff.net> On Mon, Sep 17, 2018 at 5:21 AM, Jeff King <firstname.lastname@example.org> wrote: > On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote: >> The "Git Cola" project 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: > > https://github.com/git-cola/git-cola/blob/master/share/git-cola/icons/git-cola.svg Thanks for digging and sending the link as I previously thought that the logo was actually this: https://git-cola.github.io/images/logo-top.png 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 names.
next prev parent reply index Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-02 2:26 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-09-17 13:58 ` Junio C Hamano 2018-09-18 18:24 ` Jeff King
Reply instructions: You may reply publically 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAP8UFD2cC7VMu7Zp9NaXj4x0BMBPZ5CJ6prwEv+s24SuNG=7JA@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
firstname.lastname@example.org mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox