🇹🇷Türk hukuk bağlamı arıyorsanız bu kavramın Türkçe versiyonu:OSS Lisans Yükümlülükleri (Açık Kaynak Uyumu) →

What are OSS license obligations?

Open Source Software (OSS) license obligations are the conditions imposed by individual open source licenses on the use, modification, and redistribution of the licensed software. Despite being “free” in cost terms, OSS use carries legal obligations — attribution requirements, source disclosure, derivative-work licensing constraints. Non-compliance exposes companies to copyright infringement claims, injunction risk, and product recall — Conservancy v. Vizio (2024) and BusyBox cases confirmed enforcement viability. Modern software supply chains contain 50-90% OSS by component count; compliance is non-optional for any product company.

License family obligations overview

  • Permissive (MIT, Apache 2.0, BSD): minimal obligations — preserve copyright notice and license text. Apache 2.0 adds patent grant clause.
  • Weak copyleft (LGPL, MPL 2.0, EPL): share modifications to the licensed file/library; allow proprietary linking.
  • Strong copyleft (GPL v2, GPL v3): entire derivative work must be GPL; source code distribution required.
  • Network copyleft (AGPL v3): GPL plus network-use trigger — SaaS using AGPL code must offer source to users.
  • Non-OSS source-available (SSPL, BSL, Elastic License): not OSS by OSI definition but provide source under restrictive terms.

Compliance program components

  • SBOM (Software Bill of Materials): inventory of all components, versions, licenses.
  • License scanning: automated tools (FOSSA, Snyk, Black Duck, FOSSology) identify license terms in dependency tree.
  • Policy: approved/conditional/prohibited license lists; engineering process integration.
  • Attribution documentation: OPEN_SOURCE_LICENSES.md or similar shipped with product.
  • Modification tracking: diff with upstream for copyleft compliance.
  • Distribution audit: what gets distributed externally vs. internal-only.

Common compliance failures

  • Missing attribution: failure to include MIT/Apache license text in distributed software.
  • Static linking of LGPL: exposes proprietary code to LGPL terms in some interpretations.
  • SaaS use of AGPL without source disclosure: AGPL’s network-use trigger missed by SaaS teams.
  • Patent assertion against open source: Apache 2.0 patent termination provision triggers.
  • Modifying copyleft without redistribution: internal-only modifications are usually OK; distribution triggers obligations.

Related Terms

Related terms

Browse the glossary →