FINOS Financial Services Open Source Developer key terms

The ten criteria maintained by the Open Source Initiative that a license must satisfy to be certified as open source, covering free redistribution, source code availability, derived works, and no discrimination against persons or fields of use.

A license that has passed the Open Source Initiative's review against the Open Source Definition and appears on its public license list, giving adopters confidence about the freedoms it grants.

A license such as Apache-2.0 or MIT that allows reuse, modification, and redistribution with few conditions, typically requiring only attribution and preservation of notices rather than reciprocal source disclosure.

A license that requires redistributors of modified code to release the derived work under the same terms, so downstream recipients keep the same freedoms; GPL and LGPL are common examples.

A copyleft arrangement, as in the LGPL or MPL, where the reciprocal obligation is limited to the covered files or library rather than the entire combined program, allowing broader linking with proprietary code.

A permissive license widely used in financial services projects that grants patent rights, requires preservation of notices, and obliges redistributors to state significant changes; it is the default license for most FINOS projects.

The assessment of whether code under two different licenses can lawfully be combined and redistributed in one work, which determines whether a dependency may be adopted into a given project.

A short standardized code, such as Apache-2.0 or BSD-3-Clause, assigned by the SPDX specification so tools and humans can express license terms unambiguously in package metadata and file headers.

The person or organization owning rights in a work, plus the attribution statements a license requires redistributors to keep, such as copyright lines, NOTICE files, and license texts shipped with the software.

A signed agreement in which a contributor grants the project or its foundation a license or assignment of rights to their contribution, letting the project redistribute the code and defend against later IP claims.

A lightweight attestation, added as a Signed-off-by line in a commit, that the contributor has the right to submit the code under the project's license; it avoids a separate signed agreement.

A CLA signed by an employer that covers contributions from its employees, clarifying that the organization, not just the individual, grants rights and has approved the contribution.

The Fintech Open Source Foundation, a nonprofit hosted by the Linux Foundation that curates open source projects, standards, and community programs for financial services firms, regulators, and technology vendors.

The staged maturity model, moving from proposed through incubating, active, and archived states, that governs how a FINOS project gains governance, tooling, and community support as it matures.

A FINOS community effort producing guidance, checklists, and maturity assessments that help regulated financial institutions adopt open source safely across legal, security, and engineering functions.

The organization founded in 2014 to open source collaboration technology for financial markets, which later became FINOS, providing the historical origin of the foundation's community and governance model.

Applying open source collaboration practices, such as public repositories, issue trackers, and pull-request review, inside a single organization so internal teams can reuse and contribute to each other's code.

The practice of sending fixes and features to the original open source project rather than only patching a local fork, reducing long-term maintenance burden and aligning with the project's roadmap.

A copy of a repository that diverges from the original, used either for private patching or as a starting point for contributions; long-lived forks create ongoing merge and security-patching obligations.

A proposed change submitted for review and merge into a repository, where maintainers and contributors discuss design, tests, and licensing before the code is accepted.

A trailer line, typically Signed-off-by, added to a commit message to certify the DCO; many projects enforce it with automated checks that block merges when the trailer is missing.

The structured examination of a proposed change by maintainers or peers for correctness, security, style, and tests before merge, and a primary channel through which new contributors earn trust.

A contributor with rights to review, merge, and release code and to set project direction; maintainers are the key relationship for institutions depending on a project's health.

A published set of behavioral expectations, often based on the Contributor Covenant, that governs community interaction and describes enforcement steps for harassment or other unacceptable conduct.

A repository label marking tasks scoped for newcomers, used by projects to attract contributors and by firms to give staff a low-risk entry point into community participation.

Automated scanning of a codebase and its dependency manifests to identify open source components, their licenses, and known vulnerabilities, producing the inventory regulators and auditors expect.

A machine-readable inventory of components and their versions in a software product, increasingly requested by financial regulators and customers to support incident response and supply chain risk management.

An institution's written rules on which licenses, projects, and package sources staff may use, including approval workflows and exceptions, so engineering choices align with legal and risk appetite.

A central team that sets open source strategy and policy, reviews license and security questions, tracks dependency risk, and coordinates contributions and community engagement across business units.

The regulated process of assessing and monitoring external providers, extended to open source projects and foundations through health checks, security posture reviews, and contractual or support arrangements.

The coordinated process by which security researchers report flaws privately to maintainers, who fix and publish advisories; institutions monitor these feeds to trigger patching under regulatory timelines.

A unique public reference for a specific disclosed vulnerability, used in advisories, scanners, and ticketing systems so teams can consistently track exposure and remediation status.

Automation that builds and tests every proposed change in a shared pipeline, giving fast feedback on pull requests and enforcing checks such as license headers, sign-offs, and test coverage.

Locking dependency versions in a manifest or lockfile so builds are reproducible, with deliberate, tested upgrades rather than silent changes that could break controls or introduce vulnerabilities.

The documented rules for how a project makes decisions, grants maintainer status, and handles disputes, ranging from single-vendor control to foundation-hosted meritocratic structures.

The number of people who would have to disappear before a project stalls, a health indicator institutions weigh when deciding whether a dependency is safe for critical systems.

A project's published procedure for receiving, triaging, and disclosing vulnerability reports, including private contact channels and target fix times, which consumers assess during due diligence.

An automated assessment that scores repositories on practices such as code review, branch protection, signed releases, and dependency update tooling, used to compare project security posture.