On Wed, Jun 25, 2025 at 03:16:52PM -0400, Michael S. Tsirkin wrote: > On Mon, Jun 16, 2025 at 11:22:41AM +0200, Markus Armbruster wrote: > > From: Daniel P. Berrangé <berra...@redhat.com> > > > > There has been an explosion of interest in so called AI code > > generators. Thus far though, this is has not been matched by a broadly > > accepted legal interpretation of the licensing implications for code > > generator outputs. While the vendors may claim there is no problem and > > a free choice of license is possible, they have an inherent conflict > > of interest in promoting this interpretation. More broadly there is, > > as yet, no broad consensus on the licensing implications of code > > generators trained on inputs under a wide variety of licenses > > > > The DCO requires contributors to assert they have the right to > > contribute under the designated project license. Given the lack of > > consensus on the licensing of AI code generator output, it is not > > considered credible to assert compliance with the DCO clause (b) or (c) > > where a patch includes such generated code. > > > > This patch thus defines a policy that the QEMU project will currently > > not accept contributions where use of AI code generators is either > > known, or suspected. > > > > These are early days of AI-assisted software development. The legal > > questions will be resolved eventually. The tools will mature, and we > > can expect some to become safely usable in free software projects. > > The policy we set now must be for today, and be open to revision. It's > > best to start strict and safe, then relax. > > > > Meanwhile requests for exceptions can also be considered on a case by > > case basis. > > > > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> > > Reviewed-by: Kevin Wolf <kw...@redhat.com> > > Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com> > > Reviewed-by: Alex Bennée <alex.ben...@linaro.org> > > Signed-off-by: Markus Armbruster <arm...@redhat.com> > > Sorry about only reacting now, was AFK. > > So one usecase that to me seems entirely valid, is refactoring. > > For example, change a function prototype, or a structure, > and have an LLM update all callers. > > The only part of the patch that is expressive is the > actual change, the rest is a technicality and has IMHO nothing to do with > copyright. LLMs can just do it with no hassle.
Well the policy is defined in terms of requirements to comply with the DCO, and that implicitly indicates that the code in question is eligible for copyright protection to begin with. IOW, if a change is such that it is not considered eligible for copyright protection, then you can take the view that it is trivially DCO compliant, whether you wrote the code, an arbitrary 3rd party wrote the code, or whether an AI wrote the code. > Can we soften this to only apply to expressive code? > > I feel a lot of cleanups would be enabled by this. Trying to detail every possible scenario is impractical and would make the document too onerous for people to read, remember & apply. It is better to leave it up to the contributor to decide whether a change is non-copyrightable, than to try to draw that line crudely in text. Even for refactoring that line will be fuzzy and contextual, so not a scenario where we should say any use of AI for reactoring is OK, as that will lull contributors into having a false sense of acceptibility, rather than being aware of need to question it. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
