I maintain open source projects. I also work in enterprise environments where every dependency must pass through a governance review before it reaches production. These two worlds speak different languages, and the disconnect between them is where most OSS problems originate — not in the code, but in the gap between how open source is created and how enterprises consume it.

The truth is that every modern enterprise application is, by volume, mostly open source. The proprietary code is the thin layer on top. Yet many organisations still treat OSS adoption as an afterthought — grabbing packages from npm or Maven Central with no formal evaluation, no licence audit, no plan for what happens when a critical dependency is abandoned. What follows is the governance framework I wish every organisation adopted before their first npm install.

The OSS Landscape

Open source adoption is no longer optional. Consider the stack of a typical enterprise application:

Infrastructure: Linux, Docker, Kubernetes, Terraform Data: PostgreSQL, MongoDB, Redis, Elasticsearch, Kafka Backend: Spring Boot, Node.js, Django, Go Frontend: React, Angular, Vue.js, webpack DevOps: Jenkins, GitLab, Ansible, Prometheus

The question isn’t whether to use open source—it’s how to use it responsibly.

Benefits of Open Source

Cost Efficiency

No licensing fees for the software itself. Total cost of ownership (TCO) includes support, training, and customization, but typically remains lower than proprietary alternatives.

Flexibility and Control

• No vendor lock-in: Switch providers or self-host
• Customization: Modify source code for specific needs
• Integration: APIs and formats are often open standards

Innovation and Quality

• Rapid evolution: Community-driven development outpaces many commercial products
• Transparency: Code is auditable for security and quality
• Battle-tested: Popular projects used by thousands of organisations

Talent and Community

• Developer preference: Engineers often prefer OSS tools
• Community support: Forums, documentation, Stack Overflow
• Hiring advantage: Skills transfer across organisations

Risks and Challenges

License Compliance

Open source licenses impose obligations. Violations can result in:

• Legal liability: Lawsuits and injunctions
• Forced disclosure: Required release of proprietary code
• Reputational damage: Public compliance failures

Security Vulnerabilities

• Supply chain attacks: Compromised dependencies (e.g., Log4Shell)
• Unmaintained projects: Abandoned code with unpatched vulnerabilities
• Transitive dependencies: Vulnerabilities in dependencies of dependencies

Operational Risk

• No SLA: Community support has no guarantees
• Breaking changes: Major version updates may require significant rework
• Documentation gaps: Quality varies widely

Intellectual Property

• Patent exposure: Some licenses don’t grant patent rights
• Contribution ownership: Who owns code contributed by employees?
• Derivative works: When does modification trigger copyleft?

License Categories

Understanding licence categories is fundamental to OSS governance:

Permissive Licenses

Minimal restrictions—do almost anything with proper attribution.

Safe for: All use cases including proprietary products.

Weak Copyleft

Modifications to the library must be shared, but your application code remains yours.

Safe for: Most use cases if properly isolated.

Strong Copyleft

Any derivative work must be released under the same licence. This is where I see the most confusion in enterprise settings — teams assume that “open source” means “free to use however we like,” and they are wrong.

Caution required: May require releasing proprietary code. The AGPL in particular catches SaaS companies off guard — merely serving an AGPL-licensed component over a network can trigger the copyleft obligation.

Non-Standard Licenses

Custom or modified licenses require legal review.

Recommendation: Avoid or obtain legal approval.

Evaluation Framework

Before adopting an OSS component, evaluate across five dimensions:

1. License Compatibility

✓ Is the licence approved for our use case?
✓ Are transitive dependency licenses compatible?
✓ Do we have legal review for non-standard licenses?
✓ Can we comply with attribution requirements?

2. Security Posture

✓ Are there known vulnerabilities (CVE check)?
✓ How quickly are security issues addressed?
✓ Is the project actively maintained?
✓ Are dependencies up to date?

Tools: Snyk, OWASP Dependency-Check, GitHub Dependabot, Trivy

3. Project Health

✓ Active commits in last 6 months?
✓ Responsive to issues and PRs?
✓ Multiple maintainers (bus factor > 1)?
✓ Clear governance and roadmap?

Metrics to check:

4. Technical Fit

✓ Does it solve our specific problem?
✓ Compatible with our tech stack?
✓ Performance meets requirements?
✓ Acceptable learning curve?

5. Support Options

✓ Community support (forums, chat)?
✓ Commercial support available?
✓ Internal expertise present?
✓ Fallback plan if abandoned?

Governance Framework

Approved List

Maintain a curated list of pre-approved components:

# approved-oss.yaml
components:
  - name: react
    version: ">=18.0.0"
    license: MIT
    approved_for: [frontend, mobile]
    review_date: 2024-01-15

  - name: spring-boot
    version: ">=3.0.0"
    license: Apache-2.0
    approved_for: [backend, microservices]
    review_date: 2024-01-15

  - name: postgresql
    version: ">=14.0"
    license: PostgreSQL (permissive)
    approved_for: [database, production]
    review_date: 2024-01-15

Restricted List

Components requiring additional approval:

restricted:
  - name: mongodb
    license: SSPL
    reason: "SSPL licence - requires legal review"
    alternative: postgresql

  - name: elasticsearch
    license: SSPL (>7.10)
    reason: "License change - use OpenSearch or 7.10"
    alternative: opensearch

Prohibited List

Components that must not be used:

prohibited:
  - name: left-pad
    reason: "Trivial dependency, high supply chain risk"

  - name: "*"
    license: AGPL-3.0
    reason: "Network copyleft incompatible with SaaS model"

Security Best Practices

Dependency Scanning

Integrate vulnerability scanning into CI/CD:

# GitHub Actions example
- name: Security Scan
  uses: snyk/actions/node@master
  with:
    command: test
    args: --severity-threshold=high

Software Bill of Materials (SBOM)

Generate SBOM for all releases:

# Generate SBOM with Syft
syft packages dir:. -o spdx-json > sbom.json

# Generate with CycloneDX
cyclonedx-npm --output bom.xml

Dependency Pinning

Pin exact versions in production:

// package-lock.json committed
// Use exact versions
"dependencies": {
  "express": "4.18.2",
  "lodash": "4.17.21"
}

Private Registry

Mirror approved packages internally:

Internet → Artifactory/Nexus → Internal Network
              ↓
        Security scan
        License check
        Approval gate

Update Policy

Contribution Policy

Receiving Contributions

If you open-source internal projects:

1. CLA (Contributor License Agreement): Require contributors to sign
2. Code review: All contributions reviewed by maintainers
3. IP clearance: Ensure contributions don’t include proprietary code

Contributing Upstream

Guidelines for employees contributing to external projects:

✓ Contribution benefits the company (fixes bugs we hit)
✓ No proprietary code or trade secrets
✓ Time allocated and approved by management
✓ CLA signed if required by project
✓ Use personal email or approved company identity

Internal Open Source

Sharing code between teams:

• Inner source model: Open source practices within the organisation
• Clear ownership: Designated maintainers for each component
• Documentation: README, contribution guidelines, architecture docs

Compliance Checklist

For Each Release

□ SBOM generated and archived
□ All dependencies scanned for vulnerabilities
□ License compliance verified
□ Attribution notices included (NOTICE file)
□ No prohibited components included

Quarterly Review

□ Dependency audit (outdated packages)
□ License changes in dependencies checked
□ Security advisories reviewed
□ Approved list updated
□ Training completed for new team members

Annual Review

□ Governance policy reviewed and updated
□ Tool effectiveness evaluated
□ Metrics analyzed (vulnerabilities found, compliance issues)
□ Budget for commercial support reviewed
□ Contribution policy effectiveness assessed

Tooling Recommendations

License Compliance

Security Scanning

SBOM Generation

Final Thoughts

Governance sounds like bureaucracy, and badly implemented it is. But the alternative — no governance at all — is how you end up with a Log4Shell in production on a Friday evening, with no SBOM to tell you which services are affected and no process to coordinate the response.

The goal is not to slow engineers down. The goal is to create the conditions under which they can adopt open source faster, with confidence that the legal, security, and operational risks have been addressed upstream. A curated approved list, an automated scanner in CI, and a quarterly review cadence — that is the entire framework. It is not glamorous, but it is the difference between an organisation that uses open source deliberately and one that discovers its obligations only when something breaks.

Open Source Software: Enterprise Guidelines for Adoption and Governance

A framework for responsible OSS adoption.

Achraf SOLTANI — April 19, 2024