all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ian Eure <ian@retrospec.tv>
To: guix-devel@gnu.org
Subject: Re: Next Steps For the Software Heritage Problem
Date: Tue, 18 Jun 2024 07:19:26 -0700	[thread overview]
Message-ID: <8734pa5mlx.fsf@meson> (raw)
In-Reply-To: <20240618113717.4a6bad2b@fannys.me>

Hi MSavoritias,

Thank you for the email.

I’m going to lay out this situation as clearly as I can, in the 
hope that others will better understand, and hopefully treat it 
with the seriousness it deserves.

1. Guix requests SWH to archive some source code.  This is fine.

2. SWH archives the code.  This is also fine.

3. SWH gives all their source to an AI company, HuggingFace.  This 
is questionable.  While fine in theory, the company they gave it 
to, HuggingFace, violates both the licenses of the code they’re 
given, and SWH’s own policy on LLMs.  Instead of terminating the 
partnership, SWH has continued to tout it as "responsible AI" in 
the face of these violations[1].  This makes me doubt whether 
they’re acting in good faith.

4. HuggingFace trains a LLM out of all the code they’re given and 
redistributes it.  This is *not* fine.  The LLM is a derivative 
work of the source code it’s trained on, which violates the 
licenses of many projects in its training set -- it’s akin to 
compiling a gigantic .so file built from the SWH dataset.

5. HuggingFace uses its StarCoder2 LLM to generate source code. 
This is *also* not fine.  This output is also a derivative work of 
the inputs, and it’s redistributed with no license or attribution 
whatsoever.  HuggingFace purports to include attribution in their 
model, however, their own tools make no use of it and emit code 
with no attribution.  You can observe this behavior yourself: 
https://huggingface.co/spaces/HuggingFaceH4/starchat2-playground

I understand Guix’s participation is several degrees removed from 
where the core of the problem lies.  However, the partnership with 
SWH is indirectly enabling massive violations of the licenses of 
the software it packages.  Guix should stop doing that.

Thanks,

  — Ian

[1]: 
https://www.softwareheritage.org/2024/02/28/responsible-ai-with-starcoder2/

MSavoritias <email@msavoritias.me> writes:

> Hello,
>
> Context:
>
> As you may already know there have discussions around Software 
> Heritage
> and the LLM model they are collaborating with for a bit now. The 
> model
> itself was announced at
> https://www.softwareheritage.org/2023/10/19/swh-statement-on-llm-for-code/
>
> As I have started writing some packages I became interested in 
> how I
> might actually stop my code from ever reaching Software Heritage 
> or at
> the very least said LLM model. Every single package in guix is 
> added
> there automatically.
>
> I sent an email on Friday and I got an answer back that such 
> consent
> mechanism hasn't been implemented and I was shown the legal 
> terms.
> instead what I am supposed to do is:
>
> After guix has my code, my code will be automatically in 
> Software
> Heritage and the LLM model. So I am supposed to opt out 
> seperately with
> both of them to ensure that my code wont be used for future 
> versions.
> This of course means that my code will stay forever in Software
> Heritage and the LLM model (or some version of it at least).
>
> The reasoning that was given was that code harvesting happens 
> anyway
> and we give an opt-out. I am guessing its opt-out and not opt-in
> because they would have less code but this is speculation of 
> course :)
>
> This is against our desire to make it a welcoming space and also
> against the spirit of our CoC. Specifically because authors do 
> not know
> this happens when they submit packages to Guix. So it is all 
> done
> without consent.
>
> Next Steps:
>
> So what can we do as a Guix community from here?
> Communication/Writing wise:
>
> 1. Add a clear disclaimer/requirment that any new package that 
> is added
> in Guix, the person has to give consent or get consent from the 
> person
> that the package is written in. This needs to be added in the 
> docs and
> in the email procedures.
> 2. Make a blog post of our stance towards Software Heritage and 
> the
> code harvesting they are doing. This post will write in 
> environmental
> and ethical grounds why Guix is against this and mention 
> specifically
> Software Heritage. This is done to separate and mention that we 
> do not
> like what is happening in case anyone comes asking, and 
> hopefully give
> public pressure to Software Heritage.
> 3. Exclude all Software Heritage merch, stands, talks, people in
> official capacity, logos, or anything else that participates in 
> social
> events of guix and write it in some rules we have. also write in
> channel rules that Software Heritage is offtopic same way 
> Non-Free
> Software is offtopic.
> 4. There doesn't seem to be any movement on the side of Guix 
> towards:
> - Accountability in an official capacity of SH for the terrible
>   handling of the trans name incident and a plan to make it 
>   easier in
>   the future.
> - The LLM problem that was mentioned in this email.
> So with that said I urge anybody who has been in contact with 
> them in
> an official Guix capacity to come forward, otherwise I can 
> volunteer to
> be that. Idk if we have a community outreach thing I need to be 
> in also
> for that. (we should if not)
>
> The above make two assumptions:
> 1. That the Guix community is against LLM/"AI". Which for 
> environmental
> and ethical grounds we should be.
> 2. That we are a consent culture.
>
> Coding Wise this has been talked about before some potential 
> options
> are:
> - Communicate with Software Heritage to be able to give a "sign" 
> that
> the code that is sent should go or not in the code harvesting 
> project.
> - Remove all Software Heritage integration since its too hard to 
> be
>   ethical about it and built a better solution.
>
> Conclusion:
>
> To summarize from the steps I wrote above, it seems Software 
> Heritage
> makes it harder and harder for us to actually be an inclusive,
> welcoming space we want to be. Idk what that leaves us, as I 
> said I am
> not part of any "insider" discussions. But it seems to not move 
> that
> much and its time to start doing actionable things in another 
> direction.
>
> MSavoritias


  reply	other threads:[~2024-06-18 14:53 UTC|newest]

Thread overview: 70+ 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 [this message]
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
2024-06-22 19:53             ` Ricardo Wurmus
2024-06-24  7:55               ` MSavoritias
2024-06-24  9:13                 ` Ricardo Wurmus
  -- strict thread matches above, loose matches on Subject: below --
2024-06-18 17:12 Next Steps For the Software Heritage Problem Andy Tai
2024-06-18 18:08 ` Ian Eure
2024-06-19 10:31   ` raingloom
2024-06-27 12:27   ` Ludovic Courtès
2024-06-27 15:30     ` Ian Eure
2024-06-27 16:48       ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-27 16:58       ` Ludovic Courtès
2024-06-19  7:52 Simon Tournier
2024-06-19  9:13 ` MSavoritias
2024-06-19  9:54   ` Efraim Flashner
2024-06-19 10:25     ` raingloom
2024-06-19 15:46       ` Ekaitz Zarraga
2024-06-20  6:36         ` MSavoritias
2024-06-20 14:35           ` Ekaitz Zarraga
2024-06-21  8:51             ` MSavoritias
2024-06-19 10:34     ` MSavoritias
2024-06-19 14:41   ` Simon Tournier
2024-06-20  6:51     ` MSavoritias
2024-06-20 14:40       ` Simon Tournier
2024-06-21  9:08         ` MSavoritias
2024-06-28 18:01 Juliana Sims

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

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

  git send-email \
    --in-reply-to=8734pa5mlx.fsf@meson \
    --to=ian@retrospec.tv \
    --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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.