# Draft Open Source Compliance Policy > Board-ready open source software compliance policy for a technology company, incorporating audit findings, customer contract obligations, engineering practices, and a pending relicensing development. - Skill: `finchipaiorg/draft-open-source-compliance-policy` (Agent Skill) - Install (CLI): `npx skillmds@latest add finchipaiorg/draft-open-source-compliance-policy` - Raw SKILL.md: https://api.skillmd.com/api/skills/finchipaiorg/draft-open-source-compliance-policy/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: FinchipAIOrg (https://skillmd.com/u/finchipaiorg) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/finchipaiorg/draft-open-source-compliance-policy --- # Skill: Draft Open Source Software Compliance Policy ## 1. Subject-matter triage (only if applicable) - Treat the task as a policy-drafting exercise, not a memo: produce an operative compliance policy that can be approved, implemented, and audited. - Read the audit, customer agreements, term sheet, engineering memo, and any relicensing materials as one integrated record; reconcile them before drafting. - Identify the company’s product and deployment context, including whether software is distributed, embedded, or accessed over a network, because the compliance triggers differ by mode of use. - If multiple product lines, codebases, business units, or transaction contexts appear in the source set, enumerate them first and draft the policy to cover each explicitly rather than using a single generic rule. - If the source materials disclose a live relicensing or license-change event, treat it as an active governance issue that the policy must address immediately. ## 2. Failure modes the skill is correcting - Drafting a generic open source policy that ignores the specific license mix, usage patterns, and findings in the audit or software composition analysis. - Failing to connect open source compliance rules to customer-facing contractual representations, ownership covenants, exclusivity commitments, or other IP promises. - Treating copyleft, network-triggered obligations, or distribution mechanics as abstract concepts rather than product-specific compliance triggers. - Omitting approval gates, escalation paths, owner assignments, recordkeeping, and enforcement steps, leaving the policy aspirational instead of operational. - Failing to address pending relicensing, license migration, or removal decisions as part of the policy’s change-control and exception process. - Drafting a policy that describes what should happen without stating who does it, when it happens, and what artifact proves completion. - Using vague legal conclusions without naming the controlling source of the obligation or the policy basis for the rule. ## 3. Legal frameworks / domain conventions that apply - Classify open source licenses by obligation profile: permissive, weak copyleft, and strong copyleft, and tie each class to the practical compliance steps it requires. - Treat network-access triggers as distinct from distribution triggers where the relevant license or product model makes that distinction legally meaningful. - Incorporate customer agreement obligations as a parallel constraint set; where open source use may affect ownership, non-infringement, disclosure, source-availability, or assignment representations, the policy must route review through legal and commercial approvals. - Use software composition analysis, dependency tracking, notice preservation, source-availability review, and release gating as core compliance controls. - Recognize that disclosure schedules, diligence questionnaires, and similar transaction materials may need contemporaneous updates when open source usage changes. - Anchor legal propositions to controlling authority identified in the source materials or, if absent, to the relevant license text, contract provision, statute, regulation, or established compliance practice. - Treat board-facing policies as governance documents: they should define authority, responsibility, escalation, auditability, and exception handling, not merely aspirational principles. ## 4. Analytical scaffolds - License inventory mapping: identify every license category or special licensing event referenced in the materials, then map each to its required approval, notice, disclosure, or release-step implications. - Obligation-by-trigger analysis: for each license category, ask what happens on inclusion, modification, distribution, internal deployment, or external network access. - Contract consistency check: compare the policy against customer agreement representations and operational commitments, and identify where open source compliance controls must prevent inconsistency. - Relicensing response logic: define how the company evaluates, approves, documents, and communicates a license change affecting existing or future code. - Governance design: specify owners, approvers, escalation thresholds, review cadence, exception authority, training obligations, and record retention. - Release-control design: specify when engineering must obtain clearance, what artifacts must be attached, and what blocks a release absent approval. - Disclosure-maintenance logic: specify how the policy keeps diligence materials, disclosure schedules, and internal inventories synchronized with the current codebase. - Board-readiness check: ensure the policy states purpose, scope, authority, controls, reporting lines, and implementation milestones in a form suitable for leadership approval. ## 5. Vertical / structural / temporal relationships (only if applicable) - If the source set contains more than one product, business line, or deployment model, address each in separate policy provisions or subparts so the compliance trigger is not diluted. - If the record contains both current-state findings and future-state commitments, separate baseline controls from remediation commitments and adoption milestones. - If a relicensing or code migration decision is pending, place the decision path, interim controls, and post-change update obligations in chronological order. - If customer contracts and engineering practices point in different directions, make the policy state the higher standard and route deviations through formal exception approval. - If a transaction or diligence process is underway, place disclosure update obligations on a continuing basis through signing, closing, and post-closing transition as applicable. ## 6. Output structure conventions - Draft as a board-ready policy with a clear title, purpose statement, scope, definitions, roles and responsibilities, license-class rules, review and approval workflow, release controls, recordkeeping, training, escalation, exception handling, relicensing procedure, and governance/reporting. - Use conventional policy language that is operative and enforceable: “must,” “may only with approval,” “shall retain,” “shall escalate,” and similar verbs. - Include a concise executive summary or preface if helpful, but keep it subordinate to the policy itself. - Tie each rule to the underlying compliance rationale in the body of the policy, especially where the rule responds to a specific audit finding, contract risk, or relicensing event. - Define the approval chain and the responsible functions in a way that an engineering organization can actually follow. - Include a section on monitoring, periodic review, and version control so the policy can evolve with the codebase and legal landscape. - Ensure the final document reads as an implementable internal control document, not a legal memorandum or an issue list.