Certified Open Source Developer for Enterprise common mistakes
Certified Open Source Developer for Enterprise · Understand the traps and how to avoid them.
Treating copyleft as a single behaviour, so the candidate answers that any GPL-licensed component 'infects' the whole product regardless of how it is linked or invoked.
Candidates memorise 'GPL = viral' from blog posts and never separate strong copyleft (GPL), weak copyleft (LGPL, MPL) and permissive licences (MIT, Apache-2.0), nor the distinction between derivative works, aggregation and separate processes communicating over a network.
What to do instead
Build a comparison table covering GPL-2.0, GPL-3.0, LGPL-2.1/3.0, AGPL-3.0, MPL-2.0, EPL-2.0, Apache-2.0, MIT and BSD-3-Clause with columns for linking rules, network-use trigger, patent grant, notice obligations and source-disclosure scope. For each scenario, first classify the integration model (statically linked, dynamically linked, subprocess, network service, separate tool) and only then apply the licence rule.
Assuming a licence file is unnecessary or optional when the project is published publicly, or inventing a licence by writing 'free to use' prose in the README.
Candidates conflate public availability with open source. Without an explicit licence, default copyright applies and nobody may legally copy, modify or redistribute, which contradicts the exam's emphasis on explicit grants and SPDX identifiers.
What to do instead
Learn that a licence must be an explicit grant of rights, applied via a LICENSE file plus SPDX identifiers in package metadata and source headers. Practise identifying the correct SPDX expression for combined works (for example AND versus OR) and recognise that public repositories without a licence are 'source available', not open source.
Answering that a permissive licence imposes no obligations at all, and therefore skipping attribution, NOTICE file handling and licence-text retention in the distributed product.
The shorthand 'MIT means do whatever you want' is memorable and wrong. Candidates forget that permissive licences still require copyright notice and permission-text preservation, and that Apache-2.0 adds a NOTICE file obligation and explicit patent and trademark clauses.
What to do instead
Memorise the residual obligations of each permissive licence: retain copyright and licence text in redistributions, propagate NOTICE contents when Apache-2.0 code is present, and do not imply endorsement using project trademarks. Practise producing a third-party notice bundle for a hypothetical product that mixes MIT, BSD-3-Clause and Apache-2.0 dependencies.
Confusing open source governance with open standards or open collaboration, answering that OSI approves standards, that the Free Software Foundation maintains the Open Source Definition, or that a project is open source because its code is visible on a public forge.
The vocabulary overlaps heavily: OSI, FSF, Apache Software Foundation, Linux Foundation, SPDX, OpenSSF and the four freedoms all appear in study material, and candidates blur who does what. They also skip the ten criteria of the Open Source Definition and the four freedoms.
What to do instead
Create a one-page map of organisations to artefacts: OSI owns the Open Source Definition and the licence review process, FSF owns the four freedoms and the GPL family, Apache Software Foundation is a vendor-neutral foundation with its own licence and meritocratic governance, SPDX is a Linux Foundation project for licence and SBOM identifiers, OpenSSF focuses on supply-chain security. Then test yourself by classifying statements into the correct body.
Choosing a dependency purely on GitHub stars or download counts, and skipping maintenance-health, security and licence-compatibility checks before adding it to a product.
Popularity is a visible, easy proxy for quality, and candidates transfer consumer habits into enterprise evaluation. They also overlook that a transitive dependency can carry an incompatible licence or an unpatched vulnerability even when the direct dependency looks clean.
What to do instead
Adopt a structured intake checklist: last release date, commit cadence, number of active maintainers, open critical issues, security policy and disclosure history, test coverage signals, release signing, licence and its compatibility with the product's distribution model, plus transitive dependency licences. Practise scoring two candidate libraries against the same checklist and justifying a decision.
Assuming that pulling a container image or package from a public registry is equivalent to reviewing it, so the candidate answers that vulnerability scanning at build time is sufficient without pinning, checksums or provenance verification.
Build pipelines make consumption feel frictionless and trust is implicit in the registry. Candidates do not distinguish mutable tags from immutable digests, or build-time scanning from continuous monitoring after deployment.
What to do instead
Learn the consumption controls as a chain: pin by immutable digest or lockfile with checksums, verify signatures and provenance attestations, generate an SBOM at build, scan continuously against advisories, and maintain a documented exception process. Be ready to explain what a lockfile guarantees and what it does not (it does not vet the maintainer or the licence).
Sending a large unsolicited pull request that rewrites formatting, renames APIs or adds an unrequested feature, without reading CONTRIBUTING, the issue tracker or the discussion history first.
Candidates optimise for code quality in the abstract and treat the repository as a personal portfolio. They underestimate social and process constraints: maintainer bandwidth, design consensus, scope discipline and the project's definition of a welcome change.
What to do instead
Follow the contribution workflow deliberately: read CONTRIBUTING and the code of conduct, search issues and discussions, open or claim an issue and agree on approach before writing code, keep the change minimal and focused, add tests and documentation, sign off commits where a DCO is required, and respond to review without force-pushing over reviewer comments. Practise writing a good issue report with reproduction steps and a scoped pull-request description.
Treating a contributor licence agreement or developer certificate of origin as a formality, and answering that signing a CLA transfers the contributor's copyright to the foundation in every project or that a DCO sign-off is a legal review.
The two mechanisms look similar from the outside and candidates merge them. They also miss that CLA terms vary by project and that sign-off is an assertion of the right to submit under the project licence, not a copyright assignment.
What to do instead
Learn the distinction explicitly: a DCO sign-off certifies provenance under the project's existing licence and is lightweight, while a CLA is a separate agreement that may grant a broad copyright or patent licence to the project sponsor and may or may not assign copyright depending on its text. Read one real CLA and one DCO text and compare what each grants.
Answering that a company policy banning all copyleft software, or conversely an informal 'developers may add whatever they need' norm, constitutes an adequate open source management programme.
Candidates reduce programme management to a single rule and skip the operating model: policy, approval workflow, inventory, training, audit and remediation. Blanket bans are easy to state but push usage underground; laissez-faire norms leave the organisation unable to answer a due-diligence questionnaire.
What to do instead
Frame the programme as a lifecycle: policy and licence categories, an approval request workflow with escalation, automated inventory and SBOM generation, periodic audits with remediation plans, developer training, and clear ownership of the process. Be prepared to describe what happens when an incompatible licence is discovered in a shipped product, from containment to disclosure to re-engineering.
Believing that an SBOM is a one-off deliverable produced for a compliance request, and that its presence demonstrates licence compliance and security.
Regulation and customer questionnaires have made SBOMs a checkbox, so candidates treat the document as the goal. They miss that an SBOM is only as useful as its accuracy, freshness, format and linkage to vulnerability and licence data, and that it does not by itself establish compliance or absence of vulnerabilities.
What to do instead
Learn what an SBOM contains (components, versions, identifiers such as purl and CPE, dependency relationships, supplier), the common formats (SPDX, CycloneDX) and where it fits in the pipeline: generated automatically at build, stored with the artefact, and consumed by scanners and licence tooling. Practise explaining the limits of an SBOM and how it supports, but does not replace, licence review and incident response.