unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Sent <richard@freakingpenguin.com>
To: MSavoritias <email@msavoritias.me>
Cc: Andreas Enge <andreas@enge.fr>,  guix-devel@gnu.org
Subject: Re: About SWH, let avoid the wrong discussion
Date: Sat, 22 Jun 2024 09:06:20 -0400	[thread overview]
Message-ID: <87zfrdazzn.fsf@freakingpenguin.com> (raw)
In-Reply-To: <20240621134439.5bc324b4@fannys.me> (MSavoritias's message of "Fri, 21 Jun 2024 13:44:39 +0300")

Hi MSavoritias,

MSavoritias <email@msavoritias.me> writes:

>> Well, the opt-in model is in place: As soon as I put my code under a free
>> license on the Internet, I opt in for it to be harvested by SWH (and anybody
>> else, including non-friendly companies and state actors).
> That may be how you have understood it but that is not how most people
> understand it. See for example mirroring videos that creators have
> made online, or more recently some activitypub software harvesting
> posts for a search engine.
>
> As I have been saying a lot in this thread (because there seem to be a
> lot of people in the Guix community not familiar that legal are not
> the same as social rules):

I feel the need to jump in here because that first paragraph, to me,
implies that the silent members of the community agree with you. I do
not.

Mirroring/archiving code released under a free license is different then
copying videos or posts that were not licensed. The two are so different
that opposition to the latter can't be compared to opposition to the
former. And yes, I do mean from a ethical perspective. These are wildly
different issues.

> Saying that I can do whatever I want is a very reductionist point of
> view that I doubt would be acceptable inside Guix and FSF even. Given
> that GPL itself doesn't allow you to do whatever you want.

Restrictions for the purpose of maximizing freedom are different then
restrictions for the purpose of limiting freedom.

> Again as I wrote above legal has nothing to do with it really. Its
> about our social rules and what we have as common understanding in
> Guix.

To some people (myself included), ensuring software is and remains free
IS an ethical rule (along with the contents of Guix's Contributor
Covenant of course). I do not believe any rules in said code of conduct
are being violated here.

>>    `-x archival` does it, but it is too easy to forget and once the cat is out
>> of the bag privacy is lost.  I really think this should be default behaviour, 
>> or
>> at least there should be a flag in the package definition.  I would still be
>> uncomfortable with the last option, as everyone would be relying on the
>> collective of Guix maintainers to not screw up and accidentally leak private
>> data.
>>
>> Dale
> Yeah very much agree this should be the default behavior. Archiving
> should be opt-in to avoid any surprises for the person running it. I
> am surprised it became default actually.

It is not my responsibility to ensure publicly available code released
under a FOSS license is not archived. It is the developers
responsibility to not release it under a FOSS license. (Perhaps nonfree
private channels would benefit from a change in the default behavior but
Guix should not tailor its defaults around such a use case.)

I am opposed to any theoretical change in Guix's packaging policy that
restricts software freedom. This would include a system that allows for
marking individual packages as "do not upload to software heritage".

To clarify. I am specifically opposed to a change in official Guix
packages that allows for this statement:

"Do not upload automatically to software heritage, and no one else can
either."

I have no objection to disabling archival for technical reasons. And of
course, 3rd party channels are free to do whatever they want.

As Felix said:

> The new field looks to me like an amendment of the license terms,
> especially if the field was added by the author pursuant to the
> objections raised in this thread. I would rather not pollute my
> systems with potentially unfree software.

Nonfree software does not belong in Guix proper.

I believe [1] is a relevant piece on this topic. It discusses some of
the issues with adding additional restrictions to a GPL license. Here's
a choice quote from the GPL:

> All other non-permissive additional terms are considered "further
> restrictions" within the meaning of section 10. If the Program as you
> received it, or any part of it, contains a notice stating that it is
> governed by this License along with a term that is a further
> restriction, you may remove that term.

And the rationale:

> Here we were particularly concerned to address the problem of program
> authors who purport to license their works in a misleading and
> possibly self-contradictory fashion, using the GPL together with
> unacceptable added restrictions that would make those works non-free
> software.

[1]: https://www.fsf.org/blogs/licensing/protecting-free-software-against-confusing-additional-restrictions

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.


  parent reply	other threads:[~2024-06-22 13:07 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-18  8:37 Next Steps For the Software Heritage Problem MSavoritias
2024-06-18 14:19 ` Ian Eure
2024-06-19  8:36   ` Dale Mellor
2024-06-20 17:00     ` Andreas Enge
2024-06-20 18:42       ` Dale Mellor
2024-06-20 20:54         ` Andreas Enge
2024-06-20 20:59           ` Ekaitz Zarraga
2024-06-20 21:12             ` Andreas Enge
2024-06-21  8:41             ` Dale Mellor
2024-06-21  9:19               ` MSavoritias
2024-06-21 13:33                 ` Luis Felipe
2024-06-21 17:51               ` Exclude checker with package properties [draft PATCH] Simon Tournier
2024-06-21 18:37                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-21 18:44                   ` Simon Tournier
2024-06-21 18:42                 ` Simon Tournier
2024-06-22 15:54                 ` Draft: dry-run + Exclude checker with package properties Simon Tournier
2024-06-20 21:27         ` Next Steps For the Software Heritage Problem Simon Tournier
2024-06-18 16:21 ` Greg Hogan
2024-06-18 16:33   ` MSavoritias
2024-06-18 17:31     ` Greg Hogan
2024-06-18 17:57       ` Ian Eure
2024-06-19  7:01       ` MSavoritias
2024-06-19  9:57         ` Efraim Flashner
2024-06-20  2:56         ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-20  5:18           ` MSavoritias
2024-06-19 10:10 ` Efraim Flashner
2024-06-21  8:39 ` About SWH, let avoid the wrong discussion Simon Tournier
2024-06-21  9:12   ` MSavoritias
2024-06-21  9:46     ` Andreas Enge
2024-06-21 10:44       ` MSavoritias
2024-06-21 13:45         ` Luis Felipe
2024-06-21 14:15           ` MSavoritias
2024-06-21 16:33             ` Luis Felipe
2024-06-21 17:04               ` Msavoritias
2024-06-21 16:34             ` Liliana Marie Prikler
2024-06-21 16:51         ` Vagrant Cascadian
2024-06-21 17:22           ` MSavoritias
2024-06-21 20:51             ` Vagrant Cascadian
2024-06-22 15:46               ` MSavoritias
2024-06-22 17:55                 ` Breath, let take a short break :-) Simon Tournier
2024-06-24  7:30                   ` MSavoritias
2024-06-24 10:23                     ` Tomas Volf
2024-06-24 11:56                     ` Lets cut this off Efraim Flashner
2024-06-21 17:25           ` About SWH, let avoid the wrong discussion Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-22 13:06         ` Richard Sent [this message]
2024-06-22 14:42           ` MSavoritias
2024-06-22 19:53             ` Ricardo Wurmus
2024-06-24  7:55               ` MSavoritias
2024-06-24  9:13                 ` Ricardo Wurmus

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://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87zfrdazzn.fsf@freakingpenguin.com \
    --to=richard@freakingpenguin.com \
    --cc=andreas@enge.fr \
    --cc=email@msavoritias.me \
    --cc=guix-devel@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/guix.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).