New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DRAFT UPDATE to GitHub Terms of Service #1

Merged
merged 1 commit into from Aug 7, 2017

Conversation

@bluemazzoo
Contributor

bluemazzoo commented Jun 10, 2017

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.

Show outdated Hide outdated Policies/github-terms-of-service.md
#### 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

This comment has been minimized.

@jamierocks

jamierocks Jul 6, 2017

Why the newline? This format hasn't been used anywhere else.

@jamierocks

jamierocks Jul 6, 2017

Why the newline? This format hasn't been used anywhere else.

Show outdated Hide outdated Policies/github-terms-of-service.md
### 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.

This comment has been minimized.

@jamierocks

jamierocks Jul 6, 2017

Would like nicer if there was a newline here + it seems to be the format.
The sames goes for 1 through 4.

@jamierocks

jamierocks Jul 6, 2017

Would like nicer if there was a newline here + it seems to be the format.
The sames goes for 1 through 4.

This comment has been minimized.

@jglasgow3

jglasgow3 Jul 10, 2017

Should there any provisions here for non-profit/educational entities?

@jglasgow3

jglasgow3 Jul 10, 2017

Should there any provisions here for non-profit/educational entities?

This comment has been minimized.

@dsstutts

dsstutts Jul 17, 2017

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.

@dsstutts

dsstutts Jul 17, 2017

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.

This comment has been minimized.

@nsqe

nsqe Aug 1, 2017

Contributor

Thanks, @jamierocks, @jglasgow3, and @dsstutts — we've fixed these! See f470f8a.

@nsqe

nsqe Aug 1, 2017

Contributor

Thanks, @jamierocks, @jglasgow3, and @dsstutts — we've fixed these! See f470f8a.

Show outdated Hide outdated Policies/github-terms-of-service.md
#### 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.

This comment has been minimized.

@jamierocks

jamierocks Jul 6, 2017

security reasons is perfectly valid in the short version, but perhaps a more expanded on description should be provided here?

@jamierocks

jamierocks Jul 6, 2017

security reasons is perfectly valid in the short version, but perhaps a more expanded on description should be provided here?

This comment has been minimized.

@djfurman

djfurman Jul 8, 2017

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?

@djfurman

djfurman Jul 8, 2017

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?

This comment has been minimized.

@LeifAndersen

LeifAndersen Jul 9, 2017

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.)

@LeifAndersen

LeifAndersen Jul 9, 2017

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.)

This comment has been minimized.

@HNJAMeindersma

HNJAMeindersma Jul 9, 2017

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)

@HNJAMeindersma

HNJAMeindersma Jul 9, 2017

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)

This comment has been minimized.

@pckilgore

pckilgore Jul 11, 2017

Will GitHub notify us of Subpoena and provide an account holder with an opportunity to move to quash?

@pckilgore

pckilgore Jul 11, 2017

Will GitHub notify us of Subpoena and provide an account holder with an opportunity to move to quash?

This comment has been minimized.

@heartles

heartles Jul 16, 2017

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.

@heartles

heartles Jul 16, 2017

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.

This comment has been minimized.

@dynaread
@dynaread

This comment has been minimized.

@gau-veldt

gau-veldt Jul 16, 2017

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.

@gau-veldt

gau-veldt Jul 16, 2017

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.

This comment has been minimized.

@tpietsc1

tpietsc1 Jul 17, 2017

Security reason sounds quite generic and without detailed description it should be removed.

@tpietsc1

tpietsc1 Jul 17, 2017

Security reason sounds quite generic and without detailed description it should be removed.

This comment has been minimized.

@nsqe

nsqe Aug 1, 2017

Contributor

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.

@nsqe

nsqe Aug 1, 2017

Contributor

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.

Show outdated Hide outdated Policies/github-terms-of-service.md
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.

This comment has been minimized.

@LeifAndersen

LeifAndersen Jul 9, 2017

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.

@LeifAndersen

LeifAndersen Jul 9, 2017

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.

This comment has been minimized.

@yngndrw

yngndrw Jul 12, 2017

...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.

@yngndrw

yngndrw Jul 12, 2017

...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.

This comment has been minimized.

@mundschenk-at

mundschenk-at Jul 16, 2017

@yngndrw Chapter 3 defines "Your Content" in a specific way, that's why it is capitalized.

@mundschenk-at

mundschenk-at Jul 16, 2017

@yngndrw Chapter 3 defines "Your Content" in a specific way, that's why it is capitalized.

This comment has been minimized.

@GinjaNinja32

GinjaNinja32 Jul 16, 2017

'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.

@GinjaNinja32

GinjaNinja32 Jul 16, 2017

'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.

This comment has been minimized.

@matthewhuangsap

matthewhuangsap Jul 17, 2017

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!

@matthewhuangsap

matthewhuangsap Jul 17, 2017

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!

This comment has been minimized.

@nsqe

nsqe Jul 21, 2017

Contributor

@matthewhuangsap That's correct.

@nsqe

nsqe Jul 21, 2017

Contributor

@matthewhuangsap That's correct.

This comment has been minimized.

@nsqe

nsqe Aug 1, 2017

Contributor

@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.

@nsqe

nsqe Aug 1, 2017

Contributor

@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.

Show outdated Hide outdated Policies/github-terms-of-service.md
#### 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.

This comment has been minimized.

@Benjamin-Dobell

Benjamin-Dobell Jul 9, 2017

, 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.

@Benjamin-Dobell

Benjamin-Dobell Jul 9, 2017

, 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.

This comment has been minimized.

@Benjamin-Dobell

Benjamin-Dobell Jul 9, 2017

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?)

@Benjamin-Dobell

Benjamin-Dobell Jul 9, 2017

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?)

This comment has been minimized.

@americast

americast Jul 10, 2017

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.

@americast

americast Jul 10, 2017

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.

This comment has been minimized.

@nsqe

nsqe Jul 10, 2017

Contributor

, 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.)

@nsqe

nsqe Jul 10, 2017

Contributor

, 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.)

This comment has been minimized.

@dynaread

dynaread Jul 16, 2017

Thumbs Up!

@dynaread

This comment has been minimized.

@dcerisano

dcerisano Jul 16, 2017

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.

@dcerisano

dcerisano Jul 16, 2017

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.

This comment has been minimized.

@jeremykohn

jeremykohn Jul 16, 2017

@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

@jeremykohn

jeremykohn Jul 16, 2017

@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

This comment has been minimized.

@tristandl

tristandl Jul 16, 2017

ditto the issue of confidentially around issues/PRs etc - clarification here would be nice

@tristandl

tristandl Jul 16, 2017

ditto the issue of confidentially around issues/PRs etc - clarification here would be nice

This comment has been minimized.

@nsqe

nsqe Jul 21, 2017

Contributor

@dcerisano:

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.

@nsqe

nsqe Jul 21, 2017

Contributor

@dcerisano:

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.

This comment has been minimized.

@nsqe

nsqe Aug 1, 2017

Contributor

@Benjamin-Dobell Re:

, and only the contents of private repositories,

Thanks for the suggestion! Fixed here: f470f8a

@nsqe

nsqe Aug 1, 2017

Contributor

@Benjamin-Dobell Re:

, and only the contents of private repositories,

Thanks for the suggestion! Fixed here: f470f8a

Show outdated Hide outdated Policies/github-terms-of-service.md
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.

This comment has been minimized.

@jamierocks

jamierocks Jul 10, 2017

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?

@jamierocks

jamierocks Jul 10, 2017

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?

This comment has been minimized.

@dynaread

dynaread Jul 16, 2017

Agree 100%

@dynaread

This comment has been minimized.

@dcerisano

dcerisano Jul 16, 2017

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.

@dcerisano

dcerisano Jul 16, 2017

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.

This comment has been minimized.

@nicolas17

nicolas17 Jul 16, 2017

@dcerisano stop posting that comment everywhere, it's not relevant to the discussion of the policies

@nicolas17

nicolas17 Jul 16, 2017

@dcerisano stop posting that comment everywhere, it's not relevant to the discussion of the policies

This comment has been minimized.

@dcerisano

dcerisano Jul 16, 2017

@nicolas17 It is only posted where relevant, and effectively negates the requirement for any git service provider policy discussions such as this.

@dcerisano

dcerisano Jul 16, 2017

@nicolas17 It is only posted where relevant, and effectively negates the requirement for any git service provider policy discussions such as this.

This comment has been minimized.

@nsqe

nsqe Aug 1, 2017

Contributor

@jamierocks We do explicitly define, in S.1, which law governs. In contracts, that is generally found at the end, not in the definitions.

@nsqe

nsqe Aug 1, 2017

Contributor

@jamierocks We do explicitly define, in S.1, which law governs. In contracts, that is generally found at the end, not in the definitions.

Show outdated Hide outdated Policies/github-terms-of-service.md
@@ -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.*

This comment has been minimized.

@jamierocks

jamierocks Jul 10, 2017

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.

@jamierocks

jamierocks Jul 10, 2017

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.

This comment has been minimized.

@nsqe

nsqe Aug 1, 2017

Contributor

@jamierocks Thanks, the current version does reflect that it's Section H!

@nsqe

nsqe Aug 1, 2017

Contributor

@jamierocks Thanks, the current version does reflect that it's Section H!

Show outdated Hide outdated Policies/github-terms-of-service.md
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.

This comment has been minimized.

@gdgib-bina

gdgib-bina Jul 12, 2017

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?

@gdgib-bina

gdgib-bina Jul 12, 2017

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?

This comment has been minimized.

@jamierocks

jamierocks Jul 12, 2017

There is a definition of Your.

@jamierocks

jamierocks Jul 12, 2017

There is a definition of Your.

This comment has been minimized.

@Kasijjuf

Kasijjuf Jul 16, 2017

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.

@Kasijjuf

Kasijjuf Jul 16, 2017

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.

This comment has been minimized.

@nsqe

nsqe Jul 21, 2017

Contributor

@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.

@nsqe

nsqe Jul 21, 2017

Contributor

@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.

Show outdated Hide outdated Policies/github-terms-of-service.md
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.

This comment has been minimized.

@0xcaff

0xcaff Jul 12, 2017

It would be cool if you guys put a cryptographic hash in the blockchain everytime this document is changed too. Maybe by using KeybaseFS?

@0xcaff

0xcaff Jul 12, 2017

It would be cool if you guys put a cryptographic hash in the blockchain everytime this document is changed too. Maybe by using KeybaseFS?

This comment has been minimized.

@berlincount

berlincount Jul 16, 2017

Hm. Git is a big bunch of cryptographic hashes? Do you really need more papertrail? A GPG signature would be nice, though.

@berlincount

berlincount Jul 16, 2017

Hm. Git is a big bunch of cryptographic hashes? Do you really need more papertrail? A GPG signature would be nice, though.

This comment has been minimized.

@tyrope

tyrope Jul 18, 2017

"You" and "Us" should be capitalized here, no?

@tyrope

tyrope Jul 18, 2017

"You" and "Us" should be capitalized here, no?

This comment has been minimized.

@nsqe

nsqe Jul 21, 2017

Contributor

@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?

@nsqe

nsqe Jul 21, 2017

Contributor

@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?

This comment has been minimized.

@wking

wking Jul 22, 2017

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.

@wking

wking Jul 22, 2017

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.

This comment has been minimized.

@tyrope

tyrope Jul 22, 2017

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?

@tyrope

tyrope Jul 22, 2017

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?

@mbc1710

This comment has been minimized.

Show comment
Hide comment
@mbc1710

mbc1710 commented Jul 13, 2017

Ok

Show outdated Hide outdated Policies/github-terms-of-service.md
#### 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.

This comment has been minimized.

@gs-rezaem

gs-rezaem Jul 14, 2017

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.

@gs-rezaem

gs-rezaem Jul 14, 2017

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.

This comment has been minimized.

@kaithar

kaithar Jul 19, 2017

@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.

@kaithar

kaithar Jul 19, 2017

@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.

This comment has been minimized.

@gs-rezaem

gs-rezaem Jul 19, 2017

"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.

@gs-rezaem

gs-rezaem Jul 19, 2017

"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.

This comment has been minimized.

@nsqe

nsqe Jul 22, 2017

Contributor

@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?

@nsqe

nsqe Jul 22, 2017

Contributor

@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?

This comment has been minimized.

@gs-rezaem

gs-rezaem Jul 24, 2017

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?

@gs-rezaem

gs-rezaem Jul 24, 2017

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?

This comment has been minimized.

@gs-rezaem

gs-rezaem Jul 31, 2017

@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).

@gs-rezaem

gs-rezaem Jul 31, 2017

@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).

This comment has been minimized.

@nsqe

nsqe Jul 31, 2017

Contributor

@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.

@nsqe

nsqe Jul 31, 2017

Contributor

@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.

This comment has been minimized.

@gs-rezaem

gs-rezaem Aug 1, 2017

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?

@gs-rezaem

gs-rezaem Aug 1, 2017

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?

This comment has been minimized.

@gs-rezaem

gs-rezaem Aug 1, 2017

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.

@gs-rezaem

gs-rezaem Aug 1, 2017

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.

This comment has been minimized.

@nsqe

nsqe Aug 1, 2017

Contributor

Thanks, @gs-rezaem — no problem at all. We like discussions like these. They help us make our policies better.

@nsqe

nsqe Aug 1, 2017

Contributor

Thanks, @gs-rezaem — no problem at all. We like discussions like these. They help us make our policies better.

@Kimeiga

This comment has been minimized.

Show comment
Hide comment
@Kimeiga

Kimeiga Jul 16, 2017

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. 😄

Kimeiga commented Jul 16, 2017

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. 😄

@CrazyPython

This comment has been minimized.

Show comment
Hide comment
@CrazyPython

CrazyPython Jul 16, 2017

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?

CrazyPython commented Jul 16, 2017

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?

@oehm-smith

This comment has been minimized.

Show comment
Hide comment
@oehm-smith

oehm-smith Jul 17, 2017

I love the TLDR / Short Version. First time I've seen these. So refreshing.

oehm-smith commented Jul 17, 2017

I love the TLDR / Short Version. First time I've seen these. So refreshing.

wking added a commit to wking/github-site-policy that referenced this pull request Jul 18, 2017

github-terms-of-service D: Locally condition grants on existing license
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).

wking added a commit to wking/github-site-policy that referenced this pull request Jul 18, 2017

github-terms-of-service D: Locally condition grants on existing license
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).

wking added a commit to wking/github-site-policy that referenced this pull request Jul 18, 2017

github-terms-of-service D: Locally condition grants on existing license
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).
Show outdated Hide outdated Policies/github-terms-of-service.md
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.

This comment has been minimized.

@wking

wking Jul 18, 2017

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.

@wking

wking Jul 18, 2017

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.

@nsqe

This comment has been minimized.

Show comment
Hide comment
@nsqe

nsqe Jul 22, 2017

Contributor

@CrazyPython

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?

It's in our Privacy Statement:

In complying with court orders and similar legal processes, GitHub strives for transparency. When permitted, we will make a reasonable effort to notify users of any disclosure of their information, unless we are prohibited by law or court order from doing so, or in rare, exigent circumstances.

For more information, see our Guidelines for Legal Requests of User Data.

Contributor

nsqe commented Jul 22, 2017

@CrazyPython

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?

It's in our Privacy Statement:

In complying with court orders and similar legal processes, GitHub strives for transparency. When permitted, we will make a reasonable effort to notify users of any disclosure of their information, unless we are prohibited by law or court order from doing so, or in rare, exigent circumstances.

For more information, see our Guidelines for Legal Requests of User Data.

@Ashiftahan

This comment has been minimized.

Show comment
Hide comment
@Ashiftahan

Ashiftahan commented Jul 22, 2017

well done

@github github deleted a comment Jul 26, 2017

bluemazzoo added a commit that referenced this pull request Jul 26, 2017

Additional edits based on feedback
Here are a few edits, based on the following feedback:

#19

#1 (comment)

#1 (comment)

#1 (comment)

bluemazzoo added a commit that referenced this pull request Jul 26, 2017

Additional edits based on feedback
Here are a few edits based on the following feedback:

#19

#1 (comment)

#1 (comment)

#1 (comment)
@bluemazzoo

This comment has been minimized.

Show comment
Hide comment
@bluemazzoo

bluemazzoo Jul 26, 2017

Contributor

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:

  • DMCA Takedown Policy
  • Corporate ToS
  • standard ToS

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.

Contributor

bluemazzoo commented Jul 26, 2017

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:

  • DMCA Takedown Policy
  • Corporate ToS
  • standard ToS

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.

bluemazzoo added a commit that referenced this pull request Aug 5, 2017

wking pushed a commit to wking/github-site-policy that referenced this pull request Aug 6, 2017

@bluemazzoo bluemazzoo merged commit 34837ab into master Aug 7, 2017

@mlinksva mlinksva deleted the github-tos-update-july-2017 branch Sep 24, 2017

craigez pushed a commit to craigez/site-policy that referenced this pull request Oct 6, 2017

craigez pushed a commit to craigez/site-policy that referenced this pull request Oct 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment