[Top][All Lists]

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

Re: Please, no GitHub

From: Derek Fawcus
Subject: Re: Please, no GitHub
Date: Sat, 12 Dec 2015 10:20:30 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Sat, Dec 12, 2015 at 12:00:41AM -0500, Richard Stallman wrote:
>   > As far as I can see,  the existance of the Github JSON API [1] allows it
>   > to meet all of the criteria in section C of that document,  and hence be
>   > an acceptable host.
> I think you've misunderstood the meaning of some conditionss.

Possibly,  English is always subject to interpretation...

>     <li id="C0"><p>All important site functionality that???s enabled for use
>         with that package works correctly (though it need not look
>         as nice) in free browsers, including
>         <a href="/software/gnuzilla/">IceCat</a>,
>         without running any nonfree software sent by the
>         site.  <strong>(C0)</strong></p>
> means that if you visit the site normally, with nonfree JS code blocked,
> the site works normally.

Well,  I just created a repo there using a browser with JS disabled 
using the web interface.  It worked quite happily.  I created an initially empty
repo (so didn't get to pick a licence then), then pushed some initial content
from the cli.  At which point github recognised the license which was in the 


> I think you are talking about something quite different, such as whether
> you could write some other interface that would work.  Maybe you could,
> but that is not what C0 is about.

Actually,  while I did imply something similar,  my position is more that due to
the nature of git,  any extras which a hosting provider offers over and above
that available through the git protocol are irrelevant.  So access to said 
is also irrelevant.  When using git (or hg) there isn't really one main repo
a such, all hosts with the repo are peers.

One can push content to a repo without using the website,  one can requests that
content be merged without using it,  and one can merge content without using it.
Those are the important pieces of functionality.

One can even take merges from alternate hosting sites,  due to the nature of 
So if someone preferred using Gerrit for code review,  that would be no problem.

The frills which various git hosting sites provide are largely irrelevant 
to the simply act of hosting the code,  and having native git protocol access to
the repo.

Witness the Linux kernel,  where it is hosted in various disparate places,  pull
requests (and review) occur via email on the LKML, and said pulls can occur
directly from those disparate sites (or via patches sent to the list).
Similarly for the development of git itself.

>     <li id="C5"><p>Recommends and encourages GPL 3-or-later licensing at
>         least as much as any other kind of licensing.  
> <strong>(C5)</strong></p></li>
> Since you talk about offering a "choice", I think you may have
> misinterpreted "Recommends and encourages" as "permits".

Nope.  I'm suggesting that the offering of the choice is not a recommendation as
such,  and hence all have equal billing.  i.e. the choice of 'none' is equally
recommended as that of 'GPL-v-x' or later,  since none of them are in my view
a recomendation.  Which is why I quoted 'at least as much as any other kind'.

For the above repo creation,  not having JS enabled, meant that 'none' was the
only choice initially available,  but once content was pushed,  the licence
was recognised.

[For others reading the thread,  it'd be interesting to see if they could create
 interactions (PRs, etc) with the above repro through the website without having
 JS enabled.  I'm curious how much of the functionality would work that way,
 since what I saw seemed to be html5 + css smarts.]


reply via email to

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