Açık Kaynak Lisans Seçici
MIT, Apache 2.0, GPL, AGPL, BSD ve MPL lisanslarını yan yana karşılaştırın, ardından adınız ve yılınız işlenmiş LICENSE dosyasını üretin.
Lisans karşılaştırması
| Lisans | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | Patent kullanımı | Koşullar | Sınırlar |
|---|---|---|---|---|---|---|---|
| MIT License | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | 2 | 2 | |
| Apache License 2.0 | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | Patent kullanımı | 3 | 3 |
| GNU General Public License v3.0 | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | Patent kullanımı | 5 | 2 |
| GNU Affero General Public License v3.0 | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | Patent kullanımı | 6 | 2 |
| BSD 3-Clause License | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | 2 | 3 | |
| Mozilla Public License 2.0 | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | Patent kullanımı | 4 | 3 |
| The Unlicense | Ticari kullanım | Değiştirme | Dağıtma | Özel kullanım | 0 | 2 |
SPDX kimliği: MIT
Koşullar
- Telif bildirimini koru
- Lisans metnini ekle
Sınırlar
- Sorumluluk kabul edilmez
- Garanti verilmez
Özet (TL;DR)
- LICENSE dosyası olmayan bir repo açık kaynak değildir. Lisans yokluğunda varsayılan telif geçerlidir, yani her hak saklıdır.
- Apache 2.0'ın MIT'ye eklediği asıl şey açık patent lisansıdır; kurumsal hukuk birimleri çoğu zaman tam olarak bunu arar.
- AGPL'in GPL'den farkı tek bir maddedir: değiştirilmiş sürümü ağ üzerinden servis etmek de dağıtım sayılır.
- Lisans bir sürüme uygulanır. Yeni sürümü farklı lisansla yayınlayabilirsiniz ama daha önce yayınladığınız sürümü geri alamazsınız.
Lisanssız repo açık kaynak değildir
GitHub'da public bir repo, kodun serbestçe kullanılabileceği anlamına gelmiyor. Bern Sözleşmesi'ne taraf ülkelerde bir eser yaratıldığı anda telif hakkıyla korunuyor ve hiçbir izin verilmemişse varsayılan "her hak saklıdır". Yani LICENSE dosyası olmayan bir repoyu okuyabilirsiniz, fork edebilirsiniz (GitHub şartları buna izin veriyor), ama kendi projenizde kullanmanız için hukuki bir dayanağınız olmuyor.
Bu yüzden bir lisans seçmek bir kısıtlama değil, izin verme işlemi. Dosyayı koymadığınız sürece kimseye hiçbir şey vermemiş oluyorsunuz. Dikkatli bir şirket, lisanssız bir bağımlılığı kullanmayı reddediyor ve haklı olarak reddediyor.
Üç aile: izin veren, güçlü copyleft, zayıf copyleft
Lisansların arasındaki fark, kodunuzu alan kişinin ne yapmak zorunda olduğuyla ilgili. İzin veren (permissive) lisanslar neredeyse hiçbir şey istemiyor: telif bildirimini koru, gerisi serbest. Güçlü copyleft, türetilmiş eserin de aynı lisansla dağıtılmasını şart koşuyor. Zayıf copyleft ise ikisinin arasında duruyor ve kapsamı dosya seviyesinde tutuyor.
| Lisans | Aile | Kaynak açma şartı | Patent lisansı | Tipik kullanım |
|---|---|---|---|---|
| MIT | İzin veren | Yok | Açıkça yok | Kütüphaneler, en yaygın tercih |
| BSD 3-Clause | İzin veren | Yok | Açıkça yok | MIT ile aynı, ek olarak isim kullanım yasağı |
| Apache 2.0 | İzin veren | Yok | Var | Kurumsal projeler, patent riski olan alanlar |
| MPL 2.0 | Zayıf copyleft | Yalnızca değiştirilen MPL dosyaları | Var | Kapalı kodla birlikte kullanılacak bileşenler |
| GPL 3.0 | Güçlü copyleft | Türetilmiş eserin tamamı | Var | Masaüstü uygulamaları, araçlar |
| AGPL 3.0 | Güçlü copyleft | Ağ servisi de dahil | Var | Sunucu tarafı yazılım |
| Unlicense | Kamu malı ithafı | Yok | Açıkça yok | Atıf bile istemediğiniz küçük parçalar |
MPL 2.0'ın konumu sık yanlış anlaşılıyor: copyleft kapsamı dosya bazında olduğu için MPL lisanslı bir bileşeni kapalı kaynak bir ürünün içine koyabilirsiniz. Yükümlülüğünüz, yalnızca değiştirdiğiniz MPL dosyalarını MPL altında yayınlamak. GPL bunu yapmanıza izin vermiyor, çünkü kapsam bağlantılı eserin tamamına yayılıyor.
Apache 2.0 patent maddesi
MIT ile Apache 2.0 arasındaki fark günlük kullanımda görünmüyor, ikisi de aynı özgürlükleri veriyor. Fark hukuk masasında ortaya çıkıyor. Apache 2.0 katkı sağlayanların kendi patentleri için açık bir kullanım lisansı veriyor, üstelik bir misilleme maddesiyle birlikte: projeye karşı patent davası açan taraf kendi lisansını kaybediyor. MIT'de patent hakkında tek kelime yok, bu da hukukçuların "zımni lisans var mı" tartışmasına girmesi anlamına geliyor.
Pratik sonuç şu: büyük kurumların hukuk birimleri Apache 2.0'ı MIT'den daha rahat onaylıyor. Buna karşılık Apache 2.0 değişiklikleri belgelemenizi de istiyor ve NOTICE dosyası mekanizması getiriyor, yani MIT'den biraz daha fazla bakım işi çıkarıyor. Araç Apache 2.0 için tam metni değil, lisansın kendi Ek A bölümünde tarif ettiği bildirim bloğunu üretiyor; tam metin değiştirilmeden LICENSE dosyasına konmak zorunda olduğu için özetlenmesi geçersiz bir lisans dosyası üretirdi.
AGPL ve ağ kullanımı maddesi
GPL'in yükümlülüğü dağıtıma bağlı: kodu değiştirip birine verirseniz kaynağı da vermeniz gerekiyor. Yazılımı yalnızca kendi sunucunuzda çalıştırıp kullanıcılara HTTP üzerinden hizmet ediyorsanız dağıtım gerçekleşmiyor ve hiçbir yükümlülük doğmuyor. SaaS boşluğu denen şey bu.
AGPL 3.0 tam olarak bu boşluğu kapatıyor. Değiştirilmiş sürümü ağ üzerinden kullanıma sunmak da dağıtım sayılıyor ve kullanıcılara kaynak kodu sunma yükümlülüğü doğuyor. Bu yüzden kendi ürününü SaaS olarak satan şirketlerin çoğu AGPL lisanslı bağımlılıkları politika gereği yasaklıyor. Kendi projeniz için AGPL seçmek, birinin kodunuzu alıp kapalı bir servise dönüştürmesini engellemek istiyorsanız mantıklı; kütüphane yayınlıyorsanız benimsenme oranını ciddi biçimde düşürüyor.
Lisans değiştirmek ve çift lisanslama
Lisans bir sürüme uygulanıyor. v1.0'ı MIT ile yayınladıysanız v2.0'ı GPL ile yayınlayabilirsiniz, ama v1.0 herkes için MIT olmaya devam ediyor. Yayınlanmış bir sürümü geri çekemezsiniz; birileri onu zaten kopyalamış ve o kopya üzerindeki izinleri iptal edemiyorsunuz.
{ "name": "paketiniz", "license": "MIT", "//": "Çift lisans için SPDX ifadesi kullanılır:", "license_ornegi_1": "MIT OR Apache-2.0", "license_ornegi_2": "AGPL-3.0-or-later OR LicenseRef-Ticari"}Bir başka ayrıntı: lisansı değiştirmek için kodun tamamının telif hakkına sahip olmanız gerekiyor. Dışarıdan pull request kabul ettiyseniz o satırların telifi katkı sağlayana ait ve lisans değişikliği için her birinin onayı gerekiyor. Projelerin bir CLA (katkı sağlayan lisans sözleşmesi) istemesinin sebeplerinden biri de bu. Çift lisanslama, yani aynı kodu hem AGPL hem ticari lisansla sunmak, bu sahiplik toplandığı sürece mümkün.
Bilgi
Sıkça Sorulan Sorular
- Hangi lisansı seçmeliyim?
- Kararı iki soruya indirebilirsiniz. Birincisi: kodunuzu alanların değişikliklerini paylaşmasını şart koşmak istiyor musunuz? Hayırsa izin veren aile (MIT, BSD, Apache 2.0), evetse copyleft (GPL, AGPL). İkincisi: patent koruması sizin için önemli mi? Önemliyse MIT yerine Apache 2.0. En yaygın iki sonuç, küçük kütüphaneler için MIT ve kurumsal katkı bekleyen projeler için Apache 2.0 oluyor.
- Lisansı sonradan değiştirebilir miyim?
- İleriye dönük olarak evet, geriye dönük olarak hayır. Yeni sürümleri istediğiniz lisansla yayınlayabilirsiniz ama daha önce yayınlanmış sürümler için verdiğiniz izinler geçerli kalmaya devam eder. Ayrıca kodun tamamının telif hakkına sahip olmanız gerekir; dış katkılar varsa her katkı sağlayanın onayını almanız veya o kodu yeniden yazmanız gerekir.
- MIT ile Apache 2.0 arasındaki fark ne?
- Verdikleri özgürlükler pratikte aynı: ticari kullanım, değiştirme, dağıtma, özel kullanım. Apache 2.0 üç şey ekliyor. Açık bir patent lisansı ve buna bağlı misilleme maddesi, değişiklikleri belgeleme şartı, ve marka kullanımına dair açık bir sınırlama. MIT tek sayfa, Apache 2.0 birkaç sayfa. Küçük bir kütüphane için MIT yeterli, patent riski olan bir alanda veya kurumsal benimsenme hedefiyle Apache 2.0 daha güvenli.
- Özel bir repo için lisans gerekli mi?
- Hukuki olarak gerekli değil, çünkü lisans olmadığında zaten her hak sizde kalıyor. Yine de iki durumda faydalı: repo ileride public olacaksa dosyanın baştan doğru olması geçmişi temiz tutuyor, ve bir ekip içinde bile kimin ne hakla kullanabileceği yazılı olduğunda tartışma çıkmıyor. Şirket içi projelerde genelde LICENSE yerine kısa bir tescilli kullanım bildirimi konuyor.
- GPL lisanslı bir bağımlılık kullanırsam ne olur?
- Yalnızca kendi makinenizde çalıştırıyorsanız hiçbir yükümlülük doğmaz, GPL kullanmayı kısıtlamaz. Yükümlülük dağıtımda başlar: GPL bir kütüphaneyle bağlantılı (linked) bir uygulama dağıtıyorsanız, uygulamanın tamamını GPL uyumlu bir lisansla yayınlamanız beklenir. Bağlantının türü ve "türetilmiş eser" sınırı hukuken tartışmalı bir alan, bu yüzden ticari bir üründe GPL bağımlılık düşünüyorsanız önce hukuki görüş alın. LGPL veya MPL lisanslı alternatifler bu sorunu genellikle ortadan kaldırıyor.