License And Contribution Policy
Fuego consists of several parts, and includes source code from a number of different external test projects.
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.
- 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.
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:
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 <email@example.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.
Fuego mailing list
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)
- describe your changes in the commit message body
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.