I came across an inactive repo that I'd like to work off of. I opened an issue to see if they have any plans to come back to the project, with no answer.
I'm wondering what I should think about going forward in terms of attribution or any other considerations if we re-release the code as our own project.
There used to be a command-line tool for Twitter, named TTYtter, but the maintainer dropped it. A friend took it over, renaming it Oysttyer.
Requirements were that the new project had to keep the (non-standard) license and change the name. It looks like it's called "fork" in the README but the git history starts fresh at the switchover. (Or I'm reading it wrong.)
That makes sense to me. The contributions exist under the license, and so they should be continued forward under the same terms. I recall that there are things in the Linux kernel that they'd like to change, but they'd have to get sign-off by hundreds of people, many of which are identified only by email addresses corresponding to long-dead hosts.
The name is different. When the maintainers of MySQL left Oracle to go back to how it was before, they could take the code but they couldn't take the name, and thus MariaDB.
So, NewCode is a project that does something, forked from OldCode, a module by PrevCoder with all appropriate links seems like the responsible place to start.
Thanks for the input
I feel like given that you opened an issue and there's been no response--and presumably, that issue is visible and thus on record, as it were--that it'd be fine to go ahead. I'd even consider following up on the issue and saying that you've gone ahead since you didn't hear back and the repo was accessible, etc etc, here's the link, and certainly mention the original repo in yours and all of that, but that's it's basically fair game at that point.
Hmm that makes sense. I wasn't even aware of that as a thing. So you think we should clone it and start anew?
Treat abandoned as basically dead and gone forever. As Grant indicates, there's no point in even forking it, just create a new project starting from that one. Though I wouldn't worry about searching, since I've honeslty never searched for a repo on a place like github. I've always found them through a search engine.
Attribution requirements don't change for a fork or copy. Whatever the original license said must be maintained.
As it so happened, I found this project by deep searching GitHub. I figured someone had to have attempted this already. But in general I know what you mean.
If anyone's curious, this is the repo in question: github.com/patience-tema-baron/rub...
Hints at a feature I want to implement 🙂
BTW, as I just learned, you can send an email to github to disconnect the forked repository. This essentially makes it standalone. Thus it's reasonable to just start forked, then disconnect later (you can change the repo name then as well).
If the project does not already, create a CONTRIB.md , add a block of text at the time being very specific that your project is a fork of the source and will abide by the source licensing terms. As @ edA-qa mort-ora-y points out once your fork is up to date and running inform GitHub to disconnect your fork and become stand alone w/ credit to source repo.
I think that if you really can't have a feedback from the author(s), IF is licensed in an appropriate manner (so a GPL like license), you can start another project.
IMHO you have to clone the existing project on you PC, create a new EMPTY project on github, add it as new remote on your local git, push on your new project and remove the "legacy" remote. In this way I think that, if ever original author(s) come back to life, you'll can manage some git-magick to merge again the two projects. But I've never tried it, so it's just an hypotesis.
Is there a license document in the repository? Keep in mind that if there isn't, then by default the creator retains all rights to the code and you might be breaking copyright if you use/fork/clone it or create a derivative work.
On the other hand, if it's permissively licensed, an attribution is nice (if not necessary).
UPDATE: It looks like it's MIT-licensed. And I think I may have done that thing where I give a technical response to an "etiquette" question anyway, so carry on. :)
Your primary goal should be to take over the repo not fork it. Opening an issue is not enough. You need to "stalk" the person online, track down every form of communication you can for them, and try and find a way to get ahold of them, letting them know that the code is important to you and you really want to see it continue on, and can you please be made a maintainer if they're not interested in it. Alternately would they be open to you creating a new repo for it and killing theirs off so that it stops being the primary one everyone finds.
Worst case scenario: the person is unreachable and you have to fork. In that case don't click the fork button. Clone it down. create a new repo from scratch with a new name and push the code up to it. The new name can be something as simple as "_redux" -- obviously you need to maintain the license and the original code is still copyright the original author, and linking back to the original repo for crediting inspiration / source in the README would be nice.