[tomxor]

> The GPL says nothing about branding though

I said in spirit, not literally.

> In general, people tend to confuse copyright/patent with branding

I understand how trademark laws work, I'm talking about why this policy is wrong and against how OSS projects work in general. The original purpose (as stated by the policy itself) was supposedly to protect confusing forks of the same name or prevent pseudo successors, but it goes way beyond this to attack anything with git in the name.

> For example, imagine a software project which is only tangentially related to Git. It might use Git as a side effect, or might just be "Git-like" in the sense of being a distributed system with chained hashes. Let's say as an example that it does backups. We'd prefer it not call itself GitBackups. We don't endorse it, and it's just using the name to imply association that isn't there. You can come up with similar hypotheticals: GitMail that stores mailing list archives in Git, or GitWiki that uses Git as a backing store.

They reason this issue as "endorsement"... yet it's so common to have an ecosystem around a popular piece of software where project names are a derivative of the name of the core software it builds upon, I doubt anyone ever got confused or even cared much about endorsement, instead I think enforcement of this policy will just make the relationship and purpose of software built for use with git more opaque to users.

[clacke2]

There's a whole bunch of people out there, outside geek circles, who believe Linus created GitHub. Brand confusion is real.

[tomxor]

That may be so, there's probably also a whole bunch of people out there who think that Bill Gates invented the computer, it doesn't matter... it's a fools errand to try to eradicate ignorance of outsiders at the cost of disregarding any relationship that is not official and "endorsed" as invalid, i'd go as far as saying it's toxic.

Endorsement is not the only valid relationship between pieces of software, and it's definitely not the most important one. As an example of how bad this can be, git asked gitTorrent to change it's name to remove "git" - how absurd is that, git's protocols are modular, they are intended to be extended, this adds a torrent type protocol to git, it's for git... what the fuck else would you call it:

torrent-protocol-for-that-popular-merkel-tree-based-scm-that-is-not-mercurical-but-i'm-not-allowed-to-use-its-name

This "policy" completely disregards this as a valid relationship... why does it have to be endorsed, no one cares, they care about names that clearly communicate their purpose. gitTorrent and a thousand other extensions to git probably aren't going to be as popular as git itself, they aren't going to have enough presence that naming them something completely unique and obscure is going to be useful to users.

[edit]

I just want to say (and then I'll stop ranting), as much as this policy obviously irritates me... I love git, and so was pretty disappointed to find this, it doesn't make me love git any less, but It makes me more wary of people who "manage" open source projects.

[temprature]

I guess Richard Stallman violated the "spirit of the GPL" when he made MicroGnuEmacs change their name.

[tomxor]

> I guess Richard Stallman violated the "spirit of the GPL" when he made MicroGnuEmacs change their name.

No, because he asked them to remove "GNU" and It is not part of or for GNU, does not use GPL and is not a fork (it uses a combination of public domain and BSD licenses)... if he asked them to remove "Emacs" from the name then this would be the same issue - but it's not.

I am not familiar with the details of that discussion but I doubt many people would argue against me when I say it's very likely RMS was against them using GNU in the name of public domain and BSD licensed software due to significant differences in implied licensing, this is completely different reasoning to git's where it disapproves of _any_ implied relationship that is _not_ endorsed.

Also note that the focus of my comment is explicitly on the details of the significant implications to related software that is _not_ a fork or clone.