Skip to content
Snippets Groups Projects
Commit 4e282acc authored by Alberto Pianon's avatar Alberto Pianon Committed by Stefan Schmidt
Browse files

update REUSE section


Signed-off-by: default avatarAlberto Pianon <alberto@pianon.eu>
parent cbeae9f9
Branches main
No related tags found
No related merge requests found
Pipeline #12982 failed with stages
......@@ -14,6 +14,7 @@ SPDX-License-Identifier: CC-BY-4.0
- <a href="#reuse-compliance" id="toc-reuse-compliance">REUSE Compliance</a>
- <a href="#spdx-information-and-reuse-standard" id="toc-spdx-information-and-reuse-standard">SPDX Information and REUSE Standard</a>
- <a href="#spdx-header-example" id="toc-spdx-header-example">SPDX Header Example</a>
- <a href="#dep5-files-paragraph-examples" id="toc-dep5-files-paragraph-examples">DEP5 "Files" Paragraph Examples</a>
- <a href="#substantial-contributions" id="toc-substantial-contributions">Substantial Contributions</a>
- <a href="#dco-sign-off" id="toc-dco-sign-off">DCO sign-off</a>
- <a href="#overview-1" id="toc-overview-1">Overview</a>
......@@ -134,17 +135,21 @@ Once your changes have been pushed to your fork, you are ready to prepare a merg
All projects and files for an hosted project **MUST** be [REUSE](https://reuse.software/) compliant. REUSE requires SPDX information for each file, rules for which are as follows:
- Any new file must have a SPDX header (copyright and license).
- For files that don't support headers (for example binaries, patches etc.) an associated `.license` file must be included with the relevant SPDX information.
- Do not add Copyright Year as part of the SPDX header information.
- The general rule of thumb for the license of a patch file is to use the license of the component for which the patch applies.
- When modifying a file through this contribution process, you may (but don't have to) claim copyright by adding a copyright line.
- Never alter copyright statements made by others, but only add your own.
Some files will make an exception to the above rules as described below:
- Files for which copyright is not claimed and for which this information was not trivial to fetch (for example backporting patches, importing build recipes etc. when upstream doesn't provide the SPDX information in the first place)
- license files (for example `common-licenses` in bitbake layers)
- for files copyrighted by projects contributors (**"First Party Files"**):
- any new file MUST have a SPDX header (copyright and license);
- for files that don't support headers (for example binaries, patches etc.) an associated `.license` file MUST be included with the relevant SPDX information;
- do not add Copyright Year as part of the SPDX header information;
- the general rule for patch files is to use the MIT license and *not* the license of the component for which the patch applies - the latter solution would be error-prone and hard to manage and maintain in the long run, and there may be difficult-to-handle cases (what if the patches modifies multiple files in the same component - eg. gcc - which are subject to different licenses?);
- when modifying a file through this contribution process, you may (but don't have to) claim copyright by adding a copyright line;
- you MUST NOT alter copyright statements made by others, but only add your own;
- for files copyrighted by third parties and just added to the project by contributors, eg. files copied from other projects or back-ported patches (**"Third Party Files"**):
- if upstream files already have SPDX headers, they MUST be left unchanged;
- if upstream files do *not* have SPDX headers:
- the exact upstream provenance (repo, revision, path) MUST be identified;
- you MUST NOT add SPDX headers to Third Party Files;
- copyright and license information, as well as upstream provenance information (in the "Comment" section), MUST be stored in <span class="title-ref">.reuse/dep5</span> following [Debian dep5 specification](https://dep-team.pages.debian.net/deps/dep5/) (see examples below);
- you MUST NOT use wildcards (\*) in dep5 "Files" paragraphs even if Debian specs allow it: it may lead to unnoticed errors or inconsistencies in case of future file additions that may be covered by wildcard expressions even if they have a different license;
- in case of doubts or problems in finding the correct license and copyright information for Third Party Files, contributors may ask the project's Legal Team in the project mailing list <oniro-dev@eclipse.org>;
### SPDX Header Example
......@@ -158,6 +163,26 @@ Make sure all of your submitted new files have a licensing statement in the head
*/
```
### DEP5 "Files" Paragraph Examples
``` text
Files: meta-oniro-staging/recipes-containers/buildah/buildah_git.bb
Copyright: OpenEmbedded Contributors
License: MIT
Comment: Recipe file for buildah copied from meta-virtualization project at
https://git.yoctoproject.org/meta-virtualization,
recipes-containers/buildah.
README file of meta-virtualization project states:
"All metadata is MIT licensed unless otherwise stated."
Files: meta-oniro-staging/recipes-devtools/ninja/ninja/0001-feat-support-cpu-limit-by-cgroups-on-linux.patch
Copyright: Google Inc.
License: Apache-2.0
Comment: Patch for ninja backported from Ninja project at
https://github.com/ninja-build/ninja, commit 540be33
Copyright text left as found in the header of the patched file.
```
### Substantial Contributions
Therefore, if your contribution is only a patch directly applied to an existing file, then you are not required to do anything. If your contribution is an entire new project, or a substantial, copyrighted contribution, you **MUST** make sure that you do that following the [IP Policy](https://git.ostc-eu.org/oss-compliance/ip-policy/) and that you comply with REUSE standard to include the licensing information where they are required.
......
......@@ -17,17 +17,26 @@ All projects and files for an hosted project **MUST** be `REUSE <https://reuse.s
compliant. REUSE requires SPDX information for each file, rules for which are
as follows:
* Any new file must have a SPDX header (copyright and license).
* For files that don't support headers (for example binaries, patches etc.) an associated ``.license`` file must be included with the relevant SPDX information.
* Do not add Copyright Year as part of the SPDX header information.
* The general rule of thumb for the license of a patch file is to use the license of the component for which the patch applies.
* When modifying a file through this contribution process, you may (but don't have to) claim copyright by adding a copyright line.
* Never alter copyright statements made by others, but only add your own.
* for files copyrighted by projects contributors (**"First Party Files"**):
Some files will make an exception to the above rules as described below:
* any new file MUST have a SPDX header (copyright and license);
* for files that don't support headers (for example binaries, patches etc.) an associated ``.license`` file MUST be included with the relevant SPDX information;
* do not add Copyright Year as part of the SPDX header information;
* the general rule for patch files is to use the MIT license and *not* the license of the component for which the patch applies - the latter solution would be error-prone and hard to manage and maintain in the long run, and there may be difficult-to-handle cases (what if the patches modifies multiple files in the same component - eg. gcc - which are subject to different licenses);
* when modifying a file through this contribution process, you may (but don't have to) claim copyright by adding a copyright line;
* you MUST NOT alter copyright statements made by others, but only add your own;
* for files copyrighted by third parties and just added to the project by contributors, eg. files copied from other projects or back-ported patches (**"Third Party Files"**):
* if upstream files already have SPDX headers, they MUST be left unchanged;
* if upstream files do *not* have SPDX headers:
* the exact upstream provenance (repo, revision, path) MUST be identified;
* you MUST NOT add SPDX headers to Third Party Files;
* copyright and license information, as well as upstream provenance information (in the "Comment" section), MUST be stored in `.reuse/dep5` following `Debian dep5 specification <https://dep-team.pages.debian.net/deps/dep5/>`_ (see examples below);
* you MUST NOT use wildcards (\*) in dep5 "Files" paragraphs even if Debian specs allow it: it may lead to unnoticed errors or inconsistencies in case of future file additions that may be covered by wildcard expressions even if they have a different license;
* in case of doubts or problems in finding the correct license and copyright information for Third Party Files, contributors may ask the project's Legal Team in the project mailing list oniro-dev@eclipse.org;
* Files for which copyright is not claimed and for which this information was not trivial to fetch (for example backporting patches, importing build recipes etc. when upstream doesn't provide the SPDX information in the first place)
* license files (for example ``common-licenses`` in bitbake layers)
SPDX Header Example
-------------------
......@@ -42,6 +51,29 @@ Make sure all of your submitted new files have a licensing statement in the head
* SPDX-License-Identifier: Apache-2.0
*/
DEP5 "Files" Paragraph Examples
-------------------------------
.. code-block:: text
Files: meta-oniro-staging/recipes-containers/buildah/buildah_git.bb
Copyright: OpenEmbedded Contributors
License: MIT
Comment: Recipe file for buildah copied from meta-virtualization project at
https://git.yoctoproject.org/meta-virtualization,
recipes-containers/buildah.
README file of meta-virtualization project states:
"All metadata is MIT licensed unless otherwise stated."
Files: meta-oniro-staging/recipes-devtools/ninja/ninja/0001-feat-support-cpu-limit-by-cgroups-on-linux.patch
Copyright: Google Inc.
License: Apache-2.0
Comment: Patch for ninja backported from Ninja project at
https://github.com/ninja-build/ninja, commit 540be33
Copyright text left as found in the header of the patched file.
Substantial Contributions
-------------------------
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment