10

I would like to know, under what license is the content of GitHub issues that were created by others.

To clarify my needs:

  • By "issues created by others", I mean issues created by GitHub users both in their own repositories and in the repositories of others.
  • By "content", I mean all content that GitHub allows one to put into an issue – source code, images, poems, personal thoughts, etc.

What I have discovered so far

  1. GitHub's Terms of Service explicitly mention issues only in one place – in the point D.5 (they are mentioned as a part of so-called "User-Generated Content"), but there is only one indication of things interesting for me: that other GitHub users may view issues.

  2. I have tried to find indications of license (or just rights and obligations) for "User-Generated Content" in the Terms, but I could not find anything more specific than in the point D.5, according to my needs.

  3. In the point D.6, the Terms state:

    Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms.

    I suspect that the mentioned "contribution" might include issues, but I am not sure whether it is so.

Silv
  • 231
  • 1
  • 5
  • 2
    What concrete thing are you asking about? For example, suppose you attach a photograph (that you created yourself) into a GitHub issue of someone else's repository, without stating a license for use of your photograph; are you asking under what license that photograph is published? – Brandin Nov 05 '19 at 07:28
  • 1
    @Brandin Yes, that is an example of what I am asking. Maybe I should have used the word "license". – Silv Nov 05 '19 at 22:22
  • Yes I mean if you ask a specifc case like this it might be easier to answer this. Right now "what rights and obligations do I have" is kind of open ended. – Brandin Nov 05 '19 at 22:26
  • @Brandin I have changed the title, and slightly the body. – Silv Nov 05 '19 at 22:35
  • @MadHatter I generally consider my questions written in the most appropriate way (that I want to express them), but anyway, thanks for editing. Maybe it is now indeed clearer. – Silv Nov 06 '19 at 15:14
  • @Silv you should of course feel free to roll back any change you don't like! That said, my main edit was to remove the first definition (of "one"), since you yourself had removed that term from the title, thus rendering the definition a bit out of place! – MadHatter Nov 06 '19 at 15:38
  • 1
    @MadHatter Oh, right, I did not noticed that I am not using it anymore, now I see. Anyway, thanks for encouraging me to be more sure of myself. I really find the post clearer now. Either way, I think the key word is "license". – Silv Nov 06 '19 at 22:01
  • It usually is, round here :) – MadHatter Nov 07 '19 at 06:02

1 Answers1

3

IANAL, but in my understanding GitHub issues can be considered as documentation associated with source code. The only difference between opening an issue and sending a PR or committing changes directly is purely technical. The effect is the same: you add content to the repository.

If you released your repository under, say, the MIT license, then the license also applies to the documentation. You can also explicitly mention a license for documentation.

GitHub functions in a way that all contributions use the same license initially used - except otherwise stated. This rule is often referred as "inbound=outbound" and it is explicitly stated on the site. However, I'm not entirely sure it has a real legal ground without a proper Contributor Licensing Agreement. Well, most projects do not ask for a CLA or even a DCO - so I am guessing it is fine. There is a controversy about the real legal necessity of using a CLA in general, so I imagine that the answer to this question is also controversial.

All things considered, we can reasonably expect issues to be bound to the documentation license chosen by the repository.

EDIT: to respond to comments I haven't read anything from GitHub that confirm the previous statement, it was just an educated guess. Open-source teams often regard issues as documentation. However, what happens when you're the sole owner of the project (no external commits or PR) and you change the license? What about the issues posted by others? Issues could simply be "all rights reserved". Frankly I am not sure about it and the suggestion below is even more appropriate.

In doubt, reaching out to GitHub directly is probably best. You mentioned poems and other contents potentially unrelated to the software (is it even a software you're storing on GitHub?). Honestly, it's a great question.

N. Gimenez
  • 501
  • 5
  • 8
  • 1
    "GitHub issues can be considered as documentation associated with source code" - Maybe this is true but is there something in GitHub's terms that makes you think this? If so please cite a source to that. To me it's not obvious that something you post on an "issue" board of a project is automatically the same license as the project owner of that happened to choose. Of course if I post something on GitHub then of course I am accepting GitHub's TOSes, but beyond that I don't see how me posting something automatically agrees to a separate license with the project owner that posted on GitHub. – Brandin Apr 06 '20 at 12:23
  • 1
    The other possible problem with this interpretation is what happens if the owner changes the license? If you are the sole owner of a project, you can normally change the license. Does that change the license of all the issues too? – Brandin Apr 06 '20 at 12:24
  • 1
    Answer edited to mention your remarks. – N. Gimenez Apr 06 '20 at 13:45
  • 1
    It is true that without clear explicit terms neither in the repository License itself, nor in GitHub terms, default could be that issues are simply "all rights reserved". – N. Gimenez Apr 06 '20 at 13:48
  • @N.Gimenez, can you edit your answer such that it is internally consistent? (you might use strikethroughs) As it is, I can't tell what you are saying since you contradict yourself everywhere. ¶¶¶

    re "purely technical" "same: you add content to the repository"; That's rubbish [or citation needed]. For when you git fetch, you actually do get all "documentation" and all "issues" if they are within the folders but you don't get anything posted "the issues way". ¶ re MIT, it "also applies to the documentation" only if a copy of which is..

     – Pacerier Oct 29 '23 at 18:18
  • ..obtained and if they are also documentation files. Are they "Files" and "Copy Obtained"? ¶ re "all contributions use the same license"; That's rubbish [or citation needed]. All what contributions? ¶ re "reasonably expect"; This is unreasonable because poster didn't see the post appearing within the folders. But assuming he did [due to getting hacked etc], this is unreasonable because.. – Pacerier Oct 29 '23 at 18:19
  • ..poster didn't expect that to happen (nor was it easy to fix the error by subsequent deletes/undos). But assuming he did, this is unreasonable because fetcher did not see it git fetched. But assuming he did [due-hacked], this is unreasonable because fetcher didn't expect to see it. But assuming he did, this is unreasonable because GH-Issue contains a myriad of things not just bugs and documentation proper. ¶ re ""Open-source teams often [legally] regard issues as documentation""; Citation needed. and clarification [of the words used especially] needed. – Pacerier Oct 29 '23 at 18:21