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.
Türk yazılım şirketleri için OSS uyumu
Türk yazılım şirketleri (Pardus, Logo, Insider, Picus Security) OSS uyumunda hem üretici hem tüketici pozisyonundadır. AB pazarına satışta Cyber Resilience Act (CRA) ve KVKK uyumlanma gereksinimleri OSS bağımlılık şeffaflığını giderek zorunlu kılar. Türk SaaS’lerin AGPL-lisanslı bileşen (Grafana, MinIO, MongoDB pre-2018) kullanımında network kullanıcılara kaynak sunma yükümlülüğü çoğunlukla görmezden gelinmektedir — uyum riski. Modern Türk Ar-Ge ve yazılım şirketlerinde SBOM ve license scanning artık standart CI/CD pipeline parçasıdır.
Do: generate SBOM at build time using SPDX or CycloneDX format; integrate license scanning into CI/CD with policy gates; maintain attribution file in all distributed products.
Don’t: treat OSS as “free to use however” — copyleft non-compliance creates real litigation risk and AGPL has triggered enforcement actions in 2022-2024.