doc: add contributing non-Apache2.0 docs
Add contribution process for including non-Apache 2.0 components as approved by the TSC. Include a README template that lists information requested by the TSC and governing board for review. Add a brief mention in the CONTRIBUTING link that appears when submitting a new PR or Issue via the GitHub web interface. Included an introduction to the process steps that includes using the zephyr devel mailing list to discuss new components. fixes #1543 Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
parent
ef39533365
commit
10b24a87fc
|
@ -22,21 +22,51 @@ software continues to be available under the terms that the author desired.
|
|||
|
||||
.. _GitHub repo: https://github.com/zephyrproject-rtos/zephyr
|
||||
|
||||
Zephyr uses the `Apache 2.0 license`_ (as found in the LICENSE file in the
|
||||
project's `GitHub repo`_) to strike a balance between open contribution and
|
||||
allowing you to use the software however you would like to. There are some
|
||||
imported or reused components of the Zephyr project that use other licensing,
|
||||
as described in `Zephyr Licensing`_.
|
||||
Zephyr uses the `Apache 2.0 license`_ (as found in the LICENSE file in
|
||||
the project's `GitHub repo`_) to strike a balance between open
|
||||
contribution and allowing you to use the software however you would like
|
||||
to. The Apache 2.0 license is a permisive open source license that
|
||||
allows you to freely use, modify, distribute and sell your own products
|
||||
that include Apache 2.0 licensed software. (For more information about
|
||||
this, check out articles such as `Why choose Apache 2.0 licensing`_ and
|
||||
`Top 10 Apache License Questions Answered`_).
|
||||
|
||||
.. _Zephyr Licensing:
|
||||
https://www.zephyrproject.org/doc/LICENSING.html
|
||||
.. _Why choose Apache 2.0 licensing:
|
||||
https://www.zephyrproject.org/about/faq/what-rationale-choosing-apache-20-license
|
||||
|
||||
The license tells you what rights you have as a developer, provided by the
|
||||
.. _Top 10 Apache License Questions Answered:
|
||||
https://www.whitesourcesoftware.com/whitesource-blog/top-10-apache-license-questions-answered/
|
||||
|
||||
A license tells you what rights you have as a developer, as provided by the
|
||||
copyright holder. It is important that the contributor fully understands the
|
||||
licensing rights and agrees to them. Sometimes the copyright holder isn't the
|
||||
contributor, such as when the contributor is doing work on behalf of a
|
||||
company.
|
||||
|
||||
Components using other Licenses
|
||||
===============================
|
||||
|
||||
There are some imported or reused components of the Zephyr project that
|
||||
use other licensing, as described in `Zephyr Licensing`_.
|
||||
|
||||
.. _Zephyr Licensing:
|
||||
https://www.zephyrproject.org/doc/LICENSING.html
|
||||
|
||||
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
|
||||
`developer attestations <DCO>`_ for contributed code, we can ensure that
|
||||
the Zephyr community can develop products with the Zephyr Project
|
||||
without concerns over patent or copyright issues.
|
||||
|
||||
See `Contributing non-Apache 2.0 components`_ for more information about
|
||||
this contributing and review process for imported components.
|
||||
|
||||
.. _Contributing non-Apache 2.0 components:
|
||||
https://www.zephyrproject.org/doc/contribute/contribute_non-apache.html
|
||||
|
||||
.. _DCO:
|
||||
|
||||
Developer Certification of Origin (DCO)
|
||||
|
@ -248,6 +278,8 @@ it when committing code, edit your *.git/hooks/pre-commit* file to contain:
|
|||
set -e exec
|
||||
exec git diff --cached | ${ZEPHYR_BASE}/scripts/checkpatch.pl - || true
|
||||
|
||||
.. _Contribution workflow:
|
||||
|
||||
Contribution Workflow
|
||||
*********************
|
||||
|
||||
|
|
50
doc/contribute/code_component_README
Normal file
50
doc/contribute/code_component_README
Normal file
|
@ -0,0 +1,50 @@
|
|||
[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]
|
|
@ -10,3 +10,4 @@ patches for code, documentation, tests, and more, directly to the project.
|
|||
:maxdepth: 1
|
||||
|
||||
contribute_guidelines.rst
|
||||
contribute_non-apache.rst
|
||||
|
|
77
doc/contribute/contribute_non-apache.rst
Normal file
77
doc/contribute/contribute_non-apache.rst
Normal file
|
@ -0,0 +1,77 @@
|
|||
.. _contribute_non-Apache:
|
||||
|
||||
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`_.
|
||||
|
||||
.. _Zephyr governing board:
|
||||
https://www.zephyrproject.org/about/organization
|
||||
|
||||
By carefully reviewing potential contributions and also enforcing a
|
||||
:ref:`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 :ref:`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 <https://lists.zephyrproject.org>`_
|
||||
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
|
||||
:file:`doc/contributing/code_component_README` (and included
|
||||
`below`_ for reference)
|
||||
|
||||
#. The Zephyr Techincal 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 :ref:`source_tree_v2`, (in the ``ext`` folder), and
|
||||
inclusion in the :ref:`zephyr_licensing` 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.
|
||||
|
||||
.. _below:
|
||||
|
||||
Code component README template
|
||||
******************************
|
||||
|
||||
.. literalinclude:: code_component_README
|
Loading…
Reference in a new issue