From: David Aguilar <email@example.com>
To: Jeff King <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org
Subject: Re: Git trademark status and policy
Date: Sun, 16 Sep 2018 03:15:20 -0700 [thread overview]
Message-ID: <20180916101520.GC18517@gmail.com> (raw)
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 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?
> 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.
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?
next prev parent reply other threads:[~2018-09-16 10:15 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 [this message]
2018-09-17 3:21 ` Jeff King
2018-09-17 9:25 ` Christian Couder
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
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: 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 \
* 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).