repo-criteria-discuss
[Top][All Lists]
Advanced

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

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


From: Andrew Ferguson
Subject: Re: [Repo-criteria-discuss] Ethical hosting means Free Software hosting
Date: Fri, 3 Jun 2016 17:21:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

One thing that bothers me regarding the criteria is the inconsistency between this and the criteria for 'Fully Free Operating Systems'. With the repo criteria, GitLab is acceptable despite GitLab.com running on proprietary software and showing pages advertising the proprietary GitLab EE. With the operating system criteria, Debian is not endorsed because non-free is 'not thoroughly separated from the main Debian distribution' and 'the installer in some cases recommends these nonfree firmware files'. I feel that this inconsistency should be addressed.

On an unrelated note, GitHub recently updated their website to incorporate both the 'clone url' and the 'project zip download' under one menu, which requires non-free JS. The result of this is that you can no longer easily download zips of projects or clone them without running proprietary JS (the clone / download links are easily determined however, so it's not impossible, just more time consuming).

On 03/06/16 16:49, Aaron Wolf wrote:
On 06/03/2016 08:39 AM, Ian Jackson wrote:
I have a rather serious problem with the GNU Ethical Repository
Criteria.

The main one is that
   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.  Benjamin Mako Hill made the general point forcefully in
his excellent article "Free Software Needs Free Tools" in 2010:
   https://mako.cc/writing/hill-free_tools.html

For a comparison to what another project does: Debian does not run any
official services (including team-specific code hosting, bug tracking,
mailing lists, etc.), on non-free software.

Personally I would be tempted to argue that this criterion ought to be
bumped up to required-for-C.  (Although it's a bit odd that
"Acceptable hosting for a GNU package" and "Good enough to recommend"
are the way round they are.)  But I can see that with the greater
workflow diversity of the GNU packages, this may be impractical.

Certainly I think it should be bumped up to required-to-B.


Conversely, the focus on non-free JavaScript is quixotic.  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.

I understand where the original distinction between server-side code
and browser-side code comes from: the idea that _the user_ should not
be required to run non-free software, particularly on their computer.

In many contexts, particularly software packages and operating system
distributions, this distinction makes a lot of practical sense.  (And
is also a pragmatic response to the real boundaries in real deployed
systems.)

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


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.

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

If it were up to me I would demote the criterion C0, which relates to
nonfree Javascript, to required-for-B.  I would promote the criterion
A0 to required-for-B.  I would demote the LibreJS labelling criterion
(B0) to required-for-A.


The result would be that we would only recommend sites which were
actually Free Software.  But that any site which _is_ Free Software
could be recommended.

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


Thanks,
Ian.

FWIW, I agree 100% with everything you just wrote, Ian.

Unfortunately, GNU as a project, with RMS leading still, seems to have
decided that the free/libre status of services that make sense as
services (i.e. are not SaaSS strictly) is beyond the core scope of
things and is just a nice-to-have rather than essential. Still, maybe
people can be convinced that it deserves B level rather than A.

Regarding client-side JS, I have the sense that it *can* be kinda
powerful and not as strictly sandboxed in the browser as one might hope.
So, personally, I think whether the JS is freely-licensed or not is less
of an issue than whether it does objectionable things or not.

(Just speaking for myself as a volunteer here, one who participated in
this process)





reply via email to

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