Re: Implementation of AI policy listed in code provenance

[Markus Armbruster <armbru@redhat.com>]

Tyler Vo <vo068@csusm.edu> writes:

> To whom it may concern,
>
> My name is Tyler Vo, a master's student at California State
> University, San Marcos. As part of my thesis, I am researching the
> effects of AI/LLM usage on open-source software on
> racial/social/gender bias. I came across the Qemu project as I was
> trying to find an open-source repository that rejects AI-generated
> contributions.

Thanks for your interest.

Another one is Zig.  I think you should read Loris Cro's "Contributor
Poker and Zig's AI Ban":
https://kristoff.it/blog/contributor-poker-and-ai/

>                However, although the code provenance section of the
> documentation does state that AI-generated content is not allowed in
> contributions to Qemu, I would like to know how AI-generated content
> is detected in pull requests and the like.

I participated in the discussions around QEMU's AI policy.  I'll try to
answer your question based on that.  All quotations are from
docs/devel/code-provenance.rst.

Let's start with the general provenance rule:

    The QEMU community **mandates** all contributors to certify provenance of
    patch submissions they make to the project. To put it another way,
    contributors must indicate that they are legally permitted to contribute to
    the project.

    Certification is achieved with a low overhead by adding a single line to the
    bottom of every git commit::

       Signed-off-by: YOUR NAME <YOUR@EMAIL>

    The addition of this line asserts that the author of the patch is contributing
    in accordance with the clauses specified in the
    `Developer's Certificate of Origin <https://developercertificate.org>`__:

    .. _dco:

      Developer's Certificate of Origin 1.1

      By making a contribution to this project, I certify that:

      (a) The contribution was created in whole or in part by me and I
          have the right to submit it under the open source license
          indicated in the file; or

      (b) The contribution is based upon previous work that, to the best
          of my knowledge, is covered under an appropriate open source
          license and I have the right under that license to submit that
          work with modifications, whether created in whole or in part
          by me, under the same open source license (unless I am
          permitted to submit under a different license), as indicated
          in the file; or

      (c) The contribution was provided directly to me by some other
          person who certified (a), (b) or (c) and I have not modified
          it.

      (d) I understand and agree that this project and the contribution
          are public and that a record of the contribution (including all
          personal information I submit with it, including my sign-off) is
          maintained indefinitely and may be redistributed consistent with
          this project or the open source license(s) involved.

How do we detect violations of this rule?  There are two kinds:

1. People fail to provide a Signed-off-by line.

   We require everyone involved in making and merging the patch to
   provide one.  We reject contributions that lack required sign-offs.

2. People provide a Signed-off-by line without actually complying with
   (a) to (d).

   We trust people not to lie to us, and to exercise appropriate care.

   Note that lying / carelessness about such things can have unpleasant
   legal consequences for the liar / careless person.

Now consider AI generated content:

    The QEMU community requires that contributors certify their patch submissions
    are made in accordance with the rules of the `Developer's Certificate of
    Origin (DCO) <dco>`.

    To satisfy the DCO, the patch contributor has to fully understand the
    copyright and license status of content they are contributing to QEMU. With AI
    content generators, the copyright and license status of the output is
    ill-defined with no generally accepted, settled legal foundation.

    Where the training material is known, it is common for it to include large
    volumes of material under restrictive licensing/copyright terms. Even where
    the training material is all known to be under open source licenses, it is
    likely to be under a variety of terms, not all of which will be compatible
    with QEMU's licensing requirements.

This connects the special case of AI generated content to the general
provenance problem.

    How contributors could comply with DCO terms (b) or (c) for the output of AI
    content generators commonly available today is unclear.  The QEMU project is
    not willing or able to accept the legal risks of non-compliance.

This states that the QEMU project assumes non-compliance with (b) and
(c), rendering a Signed-off-by *invalid* as far as we're concerned.  In
other words, it's kind 2. above.  The answer to your question "how
AI-generated content is detected in pull requests and the like" is given
right there:

   We trust people not to lie to us, and to exercise appropriate care.

   Note that lying / carelessness about such things can have unpleasant
   legal consequences for the liar / careless person.

Further questions?