GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
| -### 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. |
Would like nicer if there was a newline here + it seems to be the format.
The sames goes for 1 through 4.
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. |
security reasons is perfectly valid in the short version, but perhaps a more expanded on description should be provided here?
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?
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.)
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)
Will GitHub notify us of Subpoena and provide an account holder with an opportunity to move to quash?
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.
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.
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.
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 | ||
| + |
| -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. |
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.
...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 Chapter 3 defines "Your Content" in a specific way, that's why it is capitalized.
'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.
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. |
, 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.
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?)
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.
, and only the contents of private repositories,
@Benjamin-Dobell Really good point regarding
(We'll respond to other comments shortly, but this one was pretty important, so I wanted to give you a quick response.)
Are Secret Gists treated like Private Repos from a confidentiality perspective?
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.
@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
ditto the issue of confidentially around issues/PRs etc - clarification here would be nice
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. |
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?
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 stop posting that comment everywhere, it's not relevant to the discussion of the policies
@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.* |
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. |
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 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 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. |
It would be cool if you guys put a cryptographic hash in the blockchain everytime this document is changed too. Maybe by using KeybaseFS?
Hm. Git is a big bunch of cryptographic hashes? Do you really need more papertrail? A GPG signature would be nice, though.
@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?
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.
I'm with wking on this one, it's not about easier to read but about clarifying for both parties what the definition is, and if there's one provided why not use it?
|
Ok |
| #### 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. |
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):
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 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.
"sneakily clever" and "legal document" are not a good mix
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 @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?
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?
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!
@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? :)
9cc7aed
|
Could add "employees" on line 170. Also change "we will only" to "they will only". |
|
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. |
|
|
wking |
6a06a80
|
|
|
wking |
fc61b7d
|
|
|
wking |
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. |
The “Your Content” definition seems ambiguous. For example, if Alice creates some content and Bob uploads it Carol's GitHub repository, then is it Your Content for Alice (who created the content) and Carol (who owns the GitHub representation)? Alice doesn't seem to have any connection that GitHub is aware of, and Bob should be involved somehow.
I expect the goal is to have it be Your Content only for Carol (who owns the repo where it landed) and Bob (only as long as Bob has write access to that repository). Similarly, if Dan opens an issue in Carol's repository, that would be Your Content for Dan and Carol (both of whom can use the web UI to edit the issue post). Ideally, Carol (who was not involved in either transaction short of granting Bob write access) wouldn't have to assert anything about either content. But the right to post is covered in §D.3, so if Bob and Dan have done their due diligence, Carol doesn't have anything to worry about.
I've taken a stab at clarifying this in #54 (filed against this branch), and can separate the change from the rest of #54 if you like.
It's in our Privacy Statement:
|
|
https://goo.gl/8xx1jgmamatcyber
Pada 22/07/2017 10:13 PG, "W. Trevor King" <notifications@github.com>
menulis:
…
|
|
well done |
bluemazzoo commentedJun 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.