Re: [ELPA] new package: tramp-docker

[Brian Cully via "Emacs development discussions." <emacs-devel@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

>   > To my knowledge there is the danger of either having a build-time or a
>   > run-time dependency on a non-free container,
>
> That's what was reported to me.
>
> Does Docker provide an easy way to verify that you have avoided such
> dependencies?  A way to make sure to avoid including them?

No it does not, but I do not regard Docker or its ilk as special
here. They provide a framework for running an operating
system. *Inspecting* that operating system is just as out-of-scope for
those projects as it would be for Qemu.

> Is that the _only_ way to develop a container?  Is it possible,
> practically speaking, to build a container without using that site at all?

There are a host of ways of building containers, and there are open
specifications for how to do so (see the Open Container Initiative),
which are all APL-2.0 licensed, to my knowledge.

Additionally, GNU's own Guix project provides a way to create Docker
containers for Guix, from the ground up.

> Alas, that does not by itself ensure that, supposing you build a container,
> you won't consider including nonfree programs.
>
> Is there an easy way you can ensure that _all_ the programs you put
> into a new container are free?  Is there an easy way to verify that
> the contents of a container are free?

Is there an easy way to do that on any given operating system? If so,
then yes, there is a way, and it is the same tool. If there is no such
tool, that's not a Docker problem, and such a tool should be created, at
which point it will be applicable to containers or other virtualization
technologies. Because the entire aim of these technologies is to present
an interface that looks very close to a physical machine (within some
limitations).

>   > > 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.
>
> Maybe so, but when you say "the commentary section", could you
> be more precise?  The commentary section of what documentation?

Personally, I don't think adding these notes to the “Commentary” section
is appropriate, any more than it would be appropriate to add it to the
SSH support. I see no difference, in the abstract, end-user sense,
between accessing a remote server via SSH or Docker. They accomplish the
same goal, with the same drawbacks, in broadly similar ways.

-bjc