unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: MSavoritias <email@msavoritias.me>
To: Richard Sent <richard@freakingpenguin.com>
Cc: Andreas Enge <andreas@enge.fr>, guix-devel@gnu.org
Subject: Re: About SWH, let avoid the wrong discussion
Date: Sat, 22 Jun 2024 17:42:42 +0300	[thread overview]
Message-ID: <20240622174242.7e1a18d5@fannys.me> (raw)
In-Reply-To: <87zfrdazzn.fsf@freakingpenguin.com>

On Sat, 22 Jun 2024 09:06:20 -0400
Richard Sent <richard@freakingpenguin.com> wrote:

> 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.

Thank you for proving my point :)
That what "limits freedom" is very subjective that is. You have your opinion other people have yours. 
GPL has been called bad for restricting freedom after all if you dont know.


> > 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.

Does you ethics not include privacy and consent? Because mine do.
see -> https://www.consentfultech.io

> >>    `-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."

Let me put this more clear Richard, the statement above that archiving should be off by default means:

- Guix respects the consent of the person using guix lint and their expectations. (that lint actually lints)
- Respects their privacy
- Respects their autonomy.

Now if you want to disagree that people should have privacy or expectations then I fear we are becoming the next Google.
Personally I do not want Guix to become the next google but I instead want to respect privacy, autonomy and consent.
If you do not believe in these then I fear we have a fundamental disagreement here.

Regards,
MSavoritias


  reply	other threads:[~2024-06-22 14:44 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
2024-06-22 14:42           ` MSavoritias [this message]
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=20240622174242.7e1a18d5@fannys.me \
    --to=email@msavoritias.me \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=richard@freakingpenguin.com \
    /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).