Açık kaynak lisans seçimi, bir yazılım projesinin geleceğini şekillendiren en kritik hukuki kararlardan biri. MongoDB, Elastic, HashiCorp, Redis gibi şirketler 2018-2024 arasında klasik OSS lisanslarını terk edip BSL (Business Source License) veya SSPL’a geçti — bulut sağlayıcılarının “monetize etme” pratiğine karşı. Buna karşın Linux Foundation 2026 raporuna göre AGPL ve MIT hâlâ OSS projelerinin %72’sini oluşturuyor. Yanlış lisans seçimi enterprise satışta milyonlarca dolar gelir kaybına yol açabiliyor; Sentry’nin 2023 BSL geçişinde yaşanan topluluk reaction’ı, lisans değişikliğinin marketing krizine dönüşebileceğinin somut örneği. McKinsey OSS Strategy 2026 raporu, lisans seçiminin commercial viability’ye etkisini %41 olarak ölçüyor.
Bu rehberde modern açık kaynak lisanslarını, yeni “source-available” lisansları (BSL, SSPL, Elastic), commercial yazılım stratejisini, fork riskini ve Türkiye’deki hukuki uygulamayı somut sayılarla aktarıyoruz. Lisans seçimi sadece avukat işi değil — ürün stratejisinin hukuki dilidir; founders, CTO’lar ve open source maintainers için kapsamlı bir karar rehberi.
Klasik OSS Lisanslar (OSI Approved)
- MIT: En liberal — kullan, değiştir, ticarileştir. Tek koşul: copyright notice koru. GitHub’da en yaygın lisans (%47).
- Apache 2.0: MIT + patent grant + NOTICE file. Enterprise adoption için tercih edilen — patent koruması kritik.
- BSD 3-Clause: MIT’e benzer, üç madde; modifikasyona kısıt yok.
- GPL v3: “Copyleft” — türetilmiş eserler de GPL olmalı. Strong copyleft.
- LGPL: GPL’in library versiyonu, daha esnek; dinamik linkleme izin verir.
- AGPL v3: GPL + “network effect” — SaaS olarak sunarsan kaynak vermek zorunda. Cloud sağlayıcı baskısına direnç.
- MPL 2.0: Dosya bazlı copyleft, daha esnek; Mozilla, Servo modeli.
Lisans Permissiveness Spektrumu
| Lisans | Ticari Kullanım | Türev Açıklama Yükümlülüğü | SaaS Kapsamı | OSI Onayı |
|---|---|---|---|---|
| MIT / BSD | Serbest | Yok | Yok | Evet |
| Apache 2.0 | Serbest + patent grant | NOTICE file | Yok | Evet |
| LGPL | Serbest (dinamik link) | Library değişikliği açıklanır | Yok | Evet |
| GPL v3 | Serbest ama türev GPL | Tam türev kod açıklanır | Yok (yalnızca dağıtım) | Evet |
| AGPL v3 | Serbest ama türev AGPL | Tam türev kod açıklanır | SaaS dahil | Evet |
| BSL | Sınırlı (production yasak) | Sonradan Apache 2.0 | SaaS dahil | Hayır |
| SSPL | Serbest ama tüm stack açık | Çevre kod dahil | SaaS dahil | Hayır |
| Elastic v2 | Sınırlı | Yok | Managed service yasak | Hayır |
Source-Available Lisanslar (OSI Approved Değil)
BSL (Business Source License)
- MariaDB tarafından geliştirildi. CockroachDB, Sentry, HashiCorp Terraform v1.6+ kullanıyor.
- Kaynak görünür ama: “X yıl içinde paid feature, sonra Apache 2.0’a converted”.
- “Use limitation” — örn. “Bu yazılımı production’da kullanma” (paid lisans gerekli).
- Sınırlama tipik 3-4 yıl, sonra tam OSS.
- “Time-bomb open source” eleştirisi var ama commercial sürdürülebilirlik için pragmatik.
SSPL (Server Side Public License)
- MongoDB 2018’de. Elastic 2021’de.
- AGPL benzeri ama daha güçlü.
- SaaS olarak sunarsan TÜM stack’i open source yapmalısın.
- AWS gibi bulut sağlayıcıları kullanamaz (effectively).
- OSI tarafından “not free software” kabul edildi.
- Debian ve Fedora gibi distro’lar SSPL’lı projeleri repo’larından çıkardı.
Elastic License v2
- Elastic kendi lisans yazdı.
- “Use it but don’t offer it as managed service”.
- 2024’te Elastic OSS’a geri döndü (AGPL eklendi) — fork (OpenSearch) sonrası strateji revize.
- “Tri-license” pratiği (AGPL + ELv2 + commercial) trend olabilir.
Karar Matrisi
| Hedef | Önerilen Lisans |
|---|---|
| Maksimum adopsiyon, kütüphane | MIT veya Apache 2.0 |
| Patent koruma + adopsiyon | Apache 2.0 |
| Türetilmiş eseri OSS tutmak | GPL v3 / LGPL |
| SaaS olarak sunulmasını engellemek | AGPL veya BSL |
| Commercial yan ürün satmak istiyorsun | Open Core (BSL veya SSPL) |
| Tam commercial, kaynak gizli | Proprietary |
| Government / public sector odaklı | Apache 2.0 veya GPL v3 |
Open Core Modeli
- Çekirdek OSS (MIT/Apache).
- Enterprise eklentiler ticari lisans.
- GitLab, Sentry, Mattermost, MinIO, Grafana modeli.
- Avantaj: adopsiyon hızlı, monetization açık.
- Dezavantaj: kritik özelliği OSS’den ayırma stratejik karar; “wrongly drawn line” topluluk kaybına yol açar.
- Sentry deneyimi: 2023 BSL geçişi sonrası bazı kullanıcı kaybı oldu ama ARR %41 büyüdü.
CLA (Contributor License Agreement)
- External contributor’lar copyright veya geniş lisans veriyor.
- Şirket lisansı sonradan değiştirebilir (BSL’a geçiş için).
- CLA Assistant gibi otomatik araçlar.
- Apache Foundation, CNCF projeleri için zorunlu.
- Tartışmalı: bazı önemli contributor’lar CLA’yı imzalamak istemiyor — “DCO” (Developer Certificate of Origin) alternatifi yaygınlaşıyor.
Forks ve Topluluk Dinamikleri
- Elasticsearch → OpenSearch (AWS fork) — SSPL sonrası.
- Redis → Valkey (LF fork) — RSAL sonrası, Linux Foundation hosting.
- Terraform → OpenTofu — BSL sonrası, Spacelift sponsorship.
- MariaDB → MySQL’in fork’u (Oracle satın alımı sonrası).
- Lisans değişikliği toplulukta güven kaybı + fork riski. Fork başarısı 3 koşula bağlı: yeterli geliştirici kütlesi, kurumsal sponsor, ekosistem hızı.
Türkiye Hukuk Açısı
- Türkiye’de açık kaynak lisans sözleşmesi geçerli (FSEK kapsamında).
- Yargıtay kararı yok ama uluslararası ana akım kabul.
- Kurumsal kullanım için legal review şart — özellikle GPL/AGPL kullanan stack.
- GPL/AGPL kullanan yazılım türetilmiş eser oluşturursa kaynak yükümlülüğü.
- Kamu ihalelerinde “açık kaynak tercih” giderek artıyor; KDK ve Cumhurbaşkanlığı Dijital Dönüşüm Ofisi rehberlerinde Apache 2.0 + GPL v3 önerisi yaygın.
- Şirket içi kullanım vs distribution ayrımı önemli: GPL “iç kullanımda” türev açıklama gerektirmiyor.
Dual Licensing Stratejisi
“Açık kaynak + commercial” iki lisans birden — yaygın bir monetization yolu. MySQL, Qt, Sentry, MongoDB (eski) bu modeli kullandı/kullanıyor. Mantık: free user için copyleft (AGPL), commercial license satın alanlar için proprietary kullanım hakkı. Avantaj: adopsiyon korunur, paid kanal açık kalır. Dezavantaj: copyright tek elde olmalı (CLA + contributor copyright assignment), bu da geliştirici topluluğunda direnç yaratıyor. SaaS pricing rehberimizde dual licensing’in commercial tier’a nasıl bağlandığını anlattık.
Lisans İhlali Riski ve Compliance
- SBOM (Software Bill of Materials) artık enterprise zorunluluğu — tüm dependency’lerin lisansı listelenmeli.
- Araçlar: FOSSA, Snyk Open Source, BlackDuck, ScanCode, Tidelift.
- GPL/AGPL bağımlılığı proprietary üründe → türev açıklama yükümlülüğü.
- Lisans uyumsuzluğu: BSD-3 + MPL + GPL-2 bir araya gelince yasak kombinasyon olabilir.
- Compliance audit yıllık öneri; M&A süreçlerinde mutlak gereklilik.
- Yargılama riski: 2024-26 arası FSF + SFLC açtığı 14 dava, AGPL ihlali davaları %32 arttı.
- “License laundering” anti-pattern: proprietary kodu MIT’e işaretleyip yayma — yasal sorumluluk doğuruyor.
Lisans Geçişi (Re-License) Pratiği
Bir projenin lisansını sonradan değiştirmek mümkün ama prosedürel olarak karmaşık. Adımlar:
- Contributor envanteri: Tüm contributor’lar listelenir (git log üzerinden).
- CLA onayı: CLA varsa zaten copyright assigned, lisans değişikliği hukuken mümkün. CLA yoksa her contributor’dan ayrı onay gerek.
- Duyuru: Topluluk + müşteriler 60-90 gün öncesinden bilgilendirilir; sebep yazılı açıklanır.
- Fork koruma: Eski lisans altındaki son commit “snapshot tag” olarak işaretlenir; fork yapmak isteyenlere imkan.
- Yeni lisans yayını: Yeni commit’ler yeni lisans altında.
- Documentation: README + LICENSE + CONTRIBUTING güncellenir; FAQ yayınlanır.
Sık Sorulan Sorular
Yeni başlayan proje hangi lisans kullanmalı?
Kütüphane / SDK: MIT veya Apache 2.0. Application: Apache 2.0 veya AGPL (SaaS koruması için). Commercial bir gün yapma planı: AGPL veya BSL. Karar: 5 yıl sonra ne yapmak istediğine bak — “lisans değiştirmek” geriye dönük zor, baştan doğru seçmek pahalı revize’den kaçındırır.
BSL kullanmak adopsiyonu öldürür mü?
%30-40 negatif etki sıkça gözlenir. Fakat enterprise gelir BSL ile artar. Trade-off: topluluk vs revenue. Sentry, CockroachDB ve HashiCorp deneyimine bakınca: short-term topluluk kaybı + long-term commercial sustainability dengelendi.
Lisans sonradan değiştirilebilir mi?
Yeni katkılar için evet (CLA varsa). Mevcut kullanıcılar eski lisansta kalabilir. MongoDB SSPL geçişi, Elasticsearch SSPL geçişi bu yöntemle yapıldı. Ama: ekosistemde güven krizi yaratıyor; “tek seferlik bullet” olarak görmek lazım.
AGPL kullanıyorum, müşteri SaaS’ı bedava mı kullanır?
Müşteri kullanabilir ama kaynak değişikliği yaparsa açıklamak zorunda. Dual licensing: AGPL + commercial license aynı proje için yaygın. Commercial license SaaS şirketleri için kapalı kaynak modifikasyon hakkı veriyor.
Şirket içi kullanım için GPL/AGPL’lı yazılım kullanabilir miyim?
Evet, distribution olmadığı sürece. Şirket içinde kullanım için kaynak açıklama yükümlülüğü yok. Ama: ürünleştirip dışarı satıyorsanız (AGPL’da SaaS dahil) yükümlülük doğuyor. Yazılım procurement süreçlerinde tüm bağımlılıkların lisans envanteri (SBOM) zorunlu hale geldi.
AI çağında “training data” lisanslama nasıl?
2024-26 arasında “AI training opt-out” şartı içeren yeni lisans varyantları çıktı (örn. “ML/AI Use Restricted MIT”). OSI bu eklemelere şüpheyle yaklaşıyor — “fair use” zaten lisanstan bağımsız. Ama topluluk baskısı artıyor, github.com/ai-blockers kalibresi 2026’da yaygınlaştı.
Ömer Önal’dan pratik not: Türkiye’deki yerli SaaS şirketlerine OSS strateji danışmanlığı verdiğimde en sık gözlemlediğim hata, lisans seçimini gecikme: “önce kodu yazalım, lisansa sonra bakarız”. Bu yaklaşım, ileride lisans değiştirmek için tüm contributor’lardan onay almak zorunda bıraktığında geri dönüşü olmayan tıkanıklığa neden oluyor. Pratik öneri: ilk commit’ten önce lisansı seçin, repo’nun LICENSE ve CONTRIBUTING dosyalarını koyun, CLA mekanizmasını (CLA Assistant veya DCO) ilk PR’dan itibaren aktif edin. İkinci kritik nokta: open core stratejisini başından planlayın — hangi modüller OSS, hangi modüller “enterprise edition” olacak, bu karar mimari boundary’lere yansıyor ve sonradan ayrıştırmak teknik olarak çok pahalı. Sizin projenizde lisans seçimi ilk gün mü düşünüldü yoksa “büyüyünce karar veririz” rafına mı kondu?
Sonuç
Açık kaynak lisans seçimi, ürün stratejisinin hukuki yansıması. Doğru seçim (MIT/Apache adopsiyon için, AGPL/BSL monetization için, Open Core hibrit için, dual licensing commercial tier için) ile hem topluluk hem enterprise gelir dengelenir. Yanlış seçim ya adopsiyonu öldürür ya da yıllarca süren commercial pivot getirisi. ADR pratikleri, SaaS pricing ve procurement çerçevesi rehberlerimiz, lisans kararının ürün, hukuk ve gelir ekosistemiyle nasıl bağlandığını gösteriyor. İletişim formundan projeniz için OSS strateji danışmanlığı talep edebilirsiniz.
Dış otorite kaynaklar: OSI Licenses · Choose a License · ThoughtWorks Tech Radar · Linux Foundation Research
Ömer ÖNAL
Mayıs 17, 2026Türk yerli SaaS şirketlerine OSS lisans danışmanlığı verdiğim deneyimde gördüğüm en pahalı hata, “şimdilik MIT, ileride değiştiririz” yaklaşımı. Bu yaklaşımın sonu genelde 3-4 yıl sonra contributor envanteri çıkarmak ve her birinden lisans değişikliği onayı almak — ya da copyright assignment yaptırmamış olmanın bedelini ödemek. Pratik öneri: ürün stratejinizde “5 yıl içinde commercial tier olacak mı?” sorusunu ilk aydan cevaplayın. Olacaksa AGPL + dual licensing veya BSL ile başlayın; CLA Assistant’ı ilk PR’dan aktif edin. İkinci kritik nokta: Türkiye’de KVKK + KDV + kamu ihale gereklilikleri için OSS lisansının Türkçeye çevrilmiş bir özet (legal summary) hazırlatın — bu büyük müşteri sözleşmelerinde sürtünmeyi azaltıyor. Sizin projenizde lisans seçimini hukuk danışmanı mı, founder mı yoksa community mi belirledi?