Contents: License Default license External test materials Copyright statements License tags Contributor agreement Submitting contributions Creating patches Alternative submission methods

License [edit section]

Fuego has the following license policy.

Fuego consists of several parts, and includes source code from a number of different external test projects.

Default license [edit section]

The default license for Fuego is the BSD 3-Clause license, as indicated in the LICENSE file at the top of the 'fuego' and 'fuego-core' source repositories.

If a file does not have an explicit license, or license indicator (such as SPDX identifier) in the file, than that file is covered by the default license for the project, with the exceptions noted below for "external test materials".

When making contributions, if you do NOT indicate an alternative license for your contribution, the contribution will be assigned the license of the file to which the contribution applies (which may be the default license, if the file contains no existing license indicator).

Although we may allow for other licenses within the Fuego project in order to accommodate external software added to our system, our preference is to avoid the proliferation of licenses in the Fuego code itself.

External test materials [edit section]

Individual tests in Fuego consist of files in the directory: engine/tests/<test_name> (which is known as the test home directory), and may include two types of materials:

• 1) Fuego-specific files
• 2) files obtained from external sources, which have their own license.

The Fuego-specific materials consist of files such as: fuego_test.sh, spec.json, reference.json, test.yaml, chart_config.json, and possibly others as created for use in the Fuego project. External test materials may consist of tar files, helper scripts and patches against the source in the tar files.

Unless otherwise indicated, the Fuego-specific materials are licensed under the Fuego default license, and the external test materials are licensed under their own individual project license - as indicated in the test source.

In some cases, there is no external source code, but only source that is originally written for Fuego and stored in the test home directory. This commonly includes tests based on a single shell script, that is written to be deployed to the Device Under Test by fuego_test.sh. Unless otherwise indicated, these files (source and scripts) are licensed under the Fuego default license.

If there is any ambiguity in the category of a particular file (external or Fuego-specific), please designate the intended license clearly in the file itself, when making a contribution.

Copyright statements [edit section]

Copyrights for individual contributions should be added to individual files, when the contributions warrant copyright assignment. Some trivial fixes to existing code may not need to have copyright assignment, and thus not every change to a file needs to include a copyright notice for the contributor.

License tags [edit section]

Our preference is to use SPDX license identifier, rather than a license notice, to indicate the license of any materials in Fuego. Such identifiers and notices are only desired if the materials are not contributed under the default Fuego license of "BSD-3-Clause".

In a test.yaml, please indicate the license of the upstream test program. If there is no upstream test program (ie, the test is self-contained), please specify the license of the Fuego test definition itself.

Please see https://spdx.org/licenses/ for a list of SPDX license tags

Contributor agreement [edit section]

The Fuego project does not require a signed Contributor License Agreement for contribution to the project. Instead, we utilize the following Developer Certificate of Origin that was copied from the Linux kernel.

Each contribution to Fuego must be accompanied by a Signed-off-by line in the patch or commit description, which indicates agreement to the following:

By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

        (d) I understand and agree that this project and the contribution
            are public and that a record of the contribution (including all
            personal information I submit with it, including my sign-off) is
            maintained indefinitely and may be redistributed consistent with
            this project or the open source license(s) involved.

Note: Please note that an "official" DCO at the web site https://developercertificate.org/ has additional text (an LF copyright, address, and statement of non-copyability). All of these are either nonsense or problematical in some legal sense. The above is a quote of a portion of the document found in the Linux kernel guide for submitting patches. See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst (copied in March, 2018).

Each commit must include a DCO which looks like this

   Signed-off-by: Joe Smith <joe.smith@email.com>

The project requires that the name used is your real name. Neither anonymous contributors nor those utilizing pseudonyms will be accepted.

You may type this line on your own when writing your commit messages. However, Git makes it easy to add this line to your commit messages. Make sure the user.name and user.email are set in your git configs. Use '-s' or '--signoff' options to 'git commit' to add the Signed-off-by line to the end of the commit message.

Submitting contributions [edit section]

Please format contributions as a patch, and send the patch to the Fuego mailing list

Before making the patch, please verify that you have followed our preferred Coding style.

We follow the style of patches used by the Linux kernel, which is described here: https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Not everything described there applies, but please do the following:

• used a Signed-off-by line
• send patch in plain text
• include PATCH in the subject line
• number patches in a series (1/n, 2/n, .. n/n)
• patch subject should have: "subsystem: description"
  • in the case of modifications to a test, the subject should have: "test: description" (that is, the test is the subsystem name)
  • the test name can be the short name, if it is unambiguous
    • That is, please don't use the 'Functional' or 'Benchmark' prefix unless there are both types of tests with the same short name
• describe your changes in the commit message body

Creating patches [edit section]

If you use git, it's easy to create a patch (or patch series), using 'git format-patch'. Or, you can go directly to e-mailing a patch or patch series using 'git send-email'

Alternative submission methods [edit section]

I also allow patches as attachments to an e-mail to the list. This is something NOT supported by the Linux kernel community.

If the patch is too big (greater than 300K), then please add it to a public git repository, and let me know the URL for the repository. I can add a remote for the repo, and fetch it and cherry pick the patch. I prefer doing a fetch and cherry-pick to a pull request.

While I will sometimes process patches through a repo, it is strongly preferred for patches to go through the mailing list as plain text, so that community members can review the patch in public.