More permissive license grant to other users

[m1cm1c]

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.

[mfrasca]

I'm not sure if my concern is covered here, too: I wish to contribute to a project where the author did not take the time to define a license. Now I opened an issue on their repository, and to include it in my own project, I hope that they will choose a license compatible with GPL, but in the meanwhile I'm in a limbo. In my experience, there's quite a few authors out there who don't realize that not defining a license does not mean "you can do whatever you want" (which is possibly what they mean) but rather: "© all rights reserved". Could we make sure that there's a default license (the very strictly collaborative GLP, or the most permissive Public Domain, or anything that allows a subsequent author to choose a license), and that authors must actively remove the default if indeed they intend to reserve all rights to themselves as is the case when you don't specify a license.

[ssokolow]

@mfrasca I'm not sure if that would be considered legally binding.

It'd probably be better to:

1. Integrate a "generate-and-commit-a-license-file wizard" version of choosealicense.com for people with commit access.
2. Display some kind of publicly-visible big red warning bar on repositories with no license. (A "choose license" button could be included for people with commit access.)
3. Do a one-time sending of e-mails for all repos created prior to the change which have no license detected.

That way, "no license" could still be an option, but a big red "this repo is 'broken' in a legal sense" warning would display unless people actively click through a summary of what it really means and, in doing so, opt in. (Think of it like a failed static analysis or CI badge, but bigger and for the license rather than the code.)

[mfrasca]

@ssokolow we are speaking of two aspects, a "sanatoria" (Italian legalese for fixing a situation we let slip through our fingers and which we now don't want) and a "future practice". I like both point 2 and 3 you suggest, as parts of the "sanatoria". Do you mean, with point 1, to make it a part of the process of creating a repository? That would probably do. I actually also wonder, should GitHub still host public projects that lack a license (aka: all rights reserved)?

[ssokolow]

Do you mean, with point 1, to make it a part of the process of creating a repository? That would probably do.

The problem with embedding point 1 in the repository creation flow is that people like me never let GitHub initialize the repository contents. We develop it offline, then push it, complete with a LICENSE file, once we realize it's become something significant enough to share.

That means that, at minimum, there are three situations that need to be addressed:

1. Existing repos with no license display a big red banner and, if the user has commit privileges, it has a "choose license" button that take them to my proposed wizard.

2. New repos where GitHub is initializing the contents. The same license wizard could be incorporated into the creation process.

3. New repos where the initialization will be handled by git push. For these, whether there's a license can't be determined until commits have been pushed. If no license is found once there are commits, the "Existing repos with no license" case applies.

I actually also wonder, should GitHub still host public projects that lack a license (aka: all rights reserved)?

The problem there is that it's very difficult to retrofit a definitive licensing model onto a system that currently handles licensing by auto-detecting from the contents of the repository.

[mfrasca]

If no license is found once there are commits, the "Existing repos with no license" case applies.

triggering your suggested point (3), I would add.

[ssokolow]

I suppose. I just thought it would be a bit much to send an e-mail in that situation.

When you initially upload a repo, it's very likely that you'll then visit it on GitHub to make sure everything looks right.

The whole point of the e-mails was to notify people of changes to repos they might not have thought about in a while. (eg. I really would have preferred if GitHub had sent me an e-mail when they added support for assigning a set of tags to each repo in addition to the description and homepage URL.)

[b264]

The only folks who might not visit the GUI on github.com are probably bots anyway that are mirroring a project on github

[mfrasca]

ok, point taken. 👍

[mirabilos]

Any licence grant that stems from the ToS must not apply to repositories in which each file already has a Free Licence from my list because otherwise, such licence grant may not be able to be legally given, e.g. when uploading content from others under a copyleft licence, see #7.

[wking]

On Mon, Jul 17, 2017 at 12:51:01PM -0700, Stephan Sokolow wrote:

That way, "no license" could still be an option, but a big red "this repo is 'broken' in a legal sense" warning would display unless people actively click through a summary of what it really means and, in doing so, opt in.

“© all rights reserved” isn't necessarily broken (for example, you may be using GitHub to publish your novel, and novels are often unlicensed). Similarly, a repository might be licensed under a NoDerivatives version of the CC (e.g. 1). In §5's first paragraph 2, the ToS require you to grant permission for other users to fork your repositories. That matches up with the CC BY-ND's “reproduce and Share the Licensed Material” (§2.a.1.A 3). However, pushing a public branch as part of filing a PR would violate the CC BY-ND's “produce and reproduce, but not Share, Adapted Material” (§2.a.1.B 3). It would seem like GitHub should either:

a. Include the right to file public PRs against public repositories on GitHub in its terms of service, just like it currently mentions forking, or

b. Make pull requests an optional feature (like issues already are 4).

(b) would provide the most flexibility (folks who didn't want to allow public adaptations could still use public GitHub repos), but getting a usable UI would be tricky. Do you disable PRs unless a user explicitly grants you appropriate license terms? Do you warn contributors in the PR UI if the target repo has not explicitly granted appropriate license terms? Do you trust automated license detection to cover “explicit license term” grants (probably not 5), or do those grants have to be made via a GitHub UI (making repo-creation-via-push 6 awkward)?

[mfrasca]

In §5's first paragraph [2], the ToS require you to grant permission for other users to fork your repositories

what is the point to have permission to fork, if you do not have permission to edit your fork and publish your edits? I would argue that CC:BY-ND (and © all rights reserved) is effectively against the idea of letting you fork the original material.

[mirabilos]

Mario Frasca dixit:

what is the point to have permission to fork, if you do not have permission to edit your fork?

Publishing material, such as RMS’ viewpoints, for others to enjoy in the form published, but to not do anything else with it, and the fork is merely to retain a copy of sorts, have a reference.

[mfrasca]

the fork is merely to retain a copy of sorts, have a reference

for this, all you need is clone.

[wking]

On Mon, Jul 17, 2017 at 10:35:30PM +0000, Mario Frasca wrote:

the fork is merely to retain a copy of sorts, have a reference

for this, all you need is clone.

You might want a fork (a GitHub copy of the forked reporsitory) to provide others with stable links. For example, the owner of the original repository may delete their repository, but your fork would still be public, and you (and others) would still be able to resolve links to your fork.

[mfrasca]

I see a problem: you would now own a repository, copy of one which did not state a license, but the original has disappeared, so without the original as a reference, could you now be able to state the license in your copy? maybe not, because commits are signed... but yet, I see more confusion now.

[evandrocoan]

@wking, notice the repository owner can still fill a DMCA for GitHub to take down your fork from his repository as well. So your copy could not do much difference.

[wking]

On Mon, Jul 17, 2017 at 10:48:30PM +0000, Evandro Coan wrote:

@wking, notice the repository owner can still fill a DMCA for GitHub to take down your fork form his repository as well. So your copy could not do much difference.

Yes if the original was nominally “all rights reserved”. But if the original copyright holder posted the content to GitHub, the current ToS grant me the right to fork their content. And that doesn't go away when they leave 1. Although see #7 about not being able to fulfill the ToS in some cases if you don't have the right to relicense or grant additional permissions when creating the initial public repository.

ToS aside, if the original content was CC BY-ND 4.0, then I have a right to share a public copy, regardless of whether the original repository still exists or not.

[mfrasca]

https://help.github.com/articles/dmca-takedown-policy/#b-what-about-forks-or-whats-a-fork the above describes practice and rationale behind forking in a way that is incompatible with the original repository being marked as CC:BY-ND or all rights reserved.

[evandrocoan]

~@mfrasca, I think it would be fine as the GitHub grants the use of the fork to be solely used under the GitHub, and shall not be used outside it. So, it would only break the CC:BY-ND or all rights reserved if the contents where used outside the GitHub platform. It would imply that under the GitHub the contents can be used as accordingly agreed under the Terms of Service (ToS), but outside the GitHub service the CC:BY-ND or all rights reserved is applied.~

~For example, let us suppose the GNU GPL v3 license was under a GitHub repository. The GPL license clearly says it can be freely distributed, but shall not be changed never. Now on 2017, we are under the process of elaborating the GPL v4 version. How could I propose a change to the license if not through forking it, changing it and creating a pull request? The process itself is controversial, how can the GPL license be updated, if not changed?~

~Initially it would be possible by changing its name from GPL v3 to GPL v4alpha, therefore further changes would be allowed until the final release version GPL v4 be published.~

Reading the section:

You may grant further rights if you

Seems to clearly solve the problem for CC:BY-ND as it seems you do not need to give the right to other change your contents while on GitHub territory. However it does not solve the problem for All Rights Reserved (ARR), as the GitHub fork button allow copies of the contents to be made.

May suggestion would be either:

1. Disable the fork button for All Rights Reserved (ARR), or
2. Allow the GitHub forks the right to change the fork contents as suggested by #53

However this last one would conflict with licences as CC:BY-ND, which does not allow changes. To solve this last problem, an automatic licence detection should disable the fork button in presence of CC:BY-ND, or at least put a big UPPERCASE red warning stating this repository is under CC:BY-ND or All Rights Reserved (ARR).

[wking]

However this last one would conflict with licences as CC:BY-ND, which does not allow changes. To solve this last problem, an automatic licence detection should disable the fork button in presence of CC:BY-ND, or at least put a big UPPERCASE red warning stating this repository is under CC:BY-ND or All Rights Reserved (ARR).

I see no reason to block forking for CC BY-ND (even if you had faith in automatic license detection, which GitHub does not). The point of CC BY-ND is that public copies (e.g. forking or cloning) are allowed (the Licensed Material). You're just not allowed to share a changed version content you've copied (that would be Adapted Material). So CC BY-ND would allow forking, but not pushing new commits to the forked repo. And AAR would not allow forking.

But maybe the same copyright holder controlls two accounts (e.g. two employees who have assigned copyright to the same employer). They could fork and commit to the fork of the other's ARR repo. So the safest course for GitHub and which repos can be publically hosted there would be for the ToS to require "users can view" and to leave it up to the users to decide what else they can do.

[mirabilos]

On Mon, 17 Jul 2017, Mario Frasca wrote:

https://help.github.com/articles/dmca-takedown-policy/#b-what-about-forks-or-whats-a-fork the above describes practice and rationale behind forking in a way that is incompatible with the original repository being marked as CC:BY-ND or all rights reserved.

No.

The right to make changes local to oneself is often granted by law; Americans have this “fair use” stuff instead, etc. and you can most definitely distribute instructions on how someone else can change their own copy of a ND work to them without making and distributing a derived work yourself.

The language in that FAQ is explanatory, it does not explain every possible circumstance. It does hint that “and may be licensed or
used in a different way” which is interesting because A can clone B’s ND repository, contact them, and get a different licence to apply to his repository back from them.

[nsqe]

Thanks for your suggestion, @m1cm1c, and for all the discussion about this topic.

For many reasons, we will not be able to require our users to grant a more permissive license. However, most open source licenses cover the kind of uses — such as pull requests, local forks, and modification — you refer to, and those uses may also be covered by legal exceptions such as fair use.

At this time, the site-policy repository is only for suggestions to our policies — we aren't able to change GitHub functionality such as by changing the behavior of the fork button depending on the presence or terms of a license.