License And Contribution Policy
License
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
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
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:
Fuego-specific files
files obtained from external sources, which have their own license.
The Fuego-specific materials consist of files such as:
fuego_test.sh
, spec.json
, criteria.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
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.
Contributor agreement
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 extra items 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
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:
Use 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)
Use a subsystem prefix on the patch subject line
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
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 method
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.