FINOS Financial Services Open Source Developer study materials
FINOS Financial Services Open Source Developer study resources

FINOS Financial Services Open Source Developer flashcards

FINOS Financial Services Open Source Developer · Build recall with a focused review session.

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

Copyleft license obligation
Copyleft licenses such as GPL require that distributed derivative works be licensed under the same terms, making source code available to recipients. Network-use clauses extend this to hosted services.
Apache-2.0 patent grant
Apache-2.0 includes an express patent license from contributors and terminates that grant for anyone who sues alleging patent infringement over the work. MIT and BSD lack this clause.
AGPL network trigger
AGPL Section 13 requires offering Corresponding Source to users who interact with modified covered software over a network, even without distributing binaries. This affects hosted financial applications.
OSI Open Source Definition
Ten criteria including free redistribution, source code availability, derived works, integrity of author source, no discrimination against persons or fields, and technology neutrality. Source-available licenses fail it.
Developer Certificate of Origin
A per-commit attestation that the contributor has the right to submit the code under the project license. Recorded as a Signed-off-by line in the commit message.
Contributor License Agreement
A legal agreement, often signed once, granting or assigning rights in contributions to the project steward. It can override the inbound=outbound default and enable relicensing.
Inbound equals outbound
The norm that contributions are accepted under the same license the project distributes under, so no separate broader grant is taken from contributors.
Trademark versus copyright
Copyright licenses govern code use and modification; they do not grant rights to project names or logos. Trademark policies separately control branding and endorsement claims.
FINOS mission
FINOS, a Linux Foundation project, hosts open source software and standards that promote collaboration and interoperability across financial services firms, technology vendors, and regulators.
FDC3 standard purpose
FDC3 defines desktop interoperability for financial applications through intents, shared context data, app directories, and desktop agents, letting separately built apps work together on a trader desktop.
Morphir business logic IR
A FINOS project providing a technology-agnostic intermediate representation of business logic, so one model can generate code for multiple languages and platforms consistently.
Foundation-hosted governance
A neutral foundation holds trademarks and project assets and applies a documented lifecycle, reducing single-vendor control risk compared with vendor-owned projects.
Mutualized open source
Shared, non-differentiating infrastructure built collaboratively across institutions to cut duplicated cost, such as data models, interoperability standards, and compliance tooling.
FINOS project lifecycle
Documented stages covering contribution, incubation, active, and archived states, with maintainer responsibilities and graduation criteria defined by community governance.
Fork and pull request flow
Fork the repository, branch, commit, push, and open a pull request against upstream. Maintainers review and merge; contributors sync their fork to stay current.
DCO sign-off syntax
A commit trailer reading Signed-off-by: Full Name <email>, certifying the Developer Certificate of Origin 1.1 terms for that specific contribution.
Software composition analysis
Automated scanning of dependencies and transitive libraries to detect license obligations, version conflicts, and known vulnerabilities before code is merged or released.
SPDX license identifier
A standardized short string such as Apache-2.0 or MIT placed in manifests and file headers so tooling can detect and validate licenses without manual review.
NOTICE file propagation
Apache-2.0 requires redistributors to include the contents of any NOTICE file, preserving attribution notices alongside the license text.
Contribution provenance check
Verifying that submitted code was authored by the contributor, is compatibly licensed, and is not copied from proprietary or unclear sources, including AI-generated code.
Open source intake review
A gated process of license classification, security scanning, architecture approval, and inventory registration before a component may be used in production.
License policy tiers
Firm-defined categories such as approved, conditional, and prohibited, mapping licenses to required controls like isolation, disclosure, or outright ban for hosted services.
Software bill of materials
A machine-readable inventory of components and dependencies, typically SPDX or CycloneDX, supporting supply-chain transparency and third-party risk reporting.
InnerSource model
Applying open source practices such as pull requests, maintainers, and open code review inside an institution while keeping the code proprietary and access-controlled.
Outbound code publication review
Approval of the chosen license, trademark use, and removal of confidential data, credentials, and client identifiers before firm code is released publicly.
Open source health metrics
Indicators such as maintainer count, commit cadence, release frequency, issue responsiveness, and security advisory history used to judge project sustainability risk.
FIPS 140 module validation
Cryptographic libraries must use a validated module where regulation demands it; validation applies to a specific module version, not the library brand generally.
CI license and DCO checks
Pipeline jobs that verify license headers, SPDX identifiers, CLA or DCO sign-off, and dependency licenses on each pull request, blocking merge on failure.
Branch protection rules
Repository settings requiring reviews, passing status checks, and sometimes signed commits before merging to protected branches such as main.
Semantic versioning contract
MAJOR.MINOR.PATCH where MAJOR signals breaking changes, MINOR adds compatible features, and PATCH fixes bugs; consumers pin and review changelogs before upgrading.
Coordinated vulnerability disclosure
A private report to maintainers, a fix developed under embargo, then a public advisory with CVE assignment, protecting users before exploit details are published.
Community health files
Standard repository files including README, CONTRIBUTING, CODE_OF_CONDUCT, SECURITY, and LICENSE that document expectations for contributors and users.
Dependency automation bots
Tools such as Dependabot or Renovate that open update pull requests for dependencies; auto-merge is gated on passing tests and license checks.