Mojaloop OpenSSF FLOSS "Passing" Level Evaluation

[gibaros]

Goal:

As a <stakeholder|persona>

I want to

so that

Acceptance Criteria:

• Evaluate OpenSSF FLOSS Passing
• Provide URL or required evidence for "Passing" level items
• Create issues with gaps identified

Complexity: <High|Medium|Low> > A short comment to remind the reason for the rating

Uncertainty: <High|Medium|Low> > A short comment to remind the reason for the rating

---

Tasks:

• TBD [ @? ]

Checked	Level	URL	Comments
	Passing
	Basics
✅	Basic project website content	https://mojaloop.io/
[ ]	The project website MUST succinctly describe what the software does (what problem does it solve?). [description_good] Details: This MUST be in language that potential users can understand (e.g., it uses minimal jargon).
✅	The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software. [interact]	https://docs.mojaloop.io/community/contributing/contributors-guide.html#where-do-i-send-bugs-questions-and-feedback https://github.com/mojaloop/mojaloop/blob/main/contribute/Reporting-Bugs.md
- []	The information on how to contribute MUST explain the contribution process (e.g., are pull requests used?) {Met URL} [contribution] Details: We presume that projects on GitHub use issues and pull requests unless otherwise noted. This information can be short, e.g., stating that the project uses pull requests, an issue tracker, or posts to a mailing list. Rationale: Contributors need to understand not only how to contribute, but also the overall contribution process, so that they'll understand how their work could be incorporated and what the expectations are after the initial submission. Note that criterion "interact" requires that the contribution information be on the project website.	https://docs.mojaloop.io/community/contributing/contributors-guide.html https://docs.mojaloop.io/community/standards/creating-new-features.html
- []	The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). {Met URL} [contribution_requirements]	https://docs.mojaloop.io/community/contributing/contributors-guide.html https://docs.mojaloop.io/community/standards/creating-new-features.html
- [x]	FLOSS license	https://github.com/mojaloop/documentation/blob/master/LICENSE.md	The software produced by the project MUST be released as FLOSS. [floss_license] Details: FLOSS is software released under licenses that meet the Open Source or Free Software definitions. Examples include MIT, Apache 2.0, GPL, etc. The software may also have other license options.
- [x]	FLOSS license		It is SUGGESTED that any required license(s) for the software produced by the project be approved by the Open Source Initiative (OSI). [floss_license_osi] Details: OSI-approved licenses are widely recognized. Unusual licenses can cause long-term issues. Rationale: OSI approval ensures a well-understood, standard license.
- [x]	FLOSS license		The project MUST post the license(s) of its results in a standard location in their source repository. {Met URL} [license_location] Details: Typically a top-level LICENSE or COPYING file. Encourages clarity on project licensing.
- [x]	Documentation	https://docs.mojaloop.io/adoption/ https://docs.mojaloop.io/community/ https://docs.mojaloop.io/product/ https://docs.mojaloop.io/technical/ https://docs.mojaloop.io/technical/technical/deployment-guide/ https://github.com/mojaloop/iacv2-docs	The project MUST provide basic documentation for the software produced by the project. [documentation_basics] Details: Includes instructions on installation, starting, usage, and secure usage, if appropriate. Users need documentation to learn how to use the software effectively.
- [x]	Documentation	https://github.com/mojaloop/documentation/tree/master/docs/technical/api	The project MUST provide reference documentation that describes the external interface of the software produced by the project. [documentation_interface] Details: Document APIs, command-line parameters, or REST interfaces clearly so they can be understood without reading the entire source code.
- [x]	Other		The project sites (website, repository, and download URLs) MUST support HTTPS using TLS. [sites_https] Details: Using HTTPS protects against man-in-the-middle attacks. If HTTP is used, it should redirect to HTTPS.
- [x]	Other	https://github.com/mojaloop/design-authority-project https://github.com/mojaloop/mojaloop-specification/issues https://github.com/mojaloop/design-authority-project/issues https://github.com/mojaloop/project/issues Slack invite link	The project MUST have one or more mechanisms for discussion that are searchable, URL-addressable, and accessible. [discussion] Details: Acceptable mechanisms include mailing lists, GitHub issues, etc. Proprietary clients aren't required.
- [x]	Other		The project SHOULD provide documentation in English and accept bug reports in English. [english] Details: English is the lingua franca of technology, enabling more worldwide collaboration.

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: TBC
• QA/Review: TBC