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

[Mike Gerwitz]

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

That doesn't mean that I don't think they're important for these
criteria, though.  Feel free to e-mail rms to ask for clarification on
why he decided the way he did; CC this list if you do so we can follow.

> 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/

Free JS is essential for our freedoms online, and it's a difficult
problem to solve---even if software is free, there's still trouble
exercising freedoms.  That doesn't mean we ignore the problem: it's
_essential_ to work toward them: some users run more SaaSS software than
traditional desktop software, and that's only going to continue.

If you're interested, I talked about it at LibrePlanet 2016:

  https://media.libreplanet.org/u/libreplanet/collection/restore-online-freedom/

> 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 this
case, I think you're talking about the server.  They're two separate
issues, because the user is only running the code served to the client.

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.

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.

But if we want to host our _own_ forum, that code would be useful to
have.  And so I agree that we should be able to have it.  But it's not
the same issue.  I can still ethically use that website, so long as it
works without proprietary JS.

> But in the context of web applications, I think it is silly.

I addressed that in my talk.  In the case of a web app (SaaSS), you're
completely forfeiting all control over your computing; that's unethical
as well.  The only way to reconcile this issue is to be able to run the
software yourself, in its entirety, server and all.

But we're not talking about SaaSS here (though we do have a criterion
for it).

> I agree that Javascript is problem and I mostly run with Javascript
> turned off.  But I am hardly any better off with an unminified ancient
> jQuery (or whatever) than with a minified hacked-up proprietary
> jQuery.

For JavaScript to be free, you need access to the corresponding source
code; minified code is, according to the GPL, object code.

> So we should not be /recommending/ sites which /require/ Javascript.

In general, I agree, though more so on pragmatic grounds.  If a "site",
however, is a "web app", then I consider that differently---I consider
it to be software, not a web page.

I discussed this with rms in the past: he said that, as long as a site
functions properly without JavaScript so that users don't have to run
proprietary JavaScript, then it's good enough
(paraphrasing).  Otherwise, we wouldn't be able to link to most web
pages.  Further, URLs are location identifiers, not content---the web
pages change.

Personally, I won't recommend a website to someone if it works poorly
with JavaScript disabled.

> 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).

> 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.

TBH, though, I agree.  We can ask rms about it.

> 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.

> If the site doesn't have the LibreJS labelling, no doubt the site
> operators would welcome patches to add it!

I hope so.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
https://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

signature.asc
Description: PGP signature