Richard Stallman ve Özgür Yazılım: Kodu Değiştiren Fikirler

Neden Richard Stallman hâlâ önemli?

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 yazı ne (ve ne değil)

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.

Dengeli, ulaşılabilir bir görüş

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” Gerçekte Ne Anlatır?

"Ö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.

Dört temel özgürlük

Özgür yazılım dört temel izinle tanımlanır:

• Freedom 0: Programı herhangi bir amaçla çalıştırma.
• Freedom 1: Programın nasıl çalıştığını inceleme ve istediğiniz gibi değiştirme.
• Freedom 2: Kopyaları yeniden dağıtarak başkalarına yardım etme.
• Freedom 3: Değiştirilmiş sürümlerinizi dağıtarak topluluğun bundan faydalanmasını sağlama.

Bu özgürlükler ajansla ilgilidir: sadece araç tüketicisi değilsiniz—doğrulayabilen, uyarlayabilen ve geliştirebilen bir katılımcı olabilirsiniz.

Kaynak kodu erişimi vazgeçilmezdir

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.

Basit bir benzetme: tarifler vs mühürlü yiyecek

Bir restoran yemeğini düşünün.

• Tescilli yazılım mühürlü, hazır bir tabak satın almak gibidir: yiyebilirsiniz ama içindekileri bilmezsiniz, tarifi değiştiremezsiniz ve kopya paylaşamazsınız.
• Özgür yazılım ise tarifi almak gibidir: evde yapabilir, nasıl yapıldığını öğrenebilir, alerjilere göre uyarlayabilir ve geliştirdiğiniz versiyonu arkadaşlarınızla paylaşabilirsiniz.

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.

Stallman’ın Tepki Verdiği Sorun

“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ı.

Paylaşım normlarından kilitli yazılıma doğru

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.

Yazıcı hikâyesi (örnek olarak)

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.

Neden yeni lisans fikirlerine yol açtı

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.

GNU Projesi: Özgür Bir İşletim Sistemi İnşa Etmek

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.

Tek bir araç değil, tam bir sistem

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:

• Derleyiciler (en meşhuru GCC) ki geliştiriciler kodu çalıştırılabilir programlara dönüştürebilsin
• Temel komut satırı araçları (dosya kopyalama, metin arama, süreç yönetimi gibi)
• Kütüphaneler ve geliştirici araçları daha fazla yazılım oluşturmayı desteklemek için
• Kabuklar ve editörler günlük çalışmayı yapmak için

Düz konuşmak gerekirse: GNU tesisatı, kabloları ve anahtarları inşa ediyordu—tek bir cihaz değil.

GNU + Linux: çoğu kişinin karşılaştığı biçim

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.

Altyapı idealler kadar önemliydi

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 Basitçe Anlatımıyla

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.

Telif hakkı üzerine kurulu bir yasal araç

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ı.

“Benzer şekilde paylaş” fikri (basit örneklerle)

Kodu izleyen bir kural gibi düşünün:

• Forklar: Bir copyleft projesini çatallarsınız, özellik eklersiniz ve çatallamayı yayımlarsınız. Kaynak kodunu yayınlamalı ve aynı lisansı korumalısınız ki başkaları da sizin çatallamanızdan faydalansın.
• Yeniden dağıtımlar: Programı müşterilere gönderdiğiniz bir ürüne dahil edersiniz. Para talep edebilirsiniz ama kaynağı ve aynı hakları alıcılara sağlamak zorundasınız.

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.

Copyleft vs izin verici lisanslar

İ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 GPL Lisansının Lisanslamayı Nasıl Değiştirdiği

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.

GPL ne verir—ve karşılığında ne ister

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:

• alıcılara kaynak kodunu sağlamak (veya elde etmenin geçerli bir yolunu sunmak)
• lisans metnini eklemek ve telif haklarını korumak
• değişikliklerinizi GPL altında lisanslamak, böylece sonraki kullanıcılar kısıtlanmasın

Kaynak dağıtım yükümlülükleri (ne zaman uygulanır)

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.

"Türev çalışma" basitçe

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.

GPL varyantları: v2, v3 ve LGPL

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.

Geliştirici Hakları—ve Özgür Lisanslardaki Sorumluluklar

Ö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.

Elde ettiğiniz haklar

GPL altında:

• Güvenle kurcalayabilirsiniz: kaynağı okuyup değiştirebilir ve değiştirilmiş versiyonunuzu çalıştırabilirsiniz.
• İşinizi paylaşabilirsiniz: orijinal veya değiştirilmiş programın kopyalarını dağıtabilirsiniz.
• Başkalarının iyileştirmeleri üzerine inşa edebilirsiniz: alıcılara aynı özgürlükler verildiği için.

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.

Üstlendiğiniz sorumluluklar

Bu haklar dağıttığınızda bazı yükümlülükleri beraberinde getirir:

• telif ve lisans bildirimlerini korumak
• gerekliyse karşılık gelen kaynak kodunu sağlamak veya teklif etmek
• lisansı olduğu gibi tutmak ki alıcılar haklarını bilsin

Bu sorumluluklar "tuzağa düşürme" değil—işbirliğinin tek taraflı sömürüye dönüşmesini engelleyen mekanizmadır.

Uygulamada uyumluluk notu

Ekipler lisans uyumluluğunu sürüm temizliği gibi ele almalıdır. Şu bilgileri takip edin:

• hangi açık kaynak bileşenlerini gönderdiğiniz,
• bunların sürümleri ve lisansları,
• kaynak nerede sağlanıyor (veya yazılı teklifler),
• yaptığınız değişiklikler.

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.

Özgür Yazılım vs Açık Kaynak: Değerler Ayrılığı

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.

Farklı öncelikler: özgürlük vs benimseme

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.

Neden “open source” yayıldı

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.

Aynı lisanslar, farklı anlatılar

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.

Basit bir karar rehberi

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.

İş Modelleri ve Gerçek Dünya Teşvikleri

Ö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.

Şirketler FOSS ile nasıl para kazanır

Yaygın, kanıtlanmış modeller:

• Destek ve hizmetler: ücretli destek hatları, SLA’lar, eğitim, denetimler, özel özellikler ve geçiş çalışmaları.
• Barındırma ve yönetilen teklifler: müşterilere kolaylık, ölçek, yedekleme ve uyumluluk için barındırılan sürümler satmak.
• Çift lisanslama: aynı yazılımı ücretsiz lisans (çoğunlukla copyleft) altında ve ayrıca farklı koşullar isteyen müşteriler için ücretli ticari lisansla sunmak.
• Open core (dikkatli): gerçekten ücretsiz bir çekirdek bırakıp üzerine tescilli eklentiler satmak. İşe yarayabilir ama “ücretsiz” kısmın kasıtlı sınırlı hissetmesi topluluk güvenini zorlayabilir.

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.

İzin verici vs copyleft stratejiyi nasıl etkiler

Lisans seçimi kimin değeri yakalayacağını şekillendirir:

• İzin verici lisanslar (MIT/Apache gibi) başkalarının, büyük satıcılar dahil, kodunuzu tescilli ürünlerde kullanmasını kolaylaştırır. Bu benimsemeyi artırabilir ama münhasıriyete dayalı para kazanma olasılığını azaltabilir.
• Copyleft lisanslar (GPL gibi) sonraki dağıtıcıların değişiklikleri aynı koşullar altında paylaşmasını gerektirir. Bu kapalı çatallanmayı caydırabilir ve hizmet, sertifikalı dağıtımlar veya çift lisanslama odaklı iş modellerini destekleyebilir.

“Ticari” ve “özgür yazılım” zıt değildir

“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.

Sürdürülebilirlik kontrol listesi

Bir FOSS projeye dayanmayı düşünmeden önce sorun:

• Aktif bir topluluk var mı (issue, sürümler, incelemeler)?
• Yönetişim açık mı (kararları kim nasıl alıyor)?
• Fonlama görünür mü (sponsorlar, şirket desteği, vakıf)?
• Bakım yükü sürdürülebilir mi (bus faktörü, tükenmişlik belirtileri)?
• Güvenlik uygulamaları belgelenmiş mi (yama hızı, duyurular)?

GPL ve FOSS Hakkında Yaygın Yanlış Anlamalar

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.

“GPL kamu malı demek”

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).

“Açık kaynak her zaman güvenlidir”

Kodun görünür olması güvenliğe yardımcı olabilir ama garanti etmez. Bir proje açık kaynak olup aynı zamanda:

• bakımsız olabilir,
• kötü incelenmiş olabilir,
• yıllarca açık kalmış zafiyetler barındırabilir.

Güvenlik aktif bakım, denetimler, sorumlu açıklama ve iyi işletme uygulamalarından gelir—lisans etiketinden değil.

“Viral lisans” iddiası

İ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.

“GPL kodunu uygulamamda kullanabilir miyim?” (yüksek düzey)

Kural olarak: yükümlülükler çoğunlukla dağıtımda tetiklenir.

• Dahili kullanım: şirket içinde GPL yazılımı kullanmak genelde değişiklikleri yayınlamayı gerektirmez.
• Uygulama/cihaz göndermek: bir GPL lisanslı programı (veya türevini) dağıtırsanız genelde kaynak ve bildirim sağlamak zorundasınız.
• SaaS / web servisleri: GPL yazılımını sunucunuzda çalıştırmak genelde kullanıcılara kaynak yayımlamayı zorunlu kılmaz. (AGPL bu boşluğu kapatmak için yaratıldı.)

Ö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.

Eleştiriler, Tartışmalar ve Süregelen Münazaralar

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.

Yönetişim ve “kararı kim veriyor?”

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:

• Liderlik nasıl seçilmeli veya değiştirilmelidir?
• Vakıflar üye odaklı mı, yönetim kurulu odaklı mı yoksa bakımcı odaklı mı olmalı?
• Bakımcı özgürlüğü ile katkıda bulunanların ihtiyaçları ne zaman çelişir?

Lisanzlar yasal koşulları koyar ama sağlıklı karar alma süreçleri kendi başına oluşmaz; bunlar da önemlidir.

Kapsayıcılık, davranış ve topluluk standartları

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.

Tartışmayı sağlam tutmak

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.

Pratik Çıkarımlar: Lisans Seçimi ve Katkı Yapma

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.

Basit bir karar ağacı

• Kodunuzun başkaları (rakipler dahil) tarafından minimum koşulla yeniden kullanılmasını mı istiyorsunuz? Bir izin verici lisans (ör. MIT, Apache-2.0) seçin.
• Kodunuzun iyileştirmelerinin yeniden dağıtıldığında paylaşılmasını istiyor musunuz? Güçlü copyleft (ör. GNU GPL) seçin.
• Paylaşımın esas olarak kütüphanenizin değişikliklerine uygulanmasını, tescilli uygulamaların linklenmesine izin vermek istiyor musunuz? Zayıf copyleft (ör. LGPL, MPL) seçin.

Ö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).

Yazılımı sorumlulukla dağıtmak için pratik adımlar

1. Her proje için bir lisans seçin ve README'de açıkça belirtin.
2. Repo köküne bir LICENSE dosyası ekleyin (tam lisans metnini kopyalayın).
3. Kuruluşunuzun istediği yerde telif başlıkları ekleyin.
4. Bağımlılıkları belgeleyin (doğrudan ve önemli transitif olanlar) ve lisanslarını kaydedin.
5. İkili dağıtıyorsanız, gerekli bildirimleri, kaynak tekliflerini (varsa) ve atıfları hazırlayın.

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.

Hafif bir iç uyumluluk rutini oluşturun

Sıkıcı ve tekrarlanabilir yapın:

• Derlemeler sırasında bir SBOM oluşturun.
• Bir notices dosyası şablonu bulundurun ve bağımlılıklar değiştikçe güncelleyin.
• PR/sürüm süreçlerine kısa bir lisans inceleme kontrolü ekleyin (10 dakikalık bir kontrol listesi bile çoğu sorunu önler).

Daha derin karşılaştırmalar için ilgili blog yazılarını ve lisans karşılaştırma kaynaklarını inceleyin.