FINOS Financial Services Open Source Developer cheat sheet

Open source license categories: permissive (Apache-2.0, MIT, BSD) grant broad reuse with attribution; copyleft (GPL, AGPL, LGPL) impose reciprocal source-disclosure obligations on distribution or network use.

Apache-2.0 adds an express patent grant and patent-retaliation clause; MIT and BSD do not, so patent exposure review differs by license.

AGPL's Section 13 triggers source disclosure when users interact with modified software over a network, which matters for hosted financial applications.

OSI-approved licenses meet the Open Source Definition's ten criteria; 'source-available' licenses (e.g., BUSL, SSPL) are not open source by that definition.

Governance models: single-vendor, foundation-hosted (neutral), and community-led; foundation hosting typically transfers trademark and IP stewardship to the foundation.

A Contributor License Agreement (CLA) assigns or licenses contributions to a steward; a DCO is a lightweight per-commit sign-off asserting the right to contribute.

Inbound=outbound is the default norm: contributions are accepted under the project's outbound license unless a CLA states otherwise.

Trademark rights are separate from copyright: a license grants code rights but not the right to use project names or logos.

License compatibility rule: combining copyleft code into a permissive-licensed product can force the combined work under the copyleft terms; check obligations before mixing.

FINOS is a project of the Linux Foundation; it hosts open source projects and standards aimed at financial services collaboration.

FINOS deliverables span code projects (e.g., FDC3, Morphir, Legend, Perspective) and standards/specifications governed by the foundation's project lifecycle.

FDC3 defines the Financial Desktop Connectivity and Collaboration Consortium interoperability standard: intents, context data, app directories, and desktop agents.

Morphir provides a technology-agnostic intermediate representation of business logic so the same model can target multiple languages and platforms.

FINOS membership tiers include financial-institution members, technology/vendor members, and associate members; contributions flow through project maintainers.

The FINOS Community Governance model covers project contribution, incubation, and lifecycle stages, including archived projects.

Participation channels include the FINOS GitHub organization, project mailing lists, and community calls open to members and non-members.

Mutualized open source in finance targets shared non-differentiating infrastructure (data models, interoperability, compliance tooling) to reduce duplicated build cost.

Standard GitHub contribution loop: fork, create a topic branch, commit with a sign-off if DCO required, open a pull request, respond to review, and squash/merge per project rules.

Before contributing, confirm the project's contribution policy: CLA vs DCO, commit message conventions, and whether a signed CLA is required on first PR.

Only contribute code you authored or that is compatibly licensed; do not paste code from Stack Overflow or proprietary repositories without a documented license.

DCO sign-off line format: Signed-off-by: Full Name ; it certifies the Developer Certificate of Origin 1.1 terms.

Scan dependencies with an SCA tool (e.g., FOSSA, Snyk, Black Duck) before merging to detect license conflicts and known vulnerabilities.

SPDX license identifiers (e.g., Apache-2.0, MIT) in package manifests and file headers make automated license detection reliable.

A NOTICE file required by Apache-2.0 must be preserved and propagated when redistributing the work.

Review third-party contributions for provenance: check the author's employer IP policy, prior art, and whether the code was generated by an AI tool with unclear licensing.

Open source intake process: request, license review, security scan (SCA/SAST), architecture approval, and registration in an internal component inventory.

License policy tiers typically classify licenses as approved, approved-with-conditions (e.g., LGPL, MPL), or prohibited (e.g., AGPL for hosted services), per firm risk appetite.

SBOM generation (SPDX or CycloneDX) supports software supply-chain transparency and regulatory expectations for third-party risk management.

Open source use falls under third-party/vendor risk frameworks: track maintainer activity, release cadence, and end-of-life status as risk indicators.

Export-control and sanctions screening can apply to contributors and to cryptography-bearing code; coordinate with compliance before publishing.

Publishing firm-authored code requires approval of the outbound license, trademark use, and removal of confidential data, credentials, and client identifiers.

InnerSource applies open source collaboration practices (pull requests, maintainers, code review) inside the firm while keeping code proprietary.

Regulatory expectations (e.g., operational resilience and model risk guidance) require documented ownership, patching SLAs, and incident response for critical open source components.

Cryptographic libraries need FIPS 140-validated modules where regulation requires; confirm the specific module, not just the library name.

CI pipelines for open source projects typically run lint, unit tests, license-header checks, DCO/CLA verification, and SCA on every pull request.

Branch protection rules enforce required reviewers, status checks, and signed commits before merge to main.

Semantic versioning (MAJOR.MINOR.PATCH) communicates breaking changes; consumers pin versions and review changelogs before upgrading.

Dependency automation (e.g., Dependabot, Renovate) opens update PRs; auto-merge only when tests and license checks pass.

Code review norms: keep PRs small, describe intent and testing, and separate refactoring from behavior changes.

Issue triage uses labels (bug, enhancement, good first issue) and a documented governance process for maintainer decisions.

Community health files (README, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, LICENSE) are expected in mature repositories.

Security disclosure follows coordinated vulnerability disclosure: private report, fix, advisory, and CVE assignment where applicable.

Container and build reproducibility: pin base images by digest, use lockfiles, and sign artifacts (e.g., Sigstore) for supply-chain integrity.