DRAFT UPDATE to GitHub Terms of Service #1
Conversation
Policies/github-terms-of-service.md
Outdated
| #### 5. Complete Agreement | ||
| These Terms of Service, together with the GitHub Privacy Statement, represent the complete and exclusive statement of the agreement between you and us. This Agreement supersedes any proposal or prior agreement oral or written, and any other communications between you and GitHub relating to the subject matter of these terms. | ||
| #### 5. Amendments; Complete Agreement | ||
|
|
There was a problem hiding this comment.
Why the newline? This format hasn't been used anywhere else.
Policies/github-terms-of-service.md
Outdated
|
|
||
| ### E. Copyright Infringement and DMCA Policy | ||
| #### 1. Control of Private Repositories. | ||
| Paid accounts may have private repositories, which allow the User to control access to Content. |
There was a problem hiding this comment.
Would like nicer if there was a newline here + it seems to be the format.
The sames goes for 1 through 4.
There was a problem hiding this comment.
Should there any provisions here for non-profit/educational entities?
There was a problem hiding this comment.
It is my understanding that academics are allowed free private repos, but there seems to be no setting or option in the web interface recognizing this provision. I also agree with jglasgow3 that academic/nonprofit provision should be spelled out in the TOS.
There was a problem hiding this comment.
Thanks, @jamierocks, @jglasgow3, and @dsstutts — we've fixed these! See f470f8a.
Policies/github-terms-of-service.md
Outdated
| #### 3. Access. | ||
| GitHub employees may only access the content of your private repositories in the following situations: | ||
| - With your consent and knowledge, for support reasons. If GitHub accesses a private repository for support reasons, we will only do so with the owner’s consent and knowledge. | ||
| - When access is required for security reasons. |
There was a problem hiding this comment.
security reasons is perfectly valid in the short version, but perhaps a more expanded on description should be provided here?
There was a problem hiding this comment.
Agree with @jamierocks on the security reasons the intent here is unclear, what security reasons would be included? Would any be excluded? Would the consent and knowledge clause not apply here? Is there a limit or restriction on considering something a security reason?
There was a problem hiding this comment.
I agree. What is a 'security reason'? Is it case of a court order, or is it just when github feels it needs to do it to test out system security. (Just so we're clear, either is fine with me, but its important to know which it is.)
There was a problem hiding this comment.
I agree on the fact that "for security reasons" should be specified and limited by the policy.
- When GitHub has a legitimate reason to believe that certain content is a treath to or damaging GitHub's services and infrastructure, then GitHub is allowed to access (your) private repositories.
Also see: #19
Further more it would be great to add something following this section where GitHub promises to notify the user about this access like it says in the first section. (Unless forbidden by court)
There was a problem hiding this comment.
Will GitHub notify us of Subpoena and provide an account holder with an opportunity to move to quash?
There was a problem hiding this comment.
Agree completely on the "for security reasons". Might be good to clarify the whole "required to by law" thing tho
When GitHub has a legitimate reason to believe that certain content is a threat to or is damaging GitHub's services and infrastructure, or when required to by law, then GitHub is allowed to access (your) private repositories without consent. GitHub will notify the owner of this private repository upon such an access, unless prohibited by law.
There was a problem hiding this comment.
In the day and age of mass bulk gag-and-spy orders it's pretty much a necessity to use a warrant canary to afford any protection to the end user.
There was a problem hiding this comment.
Security reason sounds quite generic and without detailed description it should be removed.
There was a problem hiding this comment.
Thanks, everyone, for your suggestions!
We really worked long and hard on how best to put more language around what we mean by "security reasons." After a great deal of discussion, we think we already give enough context in our Terms of Service, and in the event of a security incident that puts GitHub at risk, we need to make sure we are able to respond quickly.
More specifically, one thing to understand here is that we have intentionally restricted ourselves a lot when it comes to accessing private repositories. We've given our users not just a privacy clause but a full confidentiality agreement, and our agreement establishes that by default, GitHub employees may not access private repository contents. There are only certain enumerated situations in which we can access private repository contents, and we limit the number of employees with the ability to do so.
For those asking, our internal security investigations are completely different from our responses to warrants, subpoenas, and other court actions. Section E.4 of the Terms of Service does reference our policy on compelled disclosure.
So for right now, we're going to leave this as it is. However, if we get more discussion about it in our next comment period, we're certainly willing to reconsider.
Policies/github-terms-of-service.md
Outdated
|
|
||
| If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub's functionality. You may grant further rights if you [adopt a license](/articles/adding-a-license-to-a-repository/#including-an-open-source-license-in-your-repository). | ||
| If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you [adopt a license](/articles/adding-a-license-to-a-repository/#including-an-open-source-license-in-your-repository). If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users. |
There was a problem hiding this comment.
One example of github's functionality is to download a snapshot of the current commit. Is that covered? If so, that should be stated, if not, it could be used as an example of what not is covered.
There was a problem hiding this comment.
...and perform Your Content through the GitHub Service...
I'm not sure what "perform your content" means, although it was also mentioned in the previous version.
Also "your" should not be capitalised.
There was a problem hiding this comment.
@yngndrw Chapter 3 defines "Your Content" in a specific way, that's why it is capitalized.
There was a problem hiding this comment.
'perform' is explained a couple of paragraphs up:
4. License Grant to Us
[...] You grant us and our legal successors the right to [...] perform [Your Content], in case Your Content is something like music or video.
There was a problem hiding this comment.
I presume that the license to 'use', 'perform' and 'distribute' the Content does not include permission to use/perform/distribute the Content off Github, ie. a proprietary application? So an additional explicit license ie. MIT is required to use the code outside of Github.
Thanks in advance!
There was a problem hiding this comment.
@matthewhuangsap That's correct.
There was a problem hiding this comment.
@LeifAndersen Sorry, I missed your question earlier.
One example of github's functionality is to download a snapshot of the current commit. Is that covered?
No. The license grant in GitHub's Terms of Service only covers copies made on GitHub. However, most open source licenses cover things like local copies, and they may also be covered by legal exceptions such as fair use.
Policies/github-terms-of-service.md
Outdated
| #### 1. Control of Private Repositories. | ||
| Paid accounts may have private repositories, which allow the User to control access to Content. | ||
| #### 2. Confidentiality of Private Repositories. | ||
| GitHub considers the contents of private repositories, and only the contents of private repositories, to be confidential to you. GitHub will protect the contents of private repositories from unauthorized use, access, or disclosure in the same manner that we would use to protect our own confidential information of a similar nature and in no event with less than a reasonable degree of care. |
There was a problem hiding this comment.
, and only the contents of private repositories,
This seems to be explicitly stating that Github considers everything other than "the contents of private repositories" to be non-confidential.
If that is the case it seems to be at odds with both common sense and all sorts of privacy legislation world-wide. I'm doubtful this was intentionally worded this way, perhaps a small oversight/mistake?
I propose this wording be dropped, so the sentence simply becomes:
GitHub considers the contents of private repositories to be confidential to you.
There was a problem hiding this comment.
I think you also ought to define what the "contents" are.
Is that the patch-sets only? Does it include the list of contributors? Does it include the commit messages? Or is it everything one would obtain if they were to perform a full clone of the repository?
What about information that isn't contained within private repositories, but rather is associated with them (Issues, Pull Requests etc?)
There was a problem hiding this comment.
GitHub will protect the contents of private repositories from unauthorized use, access, or disclosure in the same manner that we would use to protect our own confidential information
Access to data in a private repository may be gained if it is hosted on a GitHub page. An explicit declaration of the same may be done.
Please correct me if this has been mentioned elsewhere.
There was a problem hiding this comment.
, and only the contents of private repositories,
@Benjamin-Dobell Really good point regarding ☝️ . Thanks for bringing that up. We're taking a much closer look at that now!
(We'll respond to other comments shortly, but this one was pretty important, so I wanted to give you a quick response.)
There was a problem hiding this comment.
Encryption should really be standard git functionality.
The onus would then be on git users to secure their assets, not git service providers who don't provide encryption services, even for "private" repositories.
Public and private remote assets can now be independently secured with git-crypt. Works with all git clients and services.
There was a problem hiding this comment.
@cclauss Not too likely. Anyone can access a secret gist if they have the URL for it, so it isn't comparable to a private repo that can only be accessed by specified users.
"Secret gists are hidden from search engines but visible to anyone you give the URL." (Source: Title text when you hover over "Create Secret Gist" button)
Here's a secret gist I created that you can access: https://gist.github.com/jeremykohn/af328ba47907875a1f04656ec8d79371
There was a problem hiding this comment.
ditto the issue of confidentially around issues/PRs etc - clarification here would be nice
There was a problem hiding this comment.
Encryption should really be standard git functionality.
We totally agree — however, we don't have any control over what features go into git. We don't maintain it, we just use it. At some point, we may add that functionality onto GitHub. As you mention, there are other tools that add that functionality on for those who are interested in using it.
Are Secret Gists treated like Private Repos from a confidentiality perspective?
@cclauss No. As @jeremykohn mentions, secret gists are not intended to be private, they're just not searchable.
There was a problem hiding this comment.
@Benjamin-Dobell Re:
, and only the contents of private repositories,
Thanks for the suggestion! Fixed here: f470f8a
Policies/github-terms-of-service.md
Outdated
|
|
||
| You may also grant a third-party application authorization to use, access, and disclose the contents of your private repositories. Your use of third-party applications is at your sole risk; GitHub is not liable for disclosures to third parties that you authorize to access a private repository. | ||
| #### 4. Exclusions. | ||
| If we have reason to believe the contents of a private repository are in violation of the law or of these Terms, we have the right to access, review, and remove them. Additionally, we may be [compelled by law](/articles/github-privacy-statement/#how-we-respond-to-compelled-disclosure) to disclose the contents of your private repositories. |
There was a problem hiding this comment.
I am assuming the reference to law here refers to US law - either way this should be explicitly mentioned.
EDIT: I see law is specified as being Californian law below, perhaps Law should be defined in the TOS Definitions?
There was a problem hiding this comment.
Encryption should really be standard git functionality.
The onus would then be on git users to secure their assets, not git service providers who don't provide encryption services, even for "private" repositories.
Public and private remote assets can now be independently secured with git-crypt. Works with all git clients and services.
There was a problem hiding this comment.
@dcerisano stop posting that comment everywhere, it's not relevant to the discussion of the policies
There was a problem hiding this comment.
@nicolas17 It is only posted where relevant, and effectively negates the requirement for any git service provider policy discussions such as this.
There was a problem hiding this comment.
@jamierocks We do explicitly define, in S.1, which law governs. In contracts, that is generally found at the end, not in the definitions.
Policies/github-terms-of-service.md
Outdated
| @@ -177,7 +191,7 @@ If you’d like to use GitHub’s trademarks, you must follow all of our tradema | |||
| #### 3. License to GitHub Policies | |||
| This Agreement is licensed under the [Creative Commons Attribution license](https://creativecommons.org/licenses/by/4.0/). You may use it freely under the terms of the Creative Commons license. | |||
|
|
|||
| ### G. API Terms | |||
| ### H. API Terms | |||
| **Short version:** *You agree to these Terms of Service, plus this Section G, when using any of GitHub's APIs (Application Provider Interface), including use of the API through a third party product that accesses GitHub.* | |||
There was a problem hiding this comment.
There is really no need for the plus this Section G, clause, and it would also need updating to reflect it is now Section H.
There was a problem hiding this comment.
@jamierocks Thanks, the current version does reflect that it's Section H!
Policies/github-terms-of-service.md
Outdated
| GitHub considers the contents of private repositories, and only the contents of private repositories, to be confidential to you. GitHub will protect the contents of private repositories from unauthorized use, access, or disclosure in the same manner that we would use to protect our own confidential information of a similar nature and in no event with less than a reasonable degree of care. | ||
| #### 3. Access. | ||
| GitHub employees may only access the content of your private repositories in the following situations: | ||
| - With your consent and knowledge, for support reasons. If GitHub accesses a private repository for support reasons, we will only do so with the owner’s consent and knowledge. |
There was a problem hiding this comment.
I'm skimming, so my apologies, but a definition of "your" might help here. In particular, does it mean any org admin, or only the person responsible for billing or what?
There was a problem hiding this comment.
This is a lowercase "your". If the meaning is the same as the definition for "Your" given elsewhere in the document, the capitalized version should be used.
There was a problem hiding this comment.
@Kasijjuf We prefer not over-using capitals. Our goal is to create a simple, easy-to-read document, not to go overboard with legalese. "You" and "your" have the same meaning throughout the contract.
That said, because we have the same agreement with any org admin, any org admin can give consent.
Policies/github-terms-of-service.md
Outdated
| These Terms of Service, together with the GitHub Privacy Statement, represent the complete and exclusive statement of the agreement between you and us. This Agreement supersedes any proposal or prior agreement oral or written, and any other communications between you and GitHub relating to the subject matter of these terms. | ||
| #### 5. Amendments; Complete Agreement | ||
|
|
||
| This Agreement may only be modified by a written amendment signed by an authorized representative of GitHub, or by the posting by GitHub of a revised version in accordance with [Section R. Changes to These Terms](/articles/github-terms-of-service/#r-changes-to-these-terms). These Terms of Service, together with the GitHub Privacy Statement, represent the complete and exclusive statement of the agreement between you and us. This Agreement supersedes any proposal or prior agreement oral or written, and any other communications between you and GitHub relating to the subject matter of these terms including any confidentiality or nondisclosure agreements. |
There was a problem hiding this comment.
It would be cool if you guys put a cryptographic hash in the blockchain everytime this document is changed too. Maybe by using KeybaseFS?
There was a problem hiding this comment.
Hm. Git is a big bunch of cryptographic hashes? Do you really need more papertrail? A GPG signature would be nice, though.
There was a problem hiding this comment.
"You" and "Us" should be capitalized here, no?
There was a problem hiding this comment.
@tyrope We prefer not over-using capitals. Our goal is to create a simple, easy-to-read document, not to go overboard with legalese.
I'm so surprised at all these requests for more capitalization. No sarcasm — is it really easier to read and understand a document where "Us" is capitalized all the way through? As someone who drafts these agreements, I'd like to know: do readers not understand who we mean by "You" unless it's capitalized?
There was a problem hiding this comment.
I'm so surprised at all these requests for more capitalization.
I think you have a lot of developers who are used to writing case-sensitive code thinking "you didn't get that variable name right" ;). It's also a nice "this word has a local definition" hint, and shows the writer intended to use that formal definition. That's where I'm coming from, anyway.
There was a problem hiding this comment.
I'm with wking on this one, it's not about easier to read but about clarifying for both parties what the definition is, and if there's one provided why not use it?
|
Ok |
Policies/github-terms-of-service.md
Outdated
|
|
||
| #### 6. Contributions Under Repository License | ||
| 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. If you have a separate agreement to license your contributions under different terms, such as a contributor license agreement, that agreement will supercede. | ||
| 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. If you have a separate agreement to license your contributions under different terms, such as a contributor license agreement, that agreement will supersede. |
There was a problem hiding this comment.
The wording here seems to emphasize repositories with no explicit contribution model (aka "in == out") over those that do. May I suggest a more equitable rewrite (replacing the entire section):
6. Contributions
For repositories that define the legal requirements for licensing your contribution (for example,
in a CONTRIBUTING file), you agree to follow the rules set forth by the repository when you make a contribution.
For repositories that contain a license with no other legal contribution requirement, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound".
If you have a separate agreement to license your contributions under different terms, such as an employment contract, that agreement will supersede all of the above.
There was a problem hiding this comment.
@gs-rezaem uh, actually the wording is more sneakily clever than that. It's saying that in the case of a repo with an explicit model that model supersedes this section if you've agreed to it. The sneaky bit is that if you haven't agreed to it then this section does apply, so not signing a CLA results in contributions being licensed under the repo terms anyway.
Wording things this way avoids issues with contributions implying an automatic signing of a CLA (which would be legally dubious), applies some licence coverage to PRs not covered by a signed CLA, and keeps the issue of licencing separate from other parts of the contribution model (ownership grants for instance). Keeping this section focused purely on the licencing aspect is a good thing.
Another interesting detail is that this section isn't specific to how the alternative agreement is presented. In the case of licencing agreements outside of the scope of the repo (perhaps such as those included in employment contracts) the "separate agreement" wording should still hold water in a way that "repositories that define the legal requirements" doesn't.
There was a problem hiding this comment.
"sneakily clever" and "legal document" are not a good mix 😟 With all due respect, and ignoring the sneakiness, as an owner of a project with a well thought out and properly formulated legal contribution model, I don't believe Github forcing a particular contribution model can do anything but cause confusion and discord. If a project has a legal requirement, it should be either that or nothing. My wording makes that clear and has no sneakiness. Sneakiness can only muddy the waters. I don't see the utility of the semi-hidden escape hatch.
I acknowledge your point regarding outside contracts. A final paragraph in my wording can imply the same (now edited in the original comment):
If you have a separate agreement to license your contributions under different terms, such as an employment contract, that agreement will supersede all of the above.
There was a problem hiding this comment.
@gs-rezaem @kaithar Well, we're certainly not intending to be sneakily clever, or sneaky in any way...or force any form of contribution model. If a project has a legal requirement, such as its own CLA, that requirement supersedes.
We're intending to provide a simple foundation for what can be a fairly complex matter, and phrase it in as clear a way as possible.
If you find the clause suggests something sneaky, we'll take another look — can you clarify what you find sneaky about it?
There was a problem hiding this comment.
I'm glad you described your intention the way you did:
If a project has a legal requirement, such as its own CLA, that requirement supersedes.
That's precisely why I reworded it to start with that assertion (see my first post here). I wasn't thinking about the sneakiness that @kaithar pointed out; I just wanted the text to be clear, but @kaithar's absolutely right. The initial wording introduces a semi-hidden escape hatch and that's not good for a legal contract. My rewording avoids that.
Said differently, is there something in my rewording that's objectionable or unclear?
There was a problem hiding this comment.
@nsqe I'm a little confused. I'm not sure I can reconcile your earlier statements that
we're certainly not intending to be sneakily clever, or sneaky in any way
with your thumbs up to @kaithar's response. IMHO, sneaky clever, even "in a good way" as @kaithar put it, is inappropriate for a legal contact.
Let me restate what's at issue here. The original wording says:
Whenever you make a contribution ... you license your contribution under the same terms .. If you have a separate agreement ... that agreement will supersede
This gives the contributor a choice: follow github's in=out scheme, or if you really want to, use a different agreement.
This can potentially put both Github's terms of service and contributors at odds with project owners. Without this choice bestowed on contributors, if a contributor tries to contribute something without following the expected process, the project owner can point them to the right procedure and ask them to follow it. It's clear to everyone involved that there is no other choice. However, with the choice, the contributor can point the project owner to this document and refuse to follow the proper process. This is not a far fetched scenario. Here are two cases:
Twitter and a removed github comment.
By leaving the wording as is, you're throwing Github's full weight behind in=out. Large organizations like Apache and Google that don't use in=out may not view that favorably.
Please consider changing the wording to make your intent clear (even if it is to push for in=out in the short term and force it in the long run).
There was a problem hiding this comment.
@gs-rezaem I'm not sure what your objection here is, and I'm afraid the links you've provided don't really help clarify it; the link to Twitter doesn't say much, and the Hacker News conversation discusses some of the disagreements over CLAs, but I don't see the specific situation you're concerned about.
We're just setting a default. Any repository owner is welcome to establish their own, more specific agreement, which will, as we said, supersede.
There was a problem hiding this comment.
The objection is simple:
- The language is sneaky.
- This is a document that all github users have to agree to. That includes both project owners and contributors. With the language as it is, a contributor could legitimately tell a project owner:
"you, the project owner, agreed to the github terms of service. According to that document, contributions are valid under in = out. By not accepting the contribution on grounds that you want a different agreement, you're breaking your agreement with Github."
It really isn't very difficult to change the language so that a project owner is given clear, ultimate control, as my wording does. I've heard zero objections to my language, which is clear, not sneaky and establishes the correct precedence of agreements.
We're just setting a default.
The trouble is you're doing a lot more than setting a default. You're giving the contributor a choice to use in=out or the project provided process. I contend, that this choice causes confusion and discord.
I'll ask this one last time: what's wrong with my wording?
There was a problem hiding this comment.
I asked a few people I trust to review this thread and the consensus was that there is no concern with the existing language. Essentially, it comes down to one thing: a project owner may refuse a pull request for any reason and is not obligated by this language to accept a PR under in=out.
Please consider this thread closed, and apologies for dragging it out.
There was a problem hiding this comment.
Thanks, @gs-rezaem — no problem at all. We like discussions like these. They help us make our policies better.
|
I just want to say that I really appreciate having access to diffs between the previous and proposed site policy. I would love if other companies did something like this. 😄 |
|
The USA Freedom Act lets companies disclose when and how often the NSA or another organization has given the company a warrant to disclose information. Perhaps write in here a [legally binding or not] pledge to disclose when GitHub is given a warrant? |
|
I love the TLDR / Short Version. First time I've seen these. So refreshing. |
With 7a72ae0 (DRAFT UPDATE to GitHub Terms of Service, 2017-07-09, #1), the ToS grew new language about conditionally granting licenses in section D.3. However, the text in D.4 and D.5 still read as if the license grant was unconditional. This commit adjusts sections D.4 and D.5 to clearly separate the permissions needed (which are always true) from the ToS grant (which is only needed if the existing license doesn't already grant those permissions). Also * Define a new term, “Other Users” so we can compactly refer to other users without ambiguity. * Adjust the Your Content criteria. For example, if you fork another user's repository, the forked repository is Your Content, just like it would be if you cloned the other user's repository and then created a new GitHub repository seeded from that local clone. This clarifies the case where Alice creates the content and Bob uploads it to GitHub (it would be Your Content for Bob, but not for Alice unless she took other action). * Trim D.3 to cover termination and payment of any permissions granted in the following D.*. The old "we need you to grant us" wasn't conditional, so now that's gone. The old "unless other Users have forked it" is no longer covered in the ToS (more on this below). The remaining lines removed from D.3 are now covered in more detail in their specific sections. * In D.4, remove "to do things like host Your Content, publish it, and share it", which are all covered in more detail in the subsequent section. * In D.4, add a new paragraph explicitly granting GitHub the required permissions if and only if your existing license doesn't already. This section doesn't address things like fair use, where GitHub might have permission to parse and share search results even in the absence of an explicit license, but I couldn't think of a concise way to cover that. * In D.5, I've removed the focus on public content, since any other user who is authorized to view the content requires this permission, regardless of whether the content is public. * In D.5, I've removed the need for fork permission. Users can view your content and decide for themselves whether they're allowed to fork it. If they fork content that you do not consider forkable, you can file a DMCA takedown request. The old "unless other Users have forked it" from D.3 is no longer needed because the forked content is no longer Your Content (see the earlier points about the Your Content criteria).
With 7a72ae0 (DRAFT UPDATE to GitHub Terms of Service, 2017-07-09, #1), the ToS grew new language about conditionally granting licenses in section D.3. However, the text in D.4 and D.5 still read as if the license grant was unconditional. This commit adjusts sections D.4 and D.5 to clearly separate the permissions needed (which are always true) from the ToS grant (which is only needed if the existing license doesn't already grant those permissions). Also * Define a new term, "Other Users" so we can compactly refer to other users without ambiguity. * Adjust the Your Content criteria. For example, if you fork another user's repository, the forked repository is Your Content, just like it would be if you cloned the other user's repository and then created a new GitHub repository seeded from that local clone. This clarifies the case where Alice creates the content and Bob uploads it to GitHub (it would be Your Content for Bob, but not for Alice unless she took other action). * Trim D.3 to cover termination and payment of any permissions granted in the following D.*. The old "we need you to grant us" wasn't conditional, so now that's gone. The old "unless other Users have forked it" is no longer covered in the ToS (more on this below). The remaining lines removed from D.3 are now covered in more detail in their specific sections. * In D.4, remove "to do things like host Your Content, publish it, and share it", which are all covered in more detail in the subsequent section. * In D.4, add a new paragraph explicitly granting GitHub the required permissions if and only if your existing license doesn't already. This section doesn't address things like fair use, where GitHub might have permission to parse and share search results even in the absence of an explicit license, but I couldn't think of a concise way to cover that. * In D.5, I've removed the focus on public content, since any other user who is authorized to view the content requires this permission, regardless of whether the content is public. * In D.5, I've removed the need for fork permission. Users can view your content and decide for themselves whether they're allowed to fork it. If they fork content that you do not consider forkable, you can file a DMCA takedown request. The old "unless other Users have forked it" from D.3 is no longer needed because the forked content is no longer Your Content (see the earlier points about the Your Content criteria).
With 7a72ae0 (DRAFT UPDATE to GitHub Terms of Service, 2017-07-09, #1), the ToS grew new language about conditionally granting licenses in section D.3. However, the text in D.4 and D.5 still read as if the license grant was unconditional. This commit adjusts sections D.4 and D.5 to clearly separate the permissions needed (which are always true) from the ToS grant (which is only needed if the existing license doesn't already grant those permissions). Also * Define a new term, "Other Users" so we can compactly refer to other users without ambiguity. * Adjust the Your Content criteria. For example, if you fork another user's repository, the forked repository is Your Content, just like it would be if you cloned the other user's repository and then created a new GitHub repository seeded from that local clone. This clarifies the case where Alice creates the content and Bob uploads it to GitHub (it would be Your Content for Bob, but not for Alice unless she took other action). I've also removed "You own the content you post on GitHub" and similar, because the poster may not be the copyright holder, and instead have focused on ownership not changing as a result of GitHub posting. * Trim D.3 to cover termination and payment of any permissions granted in the following D.*. The old "we need you to grant us" wasn't conditional, so now that's gone. The old "unless other Users have forked it" is no longer covered in the ToS (more on this below). The remaining lines removed from D.3 are now covered in more detail in their specific sections. * In D.4, remove "to do things like host Your Content, publish it, and share it", which are all covered in more detail in the subsequent section. * In D.4, add a new paragraph explicitly granting GitHub the required permissions if and only if your existing license doesn't already. This section doesn't address things like fair use, where GitHub might have permission to parse and share search results even in the absence of an explicit license, but I couldn't think of a concise way to cover that. * In D.5, I've removed the focus on public content, since any other user who is authorized to view the content requires this permission, regardless of whether the content is public. * In D.5, I've removed the need for fork permission. Users can view your content and decide for themselves whether they're allowed to fork it. If they fork content that you do not consider forkable, you can file a DMCA takedown request. The old "unless other Users have forked it" from D.3 is no longer needed because the forked content is no longer Your Content (see the earlier points about the Your Content criteria).
Policies/github-terms-of-service.md
Outdated
| 4. “The User,” “You,” and “Your” refer to the individual person, company, or organization that has visited or is using the Website or Service; that accesses or uses any part of the account; or that directs the use of the account in the performance of its functions. A User must be at least 13 years of age. Special terms may apply for business or government accounts (See [Section B(4): Additional Terms](#4-additional-terms)). | ||
| 5. “GitHub,” “We,” and “Us” refer to GitHub, Inc., as well as our affiliates, directors, subsidiaries, contractors, licensors, officers, agents, and employees. | ||
| 6. “Content” refers to content featured or displayed through the Website, including without limitation text, data, articles, images, photographs, graphics, software, applications, designs, features, and other materials that are available on the Website or otherwise available through the Service. "Content" also includes Services. “User-Generated Content” is Content, written or otherwise, created or uploaded by our Users. “Paid Content” is Content only available to Users who are participating in a payment plan, including private repositories. | ||
| 6. “Content” refers to content featured or displayed through the Website, including without limitation text, data, articles, images, photographs, graphics, software, applications, designs, features, and other materials that are available on the Website or otherwise available through the Service. "Content" also includes Services. “User-Generated Content” is Content, written or otherwise, created or uploaded by our Users. "Your Content" is Content that you create or own. “Paid Content” is Content only available to Users who are participating in a payment plan, including private repositories. |
There was a problem hiding this comment.
The “Your Content” definition seems ambiguous. For example, if Alice creates some content and Bob uploads it Carol's GitHub repository, then is it Your Content for Alice (who created the content) and Carol (who owns the GitHub representation)? Alice doesn't seem to have any connection that GitHub is aware of, and Bob should be involved somehow.
I expect the goal is to have it be Your Content only for Carol (who owns the repo where it landed) and Bob (only as long as Bob has write access to that repository). Similarly, if Dan opens an issue in Carol's repository, that would be Your Content for Dan and Carol (both of whom can use the web UI to edit the issue post). Ideally, Carol (who was not involved in either transaction short of granting Bob write access) wouldn't have to assert anything about either content. But the right to post is covered in §D.3, so if Bob and Dan have done their due diligence, Carol doesn't have anything to worry about.
I've taken a stab at clarifying this in #54 (filed against this branch), and can separate the change from the rest of #54 if you like.
It's in our Privacy Statement:
|
|
well done |
Here are a few edits, based on the following feedback: #19 #1 (comment) #1 (comment) #1 (comment)
Here are a few edits based on the following feedback: #19 #1 (comment) #1 (comment) #1 (comment)
|
Hi everyone, Thanks for all of your contributions. We just added some updated language to the following drafts, based on feedback we've received here:
Just a friendly reminder, the final drafts will become effective on August 7, so we'd appreciate it if you could provide your feedback and contributions by Tuesday, August 1. That will give us time to review the rest of the feedback, and if necessary, incorporate that feedback into our policies. If we receive substantial feedback after August 1, we will probably set it aside until our next review period. In addition to this review, we'll be responding to any issues that haven't received responses yet during this comment period. We will be accepting some of the changes users have suggested, but not all of the suggestions, and we will discuss some of those decisions. Additionally, several users offered excellent suggestions that will take more time to implement than we have in this drafting period, but we're working on those ideas. |
UPDATE to GitHub Terms of Service
UPDATE to GitHub Terms of Service
…y-statement-and-terms-of-service At 2020-11-04T18:06:06Z [2] bad links found in [https://github.com/gi…
Hey everyone! This is a Draft Update to the GitHub Terms of Service. We would love feedback on this update. Please take a look at our Contribution Guidelines for examples of the types of feedback we're looking for and for other feedback recommendations.
These changes will not be effective until July 21, 2017.NOTE: Apologies for any confusion, these changes will not be effective until August 7, 2017.