Refactor Legal Requirements & Titles (#216)

* refactored LE_01

Signed-off-by: Eddie Knight <[email protected]>

* refactored LE_02

Signed-off-by: Eddie Knight <[email protected]>

* refactored LE_03

Signed-off-by: Eddie Knight <[email protected]>

---------

Signed-off-by: Eddie Knight <[email protected]>

Author: eddie-knight

baseline/OSPS-LE.yaml

@@ -11,8 +11,9 @@ description: |
 controls:
   - id: OSPS-LE-01
     title: |
-      Require code contributors to assert that they are legally authorized to
-      commit
+      The version control system MUST require all code contributors to assert
+      that they are legally authorized to make the associated contributions
+      on every commit.
     objective: |
       Ensure that code contributors are aware of and acknowledge their legal
       responsibility for the contributions they make to the project, reducing
@@ -35,9 +36,9 @@ controls:
     assessment-requirements:
       - id: OSPS-LE-01.01
         text: |
-          The version control system MUST require all code contributors to assert
-          that they are legally authorized to commit the associated contributions
-          on every commit.
+          While active, the version control system MUST require all code
+          contributors to assert that they are legally authorized to make the
+          associated contributions on every commit.
         applicability:
           - Maturity Level 2
           - Maturity Level 3
@@ -46,11 +47,13 @@ controls:
           contributors to assert that they are legally authorized to commit the
           associated contributions on every commit. Use a status check to ensure
           the assertion is made.
+          Some version control systems, such as GitHub, may include this in the
+          platform terms of service.
 
   - id: OSPS-LE-02
     title: |
-      Ensure that the license for the source code meets the OSI Open Source
-      Definition or the FSF Free Software Definition
+      All licenses for the project MUST meet the OSI Open Source Definition
+      or the FSF Free Software Definition.
     objective: |
       Ensure that the project's source code is distributed under a recognized
       and legally enforceable open source software license, providing clarity on
@@ -73,8 +76,8 @@ controls:
     assessment-requirements:
       - id: OSPS-LE-02.01
         text: |
-          The license for the source code MUST meet the OSI Open Source Definition
-          or the FSF Free Software Definition.
+          While active, the license for the source code MUST meet the OSI Open
+          Source Definition or the FSF Free Software Definition.
         applicability:
           - Maturity Level 1
           - Maturity Level 2
@@ -87,10 +90,27 @@ controls:
           Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU
           General Public License (GPL). Releasing to the public domain meets
           this control if there are no other encumbrances such as patents.
+      - id: OSPS-LE-02.02
+        text: |
+          While active, the license for the released software assets MUST meet
+          the OSI Open Source Definition or the FSF Free Software Definition.
+        applicability:
+          - Maturity Level 1
+          - Maturity Level 2
+          - Maturity Level 3
+        recommendation: |
+          If a different license is included with released software assets,
+          ensure it is an approved license by the Open Source Initiative (OSI),
+          or a free license as approved by the Free Software Foundation (FSF).
+          Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause
+          revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the
+          GNU General Public License (GPL). Note that the license for the
+          released software assets may be different than the source code.
 
   - id: OSPS-LE-03
     title: |
-      Maintain an open source license for the project in a standard location
+      All licenses for the project's source code MUST be maintained in a 
+      standard location within the corresponding repository.
     objective: |
       Ensure that the project's source code and released software assets are
       distributed with the appropriate license terms, making it clear to users
@@ -111,8 +131,9 @@ controls:
     assessment-requirements:
       - id: OSPS-LE-03.01
         text: |
-          The license for the source code MUST be maintained in a standard
-          location within the project's repository.
+          While active, the license for the source code MUST be maintained in
+          the corresponding repository's LICENSE file, COPYING file, or
+          LICENSE/ directory.
         applicability:
           - Maturity Level 1
           - Maturity Level 2
@@ -121,19 +142,22 @@ controls:
           Include the project's source code license in the project's LICENSE
           file, COPYING file, or LICENSE/ directory to provide visibility and
           clarity on the licensing terms. The filename MAY have an extension.
+          If the project has multiple repositories, ensure that each repository
+          includes the license file.
       - id: OSPS-LE-03.02
         text: |
-          The license for the released software assets MUST meet the OSI Open
-          Source Definition or the FSF Free Software Definition.
+          While active, the license for the released software assets MUST be
+          included in the released source code, or in a LICENSE file, COPYING
+          file, or LICENSE/ directory alongside the corresponding release
+          assets.
         applicability:
           - Maturity Level 1
           - Maturity Level 2
           - Maturity Level 3
         recommendation: |
-          If a different license is included with released software assets,
-          ensure it is an approved license by the Open Source Initiative (OSI),
-          or a free license as approved by the Free Software Foundation (FSF).
-          Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause
-          revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the
-          GNU General Public License (GPL). Note that the license for the
-          released software assets may be different than the source code.
+          Include the project's released software assets license in the released
+          source code, or in a LICENSE file, COPYING file, or LICENSE/ directory
+          alongside the corresponding release assets to provide visibility and
+          clarity on the licensing terms. The filename MAY have an extension.
+          If the project has multiple repositories, ensure that each repository
+          includes the license file.