Re: ELPA submission: mathjax.el

Re: ELPA submission: mathjax.el

[Augusto Stoffel]

On Sat, 26 Oct 2024 at 01:46, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > A. If the build environment has Node/npm, all that is needed is to run
>   > make math2svg.js.
>
> node.js  is a collection of many Javascript programs, right?
> Are we sure that they are all free software?

Node.js is a JS runtime, so more than just a bunch of JS files.  It is
the kind of software that touts itself as open source rather than free
software, but effectively it is.  The license is MIT and it is included
in some (perhaps all) GNU/Linux distros listed at
https://www.gnu.org/distros/free-distros.html.

> npm poses a deeper problem.  I could be mistaken here, but ISTR that
> it contains lots of packages, some free and some not.  If you use
> module Foo, and it is free, to link in dependenceies from npm,
> checking whether those dependencies are free or not is manual labor.

You're right, one has to check they're not using non-free packages.  In
the case at hand, that makes it my (respectively the ELPA maintainers')
burden to check.

> If the situation is indeed like that, trying to use npm in the free
> world is asking to lose.  We shouldn't enable access to it for
> ourselves, let alone suggest that someone else do so!
>
> If the situation is different from that, maybe that makes our situation
> better, but could you please explain the actual situation with npm?
>
> Do you have a list of the modules that mathjax depends on?

Sure.  The direct dependencies of my package as listed in
math2svg/package.json and the transitive dependencies are listed in
math2svg/package-lock.json.

The number of dependencies is high, but one can also use a program that
summarizes the licenses:

    $ npx license-checker --summary
    ├─ MIT: 176
    ├─ ISC: 29
    ├─ BSD-2-Clause: 9
    ├─ Apache-2.0: 8
    ├─ BSD-3-Clause: 5
    ├─ CC-BY-4.0: 1
    ├─ (BSD-2-Clause OR MIT OR Apache-2.0): 1
    ├─ CC-BY-3.0: 1
    ├─ CC0-1.0: 1
    ├─ (MIT AND CC-BY-3.0): 1
    ├─ 0BSD: 1
    ├─ (MIT OR CC0-1.0): 1
    └─ MIT*: 1

>   > B. If the build environment can run containers, I can include a suitable
>   > Dockerfile.
>
> Container systems in general present the same kind of pitfalls as npm:
> they put lots of free modules and lots of nonfree modules into a
> bucket and making sure you don't pull out any of the nonfree ones is
> your problem.

That's correct.  But note that when your container declaration starts
with

  FROM docker.io/debian:stable

then you know you're just running on an isolated copy of Debian stable.
You have access to exactly the same nonfree software you could get in
the ELPA build system itself (which runs Debian stable).

> I've been told there are important differences between the well-known
> container systems in this regard, and I don't remember how Docker
> stacks up.  MAYBE if we consult a Docker expert we will find it can be
> used safely.  But we had better study this carefully.
>
> System distributions include binary packages to speed installation.
> We can surely package mathjax this way somehow or other.  But we must
> release sources with a build recipe too.  If we include mathjax
> somehoe in Emacs, or in GNU in any way, we _must_ include a way to
> build it from source.  That includes any special tools it needs.
>
> If the makefile to compile mathjax uses a container, it had better
> include the rules to build that container, manually specifying which
> modules to include in the container.  Somewhere there must be rules to
> rebuild THOSE modules from source.

I've just mentioned containers as a hypothetical technical solution,
it's not being considered seriously.

Re: ELPA submission: mathjax.el

[James Thomas]

Augusto Stoffel wrote:

>>   > B. If the build environment can run containers, I can include a
>>   > suitable Dockerfile.
>>
>> Container systems in general present the same kind of pitfalls as npm:
>> they put lots of free modules and lots of nonfree modules into a
>> bucket and making sure you don't pull out any of the nonfree ones is
>> your problem.
>
> That's correct.  But note that when your container declaration starts
> with
>
>   FROM docker.io/debian:stable
>
> then you know you're just running on an isolated copy of Debian stable.
> You have access to exactly the same nonfree software you could get in
> the ELPA build system itself (which runs Debian stable).
>
>> I've been told there are important differences between the well-known
>> container systems in this regard, and I don't remember how Docker
>> stacks up.  MAYBE if we consult a Docker expert we will find it can be
>> used safely.  But we had better study this carefully.
>>
>> System distributions include binary packages to speed installation.
>> We can surely package mathjax this way somehow or other.  But we must
>> release sources with a build recipe too.  If we include mathjax
>> somehoe in Emacs, or in GNU in any way, we _must_ include a way to
>> build it from source.  That includes any special tools it needs.
>>
>> If the makefile to compile mathjax uses a container, it had better
>> include the rules to build that container, manually specifying which
>> modules to include in the container.  Somewhere there must be rules to
>> rebuild THOSE modules from source.
>
> I've just mentioned containers as a hypothetical technical solution,
> it's not being considered seriously.

In any case, there seems to be a Guix package for it:

  https://packages.guix.gnu.org/packages/js-mathjax/

So it should be trivial to make a 'free' container out of.

--

ELPA submission: mathjax.el

[Augusto Stoffel]

I would like to add the package residing at the following location to
ELPA:

https://github.com/astoff/mathjax.el

There's no need to clarify the necessary header changes, but I would
like to add a technical comment: the package needs an external program
to be useful (Node) but otherwise bundles all other dependencies.

[paste Chico Buarque meme here]

More specifically, there's a 2.3 MB minified JavaScript file that is
committed to the repo and I will take care to update when the "real"
source (also in the repo, of course) changes.

Also, in case there are any JS experts around, I'd be happy to get hints
on how to make things work with other JS engines.  I have at least 3
others in my machine (2 browsers and Gnome's) but it's unclear to me if
they can be used for random purposes like this one.

Best,
Augusto

Re: ELPA submission: mathjax.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I would like to add the package residing at the following location to
  > ELPA:

  > https://github.com/astoff/mathjax.el

As I recall, mathjax does a useful job, but depends on a browser to
run special Javascript code.  It has been some years since I heard
about that -- is my memory right?  If not, could you explain how
things really work?

This raises an issue which is one of the biggest issues in computing
and freedom: how to give users control over the Javascript programs
that run in their browsers.

I have an idea for how perhaps to do that.  I don't know enough
about web browsers and Javascript to be sure whether it can work.
Could you please work with me to explore the possibility?

The first step is to think about how the Mathjax Javascript program
couples to and relates to the Emacs Lisp program.  Could you please
explain how that coupling works now?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ELPA submission: mathjax.el

[Augusto Stoffel]

On Wed, 16 Oct 2024 at 23:54, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I would like to add the package residing at the following location to
>   > ELPA:
>
>   > https://github.com/astoff/mathjax.el
>
> As I recall, mathjax does a useful job, but depends on a browser to
> run special Javascript code.  It has been some years since I heard
> about that -- is my memory right?  If not, could you explain how
> things really work?

If it was years ago then it was probably right at the time.  In the
meanwhile, however, standalone JS environments have appeared.
Apparently many people like JS and use it to develop regular programs.

MathJax is just a JS library and it can run in those standalone JS
interpreters to produce images from formulas (in TeX or MathML
notation).  So that's what my package does: it runs one of those
standalone JS interpreter and loads the MathJax library in it.

> This raises an issue which is one of the biggest issues in computing
> and freedom: how to give users control over the Javascript programs
> that run in their browsers.

Just to emphasize: MathJax as well as its JS dependencies and the
standalone JS interpreter are all free software.  So for my package this
is not an issue.

> I have an idea for how perhaps to do that.  I don't know enough
> about web browsers and Javascript to be sure whether it can work.
> Could you please work with me to explore the possibility?
>
> The first step is to think about how the Mathjax Javascript program
> couples to and relates to the Emacs Lisp program.  Could you please
> explain how that coupling works now?

The coupling is via good old pipes, with MathJax running as a subprocess
of Emacs (like a non-interactive Comint, basically).

Re: ELPA submission: mathjax.el

[Philip Kaludercic]

Augusto Stoffel <arstoffel@gmail.com> writes:

> I would like to add the package residing at the following location to
> ELPA:
>
> https://github.com/astoff/mathjax.el
>
> There's no need to clarify the necessary header changes, 

Sorry for the delay, I have added the package to ELPA, but as you know,
it won't be added until you update the Copyright line and add a
"Version" header.

>                                                          but I would
> like to add a technical comment: the package needs an external program
> to be useful (Node) but otherwise bundles all other dependencies.
>
> [paste Chico Buarque meme here]
>
> More specifically, there's a 2.3 MB minified JavaScript file that is
> committed to the repo and I will take care to update when the "real"
> source (also in the repo, of course) changes.

Is there any reason to choose the minified version?  Also, do you know
if you could support KaTeX as well?  AFAIK it is more lightweight
(though the package name might be confusing in that case).

> Also, in case there are any JS experts around, I'd be happy to get hints
> on how to make things work with other JS engines.  I have at least 3
> others in my machine (2 browsers and Gnome's) but it's unclear to me if
> they can be used for random purposes like this one.

I have tried QuickJS, but it didn't work either.  That being said, I am
not a JS expert so what I do I know :)

> Best,
> Augusto
>
>

-- 
	Philip Kaludercic on icterid

Re: ELPA submission: mathjax.el

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

>> More specifically, there's a 2.3 MB minified JavaScript file that is
>> committed to the repo and I will take care to update when the "real"
>> source (also in the repo, of course) changes.
>
> Is there any reason to choose the minified version?  Also, do you know
> if you could support KaTeX as well?  AFAIK it is more lightweight
> (though the package name might be confusing in that case).

I don't feel comfortable with distributing a 2.3 MB minified JavaScript
file, unless it is generated from source code either as part of the
package build process on GNU ELPA, or during the package installation on
users' machines.

Could we work on resolving that?

Re: ELPA submission: mathjax.el

[Augusto Stoffel]

On Wed, 23 Oct 2024 at 07:02, Stefan Kangas wrote:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> More specifically, there's a 2.3 MB minified JavaScript file that is
>>> committed to the repo and I will take care to update when the "real"
>>> source (also in the repo, of course) changes.
>>
>> Is there any reason to choose the minified version?  Also, do you know
>> if you could support KaTeX as well?  AFAIK it is more lightweight
>> (though the package name might be confusing in that case).
>
> I don't feel comfortable with distributing a 2.3 MB minified JavaScript
> file, unless it is generated from source code either as part of the
> package build process on GNU ELPA,

Ah sure, what you suggest is of course much better -- I didn't think
ELPA might be capable of building stuff.  Either of those would be
possible in my case:

A. If the build environment has Node/npm, all that is needed is to run
make math2svg.js.

B. If the build environment can run containers, I can include a suitable
Dockerfile.

> or during the package installation on users' machines.

This is not an option in my opinion.  It doesn't "just work", instead
requiring the user to execute a build step, and the download is 40 times
larger than the minified JS.

> Could we work on resolving that?

I'd be happy to.  If neither options A. or B. are currently available, I
would say implementing B. is a good approach in general for packages
that require a build step.

Re: ELPA submission: mathjax.el

[Philip Kaludercic]

Augusto Stoffel <arstoffel@gmail.com> writes:

> On Wed, 23 Oct 2024 at 07:02, Stefan Kangas wrote:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>> More specifically, there's a 2.3 MB minified JavaScript file that is
>>>> committed to the repo and I will take care to update when the "real"
>>>> source (also in the repo, of course) changes.
>>>
>>> Is there any reason to choose the minified version?  Also, do you know
>>> if you could support KaTeX as well?  AFAIK it is more lightweight
>>> (though the package name might be confusing in that case).
>>
>> I don't feel comfortable with distributing a 2.3 MB minified JavaScript
>> file, unless it is generated from source code either as part of the
>> package build process on GNU ELPA,
>
> Ah sure, what you suggest is of course much better -- I didn't think
> ELPA might be capable of building stuff.  Either of those would be
> possible in my case:
>
> A. If the build environment has Node/npm, all that is needed is to run
> make math2svg.js.

That could be arranged, but it wouldn't be a recent version of node.
But I'd like to double-check with Stefan Monnier (in the CC's) before
proceeding with this.

> B. If the build environment can run containers, I can include a suitable
> Dockerfile.
>
>> or during the package installation on users' machines.
>
> This is not an option in my opinion.  It doesn't "just work", instead
> requiring the user to execute a build step, and the download is 40 times
> larger than the minified JS.

Some systems[0] appear to have mathjax as a package they can install.
In their case, they could load the code they have installed locally.
But I agree that this would incur an annoyance for all other users.

[0] https://pkgs.org/download/mathjax

>> Could we work on resolving that?
>
> I'd be happy to.  If neither options A. or B. are currently available, I
> would say implementing B. is a good approach in general for packages
> that require a build step.

Augusto Stoffel <arstoffel@gmail.com> writes:

> On Wed, 23 Oct 2024 at 07:23, Philip Kaludercic wrote:
>
>> Also, do you know if you could support KaTeX as well?  AFAIK it is
>> more lightweight (though the package name might be confusing in that
>> case).
>
> I must confess I made the choice for mathjax out of sheer ignorance of
> KaTeX's existence.  Too bad I linked the package name with the backend
> library. :-)

If you want, it is not too late to rename the package to "shr-math" or
something like that.

>> I have tried QuickJS, but it didn't work either.  That being said, I am
>> not a JS expert so what I do I know :)
>
> Okay, this looks like an option if we wanted to turn the minified JS
> into a binary executable, but this would then be platform-dependent.  I
> guess it's not in the plans to make ELPA capable of distributing
> binaries... or is it?

No, it is not.  But QuickJS is also usable just as an interpreter.

-- 
	Philip Kaludercic on icterid

Re: ELPA submission: mathjax.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We seem to be talking abopt lots of potential dependencies.  And they
are not limited to C programs and Lisp programs such as Emacs already
includes.  Some of them mey involve practices that raise moral issues.
Or maybe not -- but we don't have enough information here to see
what issues are they might be.

So we must not think of this as a technical problem.  We need a
solution that (1) works _well enough_ and (2) clearly upholds software
freedom.  The solution that is most convenient may or may not be best.

That includes issues raised by ppossible dependencies of dependencies.

then we can study the issues and verify that they don't raise any
moral issues, or find solutions for those.

When we choose a solution, we will need to verify that all the
components are free software.  The way to do that is by testing the
build procedure in an environment where we _know_ we do not have
anything nonfree installed.  If it works there, we can consider
the job done unless/until somsone reports a problem.

In principle, let's consider the idea of treating the mathjax binary
the same way we treat other compiled prackages.  Is that possible?
What would we need to include in the Emacs sources?

The mathjax Javascript program can be packaged separately from Emacs.
We have an Emacs package for using TeX but we don't include TeX in any
Emacs package -- users install that separately.  Is there a reason not to
treat mathjax the same way?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ELPA submission: mathjax.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We started to talk about setting up mathjax as a browser extension
for users to load.  what would be involed in actually doing this?
Could we make one extension serve for various browsers?

Could we arrange to tell web pages that try to send the mathjax JS code
that they don't need to do so?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ELPA submission: mathjax.el

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A. If the build environment has Node/npm, all that is needed is to run
  > make math2svg.js.

node.js  is a collection of many Javascript programs, right?
Are we sure that they are all free software?

npm poses a deeper problem.  I could be mistaken here, but ISTR that
it contains lots of packages, some free and some not.  If you use
module Foo, and it is free, to link in dependenceies from npm,
checking whether those dependencies are free or not is manual labor.

If the situation is indeed like that, trying to use npm in the free
world is asking to lose.  We shouldn't enable access to it for
ourselves, let alone suggest that someone else do so!

If the situation is different from that, maybe that makes our situation
better, but could you please explain the actual situation with npm?

Do you have a list of the modules that mathjax depends on?

  > B. If the build environment can run containers, I can include a suitable
  > Dockerfile.

Container systems in general present the same kind of pitfalls as npm:
they put lots of free modules and lots of nonfree modules into a
bucket and making sure you don't pull out any of the nonfree ones is
your problem.

I've been told there are important differences between the well-known
container systems in this regard, and I don't remember how Docker
stacks up.  MAYBE if we consult a Docker expert we will find it can be
used safely.  But we had better study this carefully.

System distributions include binary packages to speed installation.
We can surely package mathjax this way somehow or other.  But we must
release sources with a build recipe too.  If we include mathjax
somehoe in Emacs, or in GNU in any way, we _must_ include a way to
build it from source.  That includes any special tools it needs.

If the makefile to compile mathjax uses a container, it had better
include the rules to build that container, manually specifying which
modules to include in the container.  Somewhere there must be rules to
rebuild THOSE modules from source.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ELPA submission: mathjax.el

[Augusto Stoffel]

On Wed, 23 Oct 2024 at 07:23, Philip Kaludercic wrote:

> Also, do you know if you could support KaTeX as well?  AFAIK it is
> more lightweight (though the package name might be confusing in that
> case).

I must confess I made the choice for mathjax out of sheer ignorance of
KaTeX's existence.  Too bad I linked the package name with the backend
library. :-)

> I have tried QuickJS, but it didn't work either.  That being said, I am
> not a JS expert so what I do I know :)

Okay, this looks like an option if we wanted to turn the minified JS
into a binary executable, but this would then be platform-dependent.  I
guess it's not in the plans to make ELPA capable of distributing
binaries... or is it?