Açık Kaynak Lisansları: MIT, GPL ve Apache Pratikte Ne Değiştirir?

Açık kaynak lisansları, çoğu geliştiricinin okumadan geçtiği bir metin olarak görülür. Oysa bu metin, o kütüphaneyi ticari bir üründe kullanıp kullanamayacağınızı, kendi kodunuzu açmak zorunda kalıp kalmayacağınızı ve müşterinize hangi belgeleri vermeniz gerektiğini doğrudan belirler. Bu yazıda konuyu hukuki dilden çıkarıp, günlük geliştirme kararlarına etkileri üzerinden ele alıyoruz.

Not: Bu yazı genel bilgilendirme amaçlıdır ve hukuki tavsiye yerine geçmez; kritik ticari kararlarda hukuk danışmanınıza başvurun.

Önce en önemli kural: izinsiz kod kullanılamaz

Yaygın bir yanılgı, herkese açık bir depoda duran kodun serbestçe kullanılabileceğidir. Aslında tersi geçerlidir: telif hakkı varsayılan olarak yazarındır ve bu metin, size verilen izinlerin listesidir. İlgili dosya yoksa, kodu okuyabilirsiniz ama kullanma, değiştirme veya dağıtma izniniz yoktur. Bu yüzden bir bağımlılık eklemeden önce yapılacak ilk kontrol, bu dosyanın var olup olmadığıdır. Bir paketi değerlendirirken bakılması gereken diğer ölçütler için bağımlılık değerlendirme listemize bakabilirsiniz.

İzin vericiler: MIT ve Apache 2.0

MIT

En yaygın ve en kısa olanıdır. Pratikte size şunu söyler: kodu istediğiniz gibi kullanın, değiştirin, ticari üründe satın; tek şartınız telif bildirimini korumak. Kendi kodunuzu açmak zorunda değilsiniz. Bu basitlik, MIT'yi kütüphaneler için en popüler seçim yapar.

Apache 2.0

MIT'nin sağladığı özgürlüklerin hemen hepsini sağlar, ancak iki önemli ek getirir. Birincisi açık patent iznidir: katkıda bulunanlar, katkılarındaki patent haklarını kullanıcılara açar. Bu, kurumsal ortamlarda önemli bir güvence sayılır. İkincisi, patent davası açan bir kullanıcının bu hakkı kaybetmesini sağlayan bir karşılıklılık maddesidir. Bu yüzden büyük kurumlar bağımlılık seçerken Apache 2.0'ı MIT'ye tercih edebilir.

Copyleft tarafı: GPL ailesi

GPL

Buradaki temel fikir karşılıklılıktır: kodu kullanabilirsiniz, ancak ondan türeyen çalışmayı dağıtırsanız onu da aynı koşullarla açmanız gerekir. Kritik kelime "dağıtmak"tır. Kendi şirketinizin içinde kullandığınız ve dışarıya vermediğiniz bir yazılımda GPL kod bulunması, kodunuzu açma zorunluluğu doğurmaz.

Ancak masaüstü uygulaması, mobil uygulama veya müşteriye kurulan bir yazılım dağıtıyorsanız durum değişir. Bu yüzden ticari ürün geliştiren ekiplerin çoğu GPL kapsamındaki kütüphanelerden kaçınır — teknik kaliteleri yüzünden değil, ürün modeliyle uyuşmadıkları için.

LGPL

Kütüphaneler için tasarlanmış daha yumuşak bir türüdür: kütüphaneyi değiştirmeden bağlayan bir uygulama, kendi kodunu açmak zorunda değildir. Ancak kütüphanenin kendisinde yaptığınız değişiklikler açılmalıdır.

AGPL

Bulut çağının getirdiği ek maddeyle GPL'in en katı sürümüdür: yazılımı yalnızca dağıtmak değil, ağ üzerinden hizmet olarak sunmak da kaynak kodu paylaşma yükümlülüğü doğurur. Yani AGPL kapsamındaki bir bileşeni kullanan bir SaaS ürünü, ilgili kaynak kodunu kullanıcılarına açmak zorundadır. Birçok şirketin iç politikasında bu tür bağımlılıkların tamamen yasaklanmış olmasının sebebi budur.

Uyumluluk: koşullar birbirine karışır mı?

Pratikte en çok sorun çıkaran konu budur. Genel yön şudur: izin verici koşullardaki kod, copyleft bir projeye dahil edilebilir; tersi mümkün değildir. MIT koşullarındaki bir kütüphaneyi GPL bir projede kullanabilirsiniz, ancak GPL bir kütüphaneyi MIT olarak dağıtacağınız bir projede kullanamazsınız — bu durumda projenizin tamamı GPL yükümlülüğü altına girer.

Bu yüzden bağımlılık ağacınızı düzenli olarak taramak gerekir. Doğrudan eklediğiniz paket uygun olsa bile, onun bir alt bağımlılığı farklı koşullara sahip olabilir. Bu taramayı sürekli entegrasyon hattına eklemek, bu sürprizi birleştirme öncesinde yakalar; hattı kurmak için CI/CD yazımıza bakabilirsiniz.

Kendi projeniz için hangisini seçmeli?

Amacınıza göre değişir:

• Mümkün olduğunca çok kullanılmasını istiyorsanız (bir kütüphane, bir araç): MIT veya Apache 2.0. Kurumsal kullanıcı hedefliyorsanız patent maddesi nedeniyle Apache 2.0 daha güven verir.
• İyileştirmelerin topluluğa geri dönmesini istiyorsanız: GPL veya LGPL.
• Kodunuzun ticari bir bulut hizmetine dönüştürülmesini istemiyorsanız: AGPL. Bu tercih kullanıcı kitlenizi daraltır, bunu bilerek seçmeniz gerekir.

Hangisini seçerseniz seçin, deponuzun köküne bir LICENSE dosyası koymak ve README'de belirtmek şarttır. Projenizi katkıya açık hâle getiren diğer dosyalar için katkıyı kolaylaştıran dosyalar yazımıza, katkı sürecine ilk kez girenler için ise ilk adımlar rehberimize bakabilirsiniz. Karşılaştırmalı özetler için choosealicense.com pratik bir başvuru kaynağıdır.

Kurumsal ortamda uygulanabilir bir politika

Her geliştiricinin lisans metni okumasını beklemek gerçekçi değildir. İşleyen yaklaşım, üç kategorili basit bir politika oluşturmaktır: serbestçe kullanılabilecekler (MIT, Apache 2.0, BSD), onay gerektirenler (LGPL, MPL) ve yasaklı olanlar (ürün modelinize göre GPL/AGPL). Bu liste otomatik taramaya bağlandığında, karar geliştiricinin sezgisinden çıkıp sistematik hâle gelir.

Sonuç

Açık kaynak lisansları, hukuk departmanına havale edilecek bir formalite değil, ürün modelinizi doğrudan etkileyen mühendislik kısıtlarıdır. Pratikte bilmeniz gereken ayrım sanıldığından basittir: izin vericiler (MIT, Apache) size neredeyse tam serbestlik verir, copyleft olanlar (GPL, AGPL) ise türev çalışmanızı da açmanızı isteyebilir — ve AGPL bunu bulut hizmetlerine kadar genişletir. Bugün projenizde bağımlılıklarınızın dökümünü çıkarın; listede beklemediğiniz bir koşul görmek, çoğu ekip için ilk ve en faydalı sürpriz olur.