14

This question is about a true fork (with new name, different features, different objectives and not targeting a pull request).

When I am developing a new application based on an other project I usually keep the forking link like the example bellow.

Example

Often, when I stumble on true forks on GitHub, that link is not kept. What is the proper way to operate regarding the GPLv2/GPLv3 rules? and what would be the advantages of keeping that link in this situation?

Note that the original project is referred to in the README, the copyright rule are respected and the new project is under the same license. Also I found some information on this answer and I do know that standard GitHub forks (with the link reference) do keep a sort of strong link to the main project (like master project deletion situation or commits/network analysis on the main project).

Improve this question
2
  • 4
    Github will unlink a fork from the parent upon request. I had to do this when a prior employer took a project in a direction I didn't want to be associated with.
    – chicks
    May 20, 2019 at 18:51
  • 4
    Keep in mind that no open source license requires that you use a particular version control system, and certainly none requires that you use Git or GitHub in particular. Using one is certainly good for various reasons, but those reasons have nothing to do with the license.
    – Brandin
    May 23, 2019 at 6:20

4 Answers 4

Reset to default
39

There is no requirement whatsoever in any version of the GPL to maintain a reference to some upstream project. Imagine if you use substantial code from multiple GPL-licensed projects: the GitHub website only allows one "upstream" pointer anyway.

GitHub's upstream link is only a helpful reference and is unrelated to any license requirements.

Improve this answer
5
  • 2
    Thank you for the clarification. What's your advice on this, regarding the project overall health... (keeping the link or it's better to follow what most are doing and make it completely independent)?
    – intika
    May 20, 2019 at 7:36
  • 3
    @intika: If you can every usefully cherry-pick a commit from the other tree, it might make sense to keep it. Otherwise it's probably best to have the reference only in the GitHub readme and/or other documentation. Although perhaps it's slightly interesting to have GitHub calculate 2xxx commits ahead and 3xxx commits behind the original tree, or whatever. If not, then that's just meaningless noise that you don't want to display or make Github waste time calculating.
    – Peter Cordes
    May 20, 2019 at 8:50
  • 1
    Since accounts can't have two [Github, linked] forks of the same repo, make your true repo a not-linked fork - so contributors can have a torvalds/linux fork and linux-allwiner forks and send PRs to each of them (assuming torvalds/linux would receive PRs)
    – mgarciaisaia
    May 20, 2019 at 17:49
  • For cherry picking that link isn't needed either, you can just pull that branch into your local repo and pick what you like. git doesn't care about those links. It's only about GitHub UI features.
    – johannes
    May 21, 2019 at 16:15
  • You can always add multiple remotes you wish to cherry pick from instead of just the upstream and origin reference git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
    – Tschallacka
    May 22, 2019 at 11:17
7

Not directly an answer to your question, but if you want a fork that doesn't reference the parent, you should import the repo instead:

https://github.com/new/import

Note that you will only get the code and not the wiki, settings, etc this way, as if this repo doesn't live on GitHub.

Like you wrote, it's not related to any licensing issue; if the parent is GPL, your derivative work is GPL as well.

Improve this answer
3
  • Yes, or even an import on the fork if changes have been made... the only downside is stars and some other things are lost. The alternative is to ask GitHub support for the matter I posted a full answer with all the infos together :)
    – intika
    May 20, 2019 at 11:57
  • Agreed, but sometimes the "ask github" part is enough of a hassle that I prefer to avoid it, especially in cases where I don't care for the stars and wiki.
    – noamtm
    May 22, 2019 at 6:39
  • I think they make it impossible to disable directly because keeping the fork link is better for GitHub as an ecosystem.
    – noamtm
    May 22, 2019 at 6:40
5

Considering GPL-v3 and GPL-v2 this is not required at all (and this is true for all opensource licenses).

The main purpose of a "GitHub fork" is to collaborate back to the original project, this could be one of the reason a lot of "true forks" are not using that link.

Regarding the project health as @PeterCordes commented

If you can every usefully cherry-pick a commit from the other tree, it might make sense to keep it. Otherwise it's probably best to have the reference only in the GitHub readme and/or other documentation. Although perhaps it's slightly interesting to have GitHub calculate 2xxx commits ahead and 3xxx commits behind the original tree, or whatever. If not, then that's just meaningless noise that you don't want to display or make GitHub waste time calculating.

Also as the new project will not be linked it's recommended to contact the original project owner letting him be aware of the fork.

Note that forking a project on GitHub without the link is easily doable by the import function, but bear in mind that some settings will not be imported like the wiki page, also an import on an already forked version is possible, this could be helpful if changes have been made to the fork, the only downside is, stars and some other things will be lost. The alternative is to ask GitHub support for the matter. And lastly the old commits done by other developers will remain intact because they are linked to the submission email and thus will be linked to the proper developer.

Improve this answer
5
  • 1
    [...] this could be one of the reason a lot of "true forks" are not using that link: It's a shame that GitHub doesn't allow using forking in that way to cleanly document the ancestors of the project (e.g. nvim from vim and Prezto from OMZ) and, the other way around, see the projects a project has influenced (a la Wikipedia). I guess the answer is "no" but is there a somewhat standard way to document this inheritance?
    – PiCTo
    May 20, 2019 at 13:33
  • Does the import function do anything but a simple git clone; git remote add new-remote <new_url>; git push new-remote --all --tags?
    – Voo
    May 20, 2019 at 20:12
  • @Voo I believe this is pretty much what it does (plus creating new-remote first), but on the server side so less work for you.
    – noamtm
    May 22, 2019 at 6:36
  • "this is true for most opensource licenses" - Probably this should say all open source licenses. Unless there is one you can point to that specifically says you must use GitHub, git, or a particular version control system, and dictate a particular way that you use that system; I know of no license that requires that. And if there were such a license, whether it really qualified as open source would be very suspect.
    – Brandin
    May 23, 2019 at 6:18
  • i edited it ;) i wrote that because i don't know in details all opensource licenses
    – intika
    May 23, 2019 at 7:35
1

One more bit to consider, a "github fork" project has fewer features available than a standalone (imported) project. You can not post issues to a "github fork" by default (have to go to Settings to enable them), and I believe search is constrained. You do still have a wiki and PRs on a "github fork" out of the box though.

This adds technical reasons to make a "true fork" on GitHub for a project that decides to live on its own, even if sharing legacy code with another.

Improve this answer
3
  • issues can be activated and search is not limited
    – intika
    May 22, 2019 at 21:29
  • 1
    @intika : ok, so I tried, just in case something changed recently. github.com/jimklimov/nut/search?q=systemctl&type=Code still says "Sorry, forked repositories are not currently searchable. You could try searching the parent repository." For issues - thanks, true, I did not realize that setting before :)
    – Jim Klimov
    May 24, 2019 at 10:13
  • i did not notice that it was limited that way, tho it kind a make sens because the limit is only for parent code, commit/issue and all changes on the fork are still searchable
    – intika
    May 24, 2019 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.