76

The GitHub FAQ states (emphasis mine):

You're under no obligation to choose a license. It's your right not to include one with your code or project, but please be aware of the implications. Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work. This might not be what you intend.

Even if this is what you intend, if you publish your source code in a public repository on GitHub, you have accepted the Terms of Service which do allow other GitHub users some rights. Specifically, you allow others to view and fork your repository.

If you want to share your work with others, we strongly encourage you to include an open source license.

So, if a project is "all rights reserved", but then users have the "right to fork" it, what's the license of the new fork?

unor
  • 5,620
  • 24
  • 55
o0'.
  • 860
  • 1
  • 6
  • 8

4 Answers4

76

First of all, these two statements are made in sequence, not parallel (credit to MSalters for crystallizing this point):

Generally speaking, the absence of a license means that the default copyright laws apply.

...if you publish your source code in a public repository on GitHub... you allow others to view and fork your repository.

  • The first statement is a general statement about copyright law.
  • The second statement is about a license grant required by the GitHub Terms of Service.

They are both true, and if you host your code on GitHub, the second, specific statement takes precedence over the first general rule wherever the second rule applies. The second statement is a notice that hosting on GitHub requires you to make certain license grants to GitHub users which differ from the default rules of copyright.

Below is an inspection of what the "right to fork" could possibly mean, which will clarify the question: "What's the license of the new fork?"

(This is not legal advice. Furthermore, this is barely regular advice, and is based on a speculative -- but coherent -- reading of some ambiguity in the GitHub TOS.)

Here's what the GitHub Terms of Service has to say about forking:

By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

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.

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.

(All that said, this is speculative based on a specific reading of "fork." I'd like to say, on a personal note, it is kind of ridiculous that the GitHub Terms of Service use "fork" without a shred of definition to be seen.)

Community
  • 1
apsillers
  • 35,995
  • 4
  • 94
  • 131
  • 23
    Wait, Github doesn't even define what a fork is? That's just asking for trouble... – Zizouz212 Jul 15 '15 at 12:10
  • 3
    @FreeRadical What I mean to say is that it's not a violation of copyright specifically because that action has been permitted by the author's agreement to the TOS. I agree that it's a violation of copyright in the general case, which is precisely why such language needs to be included in the TOS. I will edit to make this distinction clearer; let me know if I'm still misunderstanding you. – apsillers Jul 15 '15 at 12:37
  • My opinion about is based upon the specific TOS wording on GitHub. The problem is that it introduces a default that is incompatible with other terms stated on the site (i.e. " the absence of a license means that the default copyright laws apply", i.e. ARR). In the case of sites requires contributors to contribute under a default license (e.g. StackExcahne/WikiPedia - CC-BY-SA, and Drupal.org - GPLv2+), there is no contradiction and no legal mess. IMHO, GitHub could solve this by having some FLOSS (not ARR) as the default. Unfortunately, they have legacy repos. – Free Radical Jul 15 '15 at 12:57
  • 1
    Let us continue this discussion in chat. – apsillers Jul 15 '15 at 13:04
  • 6
    "Generally speaking ARR... Even if this is what you intend ...specifically ... license to fork" - Any half-decent lawyer will spot the contrasting positions. The "generally speaking" part does not cover GitHub, as they explicitly state you give no longer reserve all rights by posting on GitHub. This is entirely normal legal practice: when you deviate from a default position, mention that default before stating the replacement position. – MSalters Jul 15 '15 at 13:22
  • @MSalters I hope you don't mind that I've added your observation to the top of my answer. – apsillers Jul 15 '15 at 14:18
  • Moderator note: Keep the discussions out of the comments. Apsillers has got a chatroom for the discussion. Keep comments only for constructive criticism, or if you have something to add to the post. – Zizouz212 Jul 15 '15 at 16:26
  • 2
    I feel that an explicit comment on cloning the fork to a local repo is warranted. This would also seem to be a type copying that is outside the scope of the Fork feature, and would therefore be forbidden. This makes the ability to Fork an unlicensed repository largely useless, with the small exception of preserving a copy for purely viewing purposes should the original owner ever delete it. – jpmc26 Jul 15 '15 at 18:28
  • 4
    For lack of a further explanation, I would assume that 'fork" is meant in the generic sense of copying a piece of source code and continuing to work on the copy. it doesn't make much sense to put your code on GitHub for the whole world to see and then try to keep others from copying it - that wouldn't be enforceable - so it doesn't make much sense to read the clause as only applying to GitHub's forking feature, which is just one particular way of making a copy. – reinierpost Jul 16 '15 at 15:50
  • @jpmc26 I sort of agree with you. However "cloning" is such an important feature of both git and github (github after all allows uploading, downloading, check-out and revision between github and your computer directly using the 'git'-command on your computer), that I think many would assume "cloning" to you PC was included. After all, you fork a project to work on it yourself (else you could just download), and at some point, you'll probably have to do something requiring the files to be locally on your own computer (e.g. compiling source code-files you've edited). – Baard Kopperud Dec 23 '15 at 15:54
  • fork is a precise term, as used in the underlying git version control system (and all others, as far as I know). – vonbrand Mar 03 '16 at 18:34
  • @vonbrand First, I disagree that "fork" has a well-defined meaning in git: a google search for site:git-scm.com fork only turns up a single usage outside of the convext of GitHub; namely, the --fork-point flag for the merge-base. Outside of this one usage, there is no mention whatsoever of a "fork" in git, either in the documentation (unless there is a more authoritative source than git-scm.com?). By contrast, the notion of "fork" as an operation on the GitHub website is abundant. – apsillers Mar 03 '16 at 18:47
  • @vonbrand Second, if we extrapolate --fork-point to refer to git's (otherwise completely ill-defined) notion of a fork, I think we conclude that a fork of a project must have a different commit history (since --fork-point takes a commit ref), but GitHub forks (insofar as the term is defined on GitHub to refer to the website feature) need not have a differing commit history; a "fork" is simply a new GitHub.com repository whose commit history may diverge in the future. (And I argue here that actually performing such a divergence is governed by copyright law and is not green-lit by the ToS). – apsillers Mar 03 '16 at 18:47
  • @vonbrand Finally: I don't disagree that "fork" has a generally understood meaning in the open source community, and I don't disagree that its meaning can be applied to the context of git particularly. I do argue, however, that GitHub's notion of a "fork" (i.e., the product of clicking the "fork" button on Github.com) is simply different from the traditional meaning of "fork" as the term exists in open-source parlance. A traditional "fork" must be different from the original (or else it's just a copy) but a Github.com fork includes the notion of a simple copy within its scope. – apsillers Mar 03 '16 at 18:51
  • But because the purpose of pushing the fork button is to enable you to modify the code, is there an implied license to do so? – curiousdannii Mar 05 '16 at 23:20
  • People can use the fork button for a variety of different reasons, not just for modifying code. According to this blog post, many people use forks as a "download" or "bookmark" button...and don't actually modify the code. The link itself calls this use "stupid"...but also claims that the majority of users use forks in this way. Maybe download/bookmark forks are the type of forks that GitHub itself endorses in its ToS (and they make a lot of sense for "source available" projects)! – Left SE On 10_6_19 Mar 06 '16 at 15:26
15

Well, you actually give up a few rights by accepting the terms of service. The terms of service declare:

However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

So effectively you don't have all rights reserved, but most rights reserved.

But doing so leaves big grey areas:

  • Can the forker create and distribute binaries?
  • Can the original or forked source code be released somewhere else than github?
  • Under which conditions can the resulting program be used?

It may be not very safe to use such code with undeclared license on Github.

Mnementh
  • 11,189
  • 2
  • 35
  • 79
  • 8
    "what's the license of the new fork?" –  Jul 15 '15 at 10:47
  • 4
    @EricGärtner: That's the point I think the Github team hasn't reallyy thought through. Because the fork cannot give any rights the original project isn't giving, so it stays in a muddy grey area. Probably the only things allowed are viewing the source and forking on github, but not distributing source or binaries away from github. You may ask this as an own question. – Mnementh Jul 15 '15 at 10:51
  • 3
    It seems pretty clear. The TOS states you agree to allow viewing and forking. It doesn't state that you agree to allow redistribution or use. If the terms don't explicitly state that you allow those things, then unless your license allows them they aren't allowed.

    Why you would have a public repo for code that can't be used is beyond me, however.

     – Arielle Lewis Jul 15 '15 at 15:36
  • 5
    @DoyleLewis a showcase for existing work for potential employers. –  Jul 15 '15 at 15:51
  • 3
    I don't think that "give up rights" is a clear description. You issue license to perform those actions, but it is a non-exclusive license, so you don't lose them. (You do lose the ability to sue for these actions, when performed by the parties you are giving the license to -- but this is not a "right" in the same sense as "rights reserved" that immediately follows) – Ben Voigt Jul 15 '15 at 16:20
  • 2
    IANAL. But: There is no grey area IMO. You upload a picture to your homepage, "all rights reserved". Others are obviously allowed to download the picture (because they couldn't really help doing so when visiting your website), but have no license whatsoever to use or redistribute it. "You agree to allow others to view and fork your repositories" -- there is nothing in there about redistribution, i.e. such forks must be non-public. – DevSolar Jul 17 '15 at 11:34
  • 1
    this is not grey to me - you can always create a copy of anything but ... not always you can do sth with it, you can just possess the copy, that's all; what's the benefit of having such copy with no rights to change/distribute/sell it? go figure :) – Marian Paździoch Nov 12 '19 at 08:42
  • @DoyleLewis Github isn't only used for code. It also hosts blogs via the Pages functionality. – Karl Knechtel Jun 09 '22 at 16:45
13

The two fragments you've highlighted contradict each other.

The real question is: What will the courts make out of this, if a fork happens, and the original author decides to sue?

I am not going to predict the outcome of such a conflict. The court may decide the law is superior to the click-wrap of GitHub's TOS, or vice versa. Nobody will know the answer until this has been tried in court.

However, I would strongly advice anyone against forking a GitHub project without a license. IMHO the legal risks of doing so outweigh any benefits.

However, if you do so, "what's the license of the new fork"? Well, unless you put an explicit license on your fork the copyright law default ("All rights reserved") applies to the derivative, with the original author holding the copyright on his lines of code, and you holding the copyright on your adaptations.

Also: Putting an explicit FLOSS license will increase your legal liability if you do this. Not only are you violating the original author's copyright, you are falsifying the integrity of rights information. This may increase the damages you will have to pay.

kdopen
  • 6,967
  • 2
  • 28
  • 58
Free Radical
  • 9,065
  • 2
  • 28
  • 62
  • 1
    Yes. I really don't understand why Github added that to their ToS. At least they could have made it clearer, but as it is, it is a legal mess and such code is best left untouched. – Mnementh Jul 15 '15 at 11:38
  • 1
    But speculation is not good. Essentially, it means your giving your opinion on the matter. Note that within your answer. – Zizouz212 Jul 15 '15 at 12:08
  • 1
    @Zizouz212, there is no speculation in my answer. It was stated up front that my comment (now deleted as it seems to have confused you) about why the GitHub TOS has this contradictory clause, was speculation. – Free Radical Jul 15 '15 at 12:14
  • 6
    Sorry, but this is a misunderstanding of the law. "All rights reserved" is indeed the default legal position, but it is a very weak position as the usual intent is to license specific rights. Very few books are written without the intent to be printed, very few TV shows are made without the intent of being broadcast. Therefore, license grants are perfectly normal and respected by the law. Copyright law simply can't be superior to such grants, it would entirely defeat the purpose of the law. – MSalters Jul 15 '15 at 13:26
  • @MSalters, of course license grants are perfectly normal and respected by the law. The question here is about the copyright status of a work with no license and therefore no license grants. – Free Radical Jul 15 '15 at 13:39
  • 5
    @FreeRadical: You may want to review the TOS. It specifically mentions that by posting your code on GitHub, you grant two permissions (depending on the settings) : to view and to clone that code. Now you may argue that this TOS is not a separate license document, but there simply is no legal requirement for a license grant to have a particular form. The TOS is a legally valid contract between the author and GitHub which grants the latter a distribution right towards third parties (i.e. internet users). "Clickwrap" is a FUD term here, as the right granted is fundamental to what GitHub is. – MSalters Jul 15 '15 at 18:29
4

It seems obvious that this was intended to protect Github itself from claims of copyright infringement arising from the creation of forks. It wasn't meant for the benefit of Github users, so it's not surprising that it's of little practical use. You can create a fork, but without a license, you still can't do anything with the fork.

Kevin Krumwiede
  • 409
  • 3
  • 6
  • 2
    "You can create a fork, but without a license, you still can't do anything with the fork." You could well be right, but can you provide any evidence (such as from the Github TOS or other help docs) which confirm this? – curiousdannii Jul 16 '15 at 10:44
  • 5
    It's quoted in the question: "the absence of a license means that the default copyright laws apply." But that's not true because Github says so; it's true because copyright is automatic. – Kevin Krumwiede Jul 16 '15 at 16:26
  • That doesn't relate to what I was asking about. – curiousdannii Jul 16 '15 at 20:46
  • @curiousdannii Then I don't understand your question. – Kevin Krumwiede Jul 16 '15 at 20:56
  • How do you know that what Github calls a "right to fork" means you can copy the code but not develop it? Normally forks include development, so while you could be right, you need to show some evidence that they're not using the normal sense of the word. – curiousdannii Jul 16 '15 at 20:59
  • @curiousdannii Even if they are using it in the normal sense of the word, what good is it to be able to create a derivative work if you're not allowed to distribute it? (I'd argue that distribution is not implied by the normal sense of the word "fork.") – Kevin Krumwiede Jul 16 '15 at 21:04
  • This whole question is about what exactly the "right to fork" implies. I'm just saying that you need to provide evidence for your assertion. – curiousdannii Jul 16 '15 at 21:06
  • 2
    @curiousdannii You can easily look up the definition of the word "fork." The elements of the definition are pretty universal: 1) creating a copy of a program and 2) making modifications to the copy. There is nothing in the definition of the word "fork" that implies an automatic grant of any kind of license. There is no reason to assume that a "right to fork" means anything other than exactly what it says. And no, I don't need to provide evidence of this; the burden of proof would be on anyone claiming that the phrase means something other than what the words literally mean. – Kevin Krumwiede Jul 16 '15 at 23:15
  • @KevinKrumwiede, as I understand copyright law, if I get a copy of the code legally, I can do whatever I want with my copy. Compile it, translate comments into Swahili, mangle it from Pascal into C, all for my personal amusement or use. I can't distribute either the original (nor derived versions), however. – vonbrand Mar 05 '16 at 01:53
  • @vonbrand But creating a fork on Github is distribution. – Kevin Krumwiede Mar 05 '16 at 01:56