Examine license implications and ratings

  • 9 minutes

Understanding license terms is only the first step—organizations must evaluate how licenses affect their specific business models, development practices, and product distribution strategies. License implications determine whether open-source components are suitable for particular use cases and what obligations organizations must fulfill.

License implications for commercial software

Different license types have dramatically different implications for commercial software development:

Permissive license implications

Software using permissive-licensed components (MIT, Apache 2.0, BSD):

Minimal restrictions:

  • Proprietary distribution: Can incorporate components into proprietary software without open-sourcing your code.
  • Commercial products: Can build and sell commercial products incorporating permissive-licensed components.
  • Closed distribution: No requirement to provide source code to customers.
  • Sublicensing: Can typically distribute under your own license terms.

Primary obligation:

  • Attribution: Must preserve copyright notices and license text, usually satisfied by including notices in documentation, About dialogs, or license aggregation files.

Patent considerations:

  • MIT and BSD: Don't include explicit patent grants, creating potential ambiguity about patent rights.
  • Apache 2.0: Includes explicit patent grant, providing clearer protection and defensive termination for patent litigation.

Business implications:

  • Safe choice: Permissive licenses pose minimal risk for commercial products.
  • Simple compliance: Attribution requirements are straightforward to fulfill.
  • Maximum flexibility: Enable any business model including proprietary software sales.

Weak copyleft license implications

Software using weak copyleft components (LGPL, MPL):

Library use allowed:

  • Proprietary applications: Can use weak copyleft libraries in proprietary applications.
  • Linking permitted: Can link proprietary code with weak copyleft libraries (especially through dynamic linking).
  • No full copyleft: Using libraries doesn't trigger requirement to open-source the entire application.

Modification requirements:

  • Library modifications must be shared: If you modify the weak copyleft component itself, those modifications must be open-sourced.
  • File-level tracking (MPL): For MPL, requirements apply at file level, making boundaries clearer.
  • Derivative works: Creating derivative works of the library triggers open-source requirements.

Compliance considerations:

  • Source code provision: Must provide source code for the weak copyleft library (including any modifications).
  • License preservation: Must maintain license terms for the library.
  • Clear separation: Maintain clear boundaries between library code and proprietary code.

Business implications:

  • Generally acceptable: Most businesses can use weak copyleft libraries in proprietary products.
  • Modification burden: Modifying libraries creates ongoing compliance obligations.
  • Static linking concerns: Static linking might create stricter requirements; prefer dynamic linking.

Strong copyleft license implications

Software using strong copyleft components (GPL, AGPL):

Copyleft propagation:

  • Derivative works: Creating derivative works or combining code with GPL'd software triggers copyleft requirements.
  • Entire application: GPL typically applies to the entire application, not just the GPL'd component.
  • Source code requirement: Must provide complete source code when distributing binaries.
  • Same license: Derivative works must be distributed under GPL.

Distribution triggers:

  • Binary distribution: Distributing executable binaries requires providing source code.
  • Network use (AGPL): For AGPL, merely making software available over a network triggers requirements.
  • Internal use: Using GPL'd software internally without distribution doesn't trigger requirements.

Linking concerns:

  • Static linking: Clearly creates derivative work requiring GPL compliance.
  • Dynamic linking: Legal interpretation varies—some consider it safe, others believe it creates derivative work.
  • Process separation: Running GPL'd software as separate process (microservices) might avoid derivative work status.

Business implications:

  • Incompatible with proprietary software: Cannot incorporate GPL'd components in proprietary software that you distribute.
  • Open-source products: Can use GPL for products you're willing to open-source.
  • SaaS exception: GPL v2 and v3 don't require source disclosure for SaaS offerings (AGPL does).
  • High risk: GPL presents significant risk for commercial proprietary software.

License risk ratings

Organizations commonly rate licenses based on the risk they pose for commercial software development:

Risk rating framework

Low risk (Green):

  • Licenses: MIT, BSD, Apache 2.0, ISC, other permissive licenses.
  • Characteristics: Minimal restrictions, primarily attribution requirements.
  • Use cases: Safe for any commercial use including proprietary software.
  • Compliance burden: Low—primarily maintaining attribution notices.

Medium risk (Yellow):

  • Licenses: LGPL, MPL, EPL, other weak copyleft licenses.
  • Characteristics: Allow use in proprietary software with restrictions on modifications.
  • Use cases: Acceptable for using unmodified libraries; caution required when modifying.
  • Compliance burden: Moderate—must track library source and provide it upon request.

High risk (Red):

  • Licenses: GPL v2, GPL v3, AGPL, other strong copyleft licenses.
  • Characteristics: Require open-sourcing derivative works and combined applications.
  • Use cases: Incompatible with proprietary software distribution; acceptable for open-source projects.
  • Compliance burden: High—must provide complete source code for entire application.

Unknown risk (Orange):

  • Licenses: Custom licenses, unclear licensing, missing license information, obsolete licenses.
  • Characteristics: Terms unclear, compatibility uncertain, legal review required.
  • Use cases: Avoid until legal review clarifies terms and implications.
  • Compliance burden: Unknown until license terms are clarified.

Factors affecting risk assessment

Business model:

  • Open-source products: GPL is acceptable risk.
  • Proprietary software: GPL is unacceptable risk.
  • SaaS offerings: GPL v2/v3 acceptable, AGPL unacceptable.
  • Internal tools: All licenses typically acceptable since no distribution.

Distribution method:

  • Binary distribution: Triggers GPL requirements.
  • SaaS deployment: Triggers AGPL requirements.
  • Internal use only: Doesn't trigger most requirements.
  • Library provision: Triggers LGPL/MPL requirements.

Modification extent:

  • Unmodified components: Lower compliance burden.
  • Modified components: Increases obligations, especially for copyleft.
  • Deep integration: Makes compliance more complex.

Legal environment:

  • Jurisdictional differences: License interpretation varies by country/region.
  • Enforcement history: Some licenses have stronger enforcement precedent.
  • Patent considerations: Patent clauses interact with organizational patent strategies.

Intellectual property considerations

License choices affect organizational intellectual property:

Proprietary IP protection

Permissive licenses:

  • IP preserved: Your proprietary code remains proprietary.
  • Trade secrets protected: No requirement to disclose implementation details.
  • Competitive advantage maintained: Don't have to share innovations with competitors.

Strong copyleft licenses:

  • IP disclosure required: GPL requires open-sourcing derivative works, potentially exposing proprietary algorithms, business logic, and innovations.
  • Trade secrets lost: Source code disclosure eliminates trade secret protection.
  • Competitive advantage reduced: Competitors can use your innovations.

Patent considerations

Patent grants:

  • Apache 2.0: Includes explicit patent grant that provides clear rights and defensive termination.
  • GPL v3: Includes patent grant and anti-tivoization provisions.
  • MIT/BSD: No explicit patent provisions, creating potential ambiguity.

Patent defensive termination:

  • Apache 2.0 and GPL v3: Patent grants terminate if licensee sues contributors for patent infringement.
  • Strategic implication: Organizations with aggressive patent strategies might face complications.

Patent pools:

  • Some licenses integrate with patent pools: Licenses might interact with industry patent agreements.

Compliance implementation

Successfully implementing open-source software requires systematic compliance processes:

Dependency inventory

Comprehensive tracking:

  • Bill of materials: Maintain complete inventory of all open-source components.
  • Transitive dependencies: Track not just direct dependencies but dependencies of dependencies.
  • Version tracking: Record specific versions, as licenses sometimes change between versions.
  • Update monitoring: Continuously monitor for updates to dependencies and their licenses.

Automated tools:

  • Package managers: npm, pip, Maven automatically track direct dependencies.
  • SBOM tools: Software Bill of Materials tools generate comprehensive dependency inventories.
  • License scanners: Tools like FOSSA, WhiteSource, Black Duck identify licenses across dependency trees.

License compatibility verification

Compatibility checking:

  • Automated scanning: Tools automatically identify license incompatibilities.
  • Legal review: Complex cases require legal expertise to evaluate compatibility.
  • Approval workflows: Establish processes for reviewing new dependencies before use.

Common incompatibilities:

  • GPL + Apache 2.0 (GPL v2): Incompatible—cannot combine.
  • GPL + Proprietary: Incompatible for distributed software.
  • Multiple copyleft licenses: Generally incompatible with each other.

Attribution compliance

Meeting attribution requirements:

  • License aggregation: Collect all license texts in single file (often LICENSES.txt or THIRD_PARTY_NOTICES).
  • About dialogs: Include attributions in application About dialogs or settings.
  • Documentation: Include license information in product documentation.
  • Automated generation: Use tools to automatically generate attribution files from dependency data.

Source code provision

For copyleft licenses:

  • Source access: Provide complete source code for GPL'd components and derivative works.
  • Same medium: Historically required providing source on same medium as binaries; internet download now acceptable.
  • Written offer: Can offer to provide source code rather than bundling it.
  • Compilation instructions: Include build instructions so users can rebuild from source.

Software supply chain security

License compliance and security are interconnected concerns:

Vulnerability management

Security equals weakest component:

  • Chain dependency: Application security depends on every component in the dependency tree.
  • Vulnerability propagation: Vulnerability in any dependency affects all applications using it.
  • Update urgency: Security vulnerabilities require rapid updates across all affected applications.

Vulnerability scanning:

  • Automated detection: Tools like Snyk, Dependabot, WhiteSource scan dependencies for known vulnerabilities.
  • CVE monitoring: Track Common Vulnerabilities and Exposures identifiers for dependencies.
  • CVSS scoring: Use Common Vulnerability Scoring System to prioritize remediation.
  • Rapid response: Establish processes for quickly updating dependencies when critical vulnerabilities are disclosed.

Supply chain attacks

Risk mitigation:

  • Package verification: Verify package signatures and checksums.
  • Source reputation: Prefer packages with active maintenance, large user bases, and reputable maintainers.
  • Private registries: Mirror public packages in private registries to control what developers use.
  • Dependency pinning: Lock specific versions to prevent automatic updates to compromised versions.

Component quality assessment

Quality indicators:

  • Active maintenance: Regular updates indicate maintained project.
  • Community size: Large communities provide better sustainability.
  • Documentation quality: Good documentation suggests professional maintenance.
  • Test coverage: Automated testing indicates quality focus.
  • Security practices: Responsible disclosure processes and security advisories demonstrate security commitment.

Organizational policies

Effective open-source management requires clear organizational policies:

Approval workflows

Pre-use evaluation:

  • Security review: Scan for known vulnerabilities before approval.
  • License review: Verify license compatibility with intended use.
  • Quality assessment: Evaluate code quality, maintenance status, and community health.
  • Alternative analysis: Consider if approved alternatives exist.

Approved package lists:

  • Pre-vetted components: Maintain lists of approved packages for common needs.
  • Faster adoption: Developers can use approved packages immediately.
  • Periodic re-evaluation: Regularly review approved packages for security and maintenance status.

Developer education

Training programs:

  • License awareness: Educate developers about license types and implications.
  • Security practices: Train on evaluating component security.
  • Compliance processes: Explain how to request approval for new dependencies.
  • Risk awareness: Help developers understand organizational concerns.

Continuous monitoring

Ongoing compliance:

  • Dependency updates: Monitor for new versions and security patches.
  • License changes: Track when projects change licenses.
  • Vulnerability disclosure: Subscribe to security advisories for dependencies.
  • Compliance audits: Periodically audit applications for license compliance.

Understanding license implications and implementing systematic compliance processes enables organizations to harness open-source benefits while managing risks effectively. The next unit provides a summary of key concepts covered in this module.