Lines Matching full:to
9 The QEMU community **mandates** all contributors to certify provenance of
10 patch submissions they make to the project. To put it another way,
11 contributors must indicate that they are legally permitted to contribute to
14 Certification is achieved with a low overhead by adding a single line to the
27 By making a contribution to this project, I certify that:
30 have the right to submit it under the open source license
33 (b) The contribution is based upon previous work that, to the best
35 license and I have the right under that license to submit that
38 permitted to submit under a different license), as indicated
41 (c) The contribution was provided directly to me by some other
51 The name used with "Signed-off-by" does not need to be your legal name, nor
52 birth name, nor appear on any government ID. It is the identity you choose to
58 It's okay if you subscribe or contribute to the list via more than one
63 nonetheless expected to add their own ``Signed-off-by`` to comply with the
69 It is not uncommon for a patch to have contributions from multiple authors. In
70 this scenario, git commits will usually be expected to have a ``Signed-off-by``
74 considered not subject to copyright. In this case the secondary authors
78 of code as suggested fixes to a patch. The reviewers don't need to have
80 unusually large, but it is common to add ``Suggested-by`` as a credit
87 the person has permission to contribute from their employer who is the
88 copyright holder. It is nonetheless still preferable to include a
90 not able to assign copyright to their employer, and it also covers any
94 in order of authorship, from oldest to newest.
106 ``Signed-off-by`` to the same commit.
109 touches their subsystem, but intends to allow a different maintainer to
113 maintainer wants to indicate they have done a full review they should use
122 it is good practice to credit them by including a ``Reported-by`` tag on
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
134 When a subsystem maintainer accepts a patch from a contributor, in addition to
135 the normal code review points, they are expected to validate the presence of
139 **must** also then add their own ``Signed-off-by`` to indicate that they have
140 done the aforementioned validation. This is in addition to any of their own
141 ``Reviewed-by`` tags the subsystem maintainer may wish to include.
145 commit message, just prior to the maintainer's ``Signed-off-by``::
156 for patches, avoiding the need for contributors to manually type in this
162 When creating, or amending, a commit the ``-s`` flag to ``git commit`` will
166 be used to append a suitable line in the emails it creates, without modifying
167 the local commits. Alternatively to modify all the local commits on a branch::
187 or ``<enter>`` it will expand to the whole phrase.
200 or ``<enter>`` it will expand to the whole phrase.
205 For a variety of reasons there are some patches that get submitted to QEMU but
206 never merged. An unrelated contributor may decide (months or years later) to
211 * Continue to credit the original author for their work, by maintaining their
216 ``Signed-off-by`` in the patch in addition to the orignal author's
218 done via a note in the commit message, just prior to the new contributor's
228 It is also recommended to attempt to contact the original author to let them
230 to return to the work, or had any suggestions about the best way to continue.
235 Files in patches contributed to QEMU are generally expected to be provided
238 appropriate to contribute to QEMU.
240 For reasons of practicality there are some exceptions to this rule, where
243 to expect those building QEMU to run the code generation or compilation
247 to include the rendered bitmaps at desired resolution(s), since subtle
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
270 Tools which perform changes to existing code with deterministic algorithmic
272 to be "generators".
274 For instance, using Coccinelle to convert code from one pattern to another
276 code using sed / awk / etc, are not considered to be acts of code
280 At times contributors may use or create scripts/tools to generate an initial
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
285 and licensing for their output. Note in particular the caveats applying to AI
293 **Current QEMU project policy is to DECLINE any contributions which are
294 believed to include or derive from AI generated content. This includes
306 To satisfy the DCO, the patch contributor has to fully understand the
307 copyright and license status of content they are contributing to QEMU. With AI
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
314 likely to be under a variety of terms, not all of which will be compatible
319 not willing or able to accept the legal risks of non-compliance.
322 generators on patches intended to be submitted to the project, and will
325 This policy does not apply to other uses of AI, such as researching APIs or
326 algorithms, static analysis, or debugging, provided their output is not to be
334 clarifed. In the meanwhile, requests for exceptions to this policy will be
335 evaluated by the QEMU project on a case by case basis. To be granted an
336 exception, a contributor will need to demonstrate clarity of the license and
337 copyright status for the tool's output in relation to its training model and
338 code, to the satisfaction of the project maintainers.