all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Efraim Flashner <efraim@flashner.co.il>
To: MSavoritias <email@msavoritias.me>
Cc: Simon Tournier <zimon.toutoune@gmail.com>,
	Ian Eure <ian@retrospec.tv>,
	guix-devel@gnu.org
Subject: Re: Next Steps For the Software Heritage Problem
Date: Wed, 19 Jun 2024 12:54:30 +0300	[thread overview]
Message-ID: <ZnKq1iauEbgwBIAr@3900XT> (raw)
In-Reply-To: <20240619121338.71b5f340@fannys.me>

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

On Wed, Jun 19, 2024 at 12:13:38PM +0300, MSavoritias wrote:
> On Wed, 19 Jun 2024 09:52:36 +0200
> Simon Tournier <zimon.toutoune@gmail.com> wrote:
> 
> > Hi Ian, all,
> > 
> > On Tue, 18 Jun 2024 at 10:57, Ian Eure <ian@retrospec.tv> wrote:
> > 
> > > Guix is continuing to partner with SWH in spite of their continued 
> > > support of these violations.  
> > 
> > Quickly because I am in the middle of a busy day. :-)
> 
> Hey Simon,
> 
> > 
> > I think that LLM asks ethical and legal question that even FSF or EFF
> > or SFC does not provide clear answers.  (And that probably the level
> > where the discussion should happen.)  That’s not a light topic and we
> > should not rush in one definitive conclusion.
> > 
> > Thank you for the rise of the concern some weeks ago.  It appears to
> > me good that people had expressed their concerns.  And still does.
> > Although I am reading there or overthere an aggressive tone; useless.
> > 
> > Again, people behind SWH are long-term free software activists and be
> > sure that they do not take this concern lightly.  FYI, people of SWH
> > are in touch with some people from Guix to speak about all that.
> 
> That is a very good point actually and it is one I also raised in the
> email I sent. That we have been told there are some discussions but we
> haven't seen any results for over 6 months now. Hence me asking for
> anybody that has approached SH in an official Guix capacity to step
> forward. Otherwise as I said I can approach SH :)

The relationship between SWH and Hugging Face is (IMO) off-topic for the
Guix mailing lists.  I'm not surprised that the discussions are
happening elsewhere.

> > 
> > 1. Legal.
> > 
> > These license violations are your interpretation of the law and to my
> > knowledge nothing have been in Court, yet.
> > 
> > Today, it does not really matter if we (or I) share this opinion.
> > Because for now, it’s just an opinion.
> > 
> > However, no one is a lawyer here and drawing a clear line is not
> > simple.
> > 
> > Thus, FWIW, I would not jump in hard conclusions based on my own
> > opinion because today I am not confidant enough to emit a definitive
> > legal position.
> > 
> 
> That is fair, I agree that copyright wise and legal/state wise the
> answer is not clear at all. And I don't think anybody in this mailing
> list can decidely answer that as you said.
> 
> > 2. Ethical.
> > 
> > If we speak about ethical concerns, we need to be very cautious.  We
> > all share the same core of values about free software.  Then we all
> > do not bound these values to the same point.  Some of us extend them
> > to some topics, other restrict a bit.
> > 
> > Here the issue is that other values than the ones about free software
> > are dragged in the picture to emit a position.  That’s where we need
> > to be cautious because we need to embrace the diversity and do not
> > morally judge what is outside our free software project.
> > 
> > About SWH, FWIW, here is my moral reasoning; as you see, it is far to
> > be definitive.
> 
> I agree that we probably won't find any definitive answer if LLMs are
> bad or not. But that is also not the question posed here tho.
> 
> The question posed here was that *all* code that is sent from Guix to
> SH is automatically transfered without consent to be used in an LLM
> model. That is without said process being opt-in and without said
> process being transparent.

I am not a lawyer, nor do I play one on TV.

Transferring the code is (legally) fine, using the code is (legally)
fine, distributing the result is (I think) legally questionable.

If your concern is the code being transferred to the LLM owners, IMO
that's already covered by the license of the code itself. As for what
the LLM owners do with the code, (again I am not a lawyer) it should not
make a difference if SWH gives them the code, they download it from
Guix's infrastructure or get it straight from upstream. Redistributing
the source code is allowed.

> The second one could be solved by adding the disclaimer and making the
> changes to commit packages as a i said. It can also be done I was told
> by just stopping guix from uploading any new code to SH from any
> package. which I would also be in favor.
> The first one can be done with social pressure which is what the
> blogpost and the talking and potentially the not including SH into Guix
> go towards.
> 
> Whether LLMs are ethical or not has nothing to do with the question
> posted above. Although personally I would push for not including LLMs
> unless under strict criteria of environmental and ethical sourcing. but
> that can come at a later time.
> 
> I would also like SH to see why opt-in should be the default at the
> very least, and the process should be transparent to everybody putting
> code into SH. Archiving source code is a good cause. This is why
> I said to approach them in official Guix capacity :)

One of our packages, dbxfs, left Github a while ago and continued
development on a different forge. They adjusted their README to disallow
hosting of their code on Github. Based on this restriction we have
labeled later versions of the software as non-free and have not updated
the package. IMO saying that source code cannot be uploaded to SWH would
fall into the same category.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

  reply	other threads:[~2024-06-19  9:55 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19  7:52 Next Steps For the Software Heritage Problem Simon Tournier
2024-06-19  9:13 ` MSavoritias
2024-06-19  9:54   ` Efraim Flashner [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2024-06-28 18:01 Juliana Sims
2024-06-18 17:12 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-18  8:37 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-20 21:27         ` 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

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=ZnKq1iauEbgwBIAr@3900XT \
    --to=efraim@flashner.co.il \
    --cc=email@msavoritias.me \
    --cc=guix-devel@gnu.org \
    --cc=ian@retrospec.tv \
    --cc=zimon.toutoune@gmail.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 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.