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 (firefox+noscript), 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 repo. (https://github.com/dfawcus/testDummyViaWeb) > 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 extras 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 git. 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 compared 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.] DF _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
