@@ -136,19 +136,19 @@ 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:
- 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;
- 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 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;
-never 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 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;
-do *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 <spanclass="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
-never 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 project's Legal Team in the project mailing list <oniro-dev@eclipse.org>.
@@ -18,20 +18,20 @@ compliant. REUSE requires SPDX information for each file, rules for which are
as follows:
* 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;
* 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 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;
* never 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 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
* do *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);
* never 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 project's Legal Team in the project mailing list oniro-dev@eclipse.org.
