Lines Matching full:the
10 This section describes the circumstances under which external source code can be
11 imported into Zephyr, and the process that governs the inclusion.
13 There are three main factors that will be considered during the inclusion
15 described in the following sections.
18 compiled and linked into the final image, and programmed into the target
20 code analysis, testing or simulation please refer to the
21 :ref:`external-tooling` section at the end of the page.
28 External source code licensed under the Apache-2.0 license is not subject to
31 Integrating code into the Zephyr Project from other projects that use a license
32 other than the Apache 2.0 license needs to be fully understood in
33 context and approved by the `Zephyr governing board`_, as described in the
34 `Zephyr project charter`_. The board will automatically reject licenses that
35 have not been approved by the `Open Source Initiative (OSI)`_. See the
48 for contributed code, we ensure that the Zephyr community can develop products
49 with the Zephyr Project without concerns over patent or copyright issues.
55 needs to be evaluated for merit. However, in the particular case of code that
57 answered in order to accept the contribution.
58 More specifically, the following will be considered by the Technical Steering
59 Committee and evaluated carefully before the external source code is accepted
60 into the project:
62 - Is this the most optimal way to introduce the functionality to the project?
63 Both the cost of implementing this internally and the one incurred in
65 - Is the external project being actively maintained? This is particularly
67 - Have alternatives to the particular implementation proposed been considered?
68 Are there other open source project that implement the same functionality?
73 There are two ways of integrating external source code into the Zephyr Project,
74 and careful consideration must be taken to choose the appropriate one for each
77 Integration in the main tree
80 The first way to integrate external source code into the project is to simply
81 import the source code files into the main ``zephyr`` repository. This
82 automatically implies that the imported source code becomes part of the
85 - The code is formatted according to the Zephyr :ref:`coding_style`
86 - The code adheres to the project's :ref:`coding_guidelines`
87 - The code is subject to the same checks and verification requirements as the
88 rest of the code in the main tree, including static analysis
90 - If the source is not Apache 2.0 licensed,
91 an entry is added to the :ref:`licensing page <zephyr_licensing>`.
94 codebases, but it is typically used more commonly with the former.
99 The second way of integrating external source code into the project is to import
100 the whole or parts of the third-party open source project into a separate
101 repository, and then include it under the form of a :ref:`module <modules>`.
102 With this approach the code is considered as being developed externally, and
103 thus it is not automatically subject to the requirements of the previous
109 Integrating external code into the main :file:`west.yml` manifest file is
113 The integration of modules in this group is validated by the Zephyr project CI,
116 Integrated modules will not be removed from the tree without a detailed
130 There shall not be any direct dependency added in the Zephyr code tree (Git
131 repository) and all sample or test code shall be maintained as part of the module.
136 samples and test code in the Zephyr Git repository will be transitioned out
142 Similar to optional modules, but added to the Zephyr project as an entry in the
143 documentation using a pre-defined template. This type of modules exists outside the
145 to integrate the functionality.
150 Regardless of the mode of integration, external source code that is integrated
151 in Zephyr requires regular ongoing maintenance. The submitter of the proposal to
152 integrate external source code must therefore commit to maintain the integration
153 of such code for the foreseeable future.
154 This may require adding an entry in the :file:`MAINTAINERS.yml` as part of the
162 Before external source code can be included in the project, it must be reviewed
163 and accepted by the Technical Steering Committee (TSC) and, in some cases, by
164 the Zephyr governing board.
167 issue in the Zephyr project issue tracking system on GitHub with details
168 about the source code and how it integrates into the project.
170 Follow the steps below to begin the submission process:
172 #. Make sure to read through the :ref:`external-contributions` section in
173 detail, so that you are informed of the criteria used by the TSC and board in
175 #. Use the :github:`New External Source Code Issue
177 #. Fill out all required sections, making sure you provide enough detail for the
178 TSC to assess the merit of the request. Optionally you can also create a Pull
179 Request that demonstrates the integration of the external source code and
180 link to it from the issue
181 #. Wait for feedback from the TSC, respond to any additional questions added as
184 If, after consideration by the TSC, the conclusion is that integrating external
185 source code is the best solution, and the external source code is licensed under
186 the Apache-2.0 license, the submission process is complete and the external
189 If, however, the external source code uses a license other than Apache-2.0,
192 #. The TSC chair will forward the link to the GitHub issue created during the
193 early submission process to the Zephyr governing board for further review
195 #. The Zephyr governing board has two weeks to review and ask questions:
197 - If there are no objections, the matter is closed. Approval can be
198 accelerated by unanimous approval of the board before the two
202 via email, the board will meet to discuss whether to override the
203 TSC approval or identify other approaches that can resolve the
206 #. On approval of the Zephyr TSC and governing board the submission process is
209 The flowchart below shows an overview of the process:
221 This section deals exclusively with the inclusion of external tooling in the
222 Zephyr project, where tooling is defined as software that assists the
224 of the code compiled and linked into the final image. "Inclusion" in this
225 context means becoming part of the Zephyr default distribution either in the
226 main tree directly under the :file:`scripts/` folder or indirectly as a west
227 project in the main :file:`west.yml` manifest. Therefore, this section does not
229 still be referenced by the Zephyr build system or docs without being included in
232 Tooling components must be released under a license approved by the
236 another project can be integrated either in the main tree or as a :ref:`west
237 project <west-workspace>`. Note that in this case the corresponding west project
238 will not be a :ref:`module <modules>`, because tooling does not make use of the
240 :ref:`modules-vs-projects` for additional information on the differences.
242 If the tool is integrated in the main tree it should be placed under the
244 If the tool is integrated as a west project, then the project repository can be
245 hosted outside the zephyrproject-rtos GitHub organization, provided that the
246 project is made optional via the ``group-filter:`` field in the main
250 The TSC must approve every Pull Request that introduces a new external tooling
251 component. This will be done on a case-by-case, individual analysis of the
252 proposed addition by the TSC representatives.
254 Additional considerations about the main manifest
257 In general, any additions or removals whatsoever to the ``projects:`` section of
258 the `main manifest file`_ requires TSC approval. This includes, but is not