Re: [directory-discuss] Anti-features going forward

[Anonymous]

Adonay Felipe Nogueira said:

> since it's a GNU package, the best solution is to contact the
> project (GNU Radio) directly saying what is the issue.

That's been tried.  There was a discussion about CloudFlare in
#gnuradio on freenode a couple weeks ago.  It was a civil discussion
among users; none of gnuradio staff were present.  Some time after the
discussion had ended, a channel operator removed Tor proponents from
the channel.  Without warning.

Obviously GNU Radio management is quite hostile toward Tor users, and
deliberately so.  They know their website blocks Tor.  They are
evidentally certain and proud of their stance enough to be unwilling
to explain it.  Consequently the "nonfree documentation" banner is
unlikely to be shameful in their view.

I sense an undercurrent of packages labelled GNU being superior to the
rest in terms of freedom.  And perhaps that's generally true, but if
that's true then those holding GNU projects in high regard should be
embarrassed about GNU Radio.  GNU Radio damages the GNU brand.  From
where I sit, it appears the GNU label may actually be enabling GNU
Radio to get away with attacks on freedom, no?  It was excluded from
the "nonfree documentation" flag despite non-gnu CFd projects getting
flagged.

> Not enforcing some alert in the respective Free Software Directory
> entry.

Well it's not for me to say what the flagging process is (and
apparently there is no defined process). My interest is in the catalog
accurately showing a meaningful freedom appraisel.  I'd probably only
have issues if things get so bogged-down in process as to result in
users not seeing accurate and timely flags.

The most important consequence of the antifeature alerts is that users
can collectively appraise the degree of freedom offered by the various
tools.  Intentional or not, the users are the ultimate beneficiary,
not so much the project managers.

Suppose someone is trying to decide between tcpdump and wireshark.
It's important that users are informed about the wireshark freedom
pitfall so their decision can be informed.  Hiding the fact that
wireshark has jailed its documentation disservices users, as well as
competing projects.  E.g. the tcpdump project should be rewarded the
advantage of increased participation when wireshark downgrades user
freedoms.

> So, for those interested and most affected: Talk to GNU Radio
> project and ask them to do at least one of the following (for which
> you can also help doing if you wish):
> 
> (a) If their website is under CloudFlare's service, try convincing the
> project to request CloudFlare to allow users of proxies (those using Tor
> for example), and also to free/liberate their JavaScript, and for this
> last part you can contribute to an action item that already exists on
> LibrePlanet wiki, see:
> <https://libreplanet.org/wiki/Action_items/To_CloudFlare:_Free_your_JavaScript>.
> 
> (b) Move out from the service they're currently using.

For civil project managers that's a reasonable approach.  For GNU
Radio, that's a recipe for losing more freedom-- the freedom to speak
in the channel.

--
Please note this was sent anonymously, so my address will be unusable.
But I will check the list archives.