1 poin oleh GN⁺ 2025-07-16 | 1 komentar | Bagikan ke WhatsApp
  • Proyek PHP sedang membahas RFC untuk menyatukan lisensi khusus PHP dan lisensi Zend Engine yang selama ini rumit dan tidak kompatibel menjadi BSD 3-Clause (Modified BSD License)
  • Waktu penerapan lisensi baru adalah PHP 9.0, dan BSD 3-Clause akan diterapkan di seluruh kode sumber, header, dan dokumentasi, sementara klausul khusus lama serta pembatasan terkait merek akan dihapus
  • Disetujui oleh OSI dan FSF, kompatibel dengan GPL, sehingga kejelasan hukum terjamin, dan hak kontributor maupun pengguna tetap dijamin sama seperti sebelumnya
  • Untuk mengubah lisensi, dibutuhkan persetujuan resmi dari PHP Group dan Perforce Software (sebelumnya Zend), lalu proses diskusi komunitas selama lebih dari 6 bulan serta prosedur pemungutan suara
  • Perubahan ini juga merekomendasikan proyek eksternal seperti PECL/ekstensi untuk memilih BSD 3-Clause, dan tidak menganjurkan penggunaan “PHP License”

Ikhtisar

  • Selama bertahun-tahun, proyek PHP terus menghadapi kebingungan dan kontroversi karena lisensi open source buatannya sendiri dan Zend Engine License
  • Khususnya, Zend Engine License yang diterapkan pada kode sumber di direktori Zend menambah kerumitan karena bukan lisensi yang disetujui OSI
  • RFC ini mengusulkan penyederhanaan lisensi yang praktis dengan tetap mempertahankan hak cipta semua kontributor PHP sekaligus memberi pengguna hak yang sama seperti lisensi sebelumnya
  • Tujuannya adalah mengadopsi BSD 3-Clause (Modified BSD License) sebagai lisensi resmi baru untuk mengurangi kompleksitas dan kesalahpahaman tanpa mengubah hak maupun syarat penggunaan

Usulan dan perubahan utama

  • Inti masalahnya adalah menerbitkan versi baru PHP License dan Zend Engine License untuk secara resmi mengadopsi Modified BSD License (BSD-3-Clause, disetujui OSI/FSF)
  • PHP License yang ada (version 3.01) dan Zend Engine License (version 2.00) pada dasarnya sama dengan Modified BSD kecuali beberapa klausul khusus, sehingga tidak ada perubahan substansial pada hak yang diberikan
  • Setelah pembaruan lisensi:
    • Tidak ada perubahan pada hak yang diberikan kepada kontributor dan pengguna
    • Bekerja sama dengan PHP Group dan Perforce Software untuk menghapus klausul khusus milik kelompok tertentu
    • PHP dan Zend Engine akan disediakan di bawah lisensi yang disetujui OSI dan kompatibel dengan GPL
  • Penggunaan PHP License lama dan Zend Engine License tidak lagi dianjurkan
  • Berkas LICENSE dan header lisensi dalam kode sumber juga akan diganti ke format baru

Ringkasan teks lisensi

  • BSD 3-Clause memungkinkan penyalinan, modifikasi, dan distribusi secara bebas, dengan syarat tetap menyertakan hak cipta dan klausul penafian, serta larangan penggunaan nama dan merek tanpa izin
  • BSD-3-Clause adalah lisensi perangkat lunak bebas yang disetujui oleh OSI (Open Source Initiative) dan FSF, serta kompatibel dengan GPL

Prosedur perubahan dan persetujuan

  • RFC akan diputuskan melalui pemungutan suara setelah diskusi terbuka di komunitas, dan penerapan dilakukan setelah persetujuan resmi serta voting
  • Perubahan lisensi memerlukan persetujuan resmi dari PHP Group dan Perforce Software
  • Hak kontributor kode sumber sebelumnya tetap dipertahankan, dan perubahan ini tidak melanggar hak yang sudah ada
  • Komunitas akan diberi masa diskusi lebih dari 6 bulan sebelum diputuskan melalui voting
  • Perubahan dijadwalkan resmi diterapkan pada PHP 9.0

Latar belakang dan konteks historis

  • Pada masa awal, PHP 1 dan 2 menggunakan GPL, lalu berkembang melalui lisensi Apache dan lisensi kustom berbasis BSD
  • Zend Engine mempertahankan lisensi terpisah, tetapi kini pada praktiknya dianggap sebagai satu proyek yang tidak bisa dipisahkan
  • Pembatasan penggunaan nama dan klausul perlindungan merek pada lisensi PHP lama terus menimbulkan masalah dalam kompatibilitas dan distribusi dengan open source lain

Dampak pada kode lama, ekstensi, dan dokumentasi

  • RFC ini berlaku untuk seluruh php-src (kecuali kode yang secara eksplisit mencantumkan lisensi terpisah), dan PECL/ekstensi juga dianjurkan mengadopsi BSD 3-Clause
  • Berdampak pada seluruh kode dalam repositori sumber PHP baru maupun lama yang menggunakan PHP License atau Zend Engine License
  • Lisensi yang sudah ada (mis. timelib dan kode berlisensi terpisah lainnya) bukan sasaran perubahan ini
  • Manual PHP akan tetap menggunakan lisensi Creative Commons Attribution 3.0 atau yang lebih baru
  • Modul ekstensi/perangkat lunak yang ada diberi pilihan untuk menerapkan PHP License v4 (Modified BSD)
  • Untuk ekstensi baru dan proyek baru ke depan, disarankan menggunakan lisensi resmi terbaru seperti BSD/Apache

Kesimpulan

  • Struktur lisensi PHP dan Zend Engine akan disederhanakan menjadi 3-clause BSD, sehingga kejelasan, kompatibilitas, pemanfaatan komersial, dan kepastian hukum dalam ekosistem open source diperkirakan akan menguat
  • Jika usulan ini disetujui dan diterapkan, pengguna dapat menggunakan PHP dan Zend Engine secara bebas berdasarkan BSD-3-Clause
  • Setelah persetujuan kontributor, komunitas, dan perusahaan utama dalam proyek serta prosedur voting selesai, perubahan ini akan diterapkan secara resmi

1 komentar

 
GN⁺ 2025-07-16
Komentar Hacker News
  • Dijelaskan bahwa bahasa yang digunakan Meta bukan PHP melainkan Hack, namun juga disebutkan bahwa packaging, dokumentasi, dan ketersediaan Hack kurang baik; alasannya karena hal-hal itu bukan bagian yang terlihat di dalam Meta sehingga tidak tercermin dalam evaluasi kinerja, serta ditunjukkan bahwa penyembunyian pengetahuan internal juga terhubung dengan jaminan pekerjaan. Dari sisi lisensi, perusahaan IT besar seperti Meta, Google, Microsoft, dan Apple secara ketat melarang penggunaan perangkat lunak AGPL karena tidak ingin menanggung risiko hukum akibat ambiguitas klausul “Remote Network Interaction” dalam AGPL. Ditambahkan pula saran bahwa jika ingin perusahaan besar atau pelaku usaha pada umumnya sama sekali tidak bisa memakai kodenya, pilihlah AGPL. Referensi: dokumen kebijakan AGPL Google
    • Ditekankan bahwa banyak perusahaan benar-benar menggunakan perangkat lunak AGPL (misalnya Grafana, Mastodon, Mattermost) secara internal, hanya saja lebih jarang dipakai untuk layanan bagi pelanggan berbayar eksternal. Sebagai pengembang, saya menyatakan bahwa kebebasan pengguna perangkat lunak saya lebih penting daripada kekhawatiran berlebihan perusahaan raksasa.
    • Ditunjukkan bahwa yang terdampak AGPL bukanlah ‘semua pelaku usaha’, melainkan hanya ‘perusahaan yang menyediakan layanan jaringan tertutup/proprietary dengan perangkat lunak saya’. Dijelaskan bahwa inilah memang tujuan utama AGPL. Alasan kebijakan Google juga secara jelas menyebutkan hal ini karena mereka adalah penyedia layanan jaringan. Bagi kebanyakan perusahaan nonteknologi, ini praktis tidak berdampak dan tidak perlu dipikirkan.
    • Jika Anda adalah startup open source, direkomendasikan AGPL + lisensi ganda komersial (termasuk CLA pengalihan hak kekayaan intelektual) untuk mencegah dimonopoli mega-cloud seperti AWS.
    • Dijelaskan bahwa banyak perusahaan besar menggunakan perangkat lunak AGPL karena lisensi ganda dimungkinkan. Artinya, Anda bisa memasarkan proyek sebagai open source di bawah AGPL sekaligus mengenakan biaya kepada pelanggan perusahaan yang memakainya lewat lisensi komersial.
    • Belakangan ini terasa bahwa Go digunakan sangat banyak; kesannya banyak paket tampaknya ditulis ulang dalam Go.
  • Disampaikan kesan bahwa rangkuman tentang lisensi PHP dan sejarahnya yang terkumpul di satu tempat tanpa embel-embel pemasaran atau konten buatan AI itu sangat bagus.
    • Ditambahkan pendapat jenaka bahwa konten buatan AI sebenarnya tidak menambahkan informasi baru, dan omong kosong yang tidak perlu memang sejak dulu sudah ada; pada dasarnya tidak ada yang benar-benar baru.
  • Saat mempelajari langsung source code PHP Zend Engine 25 tahun lalu, teringat bahwa saat itu saya pertama kali dalam hidup melihat triple pointer (zval***). Setelah itu saya melakukan berbagai hal dengan PHP, bahkan saat masih SMA saya ikut lomba pemrograman menggunakan PHP di lingkungan CLI, tetapi gugur karena staf saat itu tidak akrab dengan bahasa dan lingkungannya; pengalaman pahit-manis yang lucu. Disampaikan juga rasa terima kasih atas kemungkinan yang dibuka PHP pada masa itu.
    • Cerita ini terasa menyenangkan, dan saya sendiri berbagi pengalaman pernah memakai Perl untuk proyek kelulusan.
    • Disebutkan bahwa sulit menemukan titik masuk yang bisa diterima secara logis untuk triple “naked” pointer; sebelum bicara performa pun, kompleksitas dereferensi implisitnya sulit dijelaskan. Misalnya hal yang jelas seperti anggota struct masih bisa dipahami, tetapi menambahkan kompleksitas tanpa alasan terasa tidak rasional. Saya teringat seorang kenalan yang sering berkata, “kenapa tidak dibuat sederhana?”
  • Ada kekhawatiran bahwa jika persetujuan semua kontributor tidak diperoleh, kontributor yang berniat jahat bisa menimbulkan masalah. Di AS dan tempat lain, gugatan untuk sekadar melecehkan secara jahat pun sangat mungkin terjadi, dan semua orang harus menanganinya dengan biaya sendiri, sehingga pada akhirnya lahir budaya yang terlalu fokus pada pembelaan hukum. Lalu disinggung juga anekdot klasik tentang Richard Stallman, penggunaan GPL oleh PHP, dan bagaimana hal itu menyebabkan lisensi ganda dihentikan.
    • Dijelaskan bahwa PHP Group, berkat klausul “or later”, dapat mengubah isi lisensi dan merilis versi baru tanpa perlu persetujuan kontributor secara terpisah.
    • Ditunjukkan bahwa materi utama yang menyebut anekdot lisensi dengan Stallman sebenarnya lebih dekat pada peralihan MySQL ke GPL dan dampaknya terhadap lisensi PHP; diungkapkan pula bahwa sulit memahami alasan meninggalkan GPL hanya karena Stallman tidak menyukainya.
  • Latar belakang terkait dapat dilihat di dokumen latar belakang perubahan lisensi di wiki PHP
  • Direkomendasikan sebagai halaman yang wajib dibaca jika ingin membangun pengetahuan mendalam tentang lisensi perangkat lunak dan perubahannya. Juga ditekankan bahwa perubahan lisensi kali ini adalah kabar yang tidak menuntut perubahan atau sertifikasi ulang apa pun dari kita; baik kontributor maupun pengguna tidak terdampak.
    • Secara jenaka diungkapkan kewaspadaan realistis dengan mencontohkan kasus 787MAX dan MCAS, di mana berita bahwa sesuatu berjalan tanpa perubahan besar justru ternyata disertai perubahan yang amat besar.
    • Dijelaskan secara rinci bahwa perubahan aktualnya adalah penghapusan frasa terkait merek dagang PHP/Zend dan proses penyatuan dua proyek ke dalam satu lisensi. Artinya, sebelumnya penggunaan nama “PHP”, “Zend”, dan “Zend Engine” masing-masing memerlukan persetujuan terpisah, tetapi kini diubah agar berlaku secara terpadu terhadap nama pemegang hak cipta dan kontributor. Klausul soal pencantuman, revisi, sertifikasi, dan pemberitahuan (poin 4~6) juga ikut dihapus.
  • Diajukan pertanyaan mengapa bagian penting dalam dokumen lisensi ditulis semua dengan huruf kapital (ALL CAPS).
    • Dijelaskan bahwa menurut hukum AS, klausul pelepasan jaminan/tanggung jawab harus bersifat “conspicuous” (mudah terlihat), dan dalam teks biasa cara termudah untuk menandainya adalah dengan huruf kapital.
    • Disebutkan bahwa ini juga cara untuk menghilangkan perdebatan soal huruf besar-kecil; kalau semua kata ditulis kapital, semuanya dianggap ditekankan sehingga kebingungan berkurang.
    • Menurut ketentuan hukum dagang (UCC), teks harus ditulis sedemikian rupa sehingga orang yang wajar pasti akan menyadarinya; salah satu caranya adalah judul besar dengan huruf kapital. Karena itu, jika seluruhnya ditulis kapital, pengadilan pun dapat menganggap pentingnya bagian itu cukup ‘mencolok’.
  • Diminta agar seseorang yang benar-benar memahami perubahan ini menjelaskannya pada level ELI5, karena penasaran apakah lisensi seluruh PHP sedang berubah.
    • Dijelaskan bahwa perlu diperjelas dulu apa yang dimaksud dengan “seluruh PHP”; perubahan kali ini berlaku pada bahasa itu sendiri, yakni interpreter, runtime, dan pustaka standarnya.
  • Disebutkan rasa penasaran mengapa tidak memakai lisensi MIT, padahal jauh lebih sederhana.
    • Dipertanyakan balik apakah perbedaan antara MIT dan BSD 3-Clause benar-benar cukup bermakna hingga terasa lebih sederhana secara praktis, dan apakah ada perbedaan yang berarti antara lisensi MIT dan lisensi BSD 3-Clause dalam makna yang substansial.