[Top][All Lists]

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

Re: contributing to Emacs

From: Dr. Arne Babenhauserheide
Subject: Re: contributing to Emacs
Date: Mon, 03 Jul 2023 06:25:51 +0200
User-agent: mu4e 1.10.3; emacs 29.0.90

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Richard Stallman <rms@gnu.org> writes:

>>   > One problem with Hyperkitty is that it requires javascript to display
>>   > any message, which is makes it kind of useless in non-js browsers like
>>   > eww and lynx.
>> Features that require Javascript are totallky unacceptable if the JS
>> code is nonfree (see https://gnu.org/philosophy/javascript-trap.html)
>> and problematical even if the JS code is free
>> (see https://gnu.org/philosophy/wwworst-app-store.html).
> Why do you assume JavaScript = nonfree? Mailman3-Hyperkitty is free software.

If he had assumed that, the second part of the sentence (problematic
even if free) would not make sense.

⇒ just quoting policy, not implying something about hyperkitty.

>> We should avoid web features that send JS code, whenever possible.
>> Sending code to run immediately in the user's computer, in a way that
> Besides avoiding JavaScript in modern web is impossible in 99% of the
> cases besides for websites that load all of their content synchronously
> on the initial load of the page.

While this is true in this very precise wording, the large majority of
websites that use Javascript can be implemented such that all of their
content is loaded on initial page load — including interactivity that
can be provided via CSS and standard form-validation.

The advantage of using that approach is that it usually degrades more
gracefully when using simpler frontends like lynx or ewww — I’ve been
limited to a text terminal quite a few times already while trying to
find answers to a problem and being able to read bug reports from a
browser that does not support JS is very useful for that.

(that said: if JS is used for progressive enhancement and the site is
 usable without JS, this just uses more of the capabilities of powerful
 clients without locking out those in simpler browsers
 https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement )

>> gives the user community no feasible opportunity to study the code and
>> release modified versions that people have a real option to use,
>> undermines the freedom of free software.
> You can't modify code of content that is loaded of from other computers,
> the entity that hosts a web application such as Hyperkitty is in control
> which JavaScript is shipped.
> In such a case GPL isn't enuogh as you don't have to release modified
> versions of the app, AGPL is required. 

This has also been discussed a lot already and is addressed in a third

«In this case, we call it Service as a Software Substitute, or SaaSS (we
coined that to be less vague and general than “Software as a Service”),
and such a service is always a bad thing. … However, most services'
principal functions are communicating or publishing information; they
are nothing like running any program yourself, so they are not SaaSS.
They could not be replaced by your copy of a program, either; a program
running in your own computers, used solely by you and isolated from
others, is not communicating with anyone else.»

@RMS: this article is not linked in
      but it appears that it would be useful to link it there, maybe
      in the sentence “We are addressing the server issue separately.”

Best wishes,
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.

Attachment: signature.asc
Description: PGP signature

reply via email to

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