phuse-org · epijim · Mar 17, 2023 · Mar 2, 2023 · Mar 17, 2023 · Mar 17, 2023
diff --git a/releasing.qmd b/releasing.qmd
@@ -54,7 +54,9 @@ If a package started its development on an internal git server, or a private rep
 
 When discussing the open sourcing of a codebase, it is important to flag to internal counsel existing external projects, and the overlap of scope with the project you intend to release.
 
-It is possible that decisions made before open sourcing could become a risk after open sourcing. As an example of a plausible scenario; a team need to implement a new function. This function exists in another GPL-3 copy left licenced project. To add that project would introduce multiple dependencies that aren't used by that particular function so a member of the team decides to copy the function into the package. One year later, the package is open sourced with the licence infringing code. Such an occurrence could be lessened by a Contributor Licence Agreement (CLA; see [the bot contributor-assistant](https://github.com/contributor-assistant/github-action) for an example of CLA automation). A CLA helps ensure that anyone contributing to a project acknowledges specific terms expected of contributions, like the contributions are novel code and the author will abide by the projects licence terms. In the absence of a CLA it is important to ensure that all code within the package is original, and there is no culture of cannibalising external code and infringing on people's copyright within the development team even for internal projects.
+It is possible that decisions made before open sourcing could become a risk after open sourcing. As an example of a plausible scenario; a team need to implement a new function. This function exists in another GPL-3 copy left licenced project. To add that project would introduce multiple dependencies that aren't used by that particular function so a member of the team decides to copy the function into the package. One year later, the package is open sourced under MIT. This would be a license breach as the authors have re-released copy-left code as permissive, and have incoporated the code without flagging it's source, changes they made, and the original licence (GPL3 requirements).
-It is possible that decisions made before open sourcing could become a risk after open sourcing. As an example of a plausible scenario; a team need to implement a new function. This function exists in another GPL-3 copy left licenced project. To add that project would introduce multiple dependencies that aren't used by that particular function so a member of the team decides to copy the function into the package. One year later, the package is open sourced under MIT. This would be a license breach as the authors have re-released copy-left code as permissive, and have incoporated the code without flagging it's source, changes they made, and the original licence (GPL3 requirements).
+It is possible that decisions made during development can become license liabilities. As an example of a plausible scenario; a team need to implement a new function. This function exists in another GPL-3 copy left licenced project. To add that project would introduce multiple dependencies that aren't used by that particular function so a member of the team decides to copy the function into the package. The newly developed package is open sourced under MIT. This would be a license breach as the authors have re-released copy-left code as permissive, and have incoporated the code without flagging it's source, changes they made, and the original licence (GPL3 requirements).
-It is possible that decisions made before open sourcing could become a risk after open sourcing. As an example of a plausible scenario; a team need to implement a new function. This function exists in another GPL-3 copy left licenced project. To add that project would introduce multiple dependencies that aren't used by that particular function so a member of the team decides to copy the function into the package. One year later, the package is open sourced under MIT. This would be a license breach as the authors have re-released copy-left code as permissive, and have incoporated the code without flagging it's source, changes they made, and the original licence (GPL3 requirements).
+It is possible that decisions made during development can become license liabilities. As an example of a plausible scenario; a team need to implement a new function. This function exists in another GPL-3 copy left licenced project. To add that project would introduce multiple dependencies that aren't used by that particular function so a member of the team decides to copy the function into the package. The newly developed package is open sourced under MIT. This would be a license breach as the authors have re-released copy-left code as permissive, and have incoporated the code without flagging it's source, changes they made, and the original licence (GPL3 requirements).
+
+Such an occurrence could be lessened by a Contributor Licence Agreement (CLA; see [the bot contributor-assistant](https://github.com/contributor-assistant/github-action) for an example of CLA automation). A CLA helps ensure that anyone contributing to a project acknowledges specific terms expected of contributions, like the contributions are novel code and the author will abide by the projects licence terms. In the absence of a CLA it is important to ensure that all code within the package is original, and there is no culture of cannibalising external code and infringing on people's copyright within the development team even for internal projects.
 
 ## Reputational risks and supporting others