Re: [GNU-linux-libre] Proposal to revise FSDG to exclude SaaSS-only software clients

[Jean Louis]

Hello Andreas,

Alright, good that you give more insights, see my comments:

* Andreas Grapentin <andreas@grapentin.org> [2021-04-11 12:41]:
> 
> Hello,
> 
> Since this issue has been discussed extensively on the issue on the
> parabola tracker linked below in the original message, I think it is
> fair to present my view on the arguments below, since I was the one to
> close the issue on the tracker. Afterwards, I will retreat from this
> discussion, because I believe everything has been said, and saying more
> is a waste of everyones time.
> 
> Comments are inline below.
> 
> On Sun, Apr 11, 2021 at 11:55:17AM +0300, Jean Louis wrote:
> > ,----
> > | The freedom to run the program as you wish
> > | 
> > | The freedom to run the program means the freedom for any kind of
> > | person or organization to use it on any kind of computer system, for
> > | any kind of overall job and purpose, without being required to
> > | communicate about it with the developer or any other specific
> > | entity. In this freedom, it is the user's purpose that matters, not
> > | the developer's purpose; you as a user are free to run the program for
> > | your purposes, and if you distribute it to someone else, she is then
> > | free to run it for her purposes, but you are not entitled to impose
> > | your purposes on her.
> > `----
> > 
> > When software package such as Telegram Desktop is included in the FSF
> > free software distribution, there are factors to observe:
> > 
> > - Telegram Desktop communicates exclusively with SaaSS Telegram
> >   servers, there is vendor's lock in, and there exist no free server
> >   software that users can host it themselves and thus operated client
> >   software such as Telegram Desktop with their own self-hosted
> >   servers.
> 
> The claim that telegram servers provide SaaSS is dubious, as the section
> "Distinguishing SaaSS from Other Network Services" on
> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
> clearly states (emphasis mine):
> 
> > Rejecting SaaSS does not mean refusing to use any network servers run
> > by anyone other than you. Most servers are not SaaSS because the jobs
> > they do are some sort of *communication*, rather than the user's own
> > computing.

That is fine, but does relate in the context of Telegram proprietary
server and decision making of including packages into free system
distributions?

Telegram API terms are API, which means Application Programming
Interface -- this there is program that computes something and there
is client software that interacts with other program.

Most of software anyway handles communication, we cannot generalize
and just use "communication" as term for decision making, we have to
look into it practically by answering questions and looking into
ethical issues.

Telegram provides cloud based messages, which means storage of images,
files, text on their servers, provision of Telegraph helps users
publish images, thus it is service of publishing, Instant View is
service of collection of online articles for reading and this has
nothing to do with personal communication, identity management system
is a service that is not just a personal communication, polls are not
just personal communication.

> Other quotes from the same page:
> 
> > By contrast, if for fundamental reasons you couldn't possibly do that
> > activity in your own computers, then the activity isn't entirely your
> > own, so the issue of SaaSS is not applicable to that activity. In
> > general, these activities involve *communication with others*.
> 
> and:
> 
> > Most servers are not SaaSS because the jobs they do are some sort of
> > *communication*, rather than the user's own computing.
> 
> [end of quotes frcom gnu.org; original message continues below]

Almost all SaaSS do this or that communications, that is not the only
term that judges about the essence of the problem.

We need free software, right? It is the purpose of free software
distributions to give users freedom to run free software.

The essence of the SaaSS problem is described on that same page:

"The basic point is, you can have control over a program someone else
wrote (if it's free), but you can never have control over a service
someone else runs, so never use a service where in principle running a
program would do."

>From viewpoint of free system distribution to give freedom to users to
run free software, by providing software that interacts as client to
proprietary SaaSS whereby users do not have any option to run their
own server side software, we are giving control up to the vendor and
developers.

With XMPP, we do not give that control up, because we can host XMPP
ourselves.

> > - Telegram network is centralized, server software is proprietary, API
> >   terms are proprietary and represent "further restrictions" on the
> >   GPL3, which are we free to ignore; we may build "Telegram-like
> >   server", but nobody did that; however, by ignoring it legal threats
> >   or issues do not end by ignorance, and issue for FSF endorsed
> >   distribution is not ended there. Reference:
> >   https://core.telegram.org/api/terms where that API terms dictate
> >   limits on how client software cannot be changed; this impairs users'
> >   freedom, but we are are, due to GPL3, free to ignore such further
> >   restrictions.
> 
> The API terms pose restrictions on what clients can do as participants
> of the telegram network, wich does not unreasonably restrict the users
> freedom. Users are free to change software as they wish, but that does
> not mean that any modifications need to be welcome as participants in
> the network.

Well, if you would be Telegram representative, I would be calmed with
your statement, but I am not. Company is huge, they deal with millions
of dollars, and millions of users. They are smart as they invented a
client which is GPL3 -- but did no release server software, they made
it with sole purpose to enlarge users' base, not to provide true
fredom to people.

In other words, they have totally different purposes, way opposite to
purposes of developers of XMPP applications, Tox, Jitsy, or other
similar free chat and communication applications.

> There are no known instances of telegram as a company issuing 'legal
> threats' to forks or alternative client implementations for
> modifications they made to the client software.

Telegram is not transparent company. There need not be anything
public. 

> There are instances of them requesting changes to forked client
> software to ensure they are well-behaved participants in the
> network. This is perhaps a grey area worthy of further discussion.

It is just not directly related to the issue related to FSF endorsed
distributions, FSF statements and users' freedom we promote.

> There are of course better (as in: better privacy) chat clients than
> telegram, which are also packages by the free distributions. That does
> not necessitate the removal of telegram from the distribution by itself.
> A stronger reason is needed.

You see, I am worried, I do use Parabola, but now I use it exclusively
technically. My worry is that developers of Parabola do not value
privacy and decentralization.

Millions of records exposed on Darknet are not good enough reason for
package not to be considered dangerous for users?
https://latesthackingnews.com/2020/08/29/telegram-data-leak-exposes-millions-of-records-on-darknet/

This is such a common brush off:

> However, the company added that most of the records are outdated,
> with 84% of data entries collected before mid-2019. Furthermore, the
> majority of accounts in the database contain irrelevant
> information. Telegram also revealed that 70% of the exposed accounts
> were from Iran, while the remaining 30% belonged to users from
> Russia.

Something what every centralized company will try to diminish when it
happens. 

Since years I use XMPP, and I have never experienced any "database
leak" from XMPP. 

By the way, along researching telegram, I was researching other
communication software in Parabola, like retroshare, 

> > grep -i telegram blacklist.txt 
> > cutegram::hyperbola:1005:[nonprivacy] only useful with Telegram service
> > libqtelegram-ae::hyperbola:1006:[nonprivacy] only useful with Telegram 
> > service
> > telegram-qt::hyperbola:1007:[nonprivacy] only useful with Telegram service
> > telegramqml::hyperbola:1008:[nonprivacy] only useful with Telegram service
> > telepathy-morse::hyperbola:1009:[nonprivacy] only useful with Telegram 
> > service
> 
> As you can see here, hyperbola has removed these packages for privacy
> reasons. parabola could do that too, but that was not discussed in the
> original ticket on the parabola tracker. I have requested the original
> messenger to open a new issue for that, and we can do the same. But that
> would need a separate discussion.

I have already answered that, maybe you did not want to include my
comment on your issues, the tag like "nonprivacy" alone is one single
word, it may be wrong, and it cannot ever fully describe the issue at
hand. That is why we write, otherwise we would understand each other
by using only tags, like "nonprivacy" and you would answer with
"confirmed". That does not handle any issue at hand.

And you do not see that "nonprivacy" is related to "only useful with
Telegram service" -- where words "only useful" point to something else
but privacy, so it is obvious it is not just an issue related to
privacy. 

> > Other examples:
> [omitted for brevity]
> 
> > Thus my proposal is that FSF reviews these matters, and that free
> > system distributions adopt the principles of Hyperbola GNU/Linux-libre
> > developers, to look at the broader picture when deciding if software
> > should be included or not -- not only into the fact that it is
> > GPL/otherwise-freely licensed.
> > 
> > Few questions shall be raised when there are conflicting issues raised
> > in relation to GPL/otherwise-freely licensed client software:
> > 
> > Purpose of software
> > ====================
> > 
> > https://www.gnu.org/philosophy/free-sw.html
> > 
> > When including package, client software into free system distribution
> > endorsed by FSF, developers shall ask themselves: is the sole purpose
> > of this package to interact with proprietary SaaSS and thus promote
> > relationship to vendor and vendor's purposes? If YES, such package
> > should not be included.
> > 
> > Or does that software helps users to be free to build their own
> > network with free server side software that interacts with client
> > software?  Do we have a free server software that may be used with
> > this software? If YES, then package should be included.
> > 
> > Answer to these questions also solves the promotion of decentralized
> > networks and is aligned to FSF public statements.
> > 
> > Inclusion of client software into FSF endorsed free system
> > distributions that promote centralized vendor' politics, does not
> > conform to FSF public statements and campaigns on surveillance and
> > decentralizations.
> > 
> > Quote:
> > 
> > ,----
> > | The freedom to run the program as you wish
> > | 
> > | The freedom to run the program means the freedom for any kind of
> > | person or organization to use it on any kind of computer system, for
> > | any kind of overall job and purpose, without being required to
> > | communicate about it with the developer or any other specific
> > | entity. In this freedom, it is the user's purpose that matters, not
> > | the developer's purpose; you as a user are free to run the program for
> > | your purposes, and if you distribute it to someone else, she is then
> > | free to run it for her purposes, but you are not entitled to impose
> > | your purposes on her.
> > `----
> > 
> > Thus I am asking FSF and developers of free system distributions to
> > consider these issues, and EXCLUDE software clients that have the sole
> > purpose to serve proprietary SaaSS -- where there is no server
> > software that users may install themselves.
> 
> In summary, I believe the arguments presented here are disingenuous and
> seem to not be motivated by the stated reasons of software freedom and
> user freedom, and instead by a personal vendetta against the telegram
> company (referred to as 'vendor'). This mail reiterates claims that have
> been refuted several times on the original issue on the parabola
> tracker, and it is frankly rather tiring to have to explain multiple
> times what the term SaaSS really means, to someone who should know
> better.

What a nonsense. 

I have no vendetta (revenge) against the Telegram company. If I would,
I would approach them, not FSF and this mailing list. Me and you
personally, are different, you are prone to use centralized networks,
and I am not. I use Fediverse, like GNU Social, Pleroma, XMPP and I
promote decentralization.

This email on this mailing list is related only by its discussion to
Parabola issue, where participants may get more data. It is not
directly related to your inclusion of software, but in general to
expand the FSDG and have some principles or rules when we consider
inclusion of software.

If there are now hypothetically 1000 websites and companies that each
of them make their own software client, beyond any universal and free
protocol, would we then start including it?

Telegram is smart, they knew they will gain user base by providing
GPL3 clients without providing server software. Users of free software
in the essence do not get anything but a locked-in promotion of
vendor's purpose.

> The message also confuses issues of freedom with issues of privacy,
> confuses local computing and services, both of which make it needlessly
> convoluted and difficult do discuss, and presents hypothetical legal
> threats by the 'vendor' which do not exist, apparently to make a
> stronger case than it really has.

Issues are related, not confused. If you have some objective facts to
add to it, feel free.

> In my opinion, the conclusion can only be that there are no freedom
> issues that would necessitate the immediate removal of any telegram
> clients from the distribution. The claims of SaaSS are wrong, and the
> GPL is not violated in any way. There may be privacy issues, but those
> need to be discussed separately, in order to have any chance of settling
> this discussion in a productive and meaningful way.

Well the disagreement is there, you consider it is freedom issue only if
software is GPL/otherwise-freely licensed, and I don't.

I do not propose immediate removal, I propose review and expansion of
FSDG guidelines, discussion of the matter and conclusions. Your input
is appreciated, regardless if we have opposing views.

For Parabola I suggest making more promotion of software that is using
decentralized networks.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

Sign an open letter in support of Richard M. Stallman
https://rms-support-letter.github.io/