--- title: "Açık Kaynak Lisansları: MIT, GPL ve Apache Pratikte Ne Değiştirir?" url: "https://cilginyazilim.com/blog/acik-kaynak-lisanslari-mit-gpl-apache-farki" description: "MIT, Apache 2.0, GPL ve AGPL lisansları pratikte neyi değiştirir? Ticari kullanım, patent koruması, copyleft etkisi ve kendi projeniz için lisans seçimi." published: "2026-09-22T10:00:00+03:00" modified: "2026-09-22T10:00:02+03:00" author: "superadmin" category: "Kariyer ve Öğrenme" tags: ["proje yönetimi", "açık kaynak", "bağımlılık yönetimi", "açık kaynak lisansları", "mit lisansı", "gpl", "apache lisansı", "ticari kullanım", "copyleft", "patent", "uyumluluk", "hukuk", "yazılım dağıtımı"] site: "CılgınYazılım" language: "tr" --- # Açık Kaynak Lisansları: MIT, GPL ve Apache Pratikte Ne Değiştirir? Lisans metni hukuki bir detay değil, projenizin ticari kullanımını belirleyen bir mühendislik kararıdır. **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.* ![Açık kaynak lisans karşılaştırma tablosu](https://cilginyazilim.com/uploads/blog/2026/07/acik-kaynak-lisanslari-mit-gpl-apache-farki-ozet.png) *Kritik ayrım, türev çalışmanın da açılmak zorunda olup olmadığıdır.* ## Ö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](https://cilginyazilim.com/blog/acik-kaynak-bagimlilik-degerlendirme-kontrol-listesi) 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](https://cilginyazilim.com/blog/ci-cd-nedir-kucuk-ekipler-icin-otomatik-dagitim) 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](https://cilginyazilim.com/blog/acik-kaynak-projeye-katkiyi-kolaylastiran-dosyalar), katkı sürecine ilk kez girenler için ise [ilk adımlar rehberimize](https://cilginyazilim.com/blog/acik-kaynak-projeye-katki-vermek-ilk-adimlar) bakabilirsiniz. Karşılaştırmalı özetler için [choosealicense.com](https://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. ## Sıkça Sorulan Sorular ### Şirket içi kullanımda GPL kod sorun yaratır mı? Yazılımı dışarıya dağıtmıyorsanız GPL genellikle kaynak açma yükümlülüğü doğurmaz. Ancak AGPL için durum farklıdır: ağ üzerinden hizmet sunmak da yükümlülük doğurur. ### Bir kütüphaneyi değiştirirsem lisans değişir mi? Lisans değişmez; değiştirdiğiniz kod aynı lisansın koşullarına tabidir. Copyleft lisanslarda yaptığınız değişiklikleri de aynı lisansla paylaşmanız gerekebilir. ### İki farklı lisanslı kodu aynı projede kullanabilir miyim? Lisanslar uyumluysa evet. Genel kural, izin verici lisanslı kodun copyleft projelere dahil edilebildiği, tersinin ise mümkün olmadığıdır. Şüphe durumunda uyumluluk tablolarına bakmak gerekir. ### Seçimi sonradan değiştirebilir miyim? Yalnızca tüm telif hakkı sahiplerinin onayıyla. Dışarıdan katkı almış bir projede bu pratikte çok zordur; bu yüzden lisans kararını mümkün olduğunca erken vermek önemlidir. --- Kaynak: [Açık Kaynak Lisansları: MIT, GPL ve Apache Pratikte Ne Değiştirir?](https://cilginyazilim.com/blog/acik-kaynak-lisanslari-mit-gpl-apache-farki)