docs/devel/code-provenance.rst

14 Certification is achieved with a low overhead by adding a single line to the
19 The addition of this line asserts that the author of the patch is contributing
33   (b) The contribution is based upon previous work that, to the best
34       of my knowledge, is covered under an appropriate open source
47       personal information I submit with it, including my sign-off) is
52 birth name, nor appear on any government ID. It is the identity you choose to
56 It is generally expected that the name and email addresses used in one of the
62 If the person sending the mail is not one of the patch authors, they are
69 It is not uncommon for a patch to have contributions from multiple authors. In
80     unusually large, but it is common to add ``Suggested-by`` as a credit
86     It can be said that in this case a ``Signed-off-by`` is indicating that
87     the person has permission to contribute from their employer who is the
88     copyright holder. It is nonetheless still preferable to include a
99 While the ``Signed-off-by`` tag is mandatory, there are a number of other tags
121    mailing list, or some other informal channel that is not the issue tracker,
122    it is good practice to credit them by including a ``Reported-by`` tag on
123    any patch fixing the issue. When the problem is reported via the GitLab
124    issue tracker, however, it is sufficient to just include a link to the
128    suggestions for how to change a patch, it is good practice to credit them
140 done the aforementioned validation. This is in addition to any of their own
144 should record their contribution.  This is typically done via a note in the
217  * Indicate who is responsible for what parts of the patch. This is typically
228 It is also recommended to attempt to contact the original author to let them
237 this is that the output of code generators or compilers is usually not
241 generated code is permitted, provided it is also accompanied by the
242 corresponding preferred source format. This is done where it is impractical
244 process. A non-exhaustive list of examples is:
246  * Images: where an bitmap image is created from a vector file it is common
249    original vector file is expected to accompany any generated bitmaps.
258    included in tree because it is desirable to be able to directly build
263    distributions. The corresponding eBPF C code for the binary is also
264    provided. This is a time-limited exception until the eBPF toolchain is
277 generation. Where an automated manipulation is performed on code, however,
281 boilerplate code template which is then filled in to produce the final patch.
283 since it is intended to be a foundation for further human authored changes.
284 Such tools are acceptable to use, provided there is clearly defined copyright
293   **Current QEMU project policy is to DECLINE any contributions which are
299 QEMU.  Of particular concern is content generated by `Large Language Models
308 content generators, the copyright and license status of the output is
311 Where the training material is known, it is common for it to include large
313 the training material is all known to be under open source licenses, it is
318 content generators commonly available today is unclear.  The QEMU project is
323 decline any contribution if use of AI is either known or suspected.
326 algorithms, static analysis, or debugging, provided their output is not to be
333 This policy may evolve as AI tools mature and the legal situation is