unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Payas Relekar <relekarpayas@gmail.com>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: [ELPA] new package: tramp-docker
Date: Tue, 18 Oct 2022 14:41:52 +0530	[thread overview]
Message-ID: <87a65tsd2q.fsf@gmail.com> (raw)
In-Reply-To: <E1oklMc-0003Mn-7c@fencepost.gnu.org>


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	other threads:[~2022-10-18  9:11 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-16  4:46 [ELPA] new package: tramp-docker Payas Relekar
2022-10-18 12:06 ` Richard Stallman
2022-10-18  9:11   ` Payas Relekar [this message]
2022-10-20 19:45     ` Richard Stallman
2022-10-21 11:35       ` Payas Relekar
     [not found] <bf072225-5933-aef0-6fed-4da031311766@spork.org>
2022-10-03 13:45 ` Brian Cully via Emacs development discussions.
2022-10-03 17:52   ` Michael Albinus
  -- strict thread matches above, loose matches on Subject: below --
2022-09-23 15:58 Brian Cully via Emacs development discussions.
2022-09-23 16:19 ` Philip Kaludercic
2022-09-23 17:47 ` Michael Albinus
     [not found]   ` <63d5f29a-05ed-f8c5-796c-a6eb9e28d575@spork.org>
2022-09-23 18:00     ` Michael Albinus
2022-09-23 18:09       ` Michael Albinus
2022-09-24 10:34         ` Michael Albinus
     [not found]           ` <44bd6537-316c-acc7-a4d6-6123bc32e2c0@spork.org>
2022-09-24 16:56             ` Michael Albinus
2022-09-24 17:31               ` Brian Cully via Emacs development discussions.
2022-09-24  2:44 ` Richard Stallman
2022-09-24  5:53   ` Robin Tarsiger
2022-09-24 10:45     ` Michael Albinus
2022-10-06 22:03     ` Richard Stallman
2022-10-07  7:35       ` Philip Kaludercic
2022-10-08 22:34         ` Richard Stallman
2022-10-09 11:54           ` Philip Kaludercic
2022-10-15 20:43             ` Richard Stallman
2022-10-15 20:43             ` Richard Stallman
2022-10-16 13:33               ` Philip Kaludercic
2022-10-17 12:30               ` zimoun
2022-10-19 17:02                 ` Richard Stallman
2022-10-20  8:18                   ` zimoun
2022-10-22 20:03                     ` Richard Stallman
2022-10-15 20:43             ` Richard Stallman
2022-10-10 13:55           ` Brian Cully via Emacs development discussions.
2022-10-10 17:46           ` zimoun
2022-10-03 13:03 ` Philippe Vaucher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a65tsd2q.fsf@gmail.com \
    --to=relekarpayas@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).