github-terms-of-service D: Locally condition grants on existing license #54
Conversation
wking
force-pushed
the
conditional-ToS-license-grant
branch
from
6a06a80
to
fc61b7d
Compare
With 7a72ae0 (DRAFT UPDATE to GitHub Terms of Service, 2017-07-09, #1), the ToS grew new language about conditionally granting licenses in section D.3. However, the text in D.4 and D.5 still read as if the license grant was unconditional. This commit adjusts sections D.4 and D.5 to clearly separate the permissions needed (which are always true) from the ToS grant (which is only needed if the existing license doesn't already grant those permissions). Also * Define a new term, "Other Users" so we can compactly refer to other users without ambiguity. * Adjust the Your Content criteria. For example, if you fork another user's repository, the forked repository is Your Content, just like it would be if you cloned the other user's repository and then created a new GitHub repository seeded from that local clone. This clarifies the case where Alice creates the content and Bob uploads it to GitHub (it would be Your Content for Bob, but not for Alice unless she took other action). I've also removed "You own the content you post on GitHub" and similar, because the poster may not be the copyright holder, and instead have focused on ownership not changing as a result of GitHub posting. * Trim D.3 to cover termination and payment of any permissions granted in the following D.*. The old "we need you to grant us" wasn't conditional, so now that's gone. The old "unless other Users have forked it" is no longer covered in the ToS (more on this below). The remaining lines removed from D.3 are now covered in more detail in their specific sections. * In D.4, remove "to do things like host Your Content, publish it, and share it", which are all covered in more detail in the subsequent section. * In D.4, add a new paragraph explicitly granting GitHub the required permissions if and only if your existing license doesn't already. This section doesn't address things like fair use, where GitHub might have permission to parse and share search results even in the absence of an explicit license, but I couldn't think of a concise way to cover that. * In D.5, I've removed the focus on public content, since any other user who is authorized to view the content requires this permission, regardless of whether the content is public. * In D.5, I've removed the need for fork permission. Users can view your content and decide for themselves whether they're allowed to fork it. If they fork content that you do not consider forkable, you can file a DMCA takedown request. The old "unless other Users have forked it" from D.3 is no longer needed because the forked content is no longer Your Content (see the earlier points about the Your Content criteria).
wking
force-pushed
the
conditional-ToS-license-grant
branch
from
fc61b7d
to
2f530a6
Compare
This would reopen #8 which was fixed only because §D.7 only applies to “Your Content”. I was being told that it’s deliberate that both “Your Content” and §D.7 only apply to code which uploader can grant the waiver on. |
| 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. | ||
| 5. “Other Users” refers to third-party people, companies, or organizations that have visited or are using the Website or Service. | ||
| 6. “GitHub,” “We,” and “Us” refer to GitHub, Inc., as well as our affiliates, directors, subsidiaries, contractors, licensors, officers, agents, and employees. | ||
| 7. “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 administer on GitHub, regardless of who created or uploaded it. “Paid Content” is Content only available to Users who are participating in a payment plan, including private repositories. |
There was a problem hiding this comment.
As posted as comment already, this would reopen #8 and goes against the intent of the previous “Your Content” definition. Please find a way to do this without changing the “Your Content” definition.
|
|
||
| Because you retain ownership of and responsibility for Your Content, we need you to grant us — and other GitHub Users — certain legal permissions, listed in Sections D.4 — D.7. These license grants apply to Your Content. 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. You understand that you will not receive any payment for any of the rights granted in Sections D.4 — D.7. The licenses you grant to us will end when you remove Your Content from our servers, unless other Users have forked it. | ||
| Because GitHub does not User-Generated Content, We — and Other Users — need certain legal permissions, as listed in Sections D.4 — D.7. You understand that You will not receive any payment for any of the rights discussed in Sections D.4 — D.7. Any permissions You grant to Us and Other Users will end when You remove Your Content from our servers. |
There was a problem hiding this comment.
- The first new sentence is lacking a verb.
- perhaps “Any permissions You grant to Us and Other Users under §D.4–D.7”?
There was a problem hiding this comment.
The first new sentence is lacking a verb.
The verb is “need”.
perhaps “Any permissions You grant to Us and Other Users under §D.4–D.7”?
That's better. I'll add it to v2. I'll also change the em-dashes to en-dashes for the range.
| This license does not grant GitHub the right to sell Your Content or otherwise distribute or use it outside of our provision of the Service. | ||
| We do not need the right to sell Your Content or otherwise distribute or use it outside of our provision of the Service. | ||
|
|
||
| If Your Content's existing license grants Us the needed permissions, no additional license is required. If Your Content's existing license does not grant Us the needed permissions, then you agree grant Us those permissions. |
There was a problem hiding this comment.
Good, except:
- The law may already grant that, but that’s just nitpicking.
- The uppercase “Us” looks a bit too pluralis maiestatis. In other places, “GitHub” is written, which looks much better and is a tad more clear.
- As noted already, this needs a separate term from “Your Content”. Perhaps “Content You upload”?
There was a problem hiding this comment.
The uppercase “Us” looks a bit too pluralis maiestatis. In other places, “GitHub” is written, which looks much better and is a tad more clear.
I have no preference on this, and consider all the GitHub terms synonymous. However, if we use “GitHub” here, I'd rather use it in the section title as well.
|
|
||
| #### 5. License Grant to Other Users | ||
| Any User-Generated Content you post publicly, including issues, comments, and contributions to other Users' repositories, may be viewed by others. By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control). | ||
| Other Users need the legal right to view Content they are authorized to access via the Website or Service. For example, all users need the legal right to access issues, comments, and contributions to public repositories. |
There was a problem hiding this comment.
- define “access”, reading? modifying? creating new ones?
- Why do they need that?
- Case in point, I can disable issues on my repositories and usually do, especially for those that are just mirrors.
There was a problem hiding this comment.
define “access”, reading? modifying? creating new ones?
I don't think we need to define “access”. It can contain all of the interpretations you suggest, but they only need the right to view that content. There's a theoretical chance that GitHub would authorize a user to modify content that they cannot view, but I don't think you need to make that distinction for Your Content. And if the Other User is creating new content, then they already have full access to it, so You don't need to grant them any new permissions.
Why do they need that?
So they can view the site.
Case in point, I can disable issues on my repositories and usually do, especially for those that are just mirrors.
If you disable issues before any are created, you are removing Other Users' right to post to that location. That does not affect Other Users right to view anything.
If you disable issues after some have been created, you may be removing an Other User's right to view it. That's the same as deleting an Other User's comment in your issue tracker. There's some wording about removing content in the current §D.3, but we may need a new section to cover User-initiated removal. Or perhaps there's a distinction to be made between “right” and “ability” (e.g. you'd be legally allowed to view this, but GitHub decides not to show it to you). Anyway, that issue (if it exists) applies both disabling a populated issue tracker and deleting individual issues. But it seems different enough that I'll punt on it for this PR.
|
|
||
| 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. | ||
| If Your Content's existing license grants Other Users the needed permissions, no additional license is required. If Your Content's existing license does not grant Other Users the needed permissions, then you agree grant Other Users those permissions. |
There was a problem hiding this comment.
Again with the “Your Content”. The new wording is better-ish, but the definitions in the new paragraph above this one are much too vague, so, not enough.
| @@ -237,7 +240,7 @@ We offer Pages sites primarily as a showcase for personal and organizational pro | |||
| #### 2. GitHub Repositories | |||
| GitHub repositories are intended to host Content. You may include static images, links, and promotional text in the README documents associated with your repositories, but they must be related to the project you are hosting on GitHub. | |||
|
|
|||
| You may not advertise in other Users' repositories, such as by posting monetized or excessive bulk content in issues. | |||
| You may not advertise in Other Users' repositories, such as by posting monetized or excessive bulk content in issues. | |||
There was a problem hiding this comment.
Unrelated, should be split into a separate PR.
| @@ -273,7 +276,7 @@ It is your responsibility to properly cancel your account with GitHub. You can [ | |||
| #### 2. Upon Cancellation | |||
| We will retain and use your information as necessary to comply with our legal obligations, resolve disputes, and enforce our agreements, but barring legal requirements, we will delete your full profile and the Content of your repositories within 90 days of cancellation or termination (though some information may remain in encrypted backups). This information can not be recovered once your account is cancelled. | |||
|
|
|||
| We will not delete Content that you have contributed to other Users' repositories or that other Users have forked. | |||
| We will not delete Content that you have contributed to Other Users' repositories or that Other Users have forked. | |||
There was a problem hiding this comment.
Unrelated, should be split into a separate PR.
|
I've just addressed this in #7 (comment). I believe that will resolve the issues here. Closing this for now, but will refer back to this when drafting the new guidelines. |
|
On Wed, Aug 02, 2017 at 01:32:26AM +0000, Hannah Poteat wrote:
I've just addressed this in #7 (comment).
The help article you propose there sounds nice, but note that [1] has:
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.
So if your help article says something like “projects released under
the GPL-3.0 need no additional rights granted to GitHub or Other
Users” (or whatever you end up saying), I still think you'd want to
improve the ToS wording to avoid the currently unqualified [2]:
You grant us and our legal successors the right to store and display
your Content and make incidental copies as necessary to render the
Website and provide the Service.
and similar.
Also note that the current ToS currently require you to grant other
users the right to fork [3]. And while that may be something that
GitHub intentionally requires you to grant other users, it limits what
people can host on GitHub (e.g. you can't host a public repository
that is “all rights reserved” while only granting other users view
permission [4]).
And I think the current “Your Content” still needs clarification,
although I've also documented that in [5].
[1]: https://github.com/github/site-policy/blob/75c016d80fe819c192f5c953eb3829bee63462a2/Policies/github-terms-of-service.md#5-complete-agreement
[2]: https://github.com/github/site-policy/blob/75c016d80fe819c192f5c953eb3829bee63462a2/Policies/github-terms-of-service.md#4-license-grant-to-us
[3]: https://github.com/github/site-policy/blob/75c016d80fe819c192f5c953eb3829bee63462a2/Policies/github-terms-of-service.md#5-license-grant-to-other-users
[4]: #38 (comment)
[5]: #1 (comment)
|
With 7a72ae0 (#1), the ToS grew new language about conditionally granting licenses in section D.3. However, the text in D.4 and D.5 still read as if the license grant was unconditional. This commit adjusts sections D.4 and D.5 to clearly separate the permissions needed (which are always true) from the ToS grant (which is only needed if the existing license doesn't already grant those permissions). Also
Define a new term, “Other Users” so we can compactly refer to other users without ambiguity.
Adjust the Your Content criteria. For example, if you fork another user's repository, the forked repository is Your Content, just like it would be if you cloned the other user's repository and then created a new GitHub repository seeded from that local clone. This clarifies the case where Alice creates the content and Bob uploads it to GitHub (it would be Your Content for Bob, but not for Alice unless she took other action).
Trim D.3 to cover termination and payment of any permissions granted in the following D.*. The old “we need you to grant us” wasn't conditional, so now that's gone. The old “unless other Users have forked it” is no longer covered in the ToS (more on this below). The remaining lines removed from D.3 are now covered in more detail in their specific sections.
In D.4, remove “to do things like host Your Content, publish it, and share it”, which are all covered in more detail in the subsequent section.
In D.4, add a new paragraph explicitly granting GitHub the required permissions if and only if your existing license doesn't already. This section doesn't address things like fair use, where GitHub might have permission to parse and share search results even in the absence of an explicit license, but I couldn't think of a concise way to cover that.
In D.5, I've removed the focus on public content, since any other user who is authorized to view the content requires this permission, regardless of whether the content is public.
In D.5, I've removed the need for fork permission. Users can view your content and decide for themselves whether they're allowed to fork it. If they fork content that you do not consider forkable, you can file a DMCA takedown request. The old “unless other Users have forked it” from D.3 is no longer needed because the forked content is no longer Your Content (see the earlier points about the Your Content criteria).
Related discussion in #53, #52, #38, #37, and #7.