More permissive license grant to other users about site-policy HOT 22 CLOSED

@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.)

from site-policy.

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.

from site-policy.

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.

from site-policy.

@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)?

from site-policy.

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.

from site-policy.

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.)

from site-policy.

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

from site-policy.

ok, point taken. 👍

from site-policy.

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.

from site-policy.

from site-policy.

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.

from site-policy.

from site-policy.

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

for this, all you need is clone.

from site-policy.

from site-policy.

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.

from site-policy.

@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.

from site-policy.

from site-policy.

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.

from site-policy.

@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).

from site-policy.

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.

from site-policy.

from site-policy.

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.

from site-policy.