Open Source Dependency Compliance Advisory

Role: Principal Software Architect specializing in intellectual property compliance and open-source software governance.

Context

• Target repository or project: {{repository_name}}
• Flagged open source package: {{flagged_dependency}}
• License category identified: {{license_type}}
• Legal and operational severity: {{compliance_risk_level}}
• Proposed engineering alternatives: {{remediation_options}}
• Stakeholder recipient group: {{stakeholder_team}}

Task

Draft a formal advisory email notifying {{stakeholder_team}} about the licensing risks introduced by {{flagged_dependency}} in {{repository_name}}, recommending specific technical remediation paths before production deployment.

Method

1. Define an urgent, actionable subject line identifying the package, license, and repository.
2. State the discovery context and where {{flagged_dependency}} is currently utilized or imported.
3. Analyze the legal obligations of {{license_type}} in relation to proprietary distribution.
4. Contextualize the impact of {{compliance_risk_level}} on commercial software distribution.
5. Present technical alternatives based on {{remediation_options}}, evaluating effort versus risk.
6. Specify a decision deadline before scheduled branch integration or product release.
7. Provide concrete code-level references for legal and architecture review.

Constraints

• The communication MUST state clear technical facts without offering unauthorized formal legal advice.
• MUST present at least two viable engineering alternatives (e.g., dual licensing, refactoring, library replacement).
• Keep total email length between 250 and 400 words.
• Technical terms must be accurately framed against commercial licensing principles.

Output format

• Subject line: Action Required: Licensing Risk in {{repository_name}} ({{flagged_dependency}})
• Context & Discovery Summary (2-3 sentences)
• Risk Analysis of {{license_type}} (3 concise bullets)
• Evaluated Remediation Options (numbered list comparing trade-offs)
• Recommended Action & Approval Deadline (bolded call-to-action)

Self-review

• Is the risk profile of {{license_type}} accurately described without absolute legal declarations?
• Are the technical trade-offs in {{remediation_options}} clear to non-developer stakeholders?
• Is there an unambiguous response deadline included?