GitPub: An extenstion to ActivityPub for web-based Git services federation
github.com
github.com
The scope of GitPub is still under active definition, and it might end up not being specific to git only.
If you're a stakeholder of any service that could federate based on Mercurial, Bazaar… you're more than welcome to give your input to the working group.
In other words, it means that if GitPub was adopted by these services, you could submit a merge request from Pagure to Gitlab, or star a GitHub project from your own Gitea instance, among many other things.
How do federated networks prevent someone from making a few hundred accounts and starring/liking a bunch of posts?
We seem to be doing OK by not caring much.
I'm fine with stars not being significant, but it's still not good if a malicious actor can suddenly spoof hundreds of accounts and spam stars, comments and what-not.
Sure, your IP will be rate-limited (GH at least) if you script it and start hammering stars, but that's not because it wants to protect the integrity of the repo star count.
It's way too early for a proposal, but if someone from GitLab wants to give some input, that's more than welcome.
Thanks!
Later, after the GitPub federation approach is proven, let another team take up the torch for AnyPub.
> Portmanteaus ("GitFoo" or "FooGit") are out. Most of the cases run into this rule. For instance, we asked GitHub to not to use "DGit" to refer to their replicated Git solution, and they[1] rebranded. We also asked "GitTorrent" not to use that name based on this rule.
[1]: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
GitPub is still very young, and it might end up supporting (D)VCS other than git, so absolutely nothing in it is definitive right now, not even the name.
If it's only portmanteaus specifically then... why, (that seems weird), and i'm sure I can find an arbitrary lab and hub name to violate them.
> The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing".
> (There was another delay caused by a competing application from a proprietary version control company that wanted to re-brand portions of their system as "GitFocused" (not the real name, but similar in spirit). We argued our right to the name and refused to settle; they eventually withdrew their application).
> So GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist.
> While the original idea was to prevent people from forking the software, breaking compatibility, and still calling it Git, the policy covers several other cases.
> One is that you can't imply successorship. So you also can't fork the software, call it "Git++", and then tell everybody your implementation is the next big thing.
This seems like a massive violation of the spirit of GPL... explicitly disallowing official endorsement is one thing (since that would be lying), but you shouldn't be able to stop someone going and doing their own thing and calling it git-something.
In general, people tend to confuse copyright/patent with branding. The former is about using, while the later is about naming. You can totally make the next git-killer, and base it on git. What you cannot do is name it "GitSomething" (regardless of whether it uses git behind the scenes), as that would be a trademark violation.
I personally think the policy makes sense, but I also understand that there might be reasonable arguments either side. But framing it as an "anti-GPL" thing seems disingenuous to me.
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.
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.
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.
To me that seems to be compatible with the text as well as the spirit of the GPL. I think a similar discussion came up in the Debian project with the Firefox trademark at some point. Debian is quite picky about what it means for software to be free, and they seem to be fine with derivatives not being allowed to modify Firefox without changing the name. (At least, I think that was the end status of this discussion.)
What do you mean? The gpl literally exists to restrict the rights of downstream developers.
But we could go on and on back and forth about this. I just wanted to make sure the opposing view from yours is present in the thread near your claim.
The steward of git defining what does and does not have the git nature is completely in line with this. You want your own take on git? Go ahead, you explicitly have the four freedoms to do so, but don't muddy the waters by calling it git if you don't represent the project.
That was the original intent of the policy and not what I have issue with, but it goes much further than that, see my other comments for details.
Keeping this relevant: GitPub is not trying to replace git obviously.
> The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing".
> GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist.
There's also some further discussion about how it probably gives them an unfair advantage, but that's the policy they've chosen to persue regardless.
[1]: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
https://framalistes.org/sympa/arc/git-federation/2018-06/msg...
The better strategy is to work on encoding ticket tracking and such into git objects, in my opinion.
Hopefully, GitPub will be the thinnest possible addition to ActivityPub, so that concepts (and vocabulary) are shared between GitPub and Mastodon, enabling comments between them.
> Aardwolf, Bridgy Fed, distbin.com, dokieli, Funkwhale, Hubzilla, Kroeg, Mastodon, Nextcloud, Numaverse, PeerTube, places.pub, Pubstrate, Smilodon, tags.pub, Pleroma, Pump.io, and Rustodon are all either implementors of or are currently implementing ActivityPub.
In addition to those, https://pixelfed.org/ is in the process of implementing federation with AP.