emacs-devel
[Top][All Lists]
Advanced

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

Re: [ELPA] new package: tramp-docker


From: Payas Relekar
Subject: Re: [ELPA] new package: tramp-docker
Date: Tue, 18 Oct 2022 14:41:52 +0530
User-agent: mu4e 1.8.10; emacs 29.0.50

Richard Stallman <rms@gnu.org> writes:

>   > Docker is a platform that provides few services:
>   > 1. A uniform container format (Now separated into OCI standard)
>   > 2. A way to build and run these containers (docker daemon)
>   ...
>
>   > Out of these, #1 is already standardised and fully open.
>   > #2 is not exclusive to docker, and there are multiple ways to acheive
>   > this thanks to #1 being open.
>
> Sad to say, that doesn't mean that #2 is no problem for software
> freedom.  Rather, it means that some methods are a problem and others
> are not.

Correct. Please see below for more thoughts.

> I can't be certain with my current partial knowledge, but I think that
> the methods which are a problem are a very grave problem, and we need
> to speak to the community about avoiding them.  I think we need to
> identify any frequently used methods for building Docker containers
> that makes it easy to fail to think about whether the contents are free.

While I am still in doubt whether it is possible to ensure a container
can only be built using free software, similar to .deb packages, short
of not using anything beyond official repos, the discussion is valuable IMO.

>   > 3. A global (and optionally local) container registry (akin to apt-get)
>
>   > #3 is where things start getting fuzzy as docker the platform does not
>   > provide any way to ensure containers only include free software. That
>   > being said, as mentioned earlier, docker itself is not necessary to
>   > build these containers.
>
> I think this is a crucial part of the reason why some ways of
> building docker containers are a grave problem.  Would you disagree?

Partially agree. What we need to separate out is a mechanism to
build/package/deploy (e.g. dpkg, containers) from mechanism to
distribution (debian repos, docker repository).

To continue the debian analogy, it is already possible to package up
proprietory software via .deb file, in face, Google Chrome is
distributed exactly like this. That does not make apt or dpkg inherently
a problem does it? It doesn't classify GNU Make as harmful, and IMO same
rule should be applied to containers. Calling containers harmful means
we are communicating false information to potential users and this may
implore them to question the whole thing rather than just the
questionable parts.

>   > As such, the name docker only signifies what has become de-facto calling
>   > convention for OCI containers, but otherwise as long as we avoid linking
>   > to docker the service, we are in the clear.
>
> That seems plausible to me.
>
> emacs-devel is not the right place to have the discssion about building
> containers.  I should launch it in some other place or way.
>
> Do you know enough about containers to help in that discussion?

I wouldn't call myself an expert, but will be happy provide any
links/study on matter as needed.

--



reply via email to

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