Hi Ludovic,

Ludovic Courtès <[email protected]> writes:

> Hi Maxim,
>
> Maxim Cournoyer <[email protected]> skribis:
>
>> Similar to others, I dislike the "we'll tell you how to run your shop,
>> in the sake of saving humanity, nothing less" talking point.  It comes
>> off as awfully lordly to my ears, which is why I'd like to narrow it
>> down to just the useful, bare minimum parts.
>
> How would you phrase rules #1 and #2?

As I mentioned in my previous reply, I'd drop #1, as it tries to police
the behavior of people and the motivation framing (outside of the
pledge) transpires in labelling genAI as a whole as something nefarious,
which I find unnecessarily divisive, and #2 already defines better the
intent anyway (do not incorporate legally significant genAI outputs in
Guix, providing some guidance/examples about what is considered legally
significant).

It'd be nice if #2 added the rationale motivating this: "As of today,
the copyright or lack of copyright of genAI outputs is still being
clarified.  In light of this uncertainty, for the time being, the Guix
project asks that no legally significant genAI output be installed to
its source.", or similar.

>>> In fact, as it stands, fully vibe-coded software like Claude’s C
>>> Compiler cannot be considered free software; this will probably be
>>> clarified one way or another in the various jurisdictions, but that’s
>>> where we are today.

That's yet to be settled; the legal community consensus thus far appears
to be that purely machine-authored works cannot be copyrighted, which is
why some vibe-coded projects have started using a public-domain style
license like CC0.  We have cc0 in our list of licenses, so a cc0
vibe-coded package, per a snapshot of today's evolving legal landscape,
would be acceptable per our FSDG guidelines.

>> "cannot be considered free software" is preposterous, no?
>
> It’s a fact that the copyright situation of LLM output is unclear (see
> “Motivation”, which contains links to relevant documents).  If it
> contains parts of its input data verbatim, then that license applies; if
> it’s a translation from one language to another, then presumably the
> original license applies; in other cases, we don’t know.

My main worry is about the ambiguous message we'd send here: no to some
purely vibe-coded software, but yes to Python, Linux and other software
gradually installing more and more LLM-produced outputs.  If
LLM-produced output is to be considered non-free from the Guix project
stance, then there cannot be some half-measures: some bits of non-free
code in Python should mean Python is now non-free.  To make any other
rule muddies the stance; I prefer no stance to an unclear stance.

My suggestion is thus to let the gray area be gray for now, for
packages, and adjust accordingly if needed when the legal landscape
surrounding LLM becomes clearer, which is why I suggest dropping point
#3 of the pledge.

> Again, this will probably change in the future, but that’s where we are.
>
>> Which sources back such claims (that they cannot be considered free
>> software) ?
>
> I hope this is clear now.

I'm afraid to say, no, it is not.  I think the whole thing could be
better addressed by simply putting out a statement saying something
like:

   As a GNU package, and out of an abundance of caution, the Guix
   project is asking its contributors to not submit nor install
   significant changes produced with an LLM.  This is because of the
   lack of clarity surrounding the copyright of such artifacts.  For
   now, packages containing LLM outputs themselves are still accepted,
   but this is subject to change as the legal understanding evolves.

This sidesteps the whole "genAI is bad" stance dividing the community,
and focuses on the core part we can probably easily agree on (take
*reasonable* precautionary measures).

>> I'd also prefer not advertising these packages by avoiding mentioning
>> them by name or URL, which seems unnecessary to me.
>
> The goal of the examples was to materialize the line drawn between, say,
> Linux and Python (which may not be excluded under this “majority of the
> code” rule in the foreseeable future) and fully vibe-coded software.

I don't think it achieves the goal; it invites the question of why is the
distinction made between purely vibe-coded and partially vibe-coded
software.  Is it purely for convenience?

-- 
Thanks,
Maxim

Reply via email to