libvirt: Contributing
Description: libvirt, virtualization, virtualization API

# Contributing

These are the basics steps you need to follow to contribute to libvirt software development.

## Repositories and external resources

The official upstream repository is kept in git (https://gitlab.com/libvirt/libvirt) and is browsable along with other libvirt-related repositories (e.g. libvirt-python) online.

Patches to translations are maintained via the Fedora Weblate service. If you want to contribute to translations of libvirt, join the appropriate language team in Weblate. Translation updates to libvirt will be merged during the feature freeze window.

## Working with the code

In general you should base your work upon the git master branch.

The "Git checkout" section of the libvirt installation instructions give an overview of the compilation process.

Optionally, Clangd with libvirt can be used to navigate the code base etc. within most code editors (and IDEs).

## Preparing patches

Make sure your patches apply against the libvirt git master branch. The backporting of changes to existing releases is typically carried out by downstream users at their discretion after code is merged into the upstream git.

Run the automated tests on your code before submitting any changes. That is:

    $ ninja test

These tests help making sure that your changes don't introduce regressions in libvirt, as well as validating that any new code follows the project's coding style.

If you're going to submit multiple patches, the automated tests must pass after each patch, not just after the last one.

Update tests and/or documentation, particularly if you are adding a new feature or changing the output of a program, and don't forget to update the release notes if your changes are significant and user-visible.

To test across a variety of build platforms prior to submitting your changes, you may create your own fork of the project on gitlab. This will give you access to (a subset of) libvirt's continuous integration test suite.

Please note that you should still follow the instructions below, rather than following gitlab's prompts to open a "merge request".

## Submitting patches

Libvirt uses a mailing list based development workflow.

While preparing your patches for submissions, make sure you follow the best practices and, once you're satisfied with the result, go ahead and submit your patches.

## Developer Certificate of Origin

Contributors to libvirt projects must assert that they are in compliance with the Developer Certificate of Origin 1.1. This is achieved by adding a "Signed-off-by" line containing the contributor's name and e-mail to every commit message. The name should be the identity the contributor has chosen to be known as in the context of the community. It does not need to be a legal name, nor match any formal ID documents, but should not be anonymous, nor misrepresent who you are. The presence of this line attests that the contributor has read the above linked DCO and agrees with its statements.

## Use of AI content generators

TL;DR:

> Current libvirt project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.

The increasing prevalence of AI-assisted software development results in a number of difficult legal questions and risks for software projects, including libvirt. Of particular concern is content generated by Large Language Models (LLMs).

The libvirt community requires that contributors certify their patch submissions are made in accordance with the rules of the Developer Certificate of Origin.

To satisfy the DCO, the patch contributor has to fully understand the copyright and license status of content they are contributing to libvirt. 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 libvirt's licensing requirements.

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

The libvirt project thus requires that contributors refrain from using AI content generators on patches intended to be submitted to the project, and will decline any contribution if use of AI is either known or suspected.

This policy does not apply to other uses of AI, such as researching APIs or algorithms, static analysis, or debugging, provided their output is not to be included in contributions.

Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content generation agents which are built on top of such tools.

This policy may evolve as AI tools mature and the legal situation is clarified. In the meanwhile, requests for exceptions to this policy will be evaluated by the libvirt project on a case by case basis. To be granted an exception, a contributor will need to demonstrate clarity of the license and copyright status for the tool's output in relation to its training model and code, to the satisfaction of the project maintainers.

## Further reading

This page only covers the very basics, so it's recommended that you also take a look at the following documents:

- Programming languages

- Advanced test suite usage

- Adoption of GLib APIs

- Committer guidelines

- Contributing to libvirt