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: Philip Kaludercic
Subject: Re: [ELPA] new package: tramp-docker
Date: Sun, 16 Oct 2022 13:33:37 +0000

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. ]]]
>
>   >   But you also don't need to
>   > use the site itself, the "docker"/"podman" commands take care of
>   > fetching everything you need, just like "apt-get" would.
>
> apt-get fetches lists of packages from a web site, and then fetched
> the packages themselves from it too.  Is that what the `docker' and
> `podman' commands do?  It looks that way.  If so, then running them
> is a way of using the respective sites, not an alternative to doing so.
>
> Accessing the site that way has an advantage: if `docker' and `podman'
> are free programs, and assuming they don't silently run any software
> fetched from the site, this avoids the danger that browsing the site
> would run nonfree JS code.

This is my understanding as well, albeit as someone who has never taken
the time to take a look at the internal details of how this is
implemented.

> So far, so much the better.  But that leaves this problem:
>
>   > > 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?
>
>   > Without an index that would only host free software, I don't see how
>   > this would currently be possible.
>
> That's what I expected.  Alas, the natural consequence is that
> building containers implies a risk of including nonfree software.  The
> more packages, the more risk.
>
> As long as that is the case, we should warn people off of distributing
> containers.
>
> GNU Emacs is not the place to publish that general point, but where we
> mention support for containers, let's include this.
>
>   Containers pose problems for software freedom.  If you are careful,
>   you can make and then use a container with only free packages.  But
>   when you make a container with more than a few packages, there is
>   nothing to help you make sure each and every one is free/libre, and
>   no easy way to verify this for an existing container.  We recommend
>   staying away from containers made by others unless they explicitly
>   commit to carefully ensure the whole contents are free/libre.

I think this sounds good.



reply via email to

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