Lisans Uyumluluğu ve Yeniden Lisanslama

yazan Richard Stallman

Eğer iki özgür programı tek bir program olarak birleştirmek veya birinden diğerine kod aktarmak istiyorsanız, bu durum lisanslarının onları birleştirmeye izin verip vermediğini veya birleştirmeyi engelleyip engellemediği sorusunu ortaya çıkarır.[1]

Eğer birleştirilecek programlar aynı lisansa sahipse, eğer, neredeyse bütün özgür lisansların olduğu gibi, akla uygun davranan bir lisanssa bir sorun yoktur.[2]

Peki iki lisans birbirinden farklıysa? Genel olarak eğer farklı lisanslar altındaki kodu, tüm lisanslarla uyumlu olacak şekilde birleştirmenin bir yolu varsa, bu lisansların uyumlu olduğunu söylüyoruz. Sonuç, sıklıkla, parçaları çeşitli uyumlu lisansların altında olan bir programdır, ancak bu her zaman olmaz. Bu tür bir birleştirebilme veya birleştirememe, verili lisans kümesinin bir niteliğidir ve lisansları hangi sırada söylediğinize bağlı değildir. Lisans kümesi ayrıca birleştirilen program için hangi lisansın gerektiğini de düzenler.

Lisansları üç sınıfa ayırıyoruz: esnek (ayrıca “hoşgorülü” [permissive] veya “kolay lokma” [pushover]), ara ve copyleft. Gevşek bir lisansın kodu özel mülk bir yazılıma koymaya müdahale konusunda hiç bir şey yapmaz. Copyleft bir lisans, programlardaki yeniden kullanımların aynı lisansa sahip olmasını gerektirerek, bunun önüne geçer. Ara lisans özel mülk kod koymaya ilişkin bazı koşullar sunar ama bunun önüne geçmeye çalışmaz.

Genel olarak, esnek, hoşgörülü lisanslar (değiştirilmiş BSD, X11, Expat, Apache, Python, vb.) birbiriyle uyumludur. Çünkü programa koyulan kodla ilgili bir gereksinimleri yoktur. Hatta bütün programın (belki bazı değişikliklerle) bir özel mülk yazılım ürününe koyulmasına da izin verirler; bu nedenle onları “kolay lokma lisanslar” olarak adlandırıyoruz, çünkü bir kullanıcı diğerlerinin özgürlüğünü engellemeye çalıştığında “hayır” diyemiyorlar.

Esnek lisanslar altındaki programların birleşiminde, her bir kısım ilk baştaki lisanslarının altında kalır. Kod, parçaların birbirinden artık ayırt edilemeyecek şekilde birleştiğinde, bu birleştirilmiş kısım, oluşturulması için birleştirilen tüm parçaların lisansının kapsamına girmelidir. Zaten tüm bu lisanslar esnek olduğu için, bu durum, lisansların oldukça uzaması dışında herhangi bir pratik sorun yaratmaz.[3]

Aynı nedenlerle, esnek lisanslar genellikle herhangi bir copyleft lisansla da uyumludur. Birleştirilmiş programda, esnek lisanslar altında gelen kısımlar yine aynı lisansların altında kalırken, birleştirilmiş program bir bütün olarak copyleft lisansını taşır. Bir esnek lisans olan Apache 2.0, patent şartlarına sahip, bu da GPL sürüm 2 ile uyumsuzdur; bu patent şartlarının iyi olduğunu düşündüğüm için, GPL sürüm 3'ü onlarla uyumlu yaptım.

Önemli bir istisna, “rahatsız edici tanıtım şartı” nedeniyle özgün BSD lisansıdır. Bu koşul, özgün BSD lisansı altında yayınlanan herhangi bir kodu içeren herhangi bir ürünün tüm tanıtımını gerektiriyordu. Bu, tüm fiili copleft lisansların hepsiyle uyumsuzdu ve hala uyumsuz. Ayrıca her dağıtım için tam bir karın ağrısıydı, çünkü programlar benzer ama farklı tanıtım gereksinimleri biriktiriyordu. Bir noktada BSD dağıtımı 70 farklı bildirim gerektiriyordu.

Bu sorunu bir dekanı, Hal Varian'ı Berkeley Üniversitesi'ni “değiştirilmiş BSD lisansı” (tanıtım şartı olmadan) yayınlamasını ve Berkeley Sistem Dağıtımı kodlarını bu yeni lisans altında yeniden dağıtmasını ve yayınlamasını sağlaması için ikna ederek büyük oranda ortadan kaldırdım. Bugünlerde özgün BSD lisansı (neyse ki) çok nadir kullanılıyor, ancak “BSD lisansı” hakkında konuşmama konusunda özen göstermeliyiz.

Genel olarak, iki farklı copyleft lisansı, açıkça uyumluluk hükümleri yoksa kaçınılmaz olarak uyumsuzdurlar. Bu ayrıntılardaki bir hatanın sonucu değildir; copyleft fikrinin doğası gereğidir. Copyleft fikri “değiştirilmiş ve genişletilmiş sürümler aynı lisans altında olmalıdır” şeklindedir. Eğer (P programını kapsayan) A lisansı genişletilmiş programlar A lisansı altında olmalıdır diyorsa ve (Q programını kapsayan) B lisansı genişletilmiş programlar B lisansı altında olmalıdır diyorsa, şiddetli bir uzlaşmazlıkları var demektir; hem P'den hem de Q'dan kod içeren birleştirilmiş programın lisansı hem A olmalıdır hem de B olmalıdır.

Bu nedenle GPL sürüm 2, GPL sürüm 3 ile uyumsuzdur; bu kaçınılmazdır. Aynı şekilde CC-BY-SA 4.0'ın koşulları da CC-BY-SA 3.0'ın koşullarıyla doğası gereği uyumsuz olacaktır, yazarları bundan kaçınamazlardı.

Farklı copyleft lisanslarından kaynaklanan uyumsuzluk sorunundan kaçınmak için iki yaklaşım var.

FSF, insanlardan programları “GNU GPL sürüm N veya sonraki bir sürüm” altında yayınlamalarını isteme yaklaşımını kullanıyor. Bu lisanslama sürüm N ve ayrıca sürüm N+1 ile de uyumludur (çünkü lisans N+1'i bir seçenek olarak sunuyor). “GPL 3 veya sonraki” altındaki bir kodla, “GPL 2 veya sonraki” altındaki bir kodu birleştirdiğinizde, birleşimin lisansı kesişimleri olur, bu da “GPL 3 veya sonraki” lisansıdır.

Umuyoruz ki hiç bir zaman bir GNU GPL sürüm 4 yapmamız gerekmez, ama hiç bir şey mükemmel değildir ve tüm sorunları öngördüğümüzü varsayamayız. Kodunuzu GNU GPL 3 veya sonrası altında yayınladığınızda, kodunuzun, ileride ihtiyacımız olur da çıkarırsak, GNU GPL sürüm 4'e yükseltilmesine izin vermiş oluyorsunuz.

Diğer yaklaşım lisansın her bir sürümün sonraki sürümlere yükseltilmesine açıkça izin verecek şekilde tanımlanmasıdır. Mozilla Vakfı da, PHP de bu yaklaşımı kullanır. Creative Commons, CC-BY-SA lisansı için bunu kullanır: sürüm 4.0 (mevcut sürüm) herhangi bir kullanıcıya değiştirilmiş çalışmalar için CC-BY-SA'nın sonraki sürümlerine yükseltmesine açıkça izin verir.

Sadece GNU lisansları yazarlara gelecekteki lisans sürümlerine izin verip vermeme seçeneğini veriyor. 1989 yılında GNU GPL'nin ilk sürümünü yazdığımda, CC lisanslarında şu an mevcut olan lisans yükseltme seçeneğini koymayı değerlendirdim, ancak bu kararı her bir yazara bırakmanın daha doğru olduğunu düşündüm. Böylece, bir yazar bir programı ister “sadece GPL 1” [GPL 1 only] isterse de “GPL 1 veya sonrası” [GPL 1 or later] altında yayınlayabilir.

O zamandan beri, bu kararın bilgeliğini sorgulamaya vardım. Sadece tek bir GNU GPL sürümüne izin veren ve lisans yükseltmesini reddeden Linux gibi programlar pratik uyumsuzluklar ortaya çıkarıyorlar.[4] Eğer bir GPL sürüm 4 yaparsak, belki de otomatik olarak 5 ve yukarısı gibi daha büyük sürümlere yeniden lisanslamaya izin veren bir yükseltme koşulu eklemeliyiz.

Bazı copyleft lisansları, kodu farklı bir copyleft lisansı altına koymaya izin veren belirgin bir yeniden lisanslama şartıyla çapraz copyleft birleşimlerine izin veriyor. Örneğin, CeCILL, kodu GNU GPL sürüm 2 veya sonraki sürümlerde yeniden lisanslamaya açıkça izin veriyor. Eğer CeCILL altındaki P programı varsa ve onu GPL sürüm 3 veya sonraki altındaki Q programıyla birleştirmek istiyorsanız, CeCILL bunu yapabileceğinizi ve birleşimi veya eklenmiş kodu GPL sürüm 3 veya sonrası altına koyabileceğinizi söylüyor.

Açık yeniden lisanslama izni, uyumluluk ile aynı şey değildir (yine de kodun yeniden lisanslanması onu diğer kodlarla uyumlu yapabilir) ve simetrik değildir. Örneğin, CeCILL kodun GNU GPL altında yeniden lisanslanmasına izin verirken, GNU GPL CeCILL altında yeniden lisanslanmaya izin vermez. Bu yüzden, bu iki P ve Q programlarını birleştirip, bu birleştirimi CeCILL altında dağıtamazsınız, çünkü bu Q programında kullanılan GPL'i ihlal eder. Bu birleştirilmiş programı yayınlamanın tek izin verilen yolu, onu uygun GPL sürüm(leri) altında yayınlamaktır.

Aynı şekilde, CC BY-SA 4.0 açık bir şekilde değiştirilmiş sürümlerin GNU GPL sürüm 3 altında yeniden lisanslanmasına izin verir, ancak GPL sürüm 3 CC BY-SA altında yeniden lisanslanmaya izin vermez. Yazılım kodu için bunun bir sorun oluşturmaması gerekir; Creative Commons lisanslarının kod için olmadığını söyler ve kod için kullanılması gereken lisansın GNU GPL olduğunu söyler. Ancak, CC BY-SA altında yayınlanan malzemeyle, GNU GPL altında yayınlanan malzemeyi birleştirmeniz gereken durumlara yol açan donanım tasarımları veya oyun sanat eserleri gibi başka tür çalışmalar da var. Bu birleştirme CC BY-SA'nın açık yeniden lisanslama izniyle yapılabilir.

Maalesef, CC BY-SA 4.0 gelecekteki GPL sürümlerine yeniden lisanslamaya izin vermiyor. Yapmanız gereken, CC-BY-SA 4.0 altındaki malzemenizi GPL altında yeniden lisanslarken, gelecekteki GPL sürümlerinin bu malzeme için geçerli olup olmadığını belirtmek için kendinizi bir lisans sürüm vekili olarak tanımlamanızdır. Eğer bir gün bir GPL sürüm 4 olursa ve Creative Commons, CC BY-SA'dan GPL sürüm 4'e yeniden lisanslamaya izin vermeye karar verirse, vekil olarak siz bu yeniden lisanslanmış malzemenin GPL sürüm 4'te kullanılmasına geçmişe dönük olarak yetki verebileceksiniz. (Alternatif olarak, bu malzemenin yazarlarından bu izni hemen vermelerini isteyebilirsiniz.)

Normal GNU Genel Kamu Lisansı ve GNU Affero Genel Kamu Lisansı iki farklı copyleft lisansıdır, bu yüzden doğal olarak uyumsuzdur. Aralarında özel türde bir açık uyumluluk oluşturduk: GNU GPL sürüm 3 altındaki kodu, diğer kaynak kodla birlikte GNU Affero GPL altında tek bir birleşmiş program olarak içerebilirsiniz. Buna izin verilmesinin nedeni bu lisanslarda bunun açıkça söylenmiş olmasıdır ve bunun etkisi GNU AGPL'nin birleştirilmiş programa uygulanabilmesidir. Ancak, GNU GPL (“veya sonrası” olsun olmasın) altındaki kodu basitçe GNU Affero GPL altında yeniden lisanslama veya tersini yapamazsınız; bu lisansların hiç biri buna izin vermiyor. Ayrıca unutmayın ki GNU Affero GPL sürüm 3, normal GNU GPL sürüm 2'nin “sonraki sürümü” değildir, çünkü GNU Affero GPL ve GNU GPL iki farklı lisans dizisidir.

GNU Kısıtlı Genel Kamu Lisansı sürüm 3 gerçekten de GNU Genel Kamu Lisansı sürüm 3 ve ek bazı izinlerdir. GPL sürüm 3 (7. bölüm) her zaman eklenmiş olan izinleri kaldırabileceğinizi söyler ve bunu yaparak aynı kodu normal GNU GPL sürüm 3 altında edinmiş olursunuz. Eğer program GNU LGPL sürüm 3 veya sonrası altında kullanıma izin veriyorsa, onu GPL sürüm 3 veya sonrası altında yeniden lisanslayabilirsiniz; gelecekte her bir GPL sürüm N (N > 3) için, GPL sürüm N artı ek izinlerden oluşan bir LGPL sürüm N yapacağız.

GNU Kısıtlı GPL sürüm 2.1 de, GNU GPL sürüm 2 veya sonrasına yeniden lisanslamaya açıkça izin veriyor.

Ara lisanslar, yeniden dağıtım için önemli gereksinimleri olan ama copyleft olmayan lisanslardır. Örnekler arasında Eclipse Kamu Lisansı ve Mozilla Kamu Lisansı sayılabilir. Ara lisanslar herhangi bir copyleft lisansla uyumsuz olma eğilimi gösterir, çünkü gereksinimleri birleştirilmiş programın copyleft lisansı altında olmasına izin vermez. Mozilla Kamu Lisansı, kod açıkça bu izni reddetmediği sürece, GNU GPL altında yeniden lisanslamaya izin veriyor.

Son olarak, ikili lisanslama nedir?[5] İkili lisans bir ayrışımdır: aynı programın iki veya daha fazla lisans seçeneği taşıdığı anlamına gelir. Örneğin, Perl'in eski sürümleri ikili lisansa sahipti: Sanatsal Lisans ile GNU Genel Kamu Lisansı'nın ayrışımı. Bu, her bir kullanıcının Perl'i ya o ya da öbür lisans altında veya Perl dağıtımının kendisi gibi bu iki lisansın ayrışımı altında yayınlayabileceği anlamına geliyor. Bir ayrışım, bu ayrışımdaki lisans seçeneklerinden biri bir küme ile uyumlu ise, ayrışımın kendisi de bu diğer lisans kümesiyle uyumludur.

Kodunuz için bir lisans seçecekseniz, lütfen GNU GPL sürüm 3 veya sonrasını veya bununla uyumlu bir lisans seçin. Bu şekilde kodunuzu neredeyse bütün özgür yazılım külliyatıyla birleştirilebilir kılarsınız. GPL veya AGPL sürüm 3 veya sonrasını seçmeniz ayrıca kodunuzun bütün sürümlerinin tüm kullanıcılarının özgürlüğünü savunmak için elden gelenin en iyisinin yapılmasını sağlayacaktır.

Kod birleştirme

Bir küme lisans birbiriyle uyumluysa, her biri bu lisanslardan biri altında olan birtakım programı yasal olarak birleştirebilir veya toplayabilirsiniz demektir. Peki böyle bir durumda birleştirilen program nasıl lisanslanmaktadır?

Her bir özgür yazılım lisansı, lisansı o lisans altındaki kodla birlikte tutmanız gerektiğini söyler. Bu yüzden, tam anlamıyla birleşmiş programın lisanslanması, tüm parçaların bütün lisanslarını içerecektir. Ancak, bazı durumlarda birleşmiş programın nasıl lisanslandığı sorusuna bir özet yanıt isterseniz. Birleşmiş programı kullanan birisi hangi lisanslara dikkat etmelidir?

Bunu hesaplamak için geçerli tüm lisansların bir listesiyle başlamalısınız. Daha sonra bu listeden başka lisans tarafından kapsanan [subsume] herhangi bir lisansı silebilirsiniz.

A lisansıyla uyum, B lisansıyla uyuma işaret ettiğinde A lisansı B lisansını kapsar diyoruz.

Örneğin, GNU GPL sürüm N ve GNU Affero GPL sürüm N'nin her ikisi de GNU Kısıtlı GPL sürüm N'yi kapsar ve bunların üçü de GNU Kısıtlı sürüm 2.1'i kapsar.

Herhangi bir GNU lisansı sürüm N, N'nin en az 3 olması koşuluyla Apache 2.0 lisansını kapsar.

GNU GPL sürüm N, kendisiyle uyumlu olan bütün Mozilla Kamu Lisansı sürümlerinin tümünü kapsar.

Apache 2.0 lisansı BSD, Expat, X11, ISC ve CC0 lisanslarını kapsar. 3 şartlı BSD lisansı BSD 2 lisansını kapsar. BSD lisansları Expat, X11 ve ISC lisansları ve CC0'ı kapsar.

Bu tam bir liste değildir, ancak eğer değinmenin yararlı olduğu düşünülen örnekler varsa, onları da ekleyeceğiz.

Bazı lisanslar kapsandığında, tüm birleştirilmiş program dağıtımlarıyla birlikte bir kopyasını içermeniz gerekmektedir.

Dipnotlar

1. Programların belirli bir birleşiminden, birleştirilen programların telif hakkı lisanslarıyla ilişkili olmayan sorunlar, başka yasal sorunların ortaya çıkabileceği akla sığmaz değildir. Biz yalnızca lisansların kendilerinden kaynaklanan sonuçları tartışıyoruz.

2. Fiili olarak kullanılan ve akla uygun şekilde davranmayan başlıca lisans TeX'in lisansıdır: eğer iki program tam da TeX gibi lisanslıysa, birleştirilmiş sürümlerini dağıtmanın yetki verilmiş bir yolu yoktur.

   TeX lisansı, değiştirilmiş bir sürümün dağıtımına sadece özgün sürümle birlikte farklılıklar dosyası biçiminde izin veriyor. Eğer A ve B ayrı olarak bu şekilde yayınlandıysa, sonra da birleştirildilerse, birleştirilen programı A ve değişiklikler dosyası olarak dağıtmak B'nin lisansını ihlal edecek. Bunu B ve değişiklikler dosyası olarak dağıtmak da A'nın lisansını ihlal edecek. Bunu başka bir şekilde dağıtmaksa her ikisinin lisansını ihlal edecek.

   TeX'in 1982'de yayınlanması bir tesadüf değil: topluluğumuz o günden beri akla uygun davranan lisanslar yazmayı öğrendi.

3. Kaynak dosyası biçiminde dağıtırken, genellikle lisans bildirimlerini bulundukları haliyle kaynak kodu içerisinde bırakmak yeterlidir; ek lisans bildirim gereksinimleri esnek lisanslarda kaynak kod olmadan sadece ikili dosyalar dağıtılıyorsa ortaya çıkıyor.

4. Ek olarak, GPL sürüm 2 hala ikili dosyaların, özel imzalanmış ikililer dışındaki her şeyi geri çeviren donanımlar tarafından özgür olmamasına izin verirken, ikili dosyaların torrent aracılığıyla dağıtımına izin vermiyor. Sürüm 2'yi değiştiremeyiz ama bu ve başka sorunları sürüm 3'te düzelttik.

5. Bazıları satış istisnaları için “ikili lisanslama” [dual licensing] terimini kullanıyor, ancak bu yanlış bir adlandırmadır. Satış istisnaları yazısına bakın. Unutmayın ki, eğer bir programın satıldığı lisans özgür olmayan herhangi bir kod içeriyorsa, bu satış istisnası değil, özgür olmayan yazılımdır.