Re: [ELPA] new package: tramp-docker

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > This code is used to access files in Docker or Podman containers that are
>   > running on the same system as Emacs. It calls the Docker or Podman program
>   > to spawn a shell inside the container to communicate with. It is similar
>   > to the su or sudo Tramp methods, in that the connection to the "remote"
>   > system involves shared kernel resources (unless Docker or Podman itself
>   > eventually chooses to do something else).
>
> Thanks for explaining.  My overload is such that I just saw this today
> -- because I recalled I hadn't seen a reply and decided to search for it.
>
> Now I understand what this is does, and it will be a convenient
> feature.  But it raises a couple of possible moral issues.
>
> 1. Is the Docker program free software?  Is the Podman program free
> software?  If neither of them is free software, is this a feature that
> promotes running nonfree software on GNU?

Yes, both are free software.

> 2. Supposing that one of them is free software, and there is no
> problem of that kind, there's another problem that people have
> reported to me: in making a container, there is a risk of including
> nonfree programs and you can't easily tell if that has happened, let
> alone make sure it won't happen.  The container-making process tends
> to pull in dependencies without checking whether they are free.n

To my knowledge there is the danger of either having a build-time or a
run-time dependency on a non-free container, though looking through a
container index like (https://hub.docker.com/search?q=), it appears that
the overwhelming majority of popular software is free software, if only
because distribution is easier.

That being said, TRAMP+Docker is a popular combination for developing
software, so what people often just do is use a distribution image
(Ubuntu, Debian, Alpine) as the foundation and then instruct the
container to install all the software they need using the distributions
package manager, while building their own image.  Seems backwards to me,
but it appears to be popular.  There is a saying that Docker is the
final stage of the "works on my machine"-mentality, as what you are
ultimately doing is shipping your entire "own" machine.

> That is not a reason to refuse to support this access-into-containers
> feature, but we should take advantage of this feature and its
> documentation to inform people about that problem.

I was looking around but couldn't find anything.  The "best" I could
find was license checking tools that made sure there was no GPL software
in a container (to avoid virality), maybe that could be turned on its
head for our needs.

> 3. Distributing free programs in containers tends to be bad for
> the community's control over the program.  Because people
> don't build the program on the GNU/Linux distros they use,
> and don't package it for those distros.
>
> This too we should use the opportunity to warn people about.

I think this could be added to the commentary section.