FINOS Financial Services Open Source Developer common mistakes
FINOS Financial Services Open Source Developer · Understand the traps and how to avoid them.
Treating a permissive license (Apache-2.0, MIT) as interchangeable with a copyleft license (GPL, AGPL) when answering questions about whether code can be merged into a FINOS-hosted project, and assuming 'open source' means 'no obligations' at all.
Candidates learn that open source is 'free to use' and conflate freedom-to-use with freedom-to-relicense or distribute inside a proprietary bank system. They skip the distinction between permissive and reciprocal obligations, and forget Apache-2.0's NOTICE and patent-grant terms.
What to do instead
Build a small mental table: permissive (MIT, BSD, Apache-2.0) allow proprietary downstream use with attribution/NOTICE retention; weak copyleft (LGPL, MPL) attaches at file/library level; strong copyleft (GPL) and network copyleft (AGPL) impose source-availability duties. For each license, state the obligation triggered by modification vs. distribution vs. network use before answering.
Confusing the role of a CLA (Contributor License Agreement) with a DCO (Developer Certificate of Origin) and assuming both do the same thing, or assuming FINOS projects uniformly require one or the other.
Both appear in contribution workflows, both are 'sign-off' steps, and candidates rarely see the actual text. They don't realize a DCO is a statement that you have the right to submit under the project license, while a CLA is a separate legal grant (often including copyright or patent licensing) to the project steward or foundation.
What to do instead
Memorize the one-line distinction: DCO = assertion of provenance via Signed-off-by; CLA = grant of rights to the steward. Then check the specific project's CONTRIBUTING file rather than assuming, since requirements vary by project and by foundation policy.
Assuming that contributing code to an open source project automatically clears the employer's IP review, or that work done on personal time is automatically the contributor's to license.
Employment agreements commonly assign IP created within scope of employment or using employer resources to the employer, and many banks require internal open source program office (OSPO) approval before external contribution. Candidates focus on the GitHub mechanics and overlook the corporate policy layer.
What to do instead
Before any external contribution, verify three things: (1) employer IP assignment terms, (2) whether an internal OSPO/approval workflow exists, (3) whether the contribution touches bank-confidential material. Answer exam questions from the assumption that corporate approval precedes the pull request.
Describing FINOS as a standards body that writes and ratifies specifications, rather than as a foundation hosting open source projects and collaborative fintech initiatives under a neutral governance umbrella.
Candidates map 'financial services + open source + governance' onto familiar models like ISO, W3C, or OASIS, and mislabel FINOS's output. They also blur FINOS with the Linux Foundation's broader structure.
What to do instead
Anchor FINOS as an open source foundation (part of the Linux Foundation family) that hosts projects, provides neutral governance, shared tooling, and community programs for financial services. Standards-like outputs come from hosted projects and SIGs, not from FINOS as a ratifying standards body.
Treating 'open source' and 'open standard' as synonyms, or assuming a project hosted by a foundation is automatically production-ready and institutionally endorsed.
Marketing language around fintech projects blurs the line between a specification (e.g., a data model or API standard) and a reference implementation. Candidates also assume foundation hosting implies a support contract or vendor backing.
What to do instead
Separate three artifacts: specification/standard, reference implementation, and production-supported distribution. Foundation hosting signals neutral governance and licensing clarity, not maturity or support. Check a project's maturity stage and release status explicitly.
Answering questions about inner source and open source as if they were the same practice, missing that inner source applies open collaboration practices inside the firm's boundary without external licensing obligations.
Both use the same tooling (Git, pull requests, code review) and the same vocabulary, so candidates assume identical governance. They miss that inner source has no external distribution and therefore no copyleft trigger, but does raise internal data-handling and access-control questions.
What to do instead
Frame inner source as 'open source methods, closed boundary': same workflow, internal-only licensing/access, no external contribution or public disclosure. Then note where the two diverge - IP review, export control, data classification, and external CLA/DCO steps.
Recommending adoption of an open source component in a regulated bank without addressing the compliance artefacts a reviewer would demand: license scan, SBOM, CVE/vulnerability tracking, maintenance/community health, and an accountable owner.
Candidates answer as engineers ('it's widely used and well maintained') rather than as contributors to a controlled change process. They underestimate how much of the exam is about defensible decision records in a regulated environment.
What to do instead
Structure adoption answers as a checklist: license identified and compatible with distribution model, SBOM generated and retained, vulnerability monitoring and patch cadence defined, project health (commits, maintainers, release cadence, bus factor) assessed, exit/fallback plan documented, and named internal owner.
Describing the contribution workflow in the wrong order - forking and pushing before checking issue/discussion, opening a PR without tests or a linked issue, or ignoring the project's CONTRIBUTING, code of conduct, and commit/DCO conventions.
Candidates rely on generic GitHub habits and skip the project-specific front matter. They also forget that many projects require an issue or design discussion before non-trivial PRs, and that CI/lint failures block review.
What to do instead
Use a fixed sequence: read CONTRIBUTING and CODE_OF_CONDUCT, search existing issues, open/discuss an issue for non-trivial work, fork and branch, add tests and docs, sign off (DCO) or sign CLA, run local lint/tests, open a focused PR referencing the issue, then respond to review. Keep PRs small and single-purpose.
Confusing the licence of a project's code with the licence of its documentation, data, or specification text, and assuming one licence covers everything in the repository.
Candidates see a LICENSE file at the repo root and stop there. Many projects license code under Apache-2.0 but specs, sample data, or docs under different terms (e.g., CC variants), which matters when a bank wants to reuse a data schema or spec text.
What to do instead
Always check for multiple licence files and per-directory notices, and state which artefact you are reusing (code, spec, sample data, docs). When answering, name the artefact and its licence rather than the repository as a whole.
Treating community and collaboration practices (code of conduct enforcement, maintainer vs. contributor roles, communication channels, asynchronous decision-making) as soft background rather than examinable governance content.
Candidates prioritize technical and legal topics and skim the collaboration material, so they miss concrete distinctions such as committer vs. maintainer vs. PMC/TSC, how consensus and lazy consensus work, and what a code of conduct violation process actually involves.
What to do instead
Learn the role ladder and decision mechanics explicitly: user → contributor → committer/reviewer → maintainer/PMC; how proposals and lazy consensus work; where decisions are recorded (issues, mailing lists, meeting minutes); and the reporting/enforcement path for code of conduct issues. Tie each to a concrete behaviour you would exhibit.