contributor-guide/submit-changes: add policy on AI generated code

Based on message by Richard Purdie on the yocto-docs list:
https://lists.yoctoproject.org/g/docs/message/6300

Re-formatted for the Yocto Project documentation syntax.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/contributor-guide/submit-changes.rst | 49 ++++++++++++++++++++++
 1 file changed, 49 insertions(+)


---
base-commit: 6eda443c7fcfeecebd6b44b96a1587c4bb093a34
change-id: 20250212-ai-policy-c2961121f251

Best regards,

HI Antonin,

On 2/12/25 9:50 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Based on message by Richard Purdie on the yocto-docs list:
> https://lists.yoctoproject.org/g/docs/message/6300
> 
> Re-formatted for the Yocto Project documentation syntax.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/contributor-guide/submit-changes.rst | 49 ++++++++++++++++++++++
>   1 file changed, 49 insertions(+)
> 
> diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
> index 85ca987df..0675aac98 100644
> --- a/documentation/contributor-guide/submit-changes.rst
> +++ b/documentation/contributor-guide/submit-changes.rst
> @@ -832,3 +832,52 @@ Other layers may have similar testing branches but there is no formal
>   requirement or standard for these so please check the documentation for the
>   layers you are contributing to.
>   
> +Acceptance of AI Generated Code
> +===============================
> +
> +The Yocto Project and OpenEmbedded follow the guidance of the Linux Foundation
> +in regards to the use of generative AI tools. See:
> +https://www.linuxfoundation.org/legal/generative-ai.
> +
> +All of the existing guidelines in this document are expected to be followed,

s/in this document/in the document linked above/ ?

Since "this document" could be interpreted as the Yocto Docs, especially 
if shared in PDF/ePUB forms.

> +including in the :doc:`recipe-style-guide`, and contributing the changes with
> +additional requirements to the items in section
> +:ref:`contributor-guide/submit-changes:Implement and commit changes`.
> +
> +All AI Generated Code must be labeled as such in the commit message,
> +prior to your ``Signed-off-by`` line. It is also strongly recommended,

s/,//

> +that any patches or code within the commit also have a comment or other

s/patches/patch/

s/also// (redundant with "also strongly recommended" at the beginning of 
the sentence; or maybe start the sentence with "Additionally" or 
"Moreover" or "In addition")

> +indication that this code was AI generated.
> +
> +For example, here is a properly formatted commit message::
> +
> +   component: Add the ability to ...
> +
> +   AI-Generated: Uses GitHub Copilot
> +
> +   Signed-off-by: Your Name <your.name@domain>
> +
> +The ``Signed-off-by`` line must be written by you, and not the AI helper.
> +As a reminder, when contributing a change, your ``Signed-off-by`` line is
> +required and the stipulations in the `Developer's Statement of Origin
> +1.1 <https://developercertificate.org/>`__ still apply.
> +
> +Additionally, you must stipulate AI contributions conform to the Linux
> +Foundation policy, specifically:
> +

This is exactly the content of the link provided above. I'm not sure we 
should duplicate it? E.g. it could be updated and we could then have 
conflicting instructions there. Should we say which one takes precedence 
when there can be a conflict?

> +#. Contributors should ensure that the terms and conditions of the generative AI
> +   tool do not place any contractual restrictions on how the tool's output can
> +   be used that are inconsistent with the project's open source software
> +   license, the project's intellectual property policies, or the Open Source
> +   Definition.
> +

There's a link in the original link, provide it here too

`Open Source Definition<https://opensource.org/osd/>`__

Cheers,
Quentin

On Mon, 2025-02-17 at 12:20 +0100, Quentin Schulz wrote:
> > +indication that this code was AI generated.
> > +
> > +For example, here is a properly formatted commit message::
> > +
> > +   component: Add the ability to ...
> > +
> > +   AI-Generated: Uses GitHub Copilot
> > +
> > +   Signed-off-by: Your Name <your.name@domain>
> > +
> > +The ``Signed-off-by`` line must be written by you, and not the AI helper.
> > +As a reminder, when contributing a change, your ``Signed-off-by`` line is
> > +required and the stipulations in the `Developer's Statement of Origin
> > +1.1 <https://developercertificate.org/>`__ still apply.
> > +
> > +Additionally, you must stipulate AI contributions conform to the Linux
> > +Foundation policy, specifically:
> > +
> 
> This is exactly the content of the link provided above. I'm not sure we 
> should duplicate it? E.g. it could be updated and we could then have 
> conflicting instructions there. Should we say which one takes precedence 
> when there can be a conflict?

It was deliberately duplicated so that if it changes we know what it
said previously. This version here is definitive.

Cheers,

Richard

Hi Richard,

On Mon Feb 17, 2025 at 3:30 PM CET, Richard Purdie wrote:
> On Mon, 2025-02-17 at 12:20 +0100, Quentin Schulz wrote:
>> > +indication that this code was AI generated.
>> > +
>> > +For example, here is a properly formatted commit message::
>> > +
>> > +   component: Add the ability to ...
>> > +
>> > +   AI-Generated: Uses GitHub Copilot
>> > +
>> > +   Signed-off-by: Your Name <your.name@domain>
>> > +
>> > +The ``Signed-off-by`` line must be written by you, and not the AI helper.
>> > +As a reminder, when contributing a change, your ``Signed-off-by`` line is
>> > +required and the stipulations in the `Developer's Statement of Origin
>> > +1.1 <https://developercertificate.org/>`__ still apply.
>> > +
>> > +Additionally, you must stipulate AI contributions conform to the Linux
>> > +Foundation policy, specifically:
>> > +
>> 
>> This is exactly the content of the link provided above. I'm not sure we 
>> should duplicate it? E.g. it could be updated and we could then have 
>> conflicting instructions there. Should we say which one takes precedence 
>> when there can be a conflict?
>
> It was deliberately duplicated so that if it changes we know what it
> said previously. This version here is definitive.

I'm not sure if your comment applies to the entire patch, or just the bullet
points. What should I leave as-is?

Antonin

On Mon, 2025-02-17 at 15:37 +0100, Antonin Godard via
lists.openembedded.org wrote:
> Hi Richard,
> 
> On Mon Feb 17, 2025 at 3:30 PM CET, Richard Purdie wrote:
> > On Mon, 2025-02-17 at 12:20 +0100, Quentin Schulz wrote:
> > > > +indication that this code was AI generated.
> > > > +
> > > > +For example, here is a properly formatted commit message::
> > > > +
> > > > +   component: Add the ability to ...
> > > > +
> > > > +   AI-Generated: Uses GitHub Copilot
> > > > +
> > > > +   Signed-off-by: Your Name <your.name@domain>
> > > > +
> > > > +The ``Signed-off-by`` line must be written by you, and not the
> > > > AI helper.
> > > > +As a reminder, when contributing a change, your ``Signed-off-
> > > > by`` line is
> > > > +required and the stipulations in the `Developer's Statement of
> > > > Origin
> > > > +1.1 <https://developercertificate.org/>`__ still apply.
> > > > +
> > > > +Additionally, you must stipulate AI contributions conform to
> > > > the Linux
> > > > +Foundation policy, specifically:
> > > > +
> > > 
> > > This is exactly the content of the link provided above. I'm not
> > > sure we 
> > > should duplicate it? E.g. it could be updated and we could then
> > > have 
> > > conflicting instructions there. Should we say which one takes
> > > precedence 
> > > when there can be a conflict?
> > 
> > It was deliberately duplicated so that if it changes we know what
> > it
> > said previously. This version here is definitive.
> 
> I'm not sure if your comment applies to the entire patch, or just the
> bullet points. What should I leave as-is?

I meant that we'd deliberately duplicated the two bullet points from
the original document/link and that we'd want to continue to do that. I
was giving a reason for the duplication to Quentin.

Cheers,

Richard

Hi Richard,

On 2/17/25 3:30 PM, Richard Purdie wrote:
> On Mon, 2025-02-17 at 12:20 +0100, Quentin Schulz wrote:
>>> +indication that this code was AI generated.
>>> +
>>> +For example, here is a properly formatted commit message::
>>> +
>>> +   component: Add the ability to ...
>>> +
>>> +   AI-Generated: Uses GitHub Copilot
>>> +
>>> +   Signed-off-by: Your Name <your.name@domain>
>>> +
>>> +The ``Signed-off-by`` line must be written by you, and not the AI helper.
>>> +As a reminder, when contributing a change, your ``Signed-off-by`` line is
>>> +required and the stipulations in the `Developer's Statement of Origin
>>> +1.1 <https://developercertificate.org/>`__ still apply.
>>> +
>>> +Additionally, you must stipulate AI contributions conform to the Linux
>>> +Foundation policy, specifically:
>>> +
>>
>> This is exactly the content of the link provided above. I'm not sure we
>> should duplicate it? E.g. it could be updated and we could then have
>> conflicting instructions there. Should we say which one takes precedence
>> when there can be a conflict?
> 
> It was deliberately duplicated so that if it changes we know what it
> said previously. This version here is definitive.
> 

Which version is definitive? The Guidance page from LF without a date 
nor a version? Ours? What if the LF changes the content and we don't? 
Which one takes precedence?

Cheers,
Quentin

On Mon, 2025-02-17 at 18:10 +0100, Quentin Schulz wrote:
> On 2/17/25 3:30 PM, Richard Purdie wrote:
> > On Mon, 2025-02-17 at 12:20 +0100, Quentin Schulz wrote:
> > > 
> > > This is exactly the content of the link provided above. I'm not sure we
> > > should duplicate it? E.g. it could be updated and we could then have
> > > conflicting instructions there. Should we say which one takes precedence
> > > when there can be a conflict?
> > 
> > It was deliberately duplicated so that if it changes we know what it
> > said previously. This version here is definitive.
> > 
> 
> Which version is definitive? The Guidance page from LF without a date
> nor a version? Ours? What if the LF changes the content and we don't?
> Which one takes precedence?

By replicating the text we are showing the thing which we are basing
the policy off and indicating the text that takes precedence (the
quoted text). Our policy and documentation should not be at the mercy
of changes by any third party.

We therefore want to indicate we took the LF document as a basis and
built upon it, recording what we based it upon. If the LF document
changes, we (the TSCs) would have to revisit things to decide if we
want to adopt those changes.

Clearer?

Cheers,

Richard

Hi Antonin,

On 2/12/25 9:50 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Based on message by Richard Purdie on the yocto-docs list:
> https://lists.yoctoproject.org/g/docs/message/6300
> 
> Re-formatted for the Yocto Project documentation syntax.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/contributor-guide/submit-changes.rst | 49 ++++++++++++++++++++++
>   1 file changed, 49 insertions(+)
> 
> diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
> index 85ca987df..0675aac98 100644
> --- a/documentation/contributor-guide/submit-changes.rst
> +++ b/documentation/contributor-guide/submit-changes.rst
> @@ -832,3 +832,52 @@ Other layers may have similar testing branches but there is no formal
>   requirement or standard for these so please check the documentation for the
>   layers you are contributing to.
>   
> +Acceptance of AI Generated Code
> +===============================
> +
> +The Yocto Project and OpenEmbedded follow the guidance of the Linux Foundation
> +in regards to the use of generative AI tools. See:

s/in regards to/in regard to/
or
s/in regards to/with regards to/

> +https://www.linuxfoundation.org/legal/generative-ai.
> +

Following the discussion with Richard in a different thread, I would 
suggest to add something like

for the document taken as inspiration

or something like that. I read this first paragraph as "we follow the 
guidance of the LF as explained here <link>". I personally read that, I 
don't even read the rest, I just head to the link and take that as the 
project's stance.

I think it makes sense to specify that what matters is what **we** as a 
project wrote here and not what's pointed at in the link above, even 
though they are today essentially the same. It's just that the LF may 
update that guidance in the future (possibly without notice) but we 
would want to keep the guidelines listed in this patch today or update 
them with a separate patch. Essentially what we want is to not blindly 
depend (or imply we depend) on a document that is outside of our control.

Otherwise the rest of the text is fine for me. Do we want something 
similar in the BitBake documentation?

Cheers,
Quentin

On 2/17/25 5:20 AM, Quentin Schulz via lists.openembedded.org wrote:
> HI Antonin,
> 
> On 2/12/25 9:50 AM, Antonin Godard via lists.yoctoproject.org wrote:
>> Based on message by Richard Purdie on the yocto-docs list:
>> https://lists.yoctoproject.org/g/docs/message/6300
>>
>> Re-formatted for the Yocto Project documentation syntax.
>>
>> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
>> ---
>>    documentation/contributor-guide/submit-changes.rst | 49 ++++++++++++++++++++++
>>    1 file changed, 49 insertions(+)
>>
>> diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
>> index 85ca987df..0675aac98 100644
>> --- a/documentation/contributor-guide/submit-changes.rst
>> +++ b/documentation/contributor-guide/submit-changes.rst
>> @@ -832,3 +832,52 @@ Other layers may have similar testing branches but there is no formal
>>    requirement or standard for these so please check the documentation for the
>>    layers you are contributing to.
>>    
>> +Acceptance of AI Generated Code
>> +===============================
>> +
>> +The Yocto Project and OpenEmbedded follow the guidance of the Linux Foundation
>> +in regards to the use of generative AI tools. See:
>> +https://www.linuxfoundation.org/legal/generative-ai.
>> +
>> +All of the existing guidelines in this document are expected to be followed,
> 
> s/in this document/in the document linked above/ ?
> 
> Since "this document" could be interpreted as the Yocto Docs, especially
> if shared in PDF/ePUB forms.

"this document", as in the 'contributor-guide', the document the user is 
currently reading as a whole,not just this section.

We only reference the generative-ai link.  We do NOT want to be beholden to an 
outside document, but we may reference it.

This matches what we've done with the kernel's developer statement of origin. 
We reference it and quote the relevant text we expect someone to follow.

> 
>> +including in the :doc:`recipe-style-guide`, and contributing the changes with
>> +additional requirements to the items in section
>> +:ref:`contributor-guide/submit-changes:Implement and commit changes`.
>> +
>> +All AI Generated Code must be labeled as such in the commit message,
>> +prior to your ``Signed-off-by`` line. It is also strongly recommended,
> 
> s/,//
> 
>> +that any patches or code within the commit also have a comment or other
> 
> s/patches/patch/
> 
> s/also// (redundant with "also strongly recommended" at the beginning of
> the sentence; or maybe start the sentence with "Additionally" or
> "Moreover" or "In addition")


Original text was 'It is recommended,"   This was changed to "It is also 
strongly recommended," to put clear emphasis that while not required, people 
will be looking for, and expecting this information.  Must/Require, 
Should/Recommended, etc are language I'm used to using from other standards 
documents.


>> +indication that this code was AI generated.
>> +
>> +For example, here is a properly formatted commit message::
>> +
>> +   component: Add the ability to ...
>> +
>> +   AI-Generated: Uses GitHub Copilot
>> +
>> +   Signed-off-by: Your Name <your.name@domain>
>> +
>> +The ``Signed-off-by`` line must be written by you, and not the AI helper.
>> +As a reminder, when contributing a change, your ``Signed-off-by`` line is
>> +required and the stipulations in the `Developer's Statement of Origin
>> +1.1 <https://developercertificate.org/>`__ still apply.
>> +
>> +Additionally, you must stipulate AI contributions conform to the Linux
>> +Foundation policy, specifically:
>> +
> 
> This is exactly the content of the link provided above. I'm not sure we
> should duplicate it? E.g. it could be updated and we could then have
> conflicting instructions there. Should we say which one takes precedence
> when there can be a conflict?

I believe Richard already covered this in his comments, but we absolute want a 
copy of anything we depend on from an outside source.

Only what is written in our contribution guide is required.  By making a copy, 
we ensure that if the outside source changes their recommendations, we are _NOT_ 
affected and our users are _NOT_ affected unless we specifically make changes.

--Mark

>> +#. Contributors should ensure that the terms and conditions of the generative AI
>> +   tool do not place any contractual restrictions on how the tool's output can
>> +   be used that are inconsistent with the project's open source software
>> +   license, the project's intellectual property policies, or the Open Source
>> +   Definition.
>> +
> 
> There's a link in the original link, provide it here too
> 
> `Open Source Definition<https://opensource.org/osd/>`__
> 
> Cheers,
> Quentin
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#612): https://lists.openembedded.org/g/tsc/message/612
> Mute This Topic: https://lists.openembedded.org/mt/111235974/3616948
> Group Owner: tsc+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/tsc/unsub [mark.hatle@kernel.crashing.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>