5 exercises — choose the best-structured answer to common OSPO Manager interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real experience.
Structure for OSPO Manager answers
Tip 1: Licence taxonomy: permissive (MIT, Apache 2.0) vs copyleft (GPL v2/v3, LGPL, AGPL) — know the implications of each
Tip 2: Compliance: SBOM (Software Bill of Materials), SPDX, CycloneDX formats, dependency scanning (FOSSA, Black Duck)
Tip 3: Contribution policy: CLA vs DCO, internal approval process for outbound contributions
Tip 4: Community: governance models (BDFL, meritocracy, foundation-led), CNCF/Apache/Linux Foundation onboarding
0 / 5 completed
1 / 5
The interviewer asks: "What is the difference between permissive and copyleft open source licences, and why does it matter for a company?" Which answer best demonstrates open source licence expertise?
Option B is strongest because it defines both categories with specific licence examples, explains the key legal triggers (distribution vs. network use), and quantifies the business risk. Key structure: permissive (attribution only, patent grant in Apache 2.0) vs. copyleft (GPL triggers on distribution, AGPL on network use, LGPL allows linking) → GPL in proprietary product requires source release or commercial licence. Option A is factually wrong — copyleft licences do not require payment. Option C confuses licence categories with community classification. Option D is wrong — copyleft licences cannot be converted to permissive by adding an attribution notice.
2 / 5
The interviewer asks: "How do you build and maintain a Software Bill of Materials (SBOM) for your products?" Which answer best demonstrates SBOM engineering maturity?
Option B is strongest because it describes a complete, automated SBOM lifecycle: generation at build time, versioning with releases, policy enforcement and CVE correlation, and external publication with the regulatory context. Key structure: Syft/CycloneDX/SPDX at CI → stored with each release → FOSSA/Black Duck for policy + CVE correlation → publish for EO 14028 compliance → SBOM ≠ lock file. Option A describes a manually maintained dependency list, not a machine-readable SBOM. Option C (quarterly audit) is not automated and not linked to the release process. Option D (Dependabot) keeps dependencies updated but does not produce compliant SBOMs.
3 / 5
The interviewer asks: "What is the difference between a CLA and a DCO for managing inbound contributions?" Which answer best demonstrates open source governance knowledge?
Option C is strongest because it defines both mechanisms precisely, explains the enforcement tooling, gives the real-world examples (Linux kernel DCO, Apache CLA), and provides a practical recommendation. Key structure: CLA (legal contract, signed once, tooling required, high friction) vs. DCO (Signed-off-by per commit, GitHub Check, lightweight) → Linux=DCO, Apache=CLA → DCO for most projects. Option A is wrong — the choice depends on legal requirements and contribution friction tolerance, not project size. Option B is wrong — they are not interchangeable and have different legal implications. Option D is factually incorrect — neither CLAs nor DCOs have annual renewal requirements.
4 / 5
The interviewer asks: "How do you create an internal policy for contributing to open source projects?" Which answer best demonstrates OSPO policy design?
Option B is strongest because it covers all six dimensions of a real contribution policy with specific rules for each, and includes the governance process (legal review, annual review). Key structure: approval process → scope (no proprietary/trade secrets) → licence compatibility → identity → time policy (strategic vs. personal) → CLA/DCO → annual legal review. Option A is incomplete — it addresses only time and equipment, missing legal exposure and scope. Option C (whitelist) is overly restrictive and does not scale as the open source ecosystem evolves. Option D (mandatory open-sourcing) is the reverse of a contribution policy and creates uncontrolled IP disclosure.
5 / 5
The interviewer asks: "How do you measure the success of an OSPO?" Which answer best demonstrates OSPO metrics maturity?
Option B is strongest because it provides a balanced scorecard covering three fundamentally different dimensions (compliance, community, business value) with specific, measurable KPIs for each. Key structure: compliance (SBOM coverage + violation MTTR + CVE MTTR) + community (contributors + maintainer roles + project health) + business value (reuse + strategic positioning + recruiting) → quarterly CTO reporting. Option A (GitHub stars) is a single vanity metric that can be gamed and does not reflect compliance or business value. Option C conflates purchasing licences with OSPO success — the OSPO manages open source risk, not licence purchasing. Option D (satisfaction survey) is a qualitative input but not a business-aligned success metric.