Skip to content

OSS licences vs. ToS: grants of rights #7

@mirabilos

Description

@mirabilos

EDITED to reflect the remaining issues for the July 2017 upgrade. Original PR at bottom.

The ToS §D.4f. in the July 2017 update still include an unconditional licence grant on content uploaded which the user may not be able to fulfil, as virtually all licences require certain terms to be enforced for any kind of redistribution (same licence for copyleft licences, retaining some words of the licence usually for Ⓕ copyfree licences).

The offending sections must be modified to apply only to repositories in which not every file is already available under a licence granting GitHub and its users “enough” rights to do what’s described. For practicality reasons, all Open Source / Open Knowledge / FSF-free / DFSG-free / Copyfree licences are, after reading their definitions, considered “enough”, and any other licences are outside the scope of this problem report.


The original PR before the edit follows:


Even after #1 there are still some remaining issues. This one is about §D.3ff. (grants of rights).


§D.3 says “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.”

Please clarify here explicitly that any of the usual OSS licences are sufficient to fulfil this ToS requirement, including honouring their termination clauses and all.

I grant you that you may include the text body of that list of free licence lists in your ToS or elsewhere. I collected this list myself. For review, it should be sufficient to review the inclusion criteria (e.g. the OSD (Open Source Definition) for the OSI list, etc.) because, as far as I can tell, any licence that fulfils the criteria to be listed in one of those lists is required to grant enough rights for GitHub and its users to do the necessary things.

Do note that I included non-code licence lists; this is often necessary for documentation, audiovisual works, etc. (such as game data, etc). My intent here is to “defang” ToS §D.3–D.5 if the entirety of the repository is available under (a combination of) Free/OSS licences, because these grant both GitHub and every GitHub user enough rights already to, in practice, do what you request.


§D.4 says “share it with other users”

Please make it explicitly clear that, if such an OSS licence (see above) applies to the work, any users will still have to comply with the licence on the work (including all of its restrictions).

This should not be a problem because those licences and the law already have provisions for service providers that include hosting, backing up the work, and transit, as long as the recipient, when sharing, is bound to the licences’ terms.


§D.4 says “This license does not grant GitHub the right”…

Please make it clear that the OSS licences (as above) supersede this anyway.


§D.5 says “you grant each User of GitHub a […] license […]”

Please make it explicitly clear here that, if any such OSS licence as above applies to the work, this additional grant is not necessary, and that this clause does not “defang” the conditions the OSS licences put on dealings in the works licenced under them.

This is also not a problem for either you or your users because the licences and, again, the usual laws, permit users rights to do some things locally with the works, and virtually all of the conditions those licences have only trigger when users further share the work.

Please make it also clear that “Content you upload is licensed under terms that grant these permissions” is also sufficiently fulfilled if such content is available under the OSS licences mentioned.


This is a follow-up on a part of the new ToS draft, partly from my prior review which I assume you know, but, if not, suggest to read. The list of free licences on my website is new, created after that article.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions