From 01fd122f34838602a2461a2db55d04ec62002871 Mon Sep 17 00:00:00 2001
From: Alberto Pianon <alberto@pianon.eu>
Date: Thu, 10 Nov 2022 16:37:09 +0000
Subject: [PATCH] Revert "capitalize MUST/MUST NOT"
This reverts commit 6d1d7fa32467ffd8af82d3682862f0d75159ca97
---
CONTRIBUTING.md | 12 ++++++------
contributing/reuse.rst | 14 +++++++-------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 3805441..be4bb95 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -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 <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
+ - 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>.
### SPDX Header Example
diff --git a/contributing/reuse.rst b/contributing/reuse.rst
index 94a5329..5e2b80d 100644
--- a/contributing/reuse.rst
+++ b/contributing/reuse.rst
@@ -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.
--
GitLab