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: a SaaS running a modified version of AGPL code must offer its corresponding source to users interacting with it over a network.
- 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.
OSS Compliance for Turkish Software Companies
Turkish software companies are both producers and consumers of open source. When selling into the EU market, Cyber Resilience Act (CRA) requirements increasingly make transparency of OSS dependencies mandatory. Among Turkish SaaS companies using AGPL-licensed components (Grafana, MinIO, MongoDB pre-2018), the obligation to offer source code to network users is frequently overlooked, which is a compliance risk. In modern Turkish R&D and software companies, SBOM generation and license scanning are now a standard part of the CI/CD pipeline.
Practical Compliance Steps
- Generate an SBOM in SPDX or CycloneDX format at build time.
- Integrate license scanning into CI/CD with policy gates.
- Keep an attribution file in every distributed product.
- Do not treat OSS as free to use however one likes: copyleft non-compliance creates real litigation risk.