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:

  1. 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)
  2. 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.
  3. 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.
  4. 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.


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]

   [Name of project hosting the original open source code]
   [Provide a link to the source]

   [Current version of this component, supported by Zephyr]

   [Brief description of what this software does]

   [Long description that will help reviewers discuss suitability of the
   package to solve the problem at hand (there may be a better package

   What is its primary functionality (e.g., SQLLite is a lightweight

   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.)]

   [What other components does this package depend on? Does the software
   include any dynamic or static linking, or automatic downloading of any

   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?]

   [location to the project's home, e.g., a github repo]



   [use SPDX identifier (, such as BSD-3-Clause]

License Link:
   [link to the project's LICENSE file, e.g.,]