Skip to content

STD-GOV-129: Open Source Policy

Owner Classification Review Date Status
CDO Office Internal April 2027 Active

STD-GOV-129: Open Source Policy

Field Value
Standard STD-GOV-129
Title Open Source Policy
Status Draft
Owner CDO
Created 2026-04-03
Review Annually

Purpose

Govern the consumption, management and contribution of open source software at Simpaisa. Open source is fundamental to Simpaisa's stack — Go, SurrealDB, KrakenD, NSQ, React and dozens of libraries. Without clear policy, the organisation risks licence violations, unpatched vulnerabilities, supply chain attacks and inadvertent IP leakage. This standard ensures open source is used safely and strategically.

Scope

All open source software consumed in Simpaisa's applications, infrastructure, tooling and development environments. Also covers any contribution of code to external open source projects by Simpaisa employees or contractors.

Licence Policy

Whitelist (Approved for Use)

These licences are pre-approved for consumption in all contexts:

Licence SPDX Identifier Notes
MIT MIT Permissive, no restrictions
Apache 2.0 Apache-2.0 Permissive, patent grant included
BSD 2-Clause BSD-2-Clause Permissive
BSD 3-Clause BSD-3-Clause Permissive
ISC ISC Permissive, functionally equivalent to MIT
MPL 2.0 MPL-2.0 Weak copyleft, file-level — acceptable for libraries

Blacklist (Prohibited)

These licences are prohibited for server-side use:

Licence SPDX Identifier Reason
AGPL 3.0 AGPL-3.0 Copyleft extends to network interaction — forces disclosure of proprietary code
SSPL SSPL-1.0 Service-level copyleft — incompatible with commercial SaaS/payment processing
GPL 3.0 GPL-3.0 Strong copyleft — prohibited for server-side linking. Acceptable for standalone CLI tools only

Grey Zone (Requires Review)

Licences not on either list require Security Lead review before adoption:

  • LGPL — acceptable if dynamically linked only; review required.

  • Creative Commons — acceptable for documentation/assets only; not for code.

  • Dual-licensed projects — must use the permissive licence option.

  • Custom/proprietary open source licences — case-by-case review.

Vulnerability Scanning

Tooling

Tool Purpose Integration Point
Dependabot Dependency version monitoring Bitbucket (via GitHub mirror for scanning)
Trivy Container image and filesystem scan CI pipeline, pre-deployment gate

Scanning Cadence

  • Every build — Trivy scans container images. Critical/high vulnerabilities block deployment.

  • Daily — Dependabot checks for new vulnerability disclosures against current dependencies.

  • Weekly — Security Lead reviews outstanding vulnerability report.

Update Cadence

Update Type Maximum Time to Apply Process
Security patches 7 calendar days Automated PR via Dependabot. Fast-track review.
Minor versions 30 calendar days Standard PR review. Test in staging first.
Major versions Quarterly Evaluate breaking changes. Test plan required. May require ADR if architectural impact.

Exceptions

  • If a security patch introduces breaking changes, the team has 14 days instead of 7, with documented justification.

  • Major version upgrades for core dependencies (Go, SurrealDB, React) require ARB review.

Dependency Management

  • All Go dependencies managed via go.mod with pinned versions (no floating).

  • All Node.js dependencies use exact versions in package-lock.json (no ^ or ~ in production).

  • Dependency tree audited quarterly for transitive dependencies with blacklisted licences.

  • Maximum dependency depth reviewed — prefer shallow dependency trees.

  • Abandoned dependencies (no commits in 12 months, no maintainer response) flagged for replacement.

Open Source Contribution Policy

Simpaisa may contribute to open source projects under the following conditions:

Approval

  • CDO approval required for all contributions.

  • IP review by legal/CDO before any code is published externally.

  • No proprietary code, algorithms, business logic or Simpaisa-specific configuration in contributions.

Permitted Contributions

  • Bug fixes to dependencies Simpaisa consumes.

  • Generic utility functions with no business logic.

  • Documentation improvements.

  • Test cases for upstream projects.

Prohibited Contributions

  • Payment routing algorithms or any competitive IP.

  • Fraud scoring models or training data.

  • Channel adapter implementations.

  • Any code referencing Simpaisa's internal architecture, merchant data or transaction flows.

Process

  1. Engineer identifies contribution opportunity and creates Beads issue with tag oss-contribution.

  2. CDO reviews for IP concerns.

  3. If approved, engineer forks on personal account (not Simpaisa org), makes contribution.

  4. Contribution must use Simpaisa's standard code quality practices.

Supply Chain Security

  • All dependencies pulled from official registries only (pkg.go.dev, npmjs.com).

  • No vendoring from unverified sources or personal forks in production.

  • Go module checksums verified via GONOSUMCHECK disabled (default behaviour).

  • Consider adopting SLSA framework for critical dependencies in future.

Actions

# Action Owner Deadline
1 Run full licence audit across all repositories Security Lead 2026-Q2
2 Configure Trivy to block blacklisted licences in CI Platform Lead 2026-Q2
3 Establish Dependabot for all active repositories Platform Lead 2026-Q2
4 Create abandoned dependency watchlist Platform Lead 2026-Q3

References

  • STD-GOV-126-TECHNOLOGY-LIFECYCLE-MANAGEMENT.md

  • STD-SECURITY-050-VULNERABILITY-MANAGEMENT.md

  • STD-GOV-130-INTELLECTUAL-PROPERTY-MANAGEMENT.md