Personally, I've frequently cloned repos to read and play around with the code. Making changes to the code is a good way for me to verify that I understand what's going on: if a change does what I expect it to do, then it means I probably understood the code. In that case, I don't really care if I miss updates.
As for people not knowing what the real repository is: there's not really a such thing as the "real" repo. Git just isn't centralized like that. Probably since you are the original coder, yours will be the most popular, but if you're worried about not getting credit for your work, there are a few things you can do:
1. As viraptor said, you can put a link to your repo in the README.
2. It's a good idea to put a LICENSE file in your repo. You can choose one which requires people to give you credit.
Keep in mind that you can't force people to pull your code with these changes, and if they've already cloned it they have it under the original license (which may be no license at all). So this doesn't really fix the problem you have now, it only prevents more people from cloning w/o a link back in the future.
This is technically correct - however according to the github TOS [1] [2] you agree to allow people to view and fork your code.
But - what is stopping me from creating a new algorithm that is X% faster than what is out there - uploading it to some service or site without a license and suing everyone who uses it? I have a feeling that someone would have done that by now.
Obviously in the US we have fair use for certain circumstances, but also I feel like if you attribute it to the author then that is fine. Otherwise every public school is forcing the students to break the law by making them use content from encyclopedias, research papers, and other online sources that don't have an explicit license. At least when I went to school - copying content from work that was not explicitly licensed was deemed ok as long as you cited it with MLA, APA, or whatever 3 letter format was popular at the time. However - mixing unlicensed code with licensed code could lead to a disastrous situation (unless you stated in the LICENSE file that a chunk of code is not under the overall license).
[1] https://help.github.com/articles/github-terms-of-service/
[2] http://programmers.stackexchange.com/questions/207941/reusin...
You're usually not going to want to reproduce so much of a work in your research that copyright law would come into play (you can legally paste a few sentences from a book on your blog IANAL). Often though a research paper fits into a category protected by fair use so you can anyway.
But you can't reproduce and distribute an entire piece of copyright protected work just by providing a citation. I hope you haven't done this. If you have, you should take everything down. Do not apologize to the copyright holder. Talk to a lawyer.
The content of the encyclopedia is still copyrighted material of the company - copyright law is always in effect. Also - when writing a program it would most likely be composed of different projects. I would find it very unlikely that you aren't using a library or piece of code that is copyrighted or licensed by someone else.
> Often though a research paper fits into a category protected by fair use so you can anyway.
You could still apply fair use for code - and if your derivative work is for non-commercial use then it would be hard to argue a copyright violation [1]. Especially if you tried to contact the author and didn't get a response.
> But you can't reproduce and distribute an entire piece of copyright protected work just by providing a citation.
I never said you could?
> I hope you haven't done this. If you have, you should take everything down.
I never said I did?
You didn't express the big picture problem - if I release some unlicensed code into the wild and people start using it - does that give me the right to sue everyone on the planet?
[1] http://ogc.harvard.edu/pages/copyright-and-fair-use
[2] http://smallbusiness.findlaw.com/intellectual-property/fair-...
Of course having a website doesn't prevent someone from cloning and adding their own website and beating your version on Google, but at that point the other party clearly has some level of commitment.
If you're hell bent on contacting people cloning your project, a better approach is to ask how they are using the code and if there's any way you can help. I don't think asking people to fork is going to get your project much good will. It's mostly bureaucratic make-work for your benefit over a concern that's not proven to exist in the wild.
Good luck.
http://www.simplybuilt.com/support/the-settings-panel/gettin...
I wouldn't worry about it - the clones will probably not go anywhere and just die off, abandoned. True they don't link back to your now-canonical repo. As viraptor said, maybe contact the users. They might prefer to fork your repo now it's on github.
This is a problem because many people will clone the old (2+years!) but popular repo and see that it does not work as well as it should. Github offers no real solution here. Maybe they should put a badge or an option to tag a repo as "official" (with sufficient proof of the owner) and present on top of search results.. although the possibilities of abuse are endless.
You will have to work your way up the search page with friends starring you. Maybe put up a blog asking your users to do so?
Arguably the name of a project is a trademark, and no one has permission to use it unless you grant them that permission. Just because you license the copyright to your code under an OSS or Free Software license, does not automatically entail granting a license to the trademark on the name.
IMO, this is one thing that makes Github a bit of a legal tar-pit... it's trivially easy to fork a repo, but nothing makes (or even encourages) you to change the name, or make it clear that your repo isn't the "official" Project Foobar. So far it seems that most people just take a "don't ask, don't tell, don't care" sort of approach to that, but I have a hunch it's going to get somebody burned eventually.
They don't, and they wouldn't. The licenses (generally) are only dealing with the code, which is something very specific, and is apart from the name of the software. The need to change the name would simply fall out of the way trademark law works, not a requirement in the license per-se.
It's just an issue that doesn't come up very often, because most people who write OSS don't seem to get very worked up over it. But a license permitting you to redistribute code, does not automatically mean you have permission to use the associated trademark.
Times when this has come up: CentOS can't call their Linux distribution "RHEL" because RHEL is a Red Hat trademark. But they can (and do) redistribute the code.
Firefox / IceWeasel controversy - Firefox have specific guidelines concerning use of the name "Firefox" and Debian ran afoul of them at some point, and the Firefox people made an issue of it, so Debian rebranded their distribution of that code as "IceWeasel".
And so on... Now, IANAL, and I'll freely admit that it's probably an open question whether or not simply forking a Github repo represents an action which would violate a trademark. I suspect it could if the owner chose to make an issue of it, but hey, I could be wrong.
People will however look at recent updates. And take into account the differences between the repositories, before deciding witch one to use.
This is how it should work by default IMHO. "Forking" is flawed: What if it was the other way around: Lets say You cloned a project and are actively maintaining it, why should people be directed to the original outdated repository!?
So how would they look at recent updates and compare differences between the repos if they only know of the one?
For various reasons, I occasionally clone instead of fork an open source project I use, but I'm always careful to put a link to the original project at the top of my README.
Also, updates are not magically merged to upstream Github repos, regardless of whether they're forked or cloned. The user has to merge any updates manually either way, unless you script these merges using Bash or some similar approach.
tldr: forking is a tool, not a rule.