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.