PHP için lisansın BSD 3-Clause olarak değiştirilmesi öneriliyor

 (wiki.php.net)
1 puan yazan GN⁺ 2025-07-16 | 1 yorum | WhatsApp'ta paylaş
  • PHP projesi, mevcut karmaşık ve birbiriyle uyumsuz PHP’ye özgü lisans ile Zend Engine lisansını BSD 3-Clause (Modified BSD License) altında birleştirmeyi amaçlayan bir RFC’yi tartışıyor
  • Yeni lisansın uygulanacağı sürüm PHP 9.0 olacak; kaynak kodu, başlıklar ve belgelerin genelinde BSD 3-Clause yansıtılacak, geçmişteki özel maddeler ve marka ile ilgili kısıtlamalar kaldırılacak
  • OSI ve FSF onayı, GPL uyumluluğu gibi hukuki netlik sağlanacak ve katkıda bulunanlarla kullanıcıların hakları mevcut haliyle korunacak
  • Lisans değişikliği için PHP Group ve Perforce Software (eski Zend) tarafından resmi onay gerekiyor; topluluk tartışmasının ardından 6 aydan uzun bir görüşme ve oylama süreci yürütülecek
  • Bu değişiklik, PECL/uzantılar gibi harici projelere de BSD 3-Clause seçimini tavsiye ediyor ve “PHP License” kullanımını önermiyor

Genel Bakış

  • PHP projesinde, uzun süredir kendi açık kaynak lisansı ile Zend Engine License nedeniyle karışıklık ve tartışmalar yaşanıyordu
  • Özellikle Zend dizinindeki kaynaklara uygulanan Zend Engine License, OSI onaylı bir lisans olmadığı için karmaşıklığı artırıyordu
  • Bu RFC, tüm PHP katkıcılarının telif haklarını korurken kullanıcılara mevcut lisanslarla aynı hakları veren pratik bir lisans sadeleştirmesi öneriyor
  • Amaç, BSD 3-Clause (Modified BSD License) lisansını yeni resmi lisans olarak benimseyip, hakları ve kullanım koşullarını korurken karmaşıklığı ve yanlış anlaşılmaları azaltmak

Öneri ve Başlıca Değişiklikler

  • Önerinin özü, PHP License ve Zend Engine License’ın yeni sürümlerini yayımlayarak Modified BSD License’ı (BSD-3-Clause, hem OSI hem FSF tarafından onaylı) resmi olarak benimsemek
  • Mevcut PHP License (version 3.01) ve Zend Engine License (version 2.00), özel maddeler dışında Modified BSD ile fiilen aynı; dolayısıyla yetkilerde özsel bir değişiklik yok
  • Lisans güncellemesinden sonra:
    • Katkıda bulunanlara ve kullanıcılara verilen haklarda değişiklik olmayacak
    • PHP Group ve Perforce Software ile iş birliği içinde belirli gruplara özgü maddeler kaldırılacak
    • PHP ve Zend Engine, OSI onaylı ve GPL uyumlu lisanslar altında sunulacak
  • Eski PHP License ve Zend Engine License kullanımı artık önerilmiyor
  • LICENSE ve kaynak içindeki lisans başlıkları da yeni formatla değiştirilecek

Lisans Metninin Özeti

  • BSD 3-Clause; özgürce kopyalama, değiştirme ve dağıtıma izin verir, ancak telif hakkı ve feragat hükümleri ile isimlerin/markaların izinsiz kullanımını yasaklayan koşullar içerir
  • BSD-3-Clause, OSI (Open Source Initiative) ve FSF tarafından onaylanmış özgür yazılım lisansıdır ve GPL ile uyumludur

Değişiklik Süreci ve Onay

  • RFC, toplulukta açık tartışmanın ardından oylamayla kesinleşecek; resmi onay ve oylama sonrasında uygulama başlayacak
  • Lisans değişikliği için PHP Group ve Perforce Software’in resmi onayı gerekiyor
  • Geçmiş kaynak kodu katkıcılarının hakları aynen korunacak ve değişiklik mevcut hakları ihlal etmeyecek
  • Topluluğa 6 aydan uzun bir tartışma süresi verildikten sonra oylamayla karara bağlanacak
  • Değişikliğin PHP 9.0’da resmi olarak yansıtılması planlanıyor

Arka Plan ve Tarihsel Bağlam

  • İlk dönemlerde PHP 1 ve 2 GPL altındaydı; ardından Apache lisansı ve özel BSD tabanlı lisanslardan geçerek gelişti
  • Zend Engine ayrı bir lisansı sürdürse de artık fiilen ayrılamayan tek bir projenin parçası olarak görülüyor
  • Mevcut PHP lisansındaki ad kullanım kısıtları ve marka koruma maddeleri, diğer açık kaynaklarla uyumluluk ve dağıtım açısından uzun süredir sorun yaratıyordu

Mevcut Kod, Uzantılar ve Belgeler Üzerindeki Etki

  • Bu RFC, php-src’nin tamamına (ayrı lisans belirtilmiş kodlar hariç) uygulanıyor; PECL/uzantılar gibi projelere de BSD 3-Clause benimsemeleri tavsiye ediliyor
  • Yeni/mevcut PHP kaynak deposundaki PHP License veya Zend Engine License uygulanan tüm kodları etkileyecek
  • Mevcut lisanslı kodlar (ör. timelib gibi ayrı lisanslı kodlar) bu değişikliğin kapsamına girmiyor
  • PHP manueli Creative Commons Attribution 3.0 veya üzeri lisansını korumaya devam edecek
  • Mevcut uzantı modüllerine/yazılımlara PHP License v4 (Modified BSD) uygulama seçeneği verilecek
  • Gelecekte uzantılar ve yeni projelerde güncel BSD/Apache gibi tanınmış lisansların kullanılması tavsiye edilecek

Sonuç

  • PHP ve Zend Engine’in lisans yapısının 3-clause BSD ile sadeleştirilmesi, açık kaynak ekosisteminde netlik, uyumluluk, ticari kullanım ve hukuki istikrarı güçlendirebilir
  • Öneri onaylanıp uygulanırsa, kullanıcılar PHP ve Zend Engine’i BSD-3-Clause temelinde özgürce kullanabilecek
  • Projedeki katkıcılar, topluluk ve başlıca şirketlerin onayı ile oylama süreci tamamlandıktan sonra resmi olarak yürürlüğe girmesi planlanıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-16
Hacker News görüşleri
  • Meta'nın kullandığı dilin PHP değil Hack olduğu belirtiliyor; ancak Hack'in paketleme, dokümantasyon ve erişilebilirlik açısından zayıf olduğu söyleniyor. Bunun nedeni olarak da bunların Meta içinde görünür işler olmaması, dolayısıyla performans değerlendirmelerine yansımaması gösteriliyor. Ayrıca kurum içi bilginin saklanmasının iş güvencesiyle bağlantılı olduğuna dikkat çekiliyor. Lisans tarafında ise Meta, Google, Microsoft, Apple gibi büyük IT şirketlerinin AGPL yazılımlarının kullanımını katı biçimde yasakladığı, bunun da AGPL'deki “Remote Network Interaction” maddesinin belirsizliği nedeniyle hukuki risk almak istememelerinden kaynaklandığı ifade ediliyor. Eğer büyük şirketlerin ya da genel olarak işletmelerin benim kodumu kesinlikle kullanamamasını istiyorsan AGPL seç deniyor. Referans: Google'ın AGPL politika belgesi
    • Birçok şirketin aslında AGPL yazılımları (ör. Grafana, Mastodon, Mattermost vb.) kurum içinde kullandığı vurgulanıyor; ancak dışarıdaki ücretli müşterilere sunulan hizmetlerde bunun daha az görüldüğü belirtiliyor. Bir geliştirici olarak ben, dev şirketlerin aşırı temkinliliğinden ziyade yazılımımın kullanıcılarının özgürlüğünü daha önemli buluyorum.
    • AGPL'den etkilenenin “tüm işletmeler” değil, “benim yazılımımla kapalı ağ hizmeti sunan şirketler” olduğu belirtiliyor. AGPL'nin temel amacı da zaten bu. Google'ın politika gerekçesinde de bu yüzden ağ sağlayıcılarından açıkça söz ediliyor. Teknik olmayan şirketlerin çoğu için bunun hiçbir etkisi yok ve umursamalarına da gerek yok.
    • Açık kaynak startup'ıysan, AWS gibi dev bulut sağlayıcılarının seni ezip geçmesini önlemek için AGPL + ticari çift lisanslama (fikri mülkiyet devri içeren CLA ile birlikte) öneriliyor.
    • Birçok büyük şirketin AGPL yazılım kullanabilmesinin nedeni olarak çift lisanslama açıklanıyor. Yani AGPL ile açık kaynak olduğu tanıtılırken, ticari lisans üzerinden kurumsal müşterilerden ücret alınabiliyor.
    • Son zamanlarda çok fazla Go kullanıldığı düşüncesi paylaşılmış; birçok paketin Go ile yeniden yazılmış gibi göründüğü izlenimi aktarılıyor.
  • PHP lisansı ve onun geçmişiyle ilgili içeriğin; pazarlama dili ya da yapay zeka üretimi metinler olmadan tek bir yerde toplanmış olmasının çok hoş olduğu söyleniyor.
    • Yapay zeka üretimi içeriklerin aslında ek bilgi vermediği, gereksiz laf kalabalığının zaten eskiden beri var olduğu ve temelde yeni bir şey olmadığı yönünde neşeli bir yorum da ekleniyor.
  • 25 yıl önce PHP Zend Engine kaynak kodunu doğrudan incelerken hayatında ilk kez üçlü pointer (zval***) ile karşılaştığını hatırlıyor. Sonrasında PHP ile çeşitli işler yaptığını, lise yıllarında programlama yarışmalarına da CLI ortamında PHP kullanarak katıldığını; ancak o dönemde görevliler dil ve ortama aşina olmadıkları için elendiği hem komik hem buruk bir anısını paylaşıyor. O dönem PHP'nin kendisine sunduğu imkanlar için teşekkür ediyor.
    • Bu hikayenin eğlenceli bulunduğu ve kendisinin de mezuniyet projesinde Perl kullandığı deneyimi paylaşılıyor.
    • Üçlü “çıplak” pointer için mantıksal olarak ikna edici bir gerekçe bulmanın zor olduğu söyleniyor. Performanstan önce, örtük dolaylı başvurunun karmaşıklığını açıklamak zor. Örneğin struct üyesi gibi açık durumlar anlaşılabilir; ama gereksiz yere karmaşıklık eklemek mantıksız görünüyor. Bir arkadaşının sık sık “Neden basit değil?” dediği anımsanıyor.
  • Tüm katkıcıların onayı alınmazsa kötü niyetli bir katkıcının sorun çıkarabileceğine dair kaygı dile getiriliyor. ABD gibi yerlerde sırf yıldırmak için dava açmanın gayet mümkün olduğu, herkesin de buna kendi cebinden karşılık vermek zorunda kaldığı; bunun sonucunda da hukuki savunmaya aşırı odaklı bir kültür oluştuğu anlatılıyor. Yan not olarak da Richard Stallman, PHP'nin GPL kullanımı ve bunun sonucunda çift lisanslamanın sona erdiğine dair klasik bir anekdot anılıyor.
    • PHP Group'un “or later” maddesi sayesinde, ayrıca katkıcı onayı almadan lisans metnini değiştirip yeni sürüm yayımlayabildiği açıklanıyor.
    • Stallman'la ilgili lisans anekdotunun geçtiği ana kaynağın aslında MySQL'in GPL'e geçişi ve bunun PHP lisansı üzerindeki etkisiyle daha ilgili olduğu belirtiliyor; Stallman sevmedi diye GPL'den vazgeçilmesi fikrinin pek ikna edici bulunmadığı söyleniyor.
  • İlgili arka plan PHP wiki'deki lisans değişikliği arka plan belgesinde görülebilir.
  • Yazılım lisansları ve bunların değişiklikleri hakkında uzmanlık kazanmak istiyorsan mutlaka okunması gereken bir sayfa olduğu öneriliyor. Ayrıca bu lisans değişikliğinin bizden herhangi bir değişiklik ya da yeniden sertifikasyon istemeyen bir gelişme olduğu özellikle vurgulanıyor; hem katkıcılar hem kullanıcılar etkilenmiyor.
    • Büyük değişiklik olmadan ilerleyen haberlerin bazen aslında devasa değişiklikler içerdiğini hatırlatmak için 787MAX ve MCAS olayı örnek verilerek esprili bir gerçekçilik sergileniyor.
    • Gerçek değişikliğin, PHP/Zend ticari markalarına ilişkin ifadelerin çıkarılması ve iki projenin tek bir lisans altında birleştirilmesi olduğu ayrıntılı biçimde anlatılıyor. Yani daha önce “PHP”, “Zend”, “Zend Engine” adlarını kullanmak için ayrı ayrı onay gerekiyorken, artık bu durum telif hakkı sahipleri ve katkıcı isimleri için topluca uygulanacak şekilde değişiyor. Ayrıca atıf, revizyon, sertifikasyon ve bildirim maddelerinin (4-6) de kaldırıldığı tek tek açıklanıyor.
  • Lisans belgelerinde neden önemli kısımların tamamının büyük harfle (ALL CAPS) yazıldığı soruluyor.
    • ABD hukukunda garanti/sorumluluk reddi maddelerinin “conspicuous” yani fark edilir olması gerektiği, düz metinde bunun en kolay yolunun büyük harf kullanmak olduğu açıklanıyor.
    • Büyük-küçük harf tartışmasını tamamen ortadan kaldırmanın bir yolu olduğu söyleniyor; tüm kelimeler büyük harfle yazılınca hepsi vurgulanmış oluyor ve karışıklık azalıyor.
    • Ticaret hukuku (UCC) hükümlerine göre, makul bir kişinin mutlaka fark edeceği şekilde yazılması gerekiyor; bunun bir yolu da başlığın büyük ve tamamen büyük harflerle olması. Bu yüzden tamamını büyük harfle yazmak, mahkemenin de bunun önemini “gözle görülür” bulmasını sağlayabiliyor.
  • Konuya hakim birinden ELI5 seviyesinde açıklama isteniyor; tüm PHP lisansının mı değiştiği merak ediliyor.
    • “Tüm PHP” ile tam olarak ne kastedildiği soruluyor ve bu değişikliğin dilin kendisine, yani interpreter'a, runtime'a ve standart kütüphaneye uygulandığı açıklanıyor.
  • MIT lisansı çok daha basitken neden onun kullanılmadığı merak ediliyor.