Re: [Repo-criteria-discuss] Ethical hosting means Free Software hosting

[Ian Jackson]

Mike Gerwitz writes ("Re: [Repo-criteria-discuss] Ethical hosting means Free 
Software hosting"):
> On Fri, Jun 03, 2016 at 16:39:24 +0100, Ian Jackson wrote:
> >   Server code released as free software. (A1)
> > is in category A.
> >
> > I don't think the GNU Project (or anyone concerned with Software
> > Freedom) ought to recommend hosting services which do not meet this
> > criterion.
> 
> I certainly think that all server-side code for services should be
> free/libre, but for different reasons: For example, users should be able
> to break from that hosted instance if they choose, and take their data
> with them; and much useful software exists only on the server today that
> the world could benefit from it.
> 
> But they are different issues from software freedom, and I think that's
> where the criteria confusion comes in; rms explains them here:
> 
>   https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

I don't understand why you say these are "different issues from
software freedom" and then link to an article by RMS which explains
how proprietary websites make people unfree.  (RMS's article attempts
to distinguish proprietary services which are for publishing things,
and proprietary services which are for computation.  I am arguing that
that distiction doesn't make any practical sense.)

> > Conversely, the focus on non-free JavaScript is quixotic.
> 
> It is certainly not.  GitLab already has it, for instance:
> 
>   https://about.gitlab.com/2015/05/20/gitlab-gitorious-free-software/

But the whole of Gitlab is Free Software.  The tagging to placate
LibreJS is easy for them to do.

> > When a user is using a proprietary website, it does not matter much
> > whether the javascript fragments or javascript libraries sent by the
> > server happen to be Free.  The user is still hostage to the whole
> > website: they cannot suggest improvements; they cannot set up and move
> > to a competing platform with their desired changes; and so on.
> 
> See the SaaSS link above.  The term "proprietary website" is a bit
> ambiguous---you could be talking about the JS or the server.

In practice, "proprietary website" is accurate _precisely_ because it
talks abouit _both_ the server code, and the JS it serves to the
browser.  I defy you to point to any website with which serves
substantial amounts of JS, where the JS is Free even though the
server-side is proprietary.

Indeed, when websites are built, the software engineers treat the
server code and the JS as parts of a whole.  In some case the JS is
even generated ad-hoc by the server.

Even if you could find some website where the JS is "Free" by this
definition, but the server side is not, the user still does not have
much practical ability to run modified JS.

> The server code isn't robbing them of their four freedoms because they
> never had the ability to exercise them in the first place: it's not
> running on their computer.

You write that this "isn't robbing them of their four freedoms" but
then you have to ackwledge that the user "never had" freedom "in the
first place".  Your comparator is deliberately crippled.

The fact that users of proprietary websites are unfree is a serious
problem.  In practice, with a truly Free website, the user is much
closer to having real software freedom.

> Nearly every website you visit does not have its source code available,
> and they distribute HTML documents.  Those documents are often generated
> by data on the server, or some sort of logic: e.g. a forum.  We don't
> think of those as robbing our freedoms, because they're aren't.

The Debian project takes a different view.  We think that our code
hosting systems, bug trackers, discussion software, and so on, need to
be Free.

> > If it were up to me I would demote the criterion C0, which relates to
> > nonfree Javascript, to required-for-B.
> 
> That would mean that a website doesn't have to be at all functional with
> JavaScript disabled in order to reach a non-failing grade; that's not
> acceptable for GNU project hosting (or any hosting of free software
> projects, IMO).

The existing criteria do not actually require that a site works
without JavaScript, of course.  It's just that a proprietary website
whose JavaScript is Free is a theoretical and impractical beast which
no-one would bother to create.

IMO the right response to a hosting site which doesn't work properly
without JavaScript is to send them patches.  Of course that means the
whole site has to be Free.

> > I would promote the criterion A0 to required-for-B.
> 
> The intent of A0 is so that users can forego JavaScript in its
> entirety---even if the JS is free---and still be able to use the
> website.

Yes.  I think this is more important than implied by "required-for-A".
Your comments above seem to suggest that you agree with me.

> > I would demote the LibreJS labelling criterion (B0) to required-for-A.
> 
> That would mean that we're recommending sites that might be serving
> proprietary JavaScript.

No, because we wouldn't be recommending any proprietary sites _at
all_, because A0 (site is Free) would be required for recommendation.

Ian.