Richard Stallman’ın özgür yazılım felsefesini, GNU projesini ve GPL’i keşfedin—ve bunların lisanslamayı, geliştirici haklarını ve açık kaynak ekosistemini nasıl yeniden şekillendirdiğini öğrenin.
Yazılım sadece teknik bir ürün değildir—aynı zamanda bir izinler kümesidir. Kim çalıştırabilir, kopyalayabilir, arkadaşına paylaşabilir, bir hatayı düzeltebilir ya da üzerine yeni bir şey inşa edebilir? Bu sorular koddansa lisanslamayla daha çok yanıtlanır. Yazılım iş, iletişim ve araştırmanın merkezine yerleştikçe “ne yapmaya izin verildiği” kuralları özellikler kadar yeniliği şekillendirmeye başladı.
Richard Stallman (çoğunlukla “RMS” olarak anılır) bu kuralları görünmez olmaktan çıkaran kişidir. 1980'lerin başında, daha fazla programın kaynak kodu olmadan dağıtıldığını ve kullanıcılara yazılımı sadece başkalarının koşullarında kullanabilecekleri söylendiğini gördü. Stallman bunu küçük bir rahatsızlık olarak değil, kullanıcı ve geliştirici özgürlüğünün kaybı olarak çerçevelendirdi ve bu özgürlükleri korumak için net ilkeler ve yasal araçlar önerdi.
Bu makale Stallman’ın fikirlerine ve bunların pratik sonuçlarına odaklanır: Free Software tanımı, GNU Projesi, copyleft ve GNU Genel Kamu Lisansı (GPL)—ve bunların modern açık kaynak ekosistemi ile yazılım lisanslama normlarını nasıl şekillendirdiği.
Burası bir biyografi değil ve çekirdek derlemeleri veya depo yönetimini teknik bir derinliğe indiren bir rehber de değil. Takip etmek için programlama geçmişine sahip olmanız gerekmiyor.
Stallman etkili olduğu kadar tartışmalıdır. Amaç burada olayları nesnel ve okunabilir tutmak: onun neyi savunduğu, hangi yasal mekanizmaların ortaya çıktığı, işletmelerin ve geliştiricilerin nasıl uyum sağladığı ve bugün hangi tartışmaların sürdüğü—böylece neden çalışmalarının günlük yazılım tercihlerini etkilemeye devam ettiğini görebilirsiniz.
"Özgür yazılım" yanlış anlaşılmaya açıktır çünkü özgür kelimesi fiyat etiketini çağrıştırır. Richard Stallman *özgür" derken özgürlükten—kullanıcının gücü ve yazılımı kontrol etme yetisinden—bahsetiyordu.
Bir program $0 olabilir ama onu incelemenize, değiştirmenize veya paylaşmanıza izin verilmiyorsa, "bedava bira" gibidir ama Stallman’ın önem verdiği anlamda özgür olmaz.
Özgür yazılım dört temel izinle tanımlanır:
Bu özgürlükler ajansla ilgilidir: sadece araç tüketicisi değilsiniz—doğrulayabilen, uyarlayabilen ve geliştirebilen bir katılımcı olabilirsiniz.
Freedom 1 ve 3 kaynak koduna erişim olmadan mümkün değildir—kaynak kodu insan tarafından okunabilir talimatlardır. Onun yokluğunda yazılım mühürlenmiş bir cihaz gibidir: kullanabilirsiniz ama ne yaptığını anlayamaz, bozulduğunda düzeltemez veya yeni ihtiyaçlara uyarlayamazsınız.
Kaynak kodu erişimi güven için de önemlidir. Bağımsız inceleme (gizlilik, güvenlik, adalet) yapılmasını sağlar ve orijinal geliştirici desteği sona erse bile yazılımın bakımının devam etmesini mümkün kılar.
Bir restoran yemeğini düşünün.
Temel fikir budur: özgür yazılım, kullanıcıların bilişim üzerinde kontrolünü sürdürebilmeleri için gerekli özgürlüklerle ilgilidir.
“Yazılım lisanslaması” yaygın bir tartışma konusu olmadan önce, pek çok programlama kültürü—özellikle üniversiteler ve araştırma laboratuvarlarında—şu varsayımla yürüyordu: bir aracı geliştirebiliyorsanız, geliştirmeyi paylaşırsınız. Kaynak kod yazılımla birlikte dolaşır, insanlar birbirlerinin çalışmalarını okuyarak öğrenir ve düzeltmeler gayri resmi işbirliğiyle yayılırdı.
Bu kültür yazılım bir ürün haline geldikçe değişmeye başladı. Şirketler (ve bazı kurumlar) kaynak kodu rekabet avantajı olarak görmeye başladı. Dağıtım “paylaşma yok” koşullarıyla geldi, kod programlarla birlikte gönderilmez oldu ve gizlilik sözleşmeleri normalleşti. Kolektif olarak problem çözmeye alışkın geliştiriciler için bu değişim yalnızca bir rahatsızlık değildi—topluluk temelli çözümlemeyi hukuken riskli hale getiren bir kural değişikliği gibiydi.
Tekrarlanan başlangıç hikâyelerinden biri MIT AI Lab’daki bir yazıcıyla ilgilidir. Stallman, yeni bir yazıcı geldiğinde yazılımın yalnızca ikili (binary) biçimde dağıtıldığını ve kaynak kodunun verilmediğini anlattı. Pratik sorun sıradan: laboratuvar programı kağıt sıkışmalarında kullanıcıları bildirecek veya işleri daha akıllıca yönetecek şekilde değiştirmek istedi. Eski "hacker" normlarında biri kodu yamalayıp düzeltmeyi paylaşırdı. Burada bunu yapamıyorlardı—çünkü kaynak kodunu görme veya değiştirme izni yoktu.
Bu tek bir yazıcının küresel bir hareket yaratmadığını dengede tutmak önemlidir. Ancak bu, insanların bağımlı oldukları araçların kullanıcıları tarafından düzeltilemez hale geldiği daha geniş bir eğilimin açık, ilişkilendirilebilir bir örneğiydi.
Stallman için temel sorun yalnızca teknik erişim değildi; işbirliği özgürlüğünün kaybıydı. Bir programın nasıl çalıştığını inceleyemezseniz, onu gerçekten kontrol edemezsiniz. İyileştirmeleri paylaşamazsanız topluluklar parçalanır ve herkes özel olarak düzeltmelerle uğraşır.
Bu motivasyon, sonrasında gelen lisanslama yeniliklerini şekillendirdi. Stallman, iyi niyete veya gayri resmi normlara bel bağlamak yerine, yazılımın ticari değere dönüşürken işbirliğinin geri çekilemeyeceği kuralları istiyordu.
Stallman’ın büyük hamlesi sadece bir manifestodan ibaret değildi—pratik bir mühendislik çabına başladı. 1983’te GNU Projesini duyurdu; iddiası şuydu: herkesin kullanabileceği, inceleyebileceği, değiştirebileceği ve paylaşabileceği tam bir işletim sistemi inşa etmek, aynı zamanda Unix ile uyumlu kalarak insanların tanıdık programları ve iş akışlarını çalıştırabilmesini sağlamak.
Bir işletim sistemi tek bir program değildir—bütün bir yığında birçok parça vardır. GNU, bir bilgisayarı kullanışlı kılmak için gereken günlük parçaların hepsini oluşturmayı hedefledi:
Düz konuşmak gerekirse: GNU tesisatı, kabloları ve anahtarları inşa ediyordu—tek bir cihaz değil.
1990'ların başına gelindiğinde, GNU bu “kullanıcı alanı”nın büyük bir kısmını üretmişti ama bir kritik parça eksikti: çekirdek (kernel). 1991’de Linux ortaya çıktığında bu boşluğu doldurdu.
İşte bu yüzden bugün popüler sistemlerin çoğu GNU bileşenleriyle birlikte Linux çekirdeğini kullanır—genellikle “GNU/Linux” olarak anılır.
GNU, özgür yazılım fikrini gerçek yaptı: özgürlüğün neden önemli olduğunu felsefe açıkladı; GNU ise özgürlüğü pratik, tekrarlanabilir ve ölçeklenebilir kılan araçları sundu.
Copyleft, yazılımı ilk sürümde olduğu gibi gelecekte de özgür tutmayı amaçlayan bir lisanslama stratejisidir. Copyleft ile dağıtılan kodu aldığınızda kullanabilir, inceleyebilir, değiştirebilir ve paylaşabilirsiniz—ancak değiştirilmiş sürümünüzü dağıttığınızda aynı özgürlükleri başkalarına da sağlamak zorundasınız.
Copyleft "anti-telif hakkı" gibi görünse de aslında telif hakkı yasasına dayanır. Yazar telif hakkını kullanarak izin kurallarını lisansla koyar: "Bunu kopyalayabilir ve değiştirebilirsiniz, ama yeniden dağıtırsanız aynı lisans altında tutmalısınız." Telif hakkı olmadan bu koşulların uygulanmasını sağlayacak yasal mekanizma olmazdı.
Kodu izleyen bir kural gibi düşünün:
Amaç Stallman’ın endişelendiği örüntüyü önlemekti: topluluk emeğini alıp iyileştirip sonra bu iyileştirmeleri kilitleyip başkalarından saklamak.
İzin verici lisanslar (MIT veya BSD gibi) kodla neredeyse her şeyi yapmanıza izin verir, hatta değişiklikleri kapalı, tescilli lisans altında yeniden dağıtma dahil. Copyleft lisanslar (ör. GNU GPL) geniş kullanım ve değiştirme özgürlüğü verir ama türevlerin yeniden dağıtımında aynı copyleft koşullarının korunmasını zorunlu kılar—böylece özgürlük aşağı doğru korunur.
GNU Genel Kamu Lisansı (GPL), paylaşımı sadece iyi niyet değil uygulanabilir bir kural haline getirerek yazılım lisanslamasını değiştirdi. GPL’ten önce, birinin size kaynak kod vermesi, onu geliştirip kapalı bir sürüm olarak göndermenize engel değildi. GPL bu dinamiği tersine çevirdi: yeniden dağıtıma koşullar ekleyerek kullanıcı özgürlüklerini korudu.
Pratik düzeyde GPL, kullanıcıya programı herhangi bir amaçla çalıştırma, kaynağı okuma ve değiştirme, orijinal veya değiştirilmiş sürümleri paylaşma hakkı verir.
Eğer GPL yazılımını yeniden dağıtırsanız, aynı özgürlükleri iletmeniz gerekir. Bu genelde şunları içerir:
GPL’in yükümlülükleri esas olarak yazılımı başkalarına dağıttığınızda devreye girer—ikili dosyaları göndermek, cihazlarda yazılım satmak veya müşterilere kopya vermek gibi. GPL kodunu özel dahili kullanım için değiştirirseniz ve dağıtmazsanız, genelde kaynağı yayınlamak zorunda değilsiniz.
Hukuk teorisine girmeden: programınız GPL kodunu öyle bir biçimde içeriyor veya bağlanıyorsa ki ortaya birleşik bir çalışma çıkıyorsa (örneğin uygulamanıza linklemek), sonuç genelde türev çalışma sayılır ve GPL altında dağıtılması gerekir. Sadece bir GPL programını çalıştırmak ya da standart arayüzlerle ayrı bir süreç olarak konuşmak çoğu zaman farklı değerlendirilir.
GPLv2 klasik, yaygın sürümdür. GPLv3 patent anlaşmaları ve "tivoization" gibi konulara karşı ek korumalar getirir. LGPL kütüphaneler için tasarlanmıştır: belirli şartlarla tescilli programlardan linklenmeye izin verirken kütüphanenin kendisini özgür tutar.
Özgür lisanslar (özellikle GNU GPL) sadece paylaşmaya izin vermez—kullanıcıların yazılımı inceleme, değiştirme ve yeniden dağıtma haklarını çekilmesi zor bir biçimde korur. Geliştiriciler için bu, iyileştirmelerinizin topluluk için erişilebilir kalabileceği anlamına gelir; kapalı bir üründe emilip topluluğun faydasından mahrum edilmez.
GPL altında:
Bu yüzden GPL sıklıkla “uygulanan karşılıklılık” olarak tanımlanır. Birisi GPL kapsamındaki bir programı veya türevi dağıttığında, aşağıya yeni kısıtlar ekleyemez.
Bu haklar dağıttığınızda bazı yükümlülükleri beraberinde getirir:
Bu sorumluluklar "tuzağa düşürme" değil—işbirliğinin tek taraflı sömürüye dönüşmesini engelleyen mekanizmadır.
Ekipler lisans uyumluluğunu sürüm temizliği gibi ele almalıdır. Şu bilgileri takip edin:
Basit bir Yazılım Bileşen Listesi (SBOM) ve sürümler için tekrarlanabilir bir kontrol listesi, çoğu sorunu hukuka gitmeden önce önler.
Kod düzeyinde “özgür yazılım” ve “açık kaynak” çoğu zaman aynı projeleri tanımlar. Ayrım esas olarak paylaşmanın neden önemli olduğuna ilişkindir.
Free Software hareketi (Richard Stallman ve Free Software Foundation ile ilişkilendirilen) yazılım özgürlüğünü etik bir mesele olarak görür: kullanıcıların yazılımı çalıştırma, inceleme, değiştirme ve paylaşma hakkı olmalıdır. Amaç sadece daha iyi mühendislik değil—kullanıcı özerkliğini korumaktır.
Açık Source yaklaşımı ise pratik sonuçları vurgular: daha iyi işbirliği, daha hızlı yineleme, daha az hata ve şeffaflıkla iyileşebilen güvenlik. Bu yaklaşım fikirleri işletmelere daha çekici sunmak için haklı olarak etiğe dayalı söylemi ön plana çıkarmadan benimser.
1998'de Open Source Initiative (OSI) “open source” terimini iş dünyası için daha uygun hale getirmek için popülerleştirdi. “Free software” sıkça "fiyatı sıfır" biçiminde yanlış anlaşılıyordu ve bazı şirketler haklar ve etik üzerine kurulu bir mesajdan çekiniyordu. “Open source” organizasyonların "bu şekilde çalışabiliriz" demesine izin verdi, ideolojik görünmeden.
Kendini açık kaynak olarak tanımlayan pek çok proje GNU GPL veya diğer copyleft lisanslarını kullanır; diğerleri MIT veya Apache gibi izin verici lisansları seçer. Yasal metin aynı olabilir; katkıda bulunanlara, kullanıcılara ve müşterilere söylenen hikâye farklıdır. Biri "bu özgürlükleri korur" der; diğeri "bu sürtünmeyi azaltır ve kaliteyi iyileştirir" der.
Eğer ekibinizin önceliği aşağıdaki kullanıcıların aynı özgürlükleri sürdürmesini garanti etmekse, free software çerçevesiyle ve copyleft ile ilerleyin.
Eğer önceliğiniz benimsemeyi maksimize etmekse (şirketlerin de rahat kullanabilmesi dahil), open source çerçevesi ve genellikle izin verici lisans daha uygun olabilir.
Geniş işbirliği ancak iyileştirmelerin geri akmasını istiyorsanız, erişilebilirlik için açık kaynak dilini kullanıp sonuç için copyleft lisansı seçebilirsiniz.
Özgür yazılım "kimse para kazanmaz" demek değildir. Kullanıcıların kodu çalıştırma, inceleme, değiştirme ve paylaşma özgürlüğüne sahip olması anlamına gelir. Birçok şirket bu özgürlük etrafında sağlıklı gelir modelleri kurar—genellikle kuruluşların gerçekten zorlandığı şeyler için ücret alır: güvenilirlik, hesap verebilirlik ve zaman.
Yaygın, kanıtlanmış modeller:
Güncel bir varyasyon: platformların hızlı uygulama üretip çalıştırdığı yönetilen hizmetlerin yükselmesi. Örneğin, Koder.ai sohbet üzerinden web, backend ve mobil uygulamalar oluşturup kaynak kodu dışa aktarmayı destekleyen bir vibe-coding platformudur. Bu kombinasyon (hızlı yineleme + kod sahipliği) yazılım özgürlüğünün arkasındaki değerlere doğal olarak uyar: yazılımı inceleme, değiştirme ve gerektiğinde taşıma yeteneği.
Lisans seçimi kimin değeri yakalayacağını şekillendirir:
“Ticari”, nasıl satıldığını; “özgür yazılım” ise kullanıcı haklarını tanımlar. Bir şirket özgür yazılımı satabilir, destek için ücret alabilir ve yazılım özgürlüğüne saygı gösterebilir.
Bir FOSS projeye dayanmayı düşünmeden önce sorun:
GPL ve “FOSS” sıkça tartışılır, ama birkaç tekrar eden yanlış anlaşılma ekiplerin sadece ürünü göndermek isterken lisansı yanlışlıkla ihlal etmelerini kolaylaştırır.
Değil. Kamu malı telif hakkı sahibi olmayan ve kimsenin koşul dayatmadığı eserlerdir—herkes herhangi bir şekilde kullanabilir.
GNU GPL bunun tam tersidir. Yazar telif hakkını korur ve geniş izin verir—ama GPL koşullarına uymanız şartıyla (en ünlüsü, kapsanan ikilileri dağıtırken kaynak paylaşma zorunluluğu).
Kodun görünür olması güvenliğe yardımcı olabilir ama garanti etmez. Bir proje açık kaynak olup aynı zamanda:
Güvenlik aktif bakım, denetimler, sorumlu açıklama ve iyi işletme uygulamalarından gelir—lisans etiketinden değil.
İnsanlar GPL’e “viral” derken her şeye bulaştığı anlamında kullanırlar. Bu yüklü bir metafordur.
Genelde kast edilen şey copylefttir: GPL kodunun türevini dağıtırsanız, karşılık gelen kaynakları GPL altında sağlamanız gerekir. Bu şart bilinçlidir: aşağı doğru kullanıcı özgürlüklerini korur. "Enfeksiyon" değil; kabul edebileceğiniz veya kaçınabileceğiniz bir koşuldur.
Kural olarak: yükümlülükler çoğunlukla dağıtımda tetiklenir.
Önemli olduğunda, kodun nasıl birleştirildiğine ve dağıtıldığına göre kesin bir değerlendirme yapın—varsayımlara değil.
Richard Stallman tartışmalı bir figürdür. Bunu kabul etmek mümkün—ve yine de onunla ilişkilendirilen fikirlerin ve lisansların kalıcı etkisini konuşmak da mümkündür.
İyi bir başlangıç iki konuşmayı ayırmaktır: (1) Stallman hakkında kişisel ve topluluk içi tartışmalar; (2) özgür yazılım ilkelerinin, GNU Projesi’nin ve GNU GPL’in yazılım lisanslaması ve geliştirici hakları üzerindeki ölçülebilir etkisi. İkincisi lisans metinleri, proje tarihleri ve benimsenme örüntüleri gibi birincil kaynaklarla tartışılabilir; kişiler hakkındaki görüşler farklı olsa bile bu nesnel olarak ele alınabilir.
Tekrarlayan eleştirilerden biri lisanslamayla ilgili değil, yönetişimle ilgilidir: projeler nasıl karar alır, yetki kimde olur ve kurucular, bakımcılar ve kullanıcılar farklı şeyler istediğinde ne olur? Özgür yazılım toplulukları şu sorularla boğuşmuştur:
Lisanzlar yasal koşulları koyar ama sağlıklı karar alma süreçleri kendi başına oluşmaz; bunlar da önemlidir.
Diğer tartışma başlığı kapsayıcılık ve topluluk normlarıdır: projeler nasıl saygılı davranışı bekler, anlaşmazlıkları nasıl ele alır ve yeni gelenlere ne kadar açık olur? Bazı topluluklar resmi davranış kuralları benimser; bazıları daha az kuralcı, daha gayri resmi moderasyon yöntemlerini tercih eder. Hiçbir yaklaşım otomatik olarak "doğru" değildir; her iki yanağın da artıları ve eksileri vardır.
Stallman’ın mirasını değerlendirirken iddiaları doğrulanabilir tutmak yardımcı olur: GPL’in ne gerektirdiği, copyleft’in uyumluluk uygulamalarını nasıl değiştirdiği ve bu fikirlerin sonraki lisanslar ile kurumlar üzerindeki etkileri. Eleştirel, destekleyici veya kararsız olabilirsiniz—ama nesnellik, saygı ve eleştirilenin ne olduğuna dair açıklık hedefleyin.
Stallman’ın en büyük pratik hediyesi basit bir soru sormaktır: Aşağıdakilere hangi özgürlükleri garanti etmek istiyorsunuz? Buna yanıt vermek lisans seçimini bir his değil, bilinçli bir karar haline getirir.
Önceliğinize göre karar verin: benimseme (izin verici) vs karşılıklılık (copyleft) vs kütüphane-dostu karşılıklılık (zayıf copyleft).
AI destekli geliştirme (sohbet tabanlı platformlar dahil) kullanıyorsanız, bu kontrol listesi daha da önem kazanır: gerçekten bağımlılıklar, gerçek artefaktlar ve gerçek lisans yükümlülükleri göndereceksiniz. Hız sorumluluğu ortadan kaldırmaz—tekrarlanabilir uyumluluk süreçleri daha kıymetli olur.
Sıkıcı ve tekrarlanabilir yapın:
Daha derin karşılaştırmalar için ilgili blog yazılarını ve lisans karşılaştırma kaynaklarını inceleyin.
"Free software" terimi fiyat değil, özgürlük anlamına gelir.
Bir program $0 olabilir ama eğer onu inceleyemiyor, değiştiremiyor veya paylaşamıyorsanız, Stallman’ın önem verdiği anlamda özgür değildir. Free software, dayandığınız yazılımı çalıştırma, inceleme, değiştirme ve yeniden dağıtma haklarına odaklanır.
Tanım dört izne dayanır:
Bunlardan herhangi biri eksikse, kullanıcılar denetimlerini kaybeder ve işbirliği zorlaşır.
Çünkü gerçekçi şekilde inceleyip veya değiştirebilmek kaynak kodu olmadan mümkün değil.
Kaynak kodu erişimi şunları sağlar:
Copyleft, yeniden dağıtımda “benzer şekilde paylaş” koşulu getiren bir yaklaşımdır.
Yazılımı kullanabilir, değiştirebilir ve satabilirsiniz; ancak yeniden dağıtırsanız, alıcılara aynı özgürlükleri vermek zorundasınız (genellikle değişikliklerin aynı lisans altında kaynakla birlikte verilmesiyle).
GPL geniş haklar verir (çalıştırma, inceleme, değiştirme, paylaşma) ve dağıtımda karşılıklılık ister.
Eğer GPL kapsamındaki ikilileri dağıtırsanız, genelde şunları yapmanız gerekir:
Çoğunlukla hayır.
GPL için yükümlülükler genelde dağıtım anında devreye girer. Değiştirdiğiniz GPL kodunu şirket içinde kullanıyorsanız ve dışarıya kopya vermiyorsanız, genelde değişikliklerinizi yayınlamak zorunda değilsiniz.
(Örnekler ve sınır durumlar olabilir—bu bir hukuk tavsiyesi değil, kural niteliğinde bir özet.)
Nasıl birleştirildiğine bağlıdır.
Genel olarak:
Dağıtıma gelince, entegrasyon desenini netleştirin.
Farklı ihtiyaçları hedefler:
Güçlü karşılıklılık istiyorsanız GPL, kütüphane-dostu karşılıklılık istiyorsanız LGPL tercih edilir.
Genellikle hayır.
Eğer GPL yazılımını sunucularınızda çalıştırıyor ve kullanıcılar sadece ağ üzerinden etkileşime giriyorsa, çoğunlukla kopya dağıtımı sayılmadığı için GPL kaynak paylaşma yükümlülüğü tetiklenmez.
Ağ üzerinden kullanımın da kaynak paylaşımını gerektirmesini istiyorsanız AGPL’ye bakmalısınız ve dağıtım modelinizi dikkatle değerlendirin.
Evet—birçok şirket, özgür/açık kaynak yazılımlar etrafında gelir elde eder; bunu kullanıcı haklarını kısıtlayarak değil, hizmet ve teslimatla yaparlar.
Yaygın modeller:
Lisans seçimi stratejiyi etkiler: permissive lisanslar benimsemeyi artırır; copyleft ise kapalı çatallanmayı caydırabilir ve hizmet tabanlı modelleri destekleyebilir.
