Formalize an open source software (OSS) policy

[godfreykutumela]

Goal:

As a security governance officer

`I want to' compliment the current statement on the Mojaloop OSS licensing by introducing a formal OSS policy to guide and govern the selection of safe to use and permissive OSS components. I spotted this as gap while I was busy finalizing the code security standard which will now reference this policy for anything OSS related and allowing the standard to focus on the secure design and securing the custom written code.

This policy does not replace Mojaloop OSS software's license is here: https://docs.mojaloop.io/getting-started/license.html but rather provide a governance framework to ensure alignment with it.

so that we can enforce compliance with the Mojaloop OSS license category while ensuring that only secure, up to date and supported OSS components are used within all Mojaloop codebases - core, vnext and Actio

Acceptance Criteria:

• [ ] TBD

Complexity: Low

Uncertainty: Low

Tasks:

• [ ] TBD [ @? ]

Done

• [ ] Acceptance Criteria pass
• [ ] Designs are up-to date
• [ ] Unit Tests pass
• [ ] Integration Tests pass
• [ ] Code Style & Coverage meets standards
• [ ] Changes made to config (default.json) are broadcast to team and follow-up tasks added to update helm charts and other deployment config.
• [ ] TBD

Pull Requests:

• [ ] TBD

Follow-up:

• N/A

Dependencies:

• N/A

Accountability:

• Owner: @godfreykutumela
• QA/Review: @millerabel @kjw000

[godfreykutumela]

Draft policy for review until 19 Oct 2022 - https://docs.google.com/document/d/1pMgnRLUUo6bEDvLXufWj4ahd6xUCQHXU/edit?usp=sharing&ouid=111271012303486374335&rtpof=true&sd=true

[godfreykutumela]

Additional Guideline on OSS License Categories. CAST-Highlight-Open-Source-License-Rulebook (1).pdf