Skip to content

The term "fork" is not defined anywhere in the GitHub Terms of Service #37

@evandrocoan

Description

@evandrocoan

There are several interpretations for what does the term Fork means, and the Terms of Service does not define of the them. Which is basically ask for trouble for the GitHub users which use the fork button on non-open source projects. As many of them comply to the Berne Convention on the absence of a explicit license.

Moreover following on the Open Source Stack Exchange questions:

  1. What does the 'right to fork' mean?
  2. How does GitHub's “forking right” cope with an “All rights reserved” project?

There are at least two understandings about what does a fork mean. They are respectively:

  1. [quoting: Gilles] The right to fork refers to forking as in taking a software project and maintaining it separately from the original. Having the right to fork a work means having the right to modify your own copy. In the context of freely distributable works, the right to fork means having the right to redistribute modified copies.

  2. [quoting: apsillers] The term "fork" is not defined anywhere in the GitHub Terms of Service, but it seems perfectly sensible to assume that "fork" here is meant in the sense that it is used elsewhere on github.com: the Fork button.

    a "Fork" button on a GitHub repository page

    GitHub probably intends "the right to fork" to mean "the right to use the Fork feature of the github.com website." In this case, "creating a fork" would not mean generally creating a copy or derivative work (as it does in general FLOSS parlance), but rather it means triggering the software of github.com to create and host a verbatim copy of a repository and categorize that copy under the user's list of forks.

Details

  1. [quoting: Gilles] The practical importance of the right to fork is that is you don't like the way the original author maintains the work (not fixing the bugs that bother you, not adding the features you wany, etc.) then you can do what you like with your own copy. Having the source (i.e. the prefered form of modification) is critical there, since it is the only practical way to fork a work. A right to fork without having the practical means to make use of it, i.e. having the source, would not be very useful.

    The combination of being allowed to and able to modify the source and the right to redistribute allows anyone who's interested to take up maintenance. This is a guarantee that free software and other open source works won't die as long as someone somewhere, anywhere, is willing and able to take up maintenance. It's also a guarantee that if someone dislikes the way the project is maintained, they can make their own version if they're willing and able to invest the requisite effort or get someone to do it.

  2. [quoting: apsillers] If the original copyright owner doesn't license any other permissions, clicking that button is all that the TOS-required permission allows the user to do. This doesn't grant any rights to create a derivative work, or to redistribute the code outside of github.com, since the "Fork" feature is intrinsic to the github.com website.

    Speculation: this right-to-fork language in the GitHub TOS was probably included to prevent legal issues around the use of the Fork feature. The intent was likely something to the effect of, "You must license the minimum amount of rights to allow github.com's Fork software feature to operate."

    Based on this reading of "fork," if another user were to use a github.com-hosted forked-repository to prepare and distribute a derivative work, that would infringe on the owner's copyright, since such an action is outside the scope of the Fork software feature. Similarly, if the user were to create a verbatim copy outside the context of github.com's Fork functionality (e.g. copying the code to another website), that would also not be permitted. The TOS does not allow the right to create copies generally; it only requires the author to grant copying permission inasmuch as copying is a necessary component of the Fork feature.


Currently the situation is open to a tribunal court do determine what rights the GitHub Fork button actually gives. As currently it is, it only implies the right to use the Fork button feature present on the site. Hence, a public GitHub repository complying with Berne Convention only, is very dangerous for GitHub users which fork it, and push commits/pull requests to their fork. As they are in great danger/liability of the prosecuted by the original repository owner, if they perform commits and pull requests due Berne Convention applied.

It follow because the repository is not giving any rights to anyone else, other then create a copy using the GitHub Fork button. Such feature is seems very useless, as if I want to fork a GitHub repository, is to apply bug fixes and new features not presented on the original repository. Or because I do not like the way the original author maintains the work, i.e., not fixing the bugs that bother you, not adding the features you want to, etc.

Therefore as we can mostly see, thousands of GitHub repositories out there are complaining with the Berne Convention. I would suggest to apply to the Fork button feature, the ability/right to allow the forked repositories to receive push commits from their forkers and perform pull requests to the original repository.

In any case, if someone is putting their code on a GitHub public repository, but has no intention to allow others to fork their project and push commits/pull requests, they should:

  1. Not put their code on a GitHub public repository. They should consider not put it on the internet or putting it on a GitHub private repository.
  2. Explicitly apply a license to their project forbidden it, which should also disable the GitHub Fork button, and clearly alert/inform the GitHub user that this repository very dangerous as its contents are not allowed to be forked and consequently changed by git commits.

image
https://en.wikipedia.org/wiki/License_compatibility

Related issues and threads:

  1. OSS licences vs. ToS: grants of rights #7 OSS licences vs. ToS: grants of rights
  2. Can it be an open source project? SublimeText/LaTeXTools#1175 Can it be an open source project?
  3. Fork (software development)
  4. Is it possible to get rich prosecuting GitHub users from a non-lincesed fork?
Details

linux_distribution_timeline

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions