GPL, MIT ve Apache lisans farkları nelerdir?

GPL, MIT ve Apache: her lisansın sizden beklentileri

GPL, MIT ve Apache 2.0 aynı soruya farklı yanıtlar verir: Yazılımı başkasına devrettiğinizde diğer insanlara karşı yükümlülüğünüz nedir? MIT, yalnızca bir telif hakkı bildirimi ister, başka bir şey talep etmez. Apache 2.0, bu bildirime ek olarak koda dokunan herkes arasında bir patent anlaşması yapılmasını şart koşar. GPL ise üzerine inşa ettiğiniz yazılımın kaynak kodunu, aldığınız lisansla aynı lisans altında yayınlamanızı gerektirir.

Bu durum, yürüttüğünüz bir proje lisansını değiştirip ikiye bölünene kadar avukatların işi gibi görünür. O noktada ise bir operasyonel sorun haline gelir. Aralarında seçim yapmanız gereken iki paket deposu ve artık birbiriyle iletişim kuramayan istemci kütüphaneleriyle karşı karşıya kalırsınız. Bu kılavuz, lisansların kendisi ve işleyiş mekanizmaları hakkındadır; onları ortaya çıkaran hareketle ilgili değildir. Bu nedenle her bölüm, doğrudan sizi, yani yükseltme işlemini yapmak zorunda olan kişiyi ilgilendirdiği noktada sona erer.

GPL neden var: kimsenin düzeltmesine izin verilmeyen bir yazıcı

1980 civarında MIT Yapay Zeka Laboratuvarı bir Xerox 9700 lazer yazıcı teslim aldı. Laboratuvar, önceki bir yazıcının yazılımını, işiniz sıkıştığında size haber verecek şekilde yamalamıştı. Yeni yazıcı için kaynak kodu yoktu ve gizlilik sözleşmesi nedeniyle kaynak kodu talebi reddedildi. O dönem laboratuvarda programcı olan Richard Stallman, bu reddi kötü bir gün olarak değil, genel bir durum olarak değerlendirdi ve 27 Eylül 1983 tarihinde GNU projesini duyurdu.

Copyleft, telif hakkı yasalarına karşı değil, bu yasalar üzerine inşa edilmiştir. Varsayılan olarak, başkasının kodunu kopyalama hakkınız yoktur. GPL bu hakkı bir koşulla tanır: Eğer programı başka birine verirseniz, onlara kaynak kodu aynı şartlar altında vermelisiniz; böylece onlar da laboratuvarın yapamadığını yapabilirler. Bu koşul uygulanabilirdir çünkü lisans olmadan başlangıçta hiçbir izniniz yoktur.

Stallman önce GNU Emacs için bir lisans yazdı, ardından bunu 25 Şubat 1989 tarihinde GPL sürüm 1 olarak genelleştirdi. GPL sürüm 2, Haziran 1991'de geldi ve hala çalıştırdığınız sistem yazılımlarının çoğunda bulunan lisanstır. Lesser GPL, kütüphaneler için geliştirildi; böylece bir copyleft kütüphanesi, herhangi bir lisans altındaki bir program tarafından, o programı GPL kapsamına çekmeden bağlanabildi.

Bir detay, GPL'in self-host yapan birini nasıl etkilediğini belirler. Yükümlülük, kullanımda değil dağıtımda tetiklenir. Bir GPL programını değiştirebilir, kendi sunucunuzda çalıştırabilir, halka hizmet verebilir ve kimseye bir şey borçlu olmazsınız; çünkü hiçbir zaman bir kopyasını dağıtmadınız. Bu boşluk, AGPL'in var olma nedenidir.

İzin verici gelenek: Önce BSD, sonra MIT

Berkeley farklı bir yol izledi. Computer Systems Research Group, Unix çalışmalarını telif hakkı bildiriminin korunmasını şart koşan ve her türlü garantiyi reddeden bir lisansla yayımladı. Orijinal sürüm dört maddeden oluşuyordu; dördüncü madde olan reklam maddesi, yazılımın özelliklerinden bahseden tüm reklam materyallerinde üniversiteye atıfta bulunulmasını gerektiriyordu. Bu ölçeklenebilir bir yöntem değildir. Stallman, 1997 tarihli bir NetBSD sürümünde 75 ayrı teşekkür notu saymıştır. UC Berkeley, Teknoloji Lisanslama Ofisi'nden William Hoskins tarafından yazılan 22 Temmuz 1999 tarihli bir mektupla bu maddeyi yürürlükten kaldırmıştır.

Geriye kalan, katkıda bulunanların isimlerinin ürününüzü desteklemek amacıyla kullanılmasını yasaklayan 3 maddeli BSD lisansı ve bunu da kaldıran 2 maddeli sürümdür. MIT lisans metni, 1980'lerde MIT'den çıkmış ve X Window System'i kapsamıştır; pratikte 2 maddeli BSD lisansı ile aynı işlevi görür.

Güdüler farklıydı. Kamu fonlarıyla finanse edilen bir üniversite, çalışmalarının şirketler dahil her yerde kullanılmasını istiyordu. GNU projesi ise kapatılamayacak bir ortak alan oluşturmayı hedefliyordu. Her iki duruş da dürüsttür ve her ikisinin de bir başarısızlık modu vardır. İzin verici (permissive) kod özel mülkiyete dönüştürülebilir ve karşılığında hiçbir şey alamazsınız. Copyleft kod ise avukatları bu koşulu kabul etmeyen şirketler tarafından reddedilir.

Berkeley'den çıkarılacak ikinci bir ders daha vardır ve bu yazı sürekli olarak bu noktaya dönmektedir. AT&T'nin Unix System Laboratories şirketi, 1992 yılında BSD kodu nedeniyle Berkeley Software Design'a dava açmış ve dava 1994 başında uzlaşmayla sonuçlanmıştır. İki yıl boyunca kimse BSD üzerine inşa etmenin güvenli olup olmadığından emin olamadı ve Linux büyürken BSD'nin benimsenme süreci duraksadı. Hukuki belirsizlik, benimsenmeyi eksik bir özellikten çok daha hızlı durdurur.

Apache 2.0 neden patent hibesi ekledi

Apache Group'un ilk lisansı, aynı reklam kısıtlaması sorununa sahip, BSD 4-clause türevi bir lisanstı. 2000 yılındaki 1.1 sürümü bu maddeyi kaldırdı. Ocak 2004'te yayımlanan 2.0 sürümü ise bir yamadan ziyade yeniden yazılmış bir metindir.

Buradaki önemli ekleme patentlerle ilgilidir. MIT ve BSD lisansları bu konuda hiçbir şey söylemez. Bir katkıda bulunan kişi, kod için size açık bir telif hakkı izni verebilir ancak kodun işlevini kapsayan bir patent hakkını elinde tutmaya devam edebilir ve ardından kodu kullanan kişilere dava açabilir. Apache 2.0 bu açığı kapatır: her katkıda bulunan kişi, katkısını kapsayan bir patent lisansı verir ve çalışmanın kendi patentlerini ihlal ettiğini iddia ederek dava açan herkes, bu çalışmaya yönelik kendi patent lisansını kaybeder. Tehdit karşılıklıdır, bu nedenle pratikte kimse dava açmaz.

2.0 sürümünün geri kalanı idari düzenlemelerden oluşur ve şirketlerin bu lisansı tercih etme nedeni de budur. Tanımlanmış bir NOTICE dosyası mevcuttur; böylece atıflar kaynak ağacına dağılmak yerine tek bir merkezde toplanır. Lisans, her kaynak dosyasına yapıştırılmak yerine referans verilerek uygulanabilir. Katkılar açık şartlarla güvence altına alınmıştır. Ticari markalar kapsam dışı bırakılmıştır. Apache 2.0 bağımlılığına yönelik bir hukuki inceleme, sorulmak istenen her sorunun metin içerisinde zaten yanıtlandığını gösterir; bu da onay sürecini rutin hale getirir. "Kurumsal varsayılan" ifadesinin temel anlamı da budur.

GPLv3 neleri değiştirdi ve Linux neden GPLv2'de kaldı

TiVo, Linux çalıştıran bir video kaydedici piyasaya sürdü ve GPLv2'nin gerektirdiği şekilde çekirdek kaynak kodunu yayımladı. Donanım, açılış sırasında kriptografik bir imzayı kontrol ediyor ve tanımadığı bir çekirdeği çalıştırmayı reddediyordu. Kaynak kodunu okuyabilir, değiştirebilir ve derleyebilirsiniz. Ancak bu kodu, cihazın geldiği donanım üzerinde çalıştıramazsınız. Lisansın lafzına uyulmuş ancak amacı boşa çıkarılmıştır; bu uygulama tivoisation (tivolaştırma) adını almıştır.

29 Haziran 2007'de yayımlanan GPL sürüm 3, bu duruma doğrudan yanıt verir. Bir tüketici cihazı içinde ikili dosyayı (binary) dağıttığınızda, "Kurulum Bilgisi"ni de sağlamanız gerekir: değiştirilmiş bir sürümü yüklemek ve çalıştırmak için gereken anahtarlar veya talimatlar. Sürüm 3 ayrıca açık bir patent hibesi, Kasım 2006'daki Microsoft ve Novell patent anlaşmasına yanıt olarak yazılmış maddeler ve Apache 2.0 ile tek yönlü uyumluluk eklemiştir.

Linux bu yolu izlemedi. Çekirdek, "veya sonraki herhangi bir sürüm" kaçış maddesi olmaksızın yalnızca GPL sürüm 2'dir ve COPYING dosyası bunu belirtir. Linus Torvalds, imzalı donanımlara yönelik tivolaştırma karşıtı maddelere kamuoyu önünde itiraz etmiştir. Pratik engel, anlaşmazlıktan daha büyüktür: çekirdeğin binlerce telif hakkı sahibi vardır, bu nedenle herkes istese bile bir lisans değişikliği için gereken izinleri toplamak imkansızdır. Bu tek gerçek, bir projenin sahip olabileceği en güçlü korumadır ve tek bir şirkete ait bir projeye baktığınızda bunu hatırlamakta fayda vardır.

2007'nin diğer lisansı sizin için daha önemlidir. Aynı yılın Kasım ayında yayımlanan GNU Affero GPL sürüm 3, kaynak kodu sağlama yükümlülüğünü programla ağ üzerinden etkileşime giren kişileri de kapsayacak şekilde genişletir. Değiştirilmiş bir AGPL servisini halka açık çalıştırırsanız, o kullanıcılara kaynak kodunu sağlamakla yükümlüsünüzdür. Bu yüzden kendi kendine barındırılan (self-hosted) web yazılımlarının çoğu AGPL'dir. Nextcloud buna bir örnektir ve eğer Nextcloud'a alternatif self-hosted çözümleri karşılaştırıyorsanız, her adayın deposundaki lisans satırı size önümüzdeki beş yıl hakkında özellik listesinden daha fazlasını anlatır.

Hangi lisanslar gerçekten birleştirilebilir?

Uyumluluk, izin verici (permissive) lisanslardan copyleft lisanslara doğru tek yönlü işler.

• MIT ve BSD kodları, kapalı kaynaklı bir ürün dahil olmak üzere her türlü projeye dahil edilebilir.
• Apache 2.0 kodu, GPLv3 bir projeye dahil edilebilir ve birleştirilmiş çalışma GPLv3 lisansına tabi olur.
• Apache 2.0 kodu, yalnızca GPLv2 lisanslı bir projeye dahil edilemez. Apache 2.0'ın patent feshi ve tazminat hükümleri, GPLv2'nin izin vermediği ek koşullar teşkil eder. Hem FSF hem de ASF bu sonuca vardıklarını açıklamıştır.
• GPL kodları, sizin tarafınızdan izin verici bir lisansa geçirilemez. Bunu yalnızca telif hakkı sahipleri yapabilir; bu da sizi tekrar telif hakkı sahiplerinin kim olduğu sorusuna götürür.

Lisans değiştirme dönemi: SSPL, BUSL ve bunların ne olmadığı

Tetikleyici unsur ticariydi. Bir şirket bir ürünün telif hakkına sahiptir, bir bulut sağlayıcısı bunu yönetilen bir hizmet olarak büyük ölçekte satar ve karşılığında çok az katkı sağlar; şirket de bunu durdurmak için lisansı değiştirir. Redis Labs, Ağustos 2018'de birkaç modülü için Apache 2.0 üzerine Commons Clause ekleyerek ilk görünür adımı attı. MongoDB, 16 Ekim 2018'de AGPLv3'ten Server Side Public License'a geçerek bunu takip etti.

SSPL, bir bölümü yeniden yazılmış AGPL'dir. Programı üçüncü taraflara bir hizmet olarak sunarsanız, yönetim ve orkestrasyon yazılımları dahil olmak üzere, hizmeti sunmak için kullandığınız her şeyin kaynak kodunu yayınlamanız gerekir. Bu yükümlülüğün net bir sınırı yoktur ve hiçbir mahkeme tarafından test edilmemiştir. OSI lisansı hiçbir zaman onaylamadı ve MongoDB başvurusunu Mart 2019'da geri çekti. Debian, Aralık 2018'de SSPL yazılımının arşivinde yerinin olmadığını zaten belirtmişti; Fedora ise Ocak 2019'da lisansın özgür olmadığına karar verdi. Bunun ardından Red Hat, MongoDB'yi Fedora'dan ve Red Hat Enterprise Linux'tan çıkardı. Bu, bir lisans değişikliğinin mekanik sonucudur: dağıtım yazılımı paketlemeyi bırakır, bu nedenle güncellemeleriniz artık satıcının takvimine göre satıcı deposundan gelir.

Business Source License farklı bir mekanizmadır. MariaDB kurucularından çıkmıştır ve 1.1 sürümü 2017 yılına dayanır. Bu bir copyleft değildir ve açık kaynak değildir. Kaynak kod herkese açıktır, satıcının istisna tuttuğu kullanımlar (genellikle rakip bir barındırma hizmeti çalıştırmak) dışında kullanım ücretsizdir ve her sürüm, yayınlanmasından en fazla dört yıl sonra bir değişim tarihinde otomatik olarak gerçek bir açık kaynak lisansına dönüşür. Dönüştüğü lisansın GPLv2 uyumlu olması gerekir. HashiCorp, 10 Ağustos 2023'te Terraform ve diğer ürünlerini BUSL 1.1'e taşıdı. Outline da bunu kullanmaktadır; kendi kendine barındırılan Notion alternatifleri arasından seçim yapıyorsanız bunu bilmekte fayda vardır: kendi ekibiniz için çalıştırmanıza izin verilir, ancak bunun üzerine bir hizmet inşa etmenize izin verilmez.

Her iki lisans da dürüst olmayan bir yapıya sahip değildir. Her ikisi de açıkça "source available" (kaynak kodu erişilebilir) olduklarını belirtir. Hiçbiri OSI tanımına göre açık kaynak değildir ve aradaki fark, hedeflenen bulut sağlayıcısından ziyade doğrudan sizi etkiler.

OpenSearch: Bir lisans çatalının operatöre maliyeti

Elastic, 14 Ocak 2021 tarihinde Elasticsearch ve Kibana'nın 7.11 sürümünden itibaren Apache 2.0 lisansından ayrılarak SSPL veya Elastic License seçeneklerine geçeceğini duyurdu. 7.10.2 sürümü, Apache 2.0 lisansına sahip son sürümdü. Yaklaşık bir hafta sonra AWS, her iki yazılımın da Apache 2.0 lisanslı bir çatalını (fork) oluşturacağını ve sürdüreceğini açıkladı. 12 Nisan 2021'de bu çatal OpenSearch olarak adlandırıldı ve Kibana, OpenSearch Dashboards olarak yeniden isimlendirildi. Elasticsearch 7.10.2 ve Kibana 7.10.2 temel alınarak geliştirilen OpenSearch 1.0, 12 Temmuz 2021 tarihinde genel kullanıma sunuldu.

Bunun küme (cluster) yönetenler için maliyetine bakmak gerekir. Paket isimleri ve depolar değişti. Operasyonel el kitaplarındaki her Kibana referansı OpenSearch Dashboards haline geldi. Eklenti isimleri taşındı. Ardından ayrılık uygulama koduna kadar ulaştı: Elastic'in resmi istemci kütüphanelerinin 7.13 sürümünden itibaren istemci, bağlandığı sunucuyu kontrol etmekte ve Elasticsearch olmayan herhangi bir sunucuya karşı çalışmayı reddederek sunucunun bilinmeyen bir ürün olduğunu bildirmektedir. Çalışmadığınız bir şirketin aldığı lisans kararı, kendi uygulamanızın içinde başarısız bir çağrı olarak karşınıza çıktı.

Hikaye daha sonra iki kez daha yön değiştirdi. Elastic, 29 Ağustos 2024'te üçüncü bir lisans seçeneği olarak AGPLv3'ü ekledi; böylece mevcut Elasticsearch tekrar OSI onaylı açık kaynak haline geldi. 16 Eylül 2024'te AWS, OpenSearch'ü Linux Foundation tarafından barındırılan OpenSearch Software Foundation'a devretti. Bu durum, çatalın tek bir şirkete bağlı olmayan bir yönetim yapısına kavuşmasını sağladı. Ayrılıktan beş yıl sonra her iki proje de açık kaynaklıdır, her ikisi de sürdürülmektedir ve OpenSearch, Ağustos 2026 itibarıyla 3.x serisindedir.

Sonuç, alınması gereken derstir. Lisans geri döndü ancak çatal kalıcı oldu. Bir ekosistemde her şeyden iki tane olduğunda, evrak işlerini geri almak onları tekrar birleştirmez.

Bir lisans değişikliğinin ne kadar zarar vereceğini belirleyen sayı, duyuru ile fiilen dağıtıma hazır kararlı bir çatal arasındaki süredir.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

Her boşluk, satıcının kamuya açık duyurusundan çatalın ilk kararlı sürümüne kadar aşağıda listelenen tarihler kullanılarak hesaplanır. OpenSearch 1.0, 179 gün sürmüştür; çünkü çatalın yeniden adlandırılması ve kopyalanacak daha eski bir çatal olmadan sıfırdan inşa edilmesi gerekmiştir. OpenTofu 153 gün sürmüştür. Valkey ise 27 gün sürmüştür; çünkü Redis 7.2.4 sürümünü çatallamış ve protokol ile disk üzerindeki formatı aynı tutmuştur. Buradaki önemli nokta şudur: güvenilir bir çatal artık haftalar içinde, ilk günden itibaren bir vakıf ve ücretli sürdürücülerle birlikte gelmektedir.

Valkey ve OpenTofu: aynı model, daha hızlı

Redis Ltd, 20 Mart 2024 tarihinde Redis'i 3-clause BSD lisansından RSALv2 veya SSPLv1 seçeneklerine taşıdı. Sekiz gün sonra Linux Foundation, Redis 7.2.4 sürümünden çatallanan ve 3-clause BSD lisansında kalan Valkey projesini duyurdu. Valkey 7.2.5, 16 Nisan 2024'te aynı protokol ve aynı veri dosyalarıyla yayınlandı; bu nedenle çoğu operatör için geçiş süreci yalnızca bir paket adı değişikliğinden ibaret oldu. Redis, Mayıs 2025'te Redis 8 ile üçüncü bir seçenek olarak AGPLv3 lisansını ekledi ve bu sayede OSI tanımına göre tekrar açık kaynak haline geldi; Valkey ise kendi yönetimi altında devam ediyor. Bu durum, Elasticsearch ile büyük ölçüde benzerlik gösteriyor.

Terraform, fazladan bir bölümle aynı süreci yaşadı. OpenTofu, Mozilla Public License 2.0 altındaki son sürümü çatalladı, Eylül 2023'te Linux Foundation'a katıldı ve 10 Ocak 2024'te 1.6.0 sürümünü yayınladı. 3 Nisan 2024'te HashiCorp avukatları, BUSL lisanslı bir Terraform sürümünden kodların çatallanan projeye kopyalandığını iddia eden bir ihtarname gönderdi. OpenTofu, 11 Nisan 2024'te iddiaları reddeden ayrıntılı bir yanıt yayınladı ve tartışmalı kodun her iki projenin de paylaştığı MPL lisanslı geçmişe dayandığını kanıtladı. Kamuoyuna yansıyan başka bir gelişme olmadı. Bu olaydaki asıl risk, akılda tutulması gereken noktadır: Sadece bir suçlama bile, otuz yıl önceki Berkeley davasının yarattığı etkiyle aynı şekilde, bir teknolojinin benimsenmesini bir çeyrek boyunca dondurabilir.

Her çatallanma lisans değişikliğiyle başlamaz. Forgejo, 2022 yılında Gitea'nın geliştirme süreçlerinin bir şirketin kontrolüne geçmesinin ardından çatallandı; bu, lisans değil bir yönetim anlaşmazlığıydı. Forgejo, 8 sürüm serisi boyunca MIT lisansında kaldı, ardından 2024'te 9.0 sürümüyle GPLv3 veya sonraki sürümlerine geçiş yaptı; böylece projenin çalışmaları ticari olarak kontrol edilen bir ürüne geri çekilemedi. Eğer self-hosted Git sunucusu seçeneklerini değerlendiriyorsanız, bu ikili, tek bir kod tabanı ve iki farklı felsefenin en net güncel örneğidir.

Herhangi bir şeyi benimsemeden önce yapılması gereken test

İlk kurulumdan sonra değil, kurulumdan önce sorulması gereken dört soru.

1. Telif hakkı kime ait? Lisans değişikliği, her bir telif hakkı sahibinden izin alınmasını gerektirir; bu nedenle yüzlerce bağımsız katkıda bulunanı olan ve hak devri yapılmamış bir projenin lisansı gerçekçi bir şekilde değiştirilemez. Her şeyin tek bir şirkete ait olduğu bir proje ise yönetim kurulu toplantısında lisans değişikliğine gidebilir.
2. Bir CLA var mı ve ne sağlıyor? Katkıda bulunanın, yaptığı katkıyı şirketin dilediği şartlar altında yeniden lisanslamasına izin veren bir katkıda bulunan lisans sözleşmesi (CLA), yukarıda bahsedilen her lisans değişikliğinin arkasındaki temel mekanizmadır. Linux çekirdeğinin 2004 yılında benimsediği ve bir onay satırı olan DCO (developer certificate of origin), hiçbir hak devri içermez. Bir vakıf tarafından tutulan CLA, şirket tarafından tutulandan daha güvenlidir; çünkü şirketler satılabilir.
3. Ticari marka kime ait? Elastic, Elasticsearch ismini elinde tuttu, bu yüzden fork (çatallanma) kendisini yeniden adlandırmak zorunda kaldı ve Kibana'dan bahseden her runbook yeniden yazılmak zorunda kaldı.
4. Bir lisans değişikliği size özel olarak neye mal olur? Veri formatını, istemci kütüphanelerini, yeniden yazacağınız yapılandırmayı ve uyumlu bir fork'un halihazırda var olup olmadığını hesaplayın.

İki komut, bunun bir kısmını saniyeler içinde yanıtlar.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

Her Debian ve Ubuntu paketi /usr/share/doc/<package>/copyright konumunda bir dosya barındırır ve bu dosya, projenin bugün kullandığı lisansı değil, kurduğunuz sürümün lisansını kaydeder. Ubuntu 24.04 üzerindeki bash için bu dosya, GNU General Public License version 3'ü belirtir. İkinci komutu bir kaynak kodu dizininde çalıştırdığınızda, lisans dosyasının kendi geçmişini alırsınız. Orada son iki yıl içinde yapılmış bir commit, proje üzerine herhangi bir şey inşa etmeden önce okunmaya değerdir. Komut hiçbir çıktı vermezse, depo lisans dosyasını başka bir şekilde adlandırmıştır; bu durumda kök dizini listeleyin ve kontrol edin.

Hiçbir lisans sizi her türlü sonuçtan korumaz ve ideolojiye göre seçim yapmak, insanların sürprizlerle karşılaşmasına neden olur. Telif hakkı birçok el arasında dağılmış veya bir vakıf tarafından tutulan projeleri tercih edin ve verilerinizi dışa aktarabileceğiniz bir formatta tutun. Ardından, geçiş yapabileceğiniz fork'u belirleyin ve ismini ihtiyaç duymadan önce bir yere not edin. Bu kontrolü her aday için uygulamak bir saatten az sürer ve 2026 yılında nelerin self-host edileceğine karar verirken, bir yükseltme ile bir göç arasındaki farkı belirleyen şey budur.

FAQ

MIT lisansı ile BSD lisansı aynı mıdır?

Pratikte MIT, 2 maddeli BSD lisansı ile aynıdır: telif hakkı bildirimini ve garanti reddini koruduğunuz sürece, kapalı kaynaklı bir ürün oluşturmak da dahil olmak üzere dilediğinizi yapabilirsiniz. 3 maddeli BSD lisansı, katkıda bulunanların isimlerinin izinsiz olarak ürününüzü desteklemek amacıyla kullanılmasını yasaklayan ek bir madde içerir. Daha eski olan 4 maddeli sürüm ise reklam materyallerinde bir teşekkür ifadesi zorunluluğu getiriyordu; UC Berkeley bu maddeyi 22 Temmuz 1999 tarihinde yürürlükten kaldırdığı için günümüzde neredeyse hiçbir güncel yazılım bu maddeyi içermemektedir.

Apache 2.0 kodunu bir GPLv2 projesine dahil edebilir miyim?

Hayır. Apache 2.0, GPLv2'nin izin vermediği koşullar ekler; bunların başında patent fesih maddesi gelir. Bu nedenle birleştirilmiş bir çalışma her iki lisansın gerekliliklerini aynı anda karşılayamaz. Hem FSF hem de ASF bu sonucu doğrulamaktadır. Diğer yönde ise işlem mümkündür: Apache 2.0 kodu bir GPLv3 projesine dahil edilebilir ve ortaya çıkan sonuç GPLv3 olur. Apache 2.0 kodunun, yalnızca GPL sürüm 2 ile lisanslanmış olan Linux kernel içerisine dahil edilememesinin nedeni de budur.

SSPL bir açık kaynak lisansı mıdır?

Hayır; bu cevabın pratik sonuçları vardır. OSI bu lisansı hiçbir zaman onaylamamış, MongoDB ise Mart 2019'da başvurusunu geri çekmiştir. Debian, Aralık 2018'de SSPL lisanslı yazılımların arşivlerinde yer alamayacağını belirtmiş; Fedora ise Ocak 2019'da bu lisansın özgür olmadığına karar vermiştir. Bu kararın ardından Red Hat, MongoDB'yi Fedora ve Red Hat Enterprise Linux paketlerinden çıkarmıştır. Sizin için bu durum, dağıtımınızın daha önce bakımını üstlendiği bir paketin artık satıcı deposundan ve satıcının destek takvimine göre sunulması anlamına gelir. Business Source License da açık kaynak değil, kaynak kodu erişilebilir (source available) bir lisanstır; ancak her sürüm dört yıl içinde açık kaynak bir lisansa dönüşür.

Lisans değişikliği halihazırda çalıştırdığım sürüme uygulanır mı?

Hayır. Bir sürümle birlikte verilen lisans, halihazırda yayınlanmış kopyalardan geri alınamaz; çatallanmaların (fork) mümkün olmasının temel nedeni de budur. OpenSearch, Elastic'in Apache 2.0 altında yayınladığı son sürüm olan Elasticsearch 7.10.2 temel alınarak oluşturulmuştur. Kaybettiğiniz şey gelecektir, çünkü bir sonraki güvenlik yaması yeni koşullar altında gelecektir. İzin verici lisansa sahip son sürümü sabitlemek size birkaç ay kazandırır ancak bu sürdürülebilir bir plan değildir.