github / site-policy

Collaborative development on GitHub's site policies, procedures, and guidelines

Site Policy on GitHub

The universe of policies and procedures that govern the use of GitHub, open-sourced for your use and inspiration. We created this repository as a place for people to fork, contribute to, and provide feedback on our policies. While this is our official repo of open-sourced policies, it may not reflect the exact policies that are live on GitHub because this site is updated separately from the Help site.

What can I do here?

First, you can use and adapt our policies!

We are proud to offer the policies in this repository under CC0-1.0. That means that if any of them are useful to you, even in part, you're welcome to use them, without restriction. Of course, keep in mind that we wrote these policies as they apply to GitHub, so you'll need to make sure the content applies to what you're using it for, and adapt it as appropriate. See the license section for use guidelines.

Because we are providing these policies to our community, we believe it is only responsible to also provide the history and insight that a repository of commits, pull requests, and issues can offer. Over time, the repository's commits, pull requests, and issues will allow anyone wanting to use our policies to see the discussions and alterations that have gone into them.

Second, you can contribute to making our policies even better.

We host collaborative development on GitHub's site policies, procedures, and guidelines here. That means you’re welcome to provide feedback via a pull request or by opening an issue. When opening an issue, please look over the Contribution Guidelines. This will help us respond to your concern more quickly.

That seems like great power! What about the great responsibility?

That's easy: just be responsible. Follow our Code of Conduct, and help us maintain a respectful environment for all contributors.

There are a few things you should not post in this repository:

• Please don't post legal complaints or ask for technical support. We may not respond to issues promptly. If you need help, contact Support and they'll get you an answer.
• Please avoid hypotheticals. We can't give you legal advice, which means we often can't tell you if a hypothetical situation would or wouldn't be a violation of our policies. We also can't tell you what you should or shouldn't do. We can tell you how we interpret our policies.
• Please don't give other users legal advice, to avoid confusion.

How often will GitHub review these policies?

We continually review and modify the policies in this repository. Our review and modification process allows for discussion about upcoming changes before they go into effect and lets our community rely on our policies. Of course, GitHub may alter our policies outside that schedule if necessary, such as when we have new product releases.

What's the process?

Policies will be open for discussion and feedback throughout the year. You can expect that someone from GitHub's legal department will see your feedback, but we might not respond immediately. If you need an immediate answer on a legal matter, contact Support.

When we open a pull request, in most cases, we'll leave it open for 24 hours before the changes go into effect. Comments on and review of our pull requests are welcome, just like in any open source project. For material changes to our Privacy Statement or Terms of Service (including our Acceptable Use Policies), we'll post the updates 30 days before they go into effect, as stated in those docs. (We had previously applied a 30-day comment period for most docs in this repo but found that we tend to get feedback soon after we post the changes and were unnecessarily delaying ships.)

For those who are following this repository, the posting of the updated policy will provide a notice of any modifications to the policy. Please note, links will not resolve in the rendering of the policies in this repository.

License

CC0-1.0. Note that CC0-1.0 does not grant any trademark permissions.

You're under no legal obligation to do so, but in the spirit of transparency and collaboration these policies are developed and shared with, you're encouraged to:

• Share your adapted policies under CC0-1.0 or other open terms
• Make your adaptations transparent by using a public repo to show changes you've made
• Let us know how you're using adapted policies

The official legal disclaimer part:

• The information in this repository is for informational purposes only and is not intended to convey or constitute legal advice. It is not intended as a solicitation, and your use of this information does not create an attorney-client relationship between you and GitHub. GitHub is not a law firm. (You know that, though, right?)
• These policies and procedures may not suit your organization's needs. Please consult a lawyer if you want to adopt these policies for your own uses.

site-policy's Issues

Email message uses wrong timezone

The e-mail says to submit comments by 5PM PST on July 28. July 28 falls within Pacific Daylight Time (PDT), not Pacific Standard Time (PST).

If you want to use a daylight savings agnostic abbreviation, you should use PT.

Also, you really should additionally list the UTC offset, e.g. 5PM PDT (UTC-7).

Clarify notification failure must be due to exigent circumstance, not merely rare

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-privacy-statement.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-privacy-statement.md#how-we-respond-to-compelled-disclosure

5. Why do you think this section or language needs improvement?

Replace "rare, exigent circumstances" with "exigent circumstances (such circumstances are rare)". This clarifies that the circumstance must not merely be rare, but also exigent. The previous wording is somewhat ambiguous as to whether the list is "and" or "or" and this change corrects that.

Link to github security article is broken.

The link "all reasonable and appropriate security measures" on "https://github.com/github/site-policy/blob/master/Policies/global-privacy-practices.md" is broken. Results in error 404.

Security
We will protect your personal information with all reasonable and appropriate security measures.

Comment Period Closed - Thanks for your contributions!

Thanks again for all your contributions during this comment period! If we haven’t responded to your issue, comment, or pull request, you can expect a response in the next week, as we make our final edits.

As we mentioned in the blog post, the terms will be effective on Monday, August 7, and will be published at the following site: https://help.github.com/categories/site-policy/. As of now, all comments to be reviewed during this comment period should have a “2017 - Summer” label attached to them. All comments, issues, and pull requests submitted after today will be reviewed as part of the next comment period.

Clarify that procedure for private repositories also applies to Student Developer Pack accounts

In Section D.8 Private Repositories of the GitHub Terms of Service it says:

Paid accounts may have private repositories, which allow the User to control access to Content. GitHub employees only access private repositories when access is required for security or maintenance or for support reasons, and then only with the consent of the repository owner.

This paragraph defines when GitHub staff may access private repositories of paid accounts under certain conditions.
However, there are also non-paid accounts that can have private repositories, namely those given to students under the Student Developer Pack. It should be clarified that the protections also apply to those accounts.

Handle the situations of user death or disablement

I believe that it would be useful to cater for the case of death or incapacity of a GitHub user in the GitHub Terms of Service Cancellation and Termination section
In essence it should be possible for an executor or carer operating under a valid power of attorney to notify GitHub of the death or incapacity of a user. This should result in the account profile being updated accordingly, preventing further activity by that account and ceasing email notifications, eg from watched repositories, etc.
Watchers of the affected user's respositories should be notified of this event, and perhaps be able to post their condolences to the user's profile.
GitHub should probably reserve the right to remove any repositories after an appropriate period, which would allow interested users to fork any repository they wish to continue developing.
Having just updated my will - as a matter of course, not for any health reason - I have started looking at the issue of digital estates.
This Wikipedia page may also be of interest.
Hope this helps.
Blessings,
Ian Hogan.

I have no idea what your email is about. Who is GitHub?

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

3. Did you already open a pull request? If so, please include a link to the PR.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

TOS Edit PR

A few changes, can be seen with my notes in the PR (link provided below)

#16

Thanks

Jdc20181

Do not explicitly write the browsers which are supported, but just enumerate the browser features required

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/supported-browsers.md

5. Why do you think this section or language needs improvement?

Because there are tons of browsers and in the ideal world any webpage using certain standardized features must work in any browser complying with the standards. So I think you should just specify the features needed by this website in order to work. I insist on multitier-support.

Tier 0 is the minimal set of features needed to have this website fully functional. I mean that users should be able to login, clone, make commits through web interface, discuiss issues, adjust settings, download zips, watch network graph (server-rendered into svg or even png+<map>, it is even possible to make it interactive with help of CSS), etc but may encounter not the best UX: some characters (emoji) may look like squares or non-githubish (using the fonts available), svg may not be displayed, pdf or 3d models may not be rendered, text recovery may not work, but all the critical features must work.
I insist on non-inclusion of fonts, svg and the most importantly JavaScript into the feature set of this tier. I mean that the website should work in TorBrowser when the security slider is set to maximum security and there are no whitelisted sites in NoScript addon settings.

Tier N is the set of features for the best UX.

TOS Typo

Corporate TOS issue: “If you're posting anything you or your Users did not create yourselves and on your behalf, you agrees that…” Fix typo.

OSS licences vs. ToS: grants of rights

EDITED to reflect the remaining issues for the July 2017 upgrade. Original PR at bottom.

The ToS §D.4f. in the July 2017 update still include an unconditional licence grant on content uploaded which the user may not be able to fulfil, as virtually all licences require certain terms to be enforced for any kind of redistribution (same licence for copyleft licences, retaining some words of the licence usually for Ⓕ copyfree licences).

The offending sections must be modified to apply only to repositories in which not every file is already available under a licence granting GitHub and its users “enough” rights to do what’s described. For practicality reasons, all Open Source / Open Knowledge / FSF-free / DFSG-free / Copyfree licences are, after reading their definitions, considered “enough”, and any other licences are outside the scope of this problem report.

---

The original PR before the edit follows:

---

Even after #1 there are still some remaining issues. This one is about §D.3ff. (grants of rights).

---

§D.3 says “If you upload Content that already comes with a license granting GitHub the permissions we need to run our Service, no additional license is required.”

Please clarify here explicitly that any of the usual OSS licences are sufficient to fulfil this ToS requirement, including honouring their termination clauses and all.

I grant you that you may include the text body of that list of free licence lists in your ToS or elsewhere. I collected this list myself. For review, it should be sufficient to review the inclusion criteria (e.g. the OSD (Open Source Definition) for the OSI list, etc.) because, as far as I can tell, any licence that fulfils the criteria to be listed in one of those lists is required to grant enough rights for GitHub and its users to do the necessary things.

Do note that I included non-code licence lists; this is often necessary for documentation, audiovisual works, etc. (such as game data, etc). My intent here is to “defang” ToS §D.3–D.5 if the entirety of the repository is available under (a combination of) Free/OSS licences, because these grant both GitHub and every GitHub user enough rights already to, in practice, do what you request.

---

§D.4 says “share it with other users”

Please make it explicitly clear that, if such an OSS licence (see above) applies to the work, any users will still have to comply with the licence on the work (including all of its restrictions).

This should not be a problem because those licences and the law already have provisions for service providers that include hosting, backing up the work, and transit, as long as the recipient, when sharing, is bound to the licences’ terms.

---

§D.4 says “This license does not grant GitHub the right”…

Please make it clear that the OSS licences (as above) supersede this anyway.

---

§D.5 says “you grant each User of GitHub a […] license […]”

Please make it explicitly clear here that, if any such OSS licence as above applies to the work, this additional grant is not necessary, and that this clause does not “defang” the conditions the OSS licences put on dealings in the works licenced under them.

This is also not a problem for either you or your users because the licences and, again, the usual laws, permit users rights to do some things locally with the works, and virtually all of the conditions those licences have only trigger when users further share the work.

Please make it also clear that “Content you upload is licensed under terms that grant these permissions” is also sufficiently fulfilled if such content is available under the OSS licences mentioned.

---

This is a follow-up on a part of the new ToS draft, partly from my prior review which I assume you know, but, if not, suggest to read. The list of free licences on my website is new, created after that article.

Remove license grant or clarify that free software licenses take precedence

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#4-license-grant-to-us

5. Why do you think this section or language needs improvement?

While I see that similar issues have been discussed at length in #7, #52, and #54, I'd like to offer a slightly different approach that may be simpler. Instead of editing or replacing the existing wording, we could instead add the following clause to the end of this section:

"If the Content's license is a license approved by the Open Source Initiative, then the Content's license will govern GitHub's (and its legal successors', assignees', and delegates') reproduction, display, modification, distribution, and performance of the Content and the above license will not apply."

Note that the list of extra entities included above is required due to https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#2-non-assignability , which mentions that "GitHub may assign or delegate these Terms of Service".

If a more complex change is desired, I generally approve of the approach of #52, though I think using the OSI list of licenses is sufficient (as opposed to using the nearly-exhaustive list of lists in #52), especially since GitHub self-identifies as "The largest open source community in the world" (see https://github.com/open-source ) and so GitHub should be fine with agreeing to the terms of licenses that the Open Source Initiative approves.

There are a number of problems with leaving this section as-is (without a change like #52 or that described above), not least of which is that, under some readings, GitHub could, for example, use an AGPL-licensed project to provide some of its Service without making the source code available to its users, even if GitHub modified the project. This holds true in spite of the last sentence of the current section ("This license does not grant GitHub the right to sell your Content or otherwise distribute it outside of our Service") since that says nothing about GitHub using the Content internally in violation of its stated license (as the rest of the section appears to grant GitHub rights beyond those of the Content's stated license).

If GitHub does not want to make the above change (or a similar one clarifying that open source licenses take precedence), I would appreciate if a GitHub employee could comment on this ticket to indicate which permissions GitHub needs in order to operate its Service that are not already granted by all of the OSI-approved licenses.

An alternative would be for GitHub to remove the "License Grant to Us" section completely, and rely on the usual caching and similar "common carrier"-related laws that most web companies rely on already. This would be even better than having to add more text (since then the existing license for Content would implicitly apply, without needing to say it in the Agreement), and would satisfy GitHub's desire "to keep it short and easy to read" as expressed in #7 (comment) (as the Agreement would be even shorter).

Add Icons to the Terms of Service

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

Entire document.

5. Why do you think this section or language needs improvement?

Many other websites are adding icons to their legal documents to make them easier to understand. One particular organization that does a great job of this is Creative Commons. Using icons would help users that skim the document be able to gain an understanding from a glance at these symbols, so even if they did not read the text, they would still get the gist of the terms. This would be mutually beneficial for GitHub and for users because of the increased likelihood of users understanding the document's contents.

DMCA section needs a option for third-parties to submit copyright reports.

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

Yes.
https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#e-copyright-infringement-and-dmca-policy

3. Did you already open a pull request? If so, please include a link to the PR.

No.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

Yes.

5. Why do you think this section or language needs improvement?

For three reasons, I think this needs an improvement to allow for third parties to submit copyright flags.

First, theres a legal requirement in sweden, for someone that hosts user-generated content without pre-moderation, to take down any copyright infringing content when ANYONE reports, not just the copyright owner.
The law is "Lag (1998:112) om ansvar för elektroniska anslagstavlor" (Law (1998:112) about responsibility for electronic bulletin boards)
Even if the title of the law might be misleading, it does not only apply to forums, but ANY site where a third-party can post content without pre-moderation by a moderator or admin.

And here is an excerpt from that law, stating its requirement to delete or disable access to any illegal content, anytime the site administrator gets notice of that:

"5 § Om en användare sänder in ett meddelande till en elektronisk anslagstavla ska den som tillhandahåller tjänsten ta bort meddelandet från tjänsten eller på annat sätt förhindra vidare spridning av meddelandet, om
...
2. det är uppenbart att användaren har gjort intrång i upphovsrätt eller i rättighet som skyddas genom föreskrift i 5 kap. lagen (1960:729) om upphovsrätt till litterära och konstnärliga verk genom att sända in meddelandet. "

Translation:
"5 § If a user submits a message to a electronic bulletin board, the entity who provides the service should delete the message from the service, or in other way prevent further distribution of the message, if
...
2. Its obvious that the user has infringed on copyright or any other right protected by 5chap law (1960:729) about copyright to litterate and art works, by sending in the message."

Two: Because DMCA does not prohibit taking down material that is infringing on copyright even if a third-party submits the DMCA notice. The only thing is that GitHub isn't required to take down (according to USA law) but they can do so if they choose so.
https://law.stackexchange.com/questions/14084/is-it-prohibited-to-accept-dmca-takedown-notices-from-non-authorized-individuals

Three:
The terms of service does have a section, C-2, "Content Restrictions", that specifically say:
"infringes on any proprietary right of any party, including patent, trademark, trade secret, copyright, right of publicity, or other rights."

which means, content can be taken down either by DMCA, or C-2.

Thus, I suggest section E, to be updated to:

E. Copyright Infringement and DMCA Policy

If you believe that content on our website violates your copyright, please contact us in accordance with our Digital Millennium Copyright Act Policy. If you are a copyright owner and you believe that content on GitHub violates your rights, please contact us via our convenient DMCA form or by emailing [email protected]. There may be legal consequences for sending a false or frivolous takedown notice. Before sending a takedown request, you must consider legal uses such as fair use and licensed uses.

If you believe that content on our website violates a third party's copyright, please contact us in accordance with our Terms of Service, Content Restrictions Policy. If you are a third party who witnesses that content on GitHub violates a third party's right, please contact us by emailing [email protected]. Please write "C-2 takedown request" in the subject line.
Please note that a C-2 takedown request isn't legally binding, will be judged by GitHub admins and/or moderators, and may be rejected. Only submit a C-2 takedown request if you are completely sure that the copyright owner does not allow that specific content there.
If a GitHub Admin or Moderator approves a C-2 takedown request on your repository, you must send proof of copyright to have the content reinstated. Proof of copyright can be for example written agreements from a copyright owner about permission to use material, a license document, or any other documents that proves you have right to use the material, or proof that you created the material. You can also have the copyright owner to contact us. They will have to prove their position as a copyright owner, and then they can ask to have your material reinstated. We will in the case copyright owner asks us to have material reinstated, also block further C-2 takedowns on that particular repository. (DMCA takedowns will still be valid).

A copyright owner or a entity authorized to act on behalf of the copyright owner, can choose if they want to send a DMCA notice or a C-2 notice. If a C-2 notice is chosen, the content will be judged by GitHub, and material taken down if the C-2 notice is approved. C-2 notices protects you from counter-notices. If a C-2 notice is rejected and you are the copyright owner or a entity authorized to act on behalf of the copyright owner, you can escalate it to a DMCA notice.

We will terminate the accounts of repeat infringers of this policy, regardless of if the takedown notice was a DMCA one or a approved C-2 one.

Also a moral thing to consider:

I can report to the admins that a repostiory contains for example pornography, drug trafficing, promotes illegal activites or other illegal/prohibited content, and have the content taken down.

I can also, if I see someone shoplifting in a store, call the police and also file a formal police report. I don't need to ask the store owner for permission.

Why is it so hard to report copyrighted content to be taken down unless Im the copyright owner?

Section G "API Terms", subsection 3 "GitHub May Terminate Your Use of the API".

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

Section G "API Terms", subsection 3 "GitHub May Terminate Your Use of the API".

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

Section G "API Terms", subsection 3 "GitHub May Terminate Your Use of the API".

3. Did you already open a pull request? If so, please include a link to the PR.

N/A

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

Would it be possible to have revocation of access to APIs occur only upon violation of the Terms of Service or other malicious activity rather than without cause? Further, would it be possible to have fifteen days' notice be provided for revocation of access?

Apply 13+ age limit to account holders, not anonymous visitors

1. What's the name of the policy?

GitHub Terms of Service

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

§A (Definitions).

3. Did you already open a pull request? If so, please include a link to the PR.

No.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

I'd like to see the current:

A User must be at least 13 years of age.

changed to:

A User must be at least 13 years of age to hold an account.

5. Why do you think this section or language needs improvement?

The current terms define “User” in part as:

…the individual person… that has visited or is using the Website or Service; …; or …

So you may be a User even if you don't have a GitHub account. While most of these terms may not apply to these anonymous users, they are the recipient of other grants (e.g. they are granted the right to view public repositories, see #57). And they are still subject to overuse restrictions and such.

The 13+ age limit is intended to avoid COPPA requirements by forbidding minors from opening GitHub accounts (see here and here). I'm not familiar with COPPA, so it's possible that collecting IP address in HTTP logs or using cookies with anonymous users is enough interaction to trigger COPPA conditions. In that case, you'd want to keep the current language (blocking minors from accessing GitHub entirely). But if anonymous GitHub access is sufficiently anonymous for COPPA, then the ToS should allow anonymous minors to browse the Website and Service, and only forbid them from opening accounts.

Translation request

Is there any chance to have these important documents translated into Spanish?
Regards.

The term "fork" is not defined anywhere in the GitHub Terms of Service

There are several interpretations for what does the term Fork means, and the Terms of Service does not define of the them. Which is basically ask for trouble for the GitHub users which use the fork button on non-open source projects. As many of them comply to the Berne Convention on the absence of a explicit license.

Moreover following on the Open Source Stack Exchange questions:

1. What does the 'right to fork' mean?
2. How does GitHub's “forking right” cope with an “All rights reserved” project?

There are at least two understandings about what does a fork mean. They are respectively:

1. [quoting: Gilles] The right to fork refers to forking as in taking a software project and maintaining it separately from the original. Having the right to fork a work means having the right to modify your own copy. In the context of freely distributable works, the right to fork means having the right to redistribute modified copies.

2. [quoting: apsillers] The term "fork" is not defined anywhere in the GitHub Terms of Service, but it seems perfectly sensible to assume that "fork" here is meant in the sense that it is used elsewhere on github.com: the Fork button.
   
   
   
   GitHub probably intends "the right to fork" to mean "the right to use the Fork feature of the github.com website." In this case, "creating a fork" would not mean generally creating a copy or derivative work (as it does in general FLOSS parlance), but rather it means triggering the software of github.com to create and host a verbatim copy of a repository and categorize that copy under the user's list of forks.
   

1. [quoting: Gilles] The practical importance of the right to fork is that is you don't like the way the original author maintains the work (not fixing the bugs that bother you, not adding the features you wany, etc.) then you can do what you like with your own copy. Having the source (i.e. the prefered form of modification) is critical there, since it is the only practical way to fork a work. A right to fork without having the practical means to make use of it, i.e. having the source, would not be very useful.
   
   The combination of being allowed to and able to modify the source and the right to redistribute allows anyone who's interested to take up maintenance. This is a guarantee that free software and other open source works won't die as long as someone somewhere, anywhere, is willing and able to take up maintenance. It's also a guarantee that if someone dislikes the way the project is maintained, they can make their own version if they're willing and able to invest the requisite effort or get someone to do it.

2. [quoting: apsillers] If the original copyright owner doesn't license any other permissions, clicking that button is all that the TOS-required permission allows the user to do. This doesn't grant any rights to create a derivative work, or to redistribute the code outside of github.com, since the "Fork" feature is intrinsic to the github.com website.
   
   Speculation: this right-to-fork language in the GitHub TOS was probably included to prevent legal issues around the use of the Fork feature. The intent was likely something to the effect of, "You must license the minimum amount of rights to allow github.com's Fork software feature to operate."
   
   Based on this reading of "fork," if another user were to use a github.com-hosted forked-repository to prepare and distribute a derivative work, that would infringe on the owner's copyright, since such an action is outside the scope of the Fork software feature. Similarly, if the user were to create a verbatim copy outside the context of github.com's Fork functionality (e.g. copying the code to another website), that would also not be permitted. The TOS does not allow the right to create copies generally; it only requires the author to grant copying permission inasmuch as copying is a necessary component of the Fork feature.

Currently the situation is open to a tribunal court do determine what rights the GitHub Fork button actually gives. As currently it is, it only implies the right to use the Fork button feature present on the site. Hence, a public GitHub repository complying with Berne Convention only, is very dangerous for GitHub users which fork it, and push commits/pull requests to their fork. As they are in great danger/liability of the prosecuted by the original repository owner, if they perform commits and pull requests due Berne Convention applied.

It follow because the repository is not giving any rights to anyone else, other then create a copy using the GitHub Fork button. Such feature is seems very useless, as if I want to fork a GitHub repository, is to apply bug fixes and new features not presented on the original repository. Or because I do not like the way the original author maintains the work, i.e., not fixing the bugs that bother you, not adding the features you want to, etc.

Therefore as we can mostly see, thousands of GitHub repositories out there are complaining with the Berne Convention. I would suggest to apply to the Fork button feature, the ability/right to allow the forked repositories to receive push commits from their forkers and perform pull requests to the original repository.

In any case, if someone is putting their code on a GitHub public repository, but has no intention to allow others to fork their project and push commits/pull requests, they should:

1. Not put their code on a GitHub public repository. They should consider not put it on the internet or putting it on a GitHub private repository.
2. Explicitly apply a license to their project forbidden it, which should also disable the GitHub Fork button, and clearly alert/inform the GitHub user that this repository very dangerous as its contents are not allowed to be forked and consequently changed by git commits.

---

https://en.wikipedia.org/wiki/License_compatibility

Related issues and threads:

1. #7 OSS licences vs. ToS: grants of rights
2. SublimeText/LaTeXTools#1175 Can it be an open source project?
3. Fork (software development)
4. Is it possible to get rich prosecuting GitHub users from a non-lincesed fork?

Minors should be able to use with parental consent

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

GitHub Terms of Service - indirectly affects all policies by broadening who can use

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#b-account-terms
Paragraph beginning in "You must be age 13 or older."

3. Did you already open a pull request? If so, please include a link to the PR.

#43

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

See above.

5. Why do you think this section or language needs improvement?

Children under 13 have coding ability, too. They currently cannot use GitHub at all. If accepted, children under 13 will be able to join with a parent's consent (software changes are needed to implement this policy in order to prevent registering fake parent accounts)

Request for mutuality

Corporate TOS issue: Section R4, “Any failure on the part of GitHub to enforce any provision of this Agreement will not be considered a waiver of our right to enforce such provision. Our rights under this Agreement will survive any termination of this Agreement.”

Please consider making both of these clauses mutual out of fairness.

nonsence

Not written in understandable English, and basically meaningless, where is the contract with a signature by both parties?
imposing even by consultation terms is onerous and entirely without merit or morals...

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

3. Did you already open a pull request? If so, please include a link to the PR.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

Content Screening Logic

Corporate TOS issue: “We do not pre-screen User-Generated Content, but we have the right (though not the obligation) to refuse or remove any User-Generated Content that, in our sole discretion, violates any GitHub terms or policies.” Logically, how do you “refuse” content you’re not pre-screening before it goes live?

CONTRIBUTING License Note

From current CONTRIBUTING.md:

Contributions to this project are dedicated to the public domain under the Creative Commons 0 terms and the final policies are licensed by GitHub under the Creative Commons Attribution 4.0 license.

Does this apply to folks like me, foisting CC0 on anything I send? The thought gives me an uncomfortable feeling. I think there are a couple reasons. Hopefully I can express them.

It's not inbound=outbound. Even looking past CC0's dedication, to the fallback license, the terms differ.

Having it in CONTRIBUTING feels like a gotcha, and therefore a bit like a grab. Like finding the King's Shilling in your hand, so to speak.

I'm not sure it works under the current terms of service, in any event. Is that language in CONTRIBUTING a "separate agreement to license your contributions under different terms, such as a contributor license agreement"? Thinking like a lawyer, there's no signature or signature-substitute indicating agreement between GitHub and I for my contributions to the repo. Thinking like a coder, "contributor license agreement" means something like the Apache or old Eclipse forms. Not terms of service, or invoked on "hook" from terms of service.

It's a bit more work, but I'd actually prefer a note in CONTRIBUTING that the team can only take language verbatim under CC0-1.0, with a request to confirm dedication in PRs. That's a chore, but it would probably flip the feeling from "If I do things on that repo, GitHub takes under the license it wants." to "I'm being me by giving under CC0, because that's an excellent thing to do.".

Avoid use of "proprietary" when speaking of rights infringements

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#2-content-restrictions

5. Why do you think this section or language needs improvement?

It is not immediately clear what the term "proprietary right" means, since "proprietary" is often used as a way for companies to describe rights that they think they have (but might not be supported by actual written or case law). As a result, the last bullet point could be construed to mean that the user should never infringe on any right that a company or other user thinks they have (such as an action clearly allowed by fair use, but that the company or other user doesn't want you to engage in).

So instead of "proprietary right", it should say "valid legal right" or similar instead. This will hopefully clear up the confusion.

Add "Print" and "Download" buttons to the Terms of Service document

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

Top of document (before table of contents)

5. Why do you think this section or language needs improvement?

It would be helpful for users to have simple buttons to click to allow them to print or download the document in a format prepared for printing (rather than having to print or download the page using the standard browser features).

Present the Terms of Service in a scrollable window for users when creating an account

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

Related to the account creation process, not the contents of the document.

5. Why do you think this section or language needs improvement?

Currently, during the account creation process users do not actually have to acknowledge that there is a Terms of Service and they agree by clicking a button or checkbox (there is just text that says by clicking sign up you agree). It would be beneficial for legal purposes for GitHub to make this change and make users confirm their agreement, but it would also give a better opportunity for users to look at the Terms of Service. Rather than having to find the page, it would be put in front of them automatically, increasing their likelihood of reading the terms.

Public domain vs identifying as human

There is a problem with requiring people to identify as human in order to access a public service. The problem is that the human condition implies the endorsement of human rights, and human rights are incompatible with the natural rights of the public at common law. This problem has implications for people who live in common law countries.

A solution to this problem would be to make the distinction between natural and artificial use, i.e. people vs scripts, or artificial intelligence systems.

We are now going to creating one project plz give me description about github use

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

3. Did you already open a pull request? If so, please include a link to the PR.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

Welcome, and early access

Welcome to the Site Policy repository!

Early access

If you're reading this in the week before June 21, you're one of our Site Policy testers. Thanks for sending us feedback on our Terms of Service back in February — we really appreciate it. Please poke around, take a look at our open pull requests, and let us know what you think. We've tried to take our users' feedback to heart, both in creating this repository and in updating our Terms.

We look forward to your feedback on the Site Policy process. We might make a few tweaks to that before the public launch on June 21, based on your feedback. However, we won't make any changes to the Terms of Service update until the rest of our community has had a chance to weigh in. We want that dialogue to be open.

Open access

If you're reading this as part of our June 21 launch, welcome! As above, please take a look at our open pull requests. We really look forward to your feedback, both on the pull requests we currently have open and on any suggestions you have to our other policies.

Postponing the Site-Policy Repo Publication Date

👋 Hi All,

Unfortunately, we need to postpone the public launch of this repo for a week or so. We were making a final tweak or two to one of the new sections, and decided we need a little more time to get it right. We'll let you know as soon as we finalize the publication date. Thanks in advance for your understanding!

Cheers,

Bluemazzoo

Links are broken

1. What's the name of the policy?

amendment-to-github-terms-of-service-applicable-to-u-s-federal-government-users.md

2. Reason:

All links in this document are broken

README wording suggestion

In the README, under the few things that should not be posted in the repo, it says this:

Please don't give other users legal advice, to avoid confusion.

I suggest rewording that to be:

To avoid confusion, please don't give other users legal advice.

It could easily be read to mean that giving others legal advice to avoid confusion is not a good idea. Technically, this is true, but it's not what you mean and the above wording is unambiguous.

Clarify Code of Conduct enforcement section

1. What's the name of the policy?

code_of_conduct.md->Contributor Covenant Code of Conduct->Enforcement

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/CODE_OF_CONDUCT.md#enforcement

3. Did you already open a pull request? If so, please include a link to the PR.

No; issue is too wide in scope for a pull request.

4. [skipped]

5. Why do you think this section or language needs improvement?

Reporting unacceptable behaviour is a critical user journey and should be made as easy as possible. Providing an email address (i.e. providing no integration with any of GitHub's interfaces) undermines the importance of this item.

• This enforcement section should have a link to an open issue against the GitHub interfaces to improve the user experience of people reporting unacceptable behaviour beyond "Email us (template not provided), and someone should read it and may choose to do something.". Since each project maintainer is expected to manage their own code of conduct a way of reporting harassing actions to each project maintainer seems key. Please add such a link to such a (placeholder) issue.

• This enforcement section states that "Further details of specific enforcement policies may be posted separately." but does not state where they might be stated. This undermines the authoritative nature of this documentation. Please provide where those further details should be stated, or state that those details, or a link to those details, will be added to this document at a later time.

Scraping policy

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#5-scraping

5. Why do you think this section or language needs improvement?

5. Scraping
   Scraping refers to extracting data from our Website via an automated process, such as a bot or webcrawler. You may scrape the website for the following reasons:

Researchers may scrape public, non-personal information from GitHub for research purposes, only if any publications resulting from that research are open access.

1 You will never know if you will have the results to publish.
2 Is publishing a preprint on arxiv.org considered as "open access" even though the peer-reviewed version of the work is behind a paywall?

Archivists may scrape GitHub for public data for archival purposes.

I don't see that search engines are allowed to scrape. It looks like that search engines are not allowed to scrape.

I have already discussed that with the support, but it's time to discuss it publicly, my suggestions are:
1 Create a webpage and API using which anyone can download a rather actual subset of the data in interest in a machine-readable (not HTML, but in a form either of database dump or a custom binary format, if it suits better, please don't use just a bunch of archived JSON/XML, it would take additional effort to put it into a DB) and compressed format. This is needed to reduce load to both GH servers and people's internet connections.
2 to give permission to anyone to scrape public data for any purpose, but reserve the right to give incorrect results.

q: Why not to disallow scraping for spamming and other evil purposes?
a: Because they will just ignore the ToS.

q: But won't disallowing this in ToS allow GH to prosecute the ones doing that?
a: They may be under non-cooperative juristiction. They also may be fully automated (not targeted to GH specifically) and too dumb to understand the ToS. Also IMHO prosecution for scraping is unacceptable. I know that it's only my opinion and GH policymakers may think it is acceptable, but it's GH service, do what you need/want to do, I just have expressed my opinion on the subject.

q: But how can GH stop abusers?
a: It cannot. They can mimic a web browser pretty well and can use a distributed network of infected co puters to avoid detectikn..

q: How about rate-limiting?
a: Write it into robots.txt as a recommendation and enforce as a part of anti-DoS measures.

q: But what if GH is going to make money on selling this data? Won;t allowi g scraping harm the profits?
a: Just do what you need/want. The recommendations above are made assumming that GH is not trying to make money selling the data.

For clarity and technical correctness, replace "pixel tag" with "tracking pixel"

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-privacy-statement.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-privacy-statement.md#how-we-communicate-with-you

5. Why do you think this section or language needs improvement?

The term "pixel tag" does not convey what the pixel does. The term also does not properly describe to a technical person what it is. Normally when one says "X tag", they mean "<X>", but there is no <pixel> in standard HTML so "pixel tag" is confusing.

Thus the privacy statement should use "tracking pixel" instead of "pixel tag" in the four places it is mentioned (3 in the section linked above and 1 in https://github.com/github/site-policy/blob/master/Policies/github-privacy-statement.md#tracking ).

With the above change, the "pixel tag" paragraph at least makes a bit more sense. I'm still not a fan of its middle sentence ("We use this pixel tag [/tracking pixel] to make our email more effective for you and to make sure we’re not sending you unwanted email") since I don't understand how that makes email more effective or determines whether I want the email (as my email client never loads such pixels so I don't know how GitHub could determine whether I want an email based on tracking pixels). But at least with my suggested change the reader knows that the pixel is used for tracking purposes (and so I don't think fixing that sentence would be as critical after my change).

Logical fallacy ToS clause addition

1. What's the name of the policy?

Github ToS

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

N/A

3. Did you already open a pull request? If so, please include a link to the PR.

No

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

I would like to add a clause to the Github ToS that makes the use of logical fallacies in thread (discussions, issues, PRs, et al) a breach of the ToS, including (but not exclusively limited to) the list of logical fallacies found at https://en.wikipedia.org/wiki/List_of_fallacies.

5. Why do you think this section or language needs improvement?

It is not uncommon for developers and contributors to deteriorate a discussion into using irrational arguments to justify their positions with regards to bugs, feature request, improvements, and suchforth.
Debates and positions taken on either side should be subject to their own merits, standalone, and use of a logical fallacy to attempt to invalidate an opposing party's position should subsequently invalidate the position of the party that used the fallacy.

Our job as programmers is to translate human requirements into logic trees that a computer can understand, to better facilitate the use of the software between humans. If we cannot agree to block out logical fallacies, then our software projects are more likely to fail, due to human reasons rather than technical merit.

Car gurus

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

3. Did you already open a pull request? If so, please include a link to the PR.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

More permissive license grant to other users

Section 5 (License Grant to Other Users) of GitHub's ToS currently grants "each User of GitHub a nonexclusive, worldwide license to access [anyone else's] Content through the GitHub Service, and to use, display and perform [anyone else's] Content, and to reproduce [anyone else's] Content solely on GitHub as permitted through GitHub's functionality".

The problem I see with this is that it doesn't grant other users of GitHub a license to open pull requests as pull requests require modifications to be made in the fork. The rights mentioned in GitHub's ToS only allow use of GitHub's functionality when one only accesses content, uses, displays, performs, or reproduces it. It doesn't grant a right to modify other users' content.

As pull requests are an important part of GitHub's functionality, I think it's important that GitHub's users can be sure they won't be sued when opening a pull request to help improve a project without a license more permissive than the default license required by GitHub's ToS.

It seems unlikely that this would happen, but given a long enough timeline, anything with a non-zero probability will happen, and a single troll possibly suing themself could seriously harm both GitHub and the projects hosted on it, as some users would be too scared to open pull requests on repositories without a license more permissive than the default license or with a license they don't understand.

More privasi policy

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

3. Did you already open a pull request? If so, please include a link to the PR.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

OSS licences vs. ToS: moral rights

Even after #1 there are still some remaining issues. This one is about §D.7 (moral rights).

I fear I must state that the presence of this section still excludes all OSS licences requiring attribution if the work comes from a nōn-GitHub source who is also someone other than the person uploading it to GitHub.

Licences such as CC-BY, but also (at least 4-clause) BSD and (with a much wider impact) Apache 2 licence with a NOTICE file, require retaining attribution.

As I stated in February, I believe this is the “cheap way out” of something that can be solved with some very minor technical effort. Please let me elaborate:

You stated (in the pre-pull#1 ToS) that this is necessary for search functionality. Such functionality can either be done by others (crawling GitHub and presenting the results), in which case you’re not responsible as long as the changes from #7 are applied and those others are required to fulfil those licences themselves, or by GitHub.

I believe that it is customary to display search results with a link to the original in its context. I believe it would be enough to fulfil those licences’ attribution requirements if you put a notice on each search result page/snippet stating that these are excerpts for search, which are not in the Public Domain but are covered by copyright and neighbouring laws, and the terms under which those are available can be found if one follows the link to the original in its context.

In the USA, you may even get by with citing “fair use”.

---

One thing I noticed in the post-pull#1 wording is that it only applies to “Your Content”, which is defined as content that the person uploading it to GitHub creates or owns. Is this deliberate?

If yes, and this is made explicit (either by commenting here or by adjusting the wording), I believe this clause can stay as-is but will not help you as people can still upload content created by others under licences requiring attribution without those others needing to waive that assertion right. (Unfairness to those who do publish to GitHub aside, then.)

So, in the end, I believe it’s better if §D.7 is removed in its entirety and small technical measures to ensure it’s not necessary are invented.

I could also live with §D.7 being amended to make it trigger only for work not under one of the OSS licences I pointed out in #7

---

This is a follow-up on a part of the new ToS draft, partly from my prior review which I assume you know, but, if not, suggest to read. The list of free licences on my website is new, created after that article.

Enshrine existing always-email-updates policy into Terms of Service

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#q-changes-to-these-terms

5. Why do you think this section or language needs improvement?

As in the Privacy Statement, this section requires that users check the Website at least as often as every 30 days, otherwise they might not be aware of new terms that apply to them.

Similar to #71, I suggest that this section mention that GitHub will also (and always) additionally inform the user by email, at least for any "material changes". This seems to be the norm at GitHub already, so it should make no difference to GitHub to make it explicit, and means that users don't have to keep re-reading the entire Agreement every few weeks to ensure they haven't missed something. Currently this section says only that users will be notified "by posting a notice on our Website", even though the Agreement applies to the Service, which consists of far more than just the Website.

Add a tag for the release prior to 2017-08-07

Please add a tag for the release prior to 2017-08-07 so we can easily see the effective changes by running a diff on the tags.

Make it clear that GitHub uses its public policies to adjudicate UGC removal

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-terms-of-service.md#3-github-may-remove-content

5. Why do you think this section or language needs improvement?

This section states that GitHub may remove any User-Generated Content (UGC) that "violates any GitHub terms or policies" without stating or defining which terms or policies those might be. As a result, UGC could be removed for arbitrary reasons (to the user), since GitHub may claim the UGC violates some internal GitHub policy that the user doesn't know about.

As a result, "violates any GitHub terms or policies" should be changed to "violates the Agreement", since Agreement is an already-defined term that covers GitHub's publicly-available policies.

Enshrine existing always-email-updates policy into Privacy Statement

1. What's the name of the policy?

https://github.com/github/site-policy/blob/master/Policies/github-privacy-statement.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/master/Policies/github-privacy-statement.md#changes-to-our-privacy-statement

5. Why do you think this section or language needs improvement?

This section implies that the user may have to manually check the GitHub website at least as often as every 30 days in order to know whether the Privacy Statement has changed. Since historically GitHub always updates users by email (in addition to updating the website), make it easier for users to comply by simply stating what already happens in practice.

In particular, "posting a notice on our home page or sending email" should be changed to "posting a notice on our home page and sending email" - the only modification here is "or" -> "and".

With the above change, users will not have to check the GitHub website frequently to see if a change has been made - instead they can rely on receipt of an email to determine whether that has occurred.

Publicity

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

Corporate TOS draft

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/compare/github-corporate-tos-update-july-2017
Line 367

3. Did you already open a pull request? If so, please include a link to the PR.

N/A

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

In section 6 on Publicity. It's not clear that the right to use the company name for promotion continues or does not continue after the company name is no longer publicly displayed.

Section L "Cancellation and Termination" subsection 3 "GitHub May Terminate"

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

Terms of Service Section L "Cancellation and Termination" subsection 3 "GitHub May Terminate"

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

Terms of Service Section L "Cancellation and Termination" subsection 3 "GitHub May Terminate"

3. Did you already open a pull request? If so, please include a link to the PR.

N/A

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

Would it be possible to have termination only occur for cause with thirty days' notice versus for any reason without notice?

remove

Please read our README.md and CONTRIBUTING.md files before creating an issue. If you are creating an issue to provide feedback about our Closed Policies, please note that we may not incorporate your feedback into our policies due to laws that limit our flexibility around those issues. If your feedback is not related to any of the questions below, feel free to delete the template questions and enter your comments in free form.

1. What's the name of the policy?

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

3. Did you already open a pull request? If so, please include a link to the PR.

4. Sometimes it's easier to just put your feedback text into an issue. If that's how you'd prefer to contribute, this is the section to do that.

5. Why do you think this section or language needs improvement?

TOS enforceability comment

Corporate TOS issue: Section R4, “If any part of this Agreement is held invalid or unenforceable, that portion of the Agreement will be construed to reflect the parties’ original intent.” Consider if this works as a blue pencil clause—if the intent unenforceable, no other expression of that intent would be enforceable, so a court might reject wholesale the applicable part of the agreement. Consider if you would be better protected by saying “[the parties] [a court] will reform that portion of the agreement to reflect the parties’ original intent as nearly as possible.”

Do not require email in order to signup and use the service

1. What's the name of the policy?

https://github.com/github/site-policy/blob/github-tos-update-july-2017/Policies/github-terms-of-service.md

2. Is this issue related to a specific section within one of our policies (e.g. the Terms of Service)? If so, please include a link to the section or subsection.

https://github.com/github/site-policy/blob/github-tos-update-july-2017/Policies/github-terms-of-service.md#b-account-terms

5. Why do you think this section or language needs improvement?

First of all I wanna say that I had some discussion with the support on the topic.

In the ToS it is written:

You must provide a valid email address in order to complete the signup process.

E-mail system is too centralised nowadays. There are several free email services available to everyone usually on the terms which are far from acceptable for some people like me, for example many web services require its users to provide the service with a cellphone number and to prove the ownership of the account related to this number. Sometimes these web services can be required by the law to collect some information like cellphone numbers. Sometimes this services allow itself too much, for example scanning peoples emails content.

So I think it's time to move further.
1 I think it's OK not to make people to provide email address. As I understand, the main purpose of providing email address is users' convenience (here I assume that GH doesn't send spam and doesn't sell the info collected), s.a. email notifications and replies with email and for access restore procedure (which can be done another way). So I have no idea why this has been made mandatory. So I propose to make this optional.

2 There is some software allowing decentralised messaging, most notably BitMessage and Tox, all of which have own pros and cons. The pros is confidentiality of the content and independence from malicious companies. The cons are high resource usage due to decentralised nature, leaking some metadata to all the world, not only to restricted set of powerful parties and some functionality limitations, such as limited lifetime of offline messages (28 days for BitMessage or no such at all for Tox). Some people would consider some the drawbacks as tolerable cost for better privacy and security.
So I propose to support these messagging systems too, even though they are experimental.

Access to data in connection with service interruptions/termination

Corporate TOS issue: Section L3, you can suspend access at any time without notice or cause and seemingly no obligation to help users extract data. Section L3, you can terminate on 30 days’ notice, with an obligation to support extracting data.

Unclear why indefinite suspension should potentially lead to a worse result than termination. Consider clarifying that you’ll provide data extract access for suspensions lasting longer than 30 days.

Related in Section Q, “We reserve the right at any time and from time to time to modify or discontinue, temporarily or permanently, the Website (or any part of it) with or without notice.” Are you able to provide any assurances about data extraction in this context?