OSS licences vs. ToS: grants of rights (#7)

[mirabilos]

should fix #7

• add a Definition for Free Licences
• explicitly disable the explicit licence grant in §D.4 and §D.5 for content under Free Licences to follow up the statement in §D.3 saying it’s not “required”

[wking]

Is there an existing term for this, or is “Free License” something we're making up for this ToS? What happens to GitHub and its users if one of the organizations you cite changes its criteria? Also note that the pages you link for approved licenses may not be complete. For example, the OSI has approved the AFL-1.0 (since superseded by the AFL-3.0), but the AFL-1.0 currently shows up on neither of the OSI's license-list pages.

I don't see a way around that short of defining what GitHub needs and what other users need (e.g. “free redistribution” for forking public repositories and “derived works” for creating public branches to be used in pull requests) or explicitly whitelisting licenses which GitHub considers sufficient.

[mirabilos]

The list of lists is not perfect. However, it is a start, it doesn’t contain any false positives, it doesn’t need GitHub to finally disclose what rights their lawyers think they precisely need, and it fixes the problem the new ToS introduced in February for most OSS projects.

Do this now, improve upon it in the background in parallel so a future ToS update will see your improvements. (I’m all for the idea of requirement-based, but you also have to state what those licences can not require from users or GitHub, and you will have to list approved licences somewhere because putting this down on every user will be ridiculously hard.) Also, note that forks do not get “free redistribution”, only inside GitHub, by the default licence.

For now, this change will make a couple of licences “first class citizens”, but for OSS stuff, that’s okay.

The organisations are known to either not change the criteria, or only in the same spirit. I think we can believe that anything that passes one set of those criteria and does not fail others’ sets in those list is “good enough” to be promoted to first-class citizen and thus explicitly excluded from the extra licence clause.

[wking]

The list of lists is not perfect. However, it is a start, it doesn’t contain any false positives, it doesn’t need GitHub to finally disclose what rights their lawyers think they precisely need, and it fixes the problem the new ToS introduced in February for most OSS projects.

Anything that gives us a list of already-sufficiently-free licenses would be very useful. But @nsqe doesn't want a local list of licenses, and delegation like you're proposing here seems dicey in the absence of a clear definition of the rights GitHub needs granted.

Also, note that forks do not get “free redistribution”, only inside GitHub, by the default licence.

Right. But are any of the license-classification groups you link making that distinction?

I think we can believe that anything that passes one set of those criteria and does not fail others’ sets in those list is “good enough” to be promoted to first-class citizen and thus explicitly excluded from the extra licence clause.

As far as users are concerned, I'd rather look at the project license directly instead of going through the ToS (assuming those are even binding). So it doesn't matter as much to me.

GitHub, on the other hand, is doing a lot of automatic stuff based on the ToS, and they might be more cautious about delegating authority to so many external organizations.

[mirabilos]

W. Trevor King dixit:

> Also, note that forks do not get “free redistribution”, only inside > GitHub, by the default licence. Right. But are any of the license-classification groups you link making that distinction?

That’s **precisely** the reason we **need** this change. I maintain software under GPL I did not create. Since February, this can no longer be mirrored at GitHub, and I took down the repository immediately of course. This needs to be fixed. I don’t want to be required to file DMCA takedowns against mirrors of copylefted (or, worse, Ⓕ) works in whose creation I participated (to not be in danger of losing the licence to them myself).

[wking]

On Tue, Jul 18, 2017 at 12:22:16AM +0000, mirabilos wrote: W. Trevor King dixit: >> Also, note that forks do not get “free redistribution”, only >> inside GitHub, by the default licence. > >Right. But are any of the license-classification groups you link >making that distinction? That’s **precisely** the reason we **need** this change.

The goal is to allow content with an existing copyleft license to be shared via GitHub without the ToS granting new permissions to either GitHub or other GitHub users. I think we can accomplish that without requiring a license-classifying group distinguish between “redistribution in general” and “redistribution only inside GitHub”. I think GitHub needs the right to redistribute the content within the GitHub UIs and APIs as long as there is sufficient context to trace whatever is being shown back to the repository it comes from (e.g. an excerpt in search results linking back to its original repository). I think GitHub users need the right to view content on GitHub. Then they can determine whether they have the right to fork into a new GitHub repository, or clone into a new local repository, etc. based on what they read in the original repository. Those two conditions seem straightforward enough that you can determine whether or not your license covers them without having an explicit license whitelist or punt to external standards bodies. If GitHub says in the ToS that you need to grant them and users those permissions *if and only if they aren't already covered by your existing license*, then I think that would cover #7. External organizations that want to weigh in on whether they think a particular license qualifies can list them as GitHub-public-repo-compatible without GitHub having to bless the external organization ahead of time.

[mirabilos]

I think GitHub needs the right to redistribute the content within the

Sure. But only what e.g. the GPL grants GitHub. That is enough to run such a service. Hence, any additional licence grant GitHub requests is redundant for all Free Licences.

Those two conditions seem straightforward enough that you can determine whether or not your license > covers them without having an explicit license whitelist or punt to external standards bodies. If

Possibly, yes. But what to do in case of doubt? Which is why a list will help clarity.

---

Anyway, some change is required right now (and has been since February). This is good enough for now.

[mirabilos]

W. Trevor King dixit:

The goal is to allow content with an existing copyleft license to be

Yes, although it ought to be “with an existing Free/OSS licence”, as not only copyleft licences have this problem, it just shows up more obviously in them.

shared via GitHub without the ToS granting new permissions to either GitHub or other GitHub users. I think we can accomplish that without

Please do make an alternative suggestion then — I’d be more than happy to have a look at that and review it, accepting if its text solves the underlying problem.

I think GitHub needs the right to redistribute the content within the GitHub UIs and APIs as long as there is sufficient context to trace whatever is being shown back to the repository it comes from (e.g. an excerpt in search results linking back to its original repository).

I believe that that is implicit within a good jurisdiction. Since GitHub relies on USA law explicitly, their “fair use” construct probably suffices (should be double-checked by an actual American lawyer, of course).

I think GitHub users need the right to view content on GitHub. Then they can determine whether they have the right to fork into a new GitHub repository, or clone into a new local repository, etc. based on what they read in the original repository.

Exactly. These are granted by all Free/OSS licences anyway, *except* they add constraints to the licence grant, so you get an all-or-nothing (you accept the licence, then you get *all* of its benefits, you don’t you get none), which is why an explicit language requiring this to be explicitly granted does *not* work with projects by non-GitHub Users under such licences.

If GitHub says in the ToS that you need to grant them and users those permissions *if and only if they aren't already covered by your existing license*

They have something _like_ that in §D.3, but not in strong enough language to make the grant requirements from §D.4f. obsolete for them. Again, please suggest wording, so they can put that into the next ToS update. I suggested wording that works with my model of ensuring either side gets what they need. You have a different model; if it suffices to fix the original problem in the ToS as of February 2017, then sure, but since I don’t have your model I don’t think it too tall an order to request you put words to where your complaint with mine is. Thanks, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt

[wking]

On Tue, Jul 18, 2017 at 08:45:23PM +0000, mirabilos wrote: > shared via GitHub without the ToS granting new permissions to > either GitHub or other GitHub users. I think we can accomplish > that without Please do make an alternative suggestion then…

Filed as #54.

[nsqe]

I've just addressed this in #7 (comment). Closing this for now, but will use it for reference when drafting the new guidelines.