The Wayback Machine - https://web.archive.org/web/20170725234720/https://github.com/github/site-policy/pull/1
Skip to content

DRAFT UPDATE to GitHub Terms of Service #1

Open
wants to merge 4 commits into
from

Conversation

Contributor

bluemazzoo commented Jun 10, 2017 edited

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.

bluemazzoo added some commits Jun 10, 2017

@bluemazzoo bluemazzoo DRAFT UPDATE to GitHub Terms of Service
This is a Draft Update to the GitHub Terms of Service. These changes
will not be effective until July 21, 2017.
7a72ae0
@bluemazzoo bluemazzoo Better "short version" explanation
Better “short version” explanation in the new Private Repos section.
b355eea
-### 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.
@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.

@jglasgow3

jglasgow3 Jul 10, 2017

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

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

+#### 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.
@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?

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

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

@HNJAMeindersma

HNJAMeindersma Jul 9, 2017 edited

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)

@pckilgore

pckilgore Jul 11, 2017

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

@dcerisano

dcerisano Jul 16, 2017 edited

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.

@heartles

heartles Jul 16, 2017 edited

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.

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

@tpietsc1

tpietsc1 Jul 17, 2017

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

-#### 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
+
@jamierocks

jamierocks Jul 6, 2017

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

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

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

@mundschenk-at

mundschenk-at Jul 16, 2017

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

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

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

+#### 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.
@Benjamin-Dobell

Benjamin-Dobell Jul 9, 2017 edited

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

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

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

@nsqe

nsqe Jul 10, 2017

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

@cclauss

cclauss Jul 16, 2017

Are Secret Gists treated like Private Repos from a confidentiality perspective?

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

@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

@tristandl

tristandl Jul 16, 2017

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

@nsqe

nsqe Jul 21, 2017

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

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

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

@nicolas17

nicolas17 Jul 16, 2017

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

@dcerisano

dcerisano Jul 16, 2017 edited

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

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

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

@jamierocks

jamierocks Jul 12, 2017

There is a definition of Your.

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

@nsqe

nsqe Jul 21, 2017

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

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

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

@tyrope

tyrope Jul 18, 2017

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

@nsqe

nsqe Jul 21, 2017

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

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

@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 commented Jul 13, 2017

Ok

#### 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.
@gs-rezaem

gs-rezaem Jul 14, 2017 edited

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.

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

@gs-rezaem

gs-rezaem Jul 19, 2017 edited

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

@nsqe

nsqe Jul 22, 2017

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

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

@nsqe

nsqe Jul 24, 2017

Said differently, is there something in my rewording that's objectionable or unclear?

Not at all — we'll take a closer look at it, and thank you. Just wanted to clarify that our intention was not any sort of sneaky forcing! 😁

@kaithar

kaithar Jul 25, 2017

@gs-rezaem @nsqe I mean it in a good way, in that it is written in a way that covers situations that aren't immediately obvious without having to explicitly list or state them.

As written, a specific agreement always takes precedence over the generic licence without completely removing it. That means that when there is a explicit licencing agreement, such as in a CLA or contribution rules, but someone HASN'T explicitly agreed to it, there's no period in which their contributions aren't covered by the licence.

I'll admit that I can't think exactly when this might be useful in terms of PRs, but it's a good thing to have just in case, especially if the standing licence is something with a fairly permissive grant.
What it does mean is that there aren't cases where there are contributions in issue and PRs, even just in terms of actual issue text, that aren't actually under an open source licence at all, everything added to the project in any way is automatically covered without the project owners having to do anything beyond specifying a licence.

Does it make it sound more useful in that framing? :)

philburk commented on 9cc7aed Jul 16, 2017 edited

Could add "employees" on line 170.
If GitHub employees access

Also change "we will only" to "they will only".

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

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.

@bluemazzoo bluemazzoo Update conference website
Update conference website to GitHub Universe
388f344

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

@wking wking 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).
6a06a80

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

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

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

@wking wking 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).
2f530a6
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.
@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 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.

well done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can't perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Morty Proxy This is a proxified and sanitized view of the page, visit original site.