Refine compliance management content for clarity Chapters 3 +

OpenChain-Training/en/Online-Training-Courses/LFC194 Course Content/Implementing Open Source License Compliance Management (LFC194).md

@@ -431,7 +431,7 @@ Support requirements:
 
 - Ensure adequate compliance staffing and designate clear lines of responsibility.
 - If necessary, e.g. for process efficiency, adapt existing business processes to support the open source compliance program.
-- Have training on the Organization’s open source policy made available to everyone.
+- Have training on the Organization’s open source policy and process made available to everyone.
 - Track progress of all open source compliance activities.
 
 ### Identification and Audit
@@ -509,7 +509,7 @@ The following step is called Approval and Registration.
 
 **Steps for approvals and registration:**
 
-- Based on the results of the software audit and review conducted in the previous steps, the software may or may not be approved for use.
+- Based on the results of the software audit and review conducted in the previous steps, the open source software may or may not be approved for use.
 - The approval should specify versions of approved open source components, the approved usage model for the component, and any other applicable obligations under the open source license.
 - Approvals should be made at appropriate authority levels. Usually, the open source review team is involved in the activities, and rarely Executive decisions shall be obtained and recorded.
 
@@ -545,8 +545,8 @@ The next compliance activity is verification.
 **Steps to verify that the software to be distributed has been reviewed and approved:**
 
 - Verify that open source packages finalized for distribution have been identified and approved.
-- Verify as much as practical that the reviewed source code matches the binary equivalents shipping in the product.
-- Verify that instructions on how to request source code are included when required by the identified open source license.
+- Verify that the reviewed source code matches the binary equivalents shipping in the product.
+- Verify that instructions on how to request source code are included when required by the identified open source license(s).
 - Verify compliance with other identified obligations.
 
 **Outcome:**
@@ -706,7 +706,7 @@ This type of failure occurs during the development process when engineers add op
 
 This type of failure can be avoided by offering training to engineering staff about compliance issues, the different types of open source licenses and the implications of including open source in proprietary source code and conducting regular source code scans or audits for all the source code in the build environment.
 
-#### Unplanned/unintended etc., linking of copyleft open source and proprietary source code
+#### Unplanned/unintended linking between copyleft open source and proprietary source code
 
 This type of failure can be discovered using a dependency tracking tool that shows any linking (and type of linking - static or dynamic) between different software components.
 
@@ -724,11 +724,11 @@ We will now discuss issues specific to license compliance. Like the previous sec
 
 #### Failure to provide source code/appropriate license, attribution or notice information
 
-This type of failure can be avoided by publishing a checklist in the product release cycle before the product becomes available in the marketplace. This checklist would examine if appropriate licenses are shared, if attribution or notice files are in place, and if links or copies of source code that needs to be shared as part of the license obligation are provided.
+This type of failure can be avoided by publishing a license compliance checklist in the product release cycle before the product becomes available in the marketplace. This checklist would examine if appropriate license texts are shared, if attribution or notice files are in place, and if links or copies of source code that needs to be shared as part of the license obligation are provided.
 
 #### Providing the incorrect version of accompanying source code
 
-This type of failure can be avoided by adding the verification step into the compliance process to ensure that the correct accompanying source code for the binary version is being published or otherwise made available. It is good practice, and some licenses require it, that the source code should be made available for several years beyond the last distribution of the software.
+This type of failure can be avoided by adding a verification step into the compliance process to ensure that the accompanying source code for the binary version is being published or otherwise made available. Note that some licenses require that the source code is made available for several years beyond the last distribution of the software.
 
 #### Failure to provide source code for open source component modifications
 
@@ -893,21 +893,21 @@ When using third-party code, it is imperative to select from high quality, well-
 
 Don’t hesitate to seek guidance and advice from the appropriate people inside your Organization, such as the Open Source Program Office (OSPO), the legal department, or the office of the CTO. Make sure you are clear on who the right people are and what is the right department to talk to - this should be clearly specified in the Organization's policy documentation. To learn more about OSPOs, enroll in the [Open Source Management & Strategy](https://training.linuxfoundation.org/training/open-source-management-and-strategy/) course series offered by the Linux Foundation.
 
-Also, check the Organization’s policy regarding the approval process. For example, some Organizations may have extensive “approve” lists for third-party code. Others may require case-by-case approvals. Most will probably have a combination of different procedures depending on the task being worked on. The Organization open source policy should help clarify this for you.
+Also, check the Organization’s policy regarding the approval process. For example, some companies may have extensive “approve” lists for third-party code. Others may require case-by-case approvals. Most will probably have a combination of different procedures depending on the task being worked on. The Organization's open source policy should help clarify this for you.
 
 It is important to either finish the above action items or to follow other Organization guidelines before checking new code into the internal Organization systems. Checking the Organization's policy regarding the approval process typically goes beyond personal use of the code for a specified project. However, it is still encouraged considering the potential negative implications of the code accidentally being used by other teams in the future without approval if there is a process breakdown.
 
 Quite often a developer or development team will be in a situation where contributing code back to a third-party project makes sense (e.g. a bug fix, so that it isn’t necessary to keep making the same fix whenever a new version of the open source is released and used). In these situations, you should also check your Organization’s open source policy (or relevant documentation) to make sure that your intended contribution fits into the Organization’s approach and that of the community in question.
 
-Regardless of whether you are taking code into your Organization or sending code outside of your Organization, it is important to be mindful and careful of license information. It should be provided in all cases to ensure clarity. Be careful not to remove or inadvertently change existing open source license information or license texts in third-party code. This applies whether it is an inbound or outbound contribution. The clarity in the licensing is critical to ensuring that things run smoothly.
+Regardless of whether you are taking code into your Organization or sending code outside of your Organization, it is important to be mindful and careful of license information. It should be retained and provided in all cases to ensure clarity. Be careful not to remove or inadvertently change existing open source license information or license texts in third-party code. This applies whether it is an inbound or outbound contribution. Clarity of the licensing is critical to ensure that things run smoothly.
 
 Wherever possible, do not rename open source components unless there is a specific requirement to do so for your particular use case or because of a requirement in a license. The reason for this is simple: if and when you rename the code, you increase the risk of misinterpretation around the license and the chance of someone in the future failing to understand the provenance of this code.
 
 Adjacent to this, you should also gather and retain attribution information according to the licenses about the third-party open source projects you are using. This will allow you and your teams to quickly return to the projects and engage with them to receive the latest code and the latest available community support.
 
 ### Anticipate Compliance Process Requirements
 
-The overhead of using third-party code in a compliant way is not high, but it does exist. It is useful to ensure that you budget time and resources for addressing your Organization’s open source policy process requirements in the development work plans. This type of activity is part of the (small) cost of having access to open source or proprietary code from third-parties.
+The overhead of using third-party code in a compliant way is not high, but it does exist. It is useful to ensure that you budget time and resources for addressing your Organization’s open source policy and process requirements in the development work plans. This type of activity is part of the (small) cost of having access to open source code.
 
 Issues you may want to spend time on include considering the impact of linking or incorporating third-party code into your code or other third-party code. Understanding license implications early on can save you a lot of time later. This can be part of your architectural planning cycle.
 
@@ -935,7 +935,7 @@ Having some form of inbound code audit is extremely useful to get this done. Thi
     - No, existing license information should be preserved, and additional header information can be added for modifications or additions to source code --> Correct answer
 - Can a new version of a previously reviewed open source component create new compliance issues? Select all answers that apply.
     - Yes, if there is a change in the open source license for the new version of the open source component --> Correct answer
-    - Yes, if new dependencies are introduced with new versions which creates additional open source obligations --> Correct answer
+    - Yes, if new dependencies are introduced with new versions which create additional open source obligations --> Correct answer
     - No, authors are not allowed to change licenses or copyright notices for future versions of existing open source components. → Incorrect answer
     - None of the above → Incorrect answer