Re: Why is it acceptable to have digital-ocean-configuration in the Guix?

[Tomas Volf <~@wolfsden.cz>]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

On 2024-01-04 14:22:48 -0500, Thompson, David wrote:
> On Thu, Jan 4, 2024 at 5:34 AM Tomas Volf <~@wolfsden.cz> wrote:
> >
> > Greetings,
> >
> > I would like to inquire regarding digital-ocean-configuration type used for
> > provisioning DigitalOcean Droplets.  I do not understand why it is acceptable to
> > have this type in the source code.  Reading the Free GNU/Linux distributions
> > criteria[0] I see this sentence (emphasis mine):
> >
> > > This means they will include, and *propose*, exclusively free software.
> >
> > As far as I know DigitalOcean Droplets are not free software (please correct me
> > if I am wrong).  I contemplated on this for a bit, and I do not understand why
> > it is acceptable.
> >
> > Would someone be so kind to explain the reason to me?
>
> Perhaps this will help explain why you can't simply call a web service
> nonfree: https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.en.html

Ah, thank you very much for the link.  Interesting reading.

One consequence I did not (until now) realize is that I could (in theory)
implement a Free GNU/Linux distribution that would be tied into various APIs of
(for example) AWS and require it to run.  And, based on my reading, it would
still qualify to be on the list.  That is unexpected.

>
> To use a different example: Google doesn't publish the source code for
> YouTube. Guix includes the free software yt-dlp program that can talk
> to YouTube and download videos. Would you consider this a violation of
> the FSDG?
>
> Guix also downloads a lot of source code from GitHub. Is this an issue?

I did not consider these examples, because it did not even occur to me that it
*could* be an issue.  I guess the perceived difference came from the Droplets
having their own dedicated place in the manual including their own type.

My takeaway from this is that when I get around to implementing this for AWS
and/or Azure, I can submit the patch.

Thank you again and have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]