Scrolls
5 min read
On this page

Using Open Source Responsibly

Every modern software company depends on open source. A typical web application pulls in hundreds or thousands of open source dependencies. Each dependency carries obligations: license terms, security risks, maintenance expectations, and ethical considerations. Using open source responsibly means treating these dependencies as critical parts of your supply chain, not as free resources you can take without thought.

License Compliance

Every open source project has a license. The license defines what you can and cannot do with the code. Using code without checking its license is the most common compliance mistake companies make.

Check Before You Use

Before adding a dependency, read its license. This is not optional. It is a legal requirement. The license determines whether you can use the code in your product, whether you must share your modifications, and whether you can use it commercially.

License check workflow:
1. Developer wants to add a new dependency
2. Check the project's LICENSE file
3. Verify the license is on the company's approved list
4. If not approved, submit for legal review
5. If approved, document the dependency and its license
6. Add to the bill of materials

Common License Categories

Permissive (usually safe for commercial use):
- MIT: Use freely, include the copyright notice
- BSD 2/3-Clause: Similar to MIT with minor variations
- Apache 2.0: Like MIT but includes patent grant
- ISC: Simplified MIT/BSD

Copyleft (requires legal review):
- GPL v2/v3: Must share source of derivative works
- AGPL v3: Must share source even for network use
- LGPL: Copyleft applies to the library, not your code (with conditions)
- MPL 2.0: File-level copyleft, modifications to MPL files must be shared

Restricted (usually blocked):
- SSPL: Not OSI-approved, restrictive for SaaS
- BSL: Source-available, not open source
- Proprietary: Not open source at all
- No license: Legally means all rights reserved, do not use

The "No License" Trap

Code on GitHub without a license is not free to use. Copyright law defaults to "all rights reserved." If a repository has no LICENSE file, you cannot legally use the code. This catches many developers off guard.

License Compliance Tools

Automated license scanning tools:
- FOSSA: license compliance and vulnerability scanning
- Snyk: security and license scanning
- WhiteSource (Mend): license compliance
- OSS Review Toolkit (ORT): open source, comprehensive
- license-checker (npm): lightweight, checks Node.js dependencies
- cargo-license (Rust): checks Rust dependency licenses

Automate license scanning in your CI/CD pipeline. A manual process will not scale when your project has hundreds of transitive dependencies.

Dependency Management

Open source dependencies are part of your software supply chain. Managing them poorly leads to security vulnerabilities, breaking changes, and production incidents.

Pin Versions

Never depend on "latest." Pin your dependencies to specific versions so that builds are reproducible and upgrades are deliberate.

Bad: depends on "lodash" (whatever is latest)
Good: depends on "lodash@4.17.21"

Bad: depends on "serde ^1" (any 1.x)
Better: depends on "serde 1.0.197" (exact version)
Best: lock file pins exact version for all transitive dependencies

Every major package manager has a lock file mechanism. Use it.

Lock files by ecosystem:
- npm: package-lock.json
- Yarn: yarn.lock
- pnpm: pnpm-lock.yaml
- Rust: Cargo.lock
- Go: go.sum
- Python: requirements.txt with pinned versions, or poetry.lock
- Ruby: Gemfile.lock

Scan for Vulnerabilities

Known vulnerabilities in open source packages are published in databases like the National Vulnerability Database (NVD) and GitHub Advisory Database. Scan your dependencies against these databases regularly.

Vulnerability scanning tools:
- GitHub Dependabot: automatic PRs for vulnerable dependencies
- Snyk: CLI and CI integration
- Trivy: container and filesystem scanning
- npm audit / cargo audit: ecosystem-specific tools
- OWASP Dependency-Check: language-agnostic

Run vulnerability scans in CI. Block deployments when critical vulnerabilities are found. Establish a policy for how quickly vulnerabilities must be patched.

Example vulnerability SLA:
- Critical (CVSS 9.0+): Patch within 24 hours
- High (CVSS 7.0-8.9): Patch within 1 week
- Medium (CVSS 4.0-6.9): Patch within 1 month
- Low (CVSS 0.1-3.9): Patch in next scheduled update

Evaluate Before Adopting

Not every open source package is worth depending on. Before adopting a dependency, evaluate it.

Evaluation criteria:
- Maintenance activity: When was the last commit? Last release?
- Bus factor: How many active maintainers?
- Community health: Are issues responded to? Are PRs reviewed?
- Security history: Has it had critical vulnerabilities? Were they patched quickly?
- License: Is it compatible with your use?
- Transitive dependencies: What does it pull in?
- Alternatives: Is there a simpler or better-maintained option?

A package with one maintainer, no recent commits, and ten open security issues is a liability, not an asset.

Contributing Back

Using open source without contributing back is legal. It is also short-sighted. The projects you depend on need maintenance, bug fixes, and security patches. If nobody contributes, the project dies, and your dependency becomes a liability.

Fix Bugs in Projects You Depend On

When you find a bug in an open source dependency, fix it and submit a pull request. This is the minimum level of contribution. You found the bug because you use the software. You have the context to fix it. Submitting the fix upstream means you do not have to maintain a fork.

Contribution workflow:
1. You find a bug in a dependency
2. Check if it is already reported
3. If not, open an issue describing the bug
4. Fork the project
5. Fix the bug, add tests
6. Submit a PR referencing the issue
7. If the PR is merged, remove your workaround
8. If the PR is not merged, maintain a fork (last resort)

Report Security Issues Responsibly

If you find a security vulnerability in an open source project, do not open a public issue. Follow the project's security disclosure policy. If they do not have one, email the maintainer directly. Give them time to fix the issue before it becomes public.

Contribute Documentation

Documentation contributions are often more valuable than code contributions. If you spent an hour figuring out how to configure a feature because the docs were unclear, write the docs and submit a PR. The next person will not have to spend that hour.

Supporting Projects Financially

The cost of a maintainer burning out is higher than a sponsorship payment. When a critical dependency loses its maintainer, your company faces a choice: fork and maintain it yourself (expensive), migrate to an alternative (disruptive), or hope someone else picks it up (risky).

The Economics

Cost of sponsoring a dependency: $5,000 to $50,000/year
Cost of a maintainer burning out:
- Forking and maintaining internally: $100,000+ per year in engineer time
- Migrating to alternative: weeks of engineering time, potential outages
- Security vulnerability with no one to patch it: incalculable

A $5,000/year sponsorship for a library used by 50 engineers in your company costs less than one hour of engineering time per engineer per year. The math is straightforward.

How to Support

Financial support options:
- GitHub Sponsors: direct sponsorship of maintainers
- Open Collective: transparent project funding
- Tidelift: subscription for dependency maintenance
- Direct contracts: pay maintainers for specific work
- Foundation memberships: Linux Foundation, Apache Foundation, etc.
- Bounty programs: pay for specific features or fixes

Building a Support Policy

Establish a company policy for financial support of open source:

Example policy:
- Any dependency used in production can be nominated for sponsorship
- Engineering teams propose sponsorships during quarterly planning
- Budget: 0.1% of engineering headcount cost (e.g., $50K for 50 engineers)
- Priority: critical infrastructure (databases, web servers, crypto libraries)
- Review: annual review of sponsorship effectiveness

The Company Policy for Open Source Usage

Mature companies have a formal open source usage policy. This policy covers license compliance, dependency management, contribution guidelines, and financial support.

Open source usage policy components:
1. Approved licenses: list of licenses approved for use
2. License review process: how to request approval for new licenses
3. Dependency management: version pinning, lock files, scanning
4. Vulnerability management: SLAs for patching, scanning frequency
5. Contribution policy: when and how employees can contribute
6. Financial support: budget and process for sponsorships
7. Inventory: bill of materials for all open source dependencies
8. Training: onboarding materials on open source compliance

The Software Bill of Materials (SBOM)

An SBOM is a complete list of all open source components in your software, including transitive dependencies. Regulatory requirements (like the US Executive Order on Cybersecurity) increasingly require SBOMs.

SBOM formats:
- SPDX: Linux Foundation standard
- CycloneDX: OWASP standard
- SWID: ISO/IEC 19770-2 standard

SBOM generation tools:
- syft (by Anchore): generates SBOMs from container images
- cdxgen: CycloneDX generator
- spdx-sbom-generator: SPDX format generator

Common Pitfalls

  • Not checking licenses. "It is on GitHub so it is free" is wrong. Every project has a license (or should), and that license has terms you must follow.
  • Depending on unmaintained projects. A package with no updates for two years is a ticking time bomb. Evaluate maintenance health before adopting.
  • Never contributing back. Free-riding on open source is legal but unsustainable. If every company free-rides, the ecosystem collapses.
  • Treating sponsorship as charity. Sponsoring open source is not philanthropy. It is supply chain investment. Frame it as risk mitigation, not goodwill.
  • Manual compliance processes. Any process that requires a human to check every dependency will fail at scale. Automate license scanning and vulnerability checks.
  • Ignoring transitive dependencies. Your project may have 10 direct dependencies and 500 transitive ones. License and vulnerability issues hide in the transitive tree.

Key Takeaways

  • Every open source dependency has a license that defines your obligations. Check licenses before use and automate compliance scanning in CI/CD.
  • Pin dependency versions, use lock files, and scan for known vulnerabilities with established SLAs for patching.
  • Contributing back (bug fixes, documentation, security reports) is the minimum responsible behavior for companies that depend on open source.
  • Financial support for critical dependencies is supply chain investment, not charity. The cost of a maintainer burning out vastly exceeds the cost of a sponsorship.
  • A formal open source usage policy covering licenses, dependencies, contributions, and financial support is essential for mature organizations.
  • Software Bills of Materials (SBOMs) are increasingly required by regulation and are a best practice for understanding your open source supply chain.