Contributing non-Apache 2.0 licensed components¶
Importing code into the Zephyr OS from other projects that use a license other than the Apache 2.0 license needs to be fully understood in context and approved by the Zephyr governing board.
By carefully reviewing potential contributions and also enforcing a Developer Certification of Origin (DCO) for contributed code, we ensure that the Zephyr community can develop products with the Zephyr Project without concerns over patent or copyright issues.
Submission and review process¶
All contributions to the Zephyr project are submitted through GitHub pull requests (PR) following the Zephyr Project’s Contribution Workflow.
Before you begin working on including a new component to the Zephyr Project (Apache-2.0 licensed or not), you should start up a conversation on the developer mailing list to see what the Zephyr community thinks about the idea. Maybe there’s someone else working on something similar you can collaborate with, or a different approach may make the new component unnecessary.
If the conclusion is that including a new component is the best solution, and this new component uses a license other than Apache-2.0, these additional steps must be followed:
- Complete a README for your code component and add it to your source
code pull request (PR). A recommended README template can be found in
doc/contribute/code_component_README
(and included below for reference) - The Zephyr Technical Steering Committee (TSC) will evaluate the code
component README as part of the PR
commit and vote on accepting it using the GitHub PR review tools.
- If rejected by the TSC, a TSC member will communicate this to the contributor and the PR will be closed.
- If approved by the TSC, the TSC chair will forward the README to the Zephyr governing board for further review.
- The Zephyr governing board has two weeks to review and ask questions:
- If there are no objections, the matter is closed. Approval can be accelerated by unanimous approval of the board before the two weeks are up.
- If a governing board member raises an objection that cannot be resolved via email, the board will meet to discuss whether to override the TSC approval or identify other approaches that can resolve the objections.
- On approval of the Zephyr TSC and governing board, final review of
the PR may be made to ensure its proper placement in the
Zephyr Project Source Tree Structure, (in the
ext
folder), and inclusion in the Licensing of Zephyr Project components document.
Note
External components not under the Apache-2.0 license cannot be included in a Zephyr OS release without approval of both the Zephyr TSC and the Zephyr governing board.
Code component README template¶
[Code Component Name]
#####################
Origin:
[Name of project hosting the original open source code]
[Provide a link to the source]
Status:
[Current version of this component, supported by Zephyr]
Purpose:
[Brief description of what this software does]
Description:
[Long description that will help reviewers discuss suitability of the
package to solve the problem at hand (there may be a better package
available.)
What is its primary functionality (e.g., SQLLite is a lightweight
database)?
What problem are you trying to solve? (e.g., a state store is
required to maintain ...)
Why is this the right package to solve it (e.g., SQLite is small,
easy to use, and has a very liberal license.)]
Dependencies:
[What other components does this package depend on? Does the software
include any dynamic or static linking, or automatic downloading of any
code?
Will the Zephyr project have a direct dependency on the component, or
will it be included via an abstraction layer with this component as a
replacable implementation?]
URL:
[location to the project's home, e.g., a github repo]
commit:
[08ded7f21529c39e5133688ffb9a9d0c94e5c6e]
Maintained-by:
[External]
License:
[use SPDX identifier (https://spdx.org/licenses/), such as BSD-3-Clause]
License Link:
[link to the project's LICENSE file, e.g., https://github.com/xyz/LICENSE]