[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: criteria A4 should be a C-class criteria

From: Aaron Wolf
Subject: Re: RFC: criteria A4 should be a C-class criteria
Date: Fri, 12 Mar 2021 20:22:30 -0800

I see your points, and I agree this merits further careful
consideration. The status quo is pretty absurd.

I'm still hesitant to agree that it's a C-level concern. The
irresponsibility of a host and of the various repositories doesn't
directly undermine the freedoms around any GNU software at that host.

Nevertheless, I can see the argument that this situation is so troubling
that GNU could take a hard stance rejecting hosts that engage with this

On 2021-03-12 4:33 p.m., bill-auger wrote:
> i cant claim to know the answer; but i have done some research -
> the implications of this are rather significant, and people
> should want to know
> for the purpose of this list though, whether or not the TOS
> allows downloading unlicensed works, is irrelevant - the fact
> is, that people are downloading tarballs, and making VCS clones
> which they have no formal license to - either way, it is
> unethical, unless the full implications are clearly explained to
> users; and either way, the service operators are responsible for
> the confusion (or trick, as the case may be) - it would probably
> take a lawyer to fully de-tangle those TOS; but i figured that
> this list would be the most appropriate to discuss and
> investigate it - if my suspicions are accurate, i think it
> should become an essential criteria
> what i do know, it goes back some years, from when i was trying
> to convince github to add something to their licensing guide,
> which would mention that people must not choose the 'no-license'
> option, if they want their code to be used and shared legally -
> at the time, it mentioned nothing about  the 'no-license' option
> - it gave absolutely no suggestion of why anyone should choose a
> license - they rejected most of my changes; but they kept the
> one sentence which made that point clear - something like: "if
> you want people to be able to use and share your software, you
> must choose a license" - if they believed that the TOS already
> allowed for that, then they could have rejected that sentence
> also, with an excuse lie: "a license is not needed for that -
> our TOS grants everyone an implicit license to use and share" -
> i did not get any such response; and im quite certain that their
> TOS does not grant anyone a license to use, copy, or distribute
> - users always get the license from the author (or none)
> i read the github TOS quite thoroughly at the time - what it
> says, is something like: "you grant us permission to present the
> code to other users, for viewing and forking" - and thats all -
> there is no further elaboration on what that implies
> i think "viewing" is obvious - that means the public can read
> the code in a web browser (look but dont touch) - the copy in
> your local browser cache, is probably permitted according to the
> legal exception, which considers the temporary copy in a CD
> player buffer to be exempt, just as with streaming media services
> im quite sure that "forking" has a similar semantics (nothing
> leaves the server in a practically usable form) - "forking"
> means "pressing the fork-me button on the website", which merely
> creates another copy on the server (for similar "viewing" and
> "forking") - i assume that it does not suggest downloading a
> proper VCS clone locally
> it does not mention anything about the downloading a tarball;
> but that is neither viewing nor forking, in any sense - that is
> very plainly "copying", and per the plain english
> interpretation, the TOS does not permit it - if it were
> permissible at all, i would expect some terms to mention it
> (something like: "users may download one copy for local
> viewing" (a weak license grant); but there is nothing that
> resembles a license grant
> that was a few years ago; but i doubt that their TOS has changed
> WRT that topic - i have not read the TOS of any other forge, but
> as most of them are github copy-cats; i expect that they have
> similarly vague TOS

reply via email to

[Prev in Thread] Current Thread [Next in Thread]