RFD 224 Open Source Policy

Any open source contribution from Oxide must have the personal attribution of the engineer (or engineers) who did the work. (In general, this attribution will take the form of the Author field of a git commit, which can differ from the Commit field.) At no point should work by one engineer be passed off as the work of another; it is every engineer’s responsibility to assure that their peers are appropriately recognized. Further, even with attribution, the original engineer should generally be made aware that their work is being upstreamed. This is a courtesy (and may help inform the testing or correctness of the upstreaming); if it’s not possible to engage with the original engineer, it should not impede upstreaming their committed work.

Copyright for all open source contribution is held by Oxide, but how this is attributed will depend on the specifics of the project. For projects started at Oxide, see the next subheading, "Copyright notice." For other projects, the project’s preferences for attribution should be followed.

In this model, it is important that the e-mail address contain the author’s corporate e-mail address (e.g. "@oxide.computer").

Different projects differ in the mechanics of their copyright notice, and legal counsel opinion will vary on mechanics of year and so on. Given that our preference is to use the MPL, we also will go by their guidance, which at the time of writing is as follows:

Here is an example header to be used, in the default Rust comment style:

If you decide to add a Copyright line, it should look like this:

The current year should be used.

Rust files in particular tend to have various things that could go at the start of the file. We are going to standardize on this order:

An example:

This is built off of the default Rust style, with documentation comments first, but the license deserves priority.

You can easily add an MPL v2.0 license header to all rust source files in a directory by using the script included in this repository.

If an Oxide project is being distributed via a package manager, make sure that you include the proper licensing information into the package’s metadata as appropriate.

For example, Rust code that is published to Crates.io should have the license key set.

All projects should have a LICENSE file at the root of the repository that contains the text of the appropriate license or licenses.

We regularly integrate source from third parties into other open source projects. If the third party source is not already open source, this activity must be done in concert with the OSCO, who will take responsibility for assuring that the third party has condoned this activity and that risk is appropriately minimized.

Some changes can be considered de minimis, and need not have a copyright notice or update. These kinds of changes include:

In general, any code change — however small — should not be considered de minimis.

We expect our staff to professionally engage with people who are not Oxide employees. It is our expectation that conduct in open source engagement will reflect the professionalism of our workplace. Where this is not the case — where we believe that actions by others in the community are violating our standards for our own conduct — action should be taken. Employees who wish to report this conduct should either report it to the OSCO or to Oxide HR. Working with the employee, the OSCO and/or Oxide HR will determine the correct course of action, with the priority being to protect the employee.

If a contributor license agreement is required, the OSCO should be consulted. Most CLAs are harmless, but formal OSCO permission will regrettably be required.

Absent explicit permission from the OSCO, all new repositories should be in GitHub, under the "oxidecomputer" GitHub account (that is, not under personal accounts).

For any new Oxide-created software, the MPL 2.0 should generally be the license of choice. The exception to this should be any software that is a part of a larger ecosystem that has a prevailing license, in which case that prevailing license may be used. For example, Rust crates are generally dual-licensed as MIT/Apache 2. The "Licenses" section under open source use applies here; if new software is to be created that is (for example) LGPL, it can only be done with the explicit permission of the OSCO.

Especially with our broad open source disposition, in Oxide-originated repositories it can be easy to accidentally divulge a secret. Certainly, there should never be production key material or passwords in a repository, even when private. We also need to be careful about production data that might be used as test data. This data can take on subtle forms. Unfortunately, code review can be too late to catch this, as our code reviews are also publicly accessible. There is no mechanical guideline here other than to be very mindful!

In our view, contributor license agreements (CLAs) are an impediment to contributions, and we do not use them for any Oxide-originated repository. (Part of the reason for our strong preference for MPL 2.0 is that the license warrants the originality of the work and obviates the need for a CLA entirely.)

A formal code of conduct is likely well-advised. This should be done in consultation with the OSCO, but it is recommended that projects use a derivative of the Contributor Covenant.