More permissive license grant to other users #38
Comments
|
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. |
|
@mfrasca I'm not sure if that would be considered legally binding. It'd probably be better to:
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.) |
|
@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". |
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 That means that, at minimum, there are three situations that need to be addressed:
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. |
triggering your suggested point (3), I would add. |
|
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.) |
|
The only folks who might not visit the GUI on github.com are probably bots anyway that are mirroring a project on github |
|
ok, point taken. 👍 |
|
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)?
[1]: https://creativecommons.org/licenses/by-nd/4.0/
[2]: https://github.com/github/site-policy/blame/75c016d80fe819c192f5c953eb3829bee63462a2/Policies/github-terms-of-service.md#L146
[3]: https://creativecommons.org/licenses/by-nd/4.0/legalcode
[4]: https://help.github.com/articles/disabling-issues/
[5]: https://developer.github.com/v3/licenses/
[6]: #38 (comment)
|
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. |
|
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.
|
for this, all you need is clone. |
|
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.
|
|
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. |
|
@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. |
|
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](https://github.com/github/dmca) 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.
[1]: https://github.com/github/site-policy/blame/75c016d80fe819c192f5c953eb3829bee63462a2/Policies/github-terms-of-service.md#L262
|
|
https://help.github.com/articles/dmca-takedown-policy/#b-what-about-forks-or-whats-a-fork |
Copied from: 1. https://help.github.com/articles/dmca-takedown-policy/#b-what-about-forks-or-whats-a-fork The definition of what a GitHub fork means. Currently the ToS only states that fork is a bare copy of a GitHub repository. However as defined on the referenced article, a fork means also the users can make changes to their copy, instead of get them as read-only copies. Related issues: 1. github#7 OSS licences vs. ToS: grants of rights 1. github#37 The term "fork" is not defined anywhere in the GitHub Terms of Service 1. github#38 More permissive license grant to other users
|
Reading the section:
Seems to clearly solve the problem for May suggestion would be either:
However this last one would conflict with licences as |
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. |
|
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.
|
|
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. |
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.
The text was updated successfully, but these errors were encountered: