1 คะแนน โดย GN⁺ 2025-07-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โปรเจกต์ PHP กำลังหารือ RFC เพื่อรวม ไลเซนส์เฉพาะของ PHP และไลเซนส์ของ Zend Engine ที่ซับซ้อนและไม่เข้ากันในปัจจุบัน ให้เป็น BSD 3-Clause (Modified BSD License)
  • ช่วงเวลาที่จะเริ่มใช้ไลเซนส์ใหม่นี้คือ PHP 9.0 โดยจะปรับใช้ BSD 3-Clause กับซอร์สโค้ด, เฮดเดอร์ และเอกสารทั้งหมด และยกเลิกข้อกำหนดพิเศษกับข้อจำกัดด้านแบรนด์ในอดีต
  • มีความชัดเจนทางกฎหมายมากขึ้นจากการที่ OSI และ FSF รับรอง รวมถึงเข้ากันได้กับ GPL ขณะที่สิทธิของผู้มีส่วนร่วมและผู้ใช้ยังคงได้รับการคุ้มครองเช่นเดิม
  • การเปลี่ยนไลเซนส์ต้องได้รับ ความยินยอมอย่างเป็นทางการจาก PHP Group และ Perforce Software (เดิมคือ Zend) และหลังการหารือในชุมชนจะมีขั้นตอนอภิปรายและลงคะแนนนานกว่า 6 เดือน
  • การเปลี่ยนแปลงนี้ยัง แนะนำให้โปรเจกต์ภายนอกอย่าง PECL/ส่วนขยายเลือกใช้ BSD 3-Clause ด้วย และไม่แนะนำให้ใช้ “PHP License”

ภาพรวม

  • โปรเจกต์ PHP มี ความสับสนและข้อถกเถียง มาอย่างยาวนานจากการใช้ทั้งไลเซนส์โอเพนซอร์สของตัวเองและ Zend Engine License
  • โดยเฉพาะไลเซนส์ Zend Engine ที่ใช้กับซอร์สในไดเรกทอรี Zend นั้น ไม่ได้เป็นไลเซนส์ที่ OSI รับรอง จึงยิ่งเพิ่มความซับซ้อน
  • RFC นี้เสนอ การทำให้โครงสร้างไลเซนส์เรียบง่ายในทางปฏิบัติ โดยยังคงลิขสิทธิ์ของผู้ร่วมพัฒนา PHP ทุกคนไว้ และมอบสิทธิให้ผู้ใช้เทียบเท่ากับไลเซนส์เดิม
  • เป้าหมายคือการนำ BSD 3-Clause (Modified BSD License) มาเป็นไลเซนส์ทางการใหม่ เพื่อคงสิทธิและเงื่อนไขการใช้งานไว้ ขณะเดียวกันก็ลดความซับซ้อนและความเข้าใจผิด

ข้อเสนอและการเปลี่ยนแปลงสำคัญ

  • แก่นของปัญหาคือการเผยแพร่ PHP License และ Zend Engine License เวอร์ชันใหม่เพื่อ รับรอง Modified BSD License (BSD-3-Clause, ได้รับการรับรองทั้งจาก OSI/FSF) อย่างเป็นทางการ
  • PHP License เดิม (version 3.01) และ Zend Engine License (version 2.00) นั้น แทบจะเหมือนกับ Modified BSD ทุกประการ ยกเว้นข้อกำหนดพิเศษบางส่วน จึงไม่มีการเปลี่ยนแปลงเชิงสาระสำคัญในเรื่องสิทธิ
  • หลังอัปเดตไลเซนส์แล้ว:
    • สิทธิที่มอบให้ผู้มีส่วนร่วมและผู้ใช้จะไม่เปลี่ยนแปลง
    • ทำงานร่วมกับ PHP Group และ Perforce Software เพื่อ ลบข้อกำหนดเฉพาะของแต่ละกลุ่ม
    • PHP และ Zend Engine จะถูกเผยแพร่ภายใต้ไลเซนส์ที่ OSI รับรองและเข้ากันได้กับ GPL
  • ไม่แนะนำให้ใช้ PHP License และ Zend Engine License แบบเดิมอีกต่อไป
  • ไฟล์ LICENSE และเฮดเดอร์ไลเซนส์ในซอร์สก็จะถูกเปลี่ยนเป็น ฟอร์แมตใหม่ ด้วย

สรุปเนื้อหาไลเซนส์

  • BSD 3-Clause อนุญาตให้คัดลอก แก้ไข และเผยแพร่ได้อย่างอิสระ โดยมีเงื่อนไขเรื่องลิขสิทธิ์และข้อปฏิเสธความรับผิด รวมถึงห้ามใช้ชื่อหรือแบรนด์โดยไม่ได้รับอนุญาต
  • BSD-3-Clause เป็นไลเซนส์ซอฟต์แวร์เสรีที่ ได้รับการรับรองจากทั้ง OSI (Open Source Initiative) และ FSF และยังเข้ากันได้กับ GPL

ขั้นตอนการเปลี่ยนแปลงและการอนุมัติ

  • RFC จะถูกสรุปผ่านการลงคะแนนหลังเปิดให้ชุมชนอภิปราย และจะเริ่มนำไปใช้หลังได้รับความยินยอมอย่างเป็นทางการและผ่านการลงคะแนนแล้ว
  • การเปลี่ยนไลเซนส์ต้องได้รับ ความยินยอมอย่างเป็นทางการจาก PHP Group และ Perforce Software
  • สิทธิของผู้มีส่วนร่วมในซอร์สโค้ดเดิมยังคงเดิม และการเปลี่ยนแปลงนี้จะไม่ละเมิดสิทธิที่มีอยู่
  • ชุมชนจะได้รับเวลาหารือมากกว่า 6 เดือนก่อนสรุปผลด้วยการลงคะแนน
  • คาดว่าจะเริ่มใช้อย่างเป็นทางการใน PHP 9.0

ฉากหลังและบริบททางประวัติศาสตร์

  • ในช่วงแรก PHP 1 และ 2 ใช้ GPL ก่อนจะค่อย ๆ พัฒนาผ่าน Apache License และไลเซนส์แบบคัสตอมที่อิงจาก BSD
  • Zend Engine เคยคงไลเซนส์แยกต่างหากไว้ แต่ปัจจุบันถือว่าแทบจะแยกจากกันไม่ได้และเป็นโปรเจกต์เดียวกันในทางปฏิบัติ
  • ข้อจำกัดเรื่องการใช้ชื่อและข้อกำหนดคุ้มครองแบรนด์ในไลเซนส์ PHP เดิม สร้างปัญหาด้านความเข้ากันได้กับโอเพนซอร์สอื่น ๆ และการแจกจ่ายมาอย่างต่อเนื่อง

ผลกระทบต่อโค้ดเดิม ส่วนขยาย และเอกสาร

  • RFC นี้ใช้กับ php-src ทั้งหมด (ยกเว้นโค้ดที่ระบุไลเซนส์อื่นไว้ต่างหาก) และยังแนะนำให้ PECL/ส่วนขยายต่าง ๆ หันมาใช้ BSD 3-Clause ด้วย
  • มีผลต่อโค้ดทั้งหมดในรีโปซอร์ส PHP ทั้งใหม่และเดิมที่อยู่ภายใต้ PHP License หรือ Zend Engine License
  • ไลเซนส์เดิมบางส่วน (เช่นโค้ดที่ใช้ไลเซนส์อื่นอย่าง timelib) ไม่อยู่ในขอบเขตของการเปลี่ยนแปลงนี้
  • คู่มือ PHP จะยังคงใช้ไลเซนส์ Creative Commons Attribution 3.0 หรือสูงกว่าต่อไป
  • โมดูลส่วนขยาย/ซอฟต์แวร์เดิมจะได้รับทางเลือกให้ใช้ PHP License v4 (Modified BSD)
  • สำหรับส่วนขยายและโปรเจกต์ใหม่ในอนาคต แนะนำให้ใช้ไลเซนส์มาตรฐานที่ได้รับการรับรอง เช่น BSD/Apache เวอร์ชันล่าสุด

บทสรุป

  • โครงสร้างไลเซนส์ของ PHP และ Zend Engine จะถูกทำให้เรียบง่ายขึ้นเป็น 3-clause BSD ซึ่งน่าจะช่วยเพิ่มความชัดเจน ความเข้ากันได้ การใช้งานเชิงพาณิชย์ และความมั่นคงทางกฎหมายในระบบนิเวศโอเพนซอร์ส
  • หากข้อเสนอนี้ได้รับการอนุมัติและเริ่มใช้ ผู้ใช้จะสามารถใช้งาน PHP และ Zend Engine ได้อย่างอิสระภายใต้เกณฑ์ของ BSD-3-Clause
  • คาดว่าจะมีการนำมาใช้อย่างเป็นทางการหลังเสร็จสิ้นกระบวนการยินยอมและลงคะแนนจากผู้มีส่วนร่วม ชุมชน และบริษัทหลักที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-07-16
ความคิดเห็นบน Hacker News
  • มีคนชี้ว่า ภาษาที่ Meta ใช้ไม่ใช่ PHP แต่เป็น Hack และกล่าวถึงด้วยว่าการแพ็กเกจ การทำเอกสาร และความพร้อมใช้งานของ Hack นั้นไม่ค่อยดีนัก โดยให้เหตุผลว่าเพราะสิ่งเหล่านี้ไม่ใช่งานที่คนภายใน Meta มองเห็น จึงไม่ค่อยถูกนำไปสะท้อนในผลงานประเมิน อีกทั้งยังชี้ว่าการกักเก็บความรู้ไว้ภายในก็เชื่อมโยงกับการประกันตำแหน่งงานของตัวเองด้วย และในมุมของไลเซนส์ บริษัท IT รายใหญ่อย่าง Meta, Google, Microsoft, Apple ฯลฯ มักห้ามใช้ซอฟต์แวร์ AGPL อย่างเข้มงวด เพราะไม่อยากรับความเสี่ยงทางกฎหมายจากความกำกวมของเงื่อนไข “Remote Network Interaction” พร้อมเสริมว่า ถ้าอยากให้บริษัทใหญ่หรือผู้ประกอบการทั่วไปไม่มีวันใช้โค้ดของตัวเองได้เลย ก็ให้เลือก AGPL ดู อ้างอิง: เอกสารนโยบาย AGPL ของ Google
    • มีการเน้นว่าหลายบริษัทใช้งานซอฟต์แวร์ AGPL ภายในจริง ๆ (เช่น Grafana, Mastodon, Mattermost ฯลฯ) เพียงแต่ไม่ค่อยนำไปใช้เป็นบริการสำหรับลูกค้าภายนอกที่ต้องจ่ายเงิน และในฐานะนักพัฒนา ผู้เขียนให้ความสำคัญกับเสรีภาพของผู้ใช้ซอฟต์แวร์ของตนมากกว่าความกังวลเกินเหตุของบริษัทยักษ์ใหญ่
    • มีคนชี้ว่าไม่ใช่ ‘ผู้ประกอบการทั้งหมด’ แต่เฉพาะ ‘บริษัทที่ให้บริการเครือข่ายแบบปิดด้วยซอฟต์แวร์ของฉัน’ เท่านั้นที่ได้รับผลจาก AGPL และนี่ก็คือเจตนาหลักของ AGPL เอง โดยอธิบายว่านโยบายของ Google ก็ระบุชัดเจนด้วยเหตุนี้ว่าเกี่ยวข้องกับผู้ให้บริการเครือข่าย สำหรับธุรกิจที่ไม่ใช่สายเทคโนโลยีส่วนใหญ่นั้นแทบไม่มีผลกระทบอะไรและไม่จำเป็นต้องกังวล
    • หากเป็นสตาร์ตอัปโอเพนซอร์ส ก็แนะนำ AGPL + ไลเซนส์เชิงพาณิชย์แบบคู่ (พร้อม CLA แบบโอนทรัพย์สินทางปัญญา) เพื่อป้องกันไม่ให้ถูกเมกะคลาวด์อย่าง AWS กินรวบ
    • มีคำอธิบายว่าที่หลายบริษัทใหญ่ใช้ซอฟต์แวร์ AGPL ก็เพราะทำ dual license ได้ กล่าวคือใช้ AGPL เพื่อโฆษณาว่าเป็นโอเพนซอร์ส แต่หากลูกค้าจะใช้งานภายใต้ไลเซนส์เชิงพาณิชย์ก็สามารถเรียกเก็บเงินได้
    • มีความเห็นว่าช่วงหลังนี้น่าจะมีคนใช้ Go กันมากขึ้น และรู้สึกว่าแพ็กเกจหลายตัวดูเหมือนถูกเขียนใหม่ด้วย Go
  • มีความเห็นว่าดีมากที่ข้อมูลเกี่ยวกับไลเซนส์ของ PHP และประวัติของมันถูกสรุปรวมไว้ในที่เดียวโดยไม่มีเนื้อหาแนวการตลาดหรือเนื้อหาที่ AI สร้างขึ้น
    • มีการเสริมอย่างขำ ๆ ว่าเนื้อหาที่ AI สร้างขึ้นจริง ๆ แล้วไม่ได้เพิ่มข้อมูลอะไรใหม่ ส่วนคำพูดฟุ่มเฟือยน่าเบื่อนั้นเดิมทีก็มีอยู่แล้ว จึงไม่มีอะไรใหม่ในสาระสำคัญ
  • มีคนรำลึกว่าตอนศึกษาซอร์สโค้ดของ PHP Zend Engine ด้วยตัวเองเมื่อ 25 ปีก่อน นั่นเป็นครั้งแรกในชีวิตที่ได้เจอ triple pointer (zval***) หลังจากนั้นก็เคยทำอะไรหลายอย่างด้วย PHP และตอนเป็นนักเรียนมัธยมยังเคยลงแข่งเขียนโปรแกรมโดยใช้ PHP ในสภาพแวดล้อมแบบ CLI แต่สุดท้ายตกรอบเพราะสตาฟในตอนนั้นไม่คุ้นกับภาษาและสภาพแวดล้อมนั้น เป็นประสบการณ์ทั้งขำทั้งเศร้า พร้อมกล่าวขอบคุณต่อความเป็นไปได้ที่ PHP เปิดให้ในยุคนั้น
    • มีคนบอกว่าเรื่องนี้ฟังดูสนุกดี และแชร์ว่าตนเองก็เคยใช้ Perl ในโปรเจ็กต์จบ
    • มีความเห็นว่าหาจุดที่ทำให้ยอมรับ triple “naked” pointer ได้อย่างมีเหตุผลค่อนข้างยาก ก่อนจะพูดถึงประสิทธิภาพเสียอีก ความซับซ้อนของการอ้างอิงทางอ้อมแบบแฝงก็อธิบายได้ยากแล้ว เช่น ถ้าเป็นสมาชิกของ struct ที่ชัดเจนก็ยังพอเข้าใจได้ แต่การเพิ่มความซับซ้อนโดยไม่จำเป็นนั้นดูไม่สมเหตุสมผล พร้อมรำลึกว่าเคยมีคนรู้จักพูดบ่อย ๆ ว่า “ทำไมมันไม่ทำให้เรียบง่ายกว่านี้?”
  • มีความกังวลว่าหากไม่ได้รับความยินยอมจากผู้มีส่วนร่วมทุกคน ผู้ร่วมพัฒนาที่ไม่หวังดีอาจสร้างปัญหาได้ และในสหรัฐฯ เป็นต้น ก็สามารถมีการฟ้องร้องเพื่อก่อกวนกันได้มากมาย โดยทุกคนต้องออกค่าใช้จ่ายสู้คดีเอง จึงเกิดวัฒนธรรมที่ให้ความสำคัญกับการป้องกันทางกฎหมายมากเกินไปไปโดยปริยาย อีกทั้งยังกล่าวถึงเกร็ดคลาสสิกเรื่อง Richard Stallman, การใช้ GPL กับ PHP และการที่สิ่งนั้นทำให้ dual licensing ต้องหยุดลง
    • มีคำอธิบายว่า PHP Group สามารถแก้ไขข้อความไลเซนส์และออกเวอร์ชันใหม่ได้โดยไม่ต้องขอความยินยอมจากผู้มีส่วนร่วมแยกต่างหาก เพราะมีเงื่อนไข “or later” อยู่
    • มีคนชี้ว่าเอกสารต้นทางที่พูดถึงเกร็ดเรื่องไลเซนส์กับ Stallman นั้นจริง ๆ ใกล้เคียงกับการที่ MySQL เปลี่ยนไปใช้ GPL และผลกระทบที่มีต่อไลเซนส์ของ PHP มากกว่า และแสดงความเห็นว่าไม่ค่อยเข้าใจเหตุผลที่จะเลิกใช้ GPL เพียงเพราะ Stallman ไม่ชอบ
  • สามารถดูบริบทเพิ่มเติมได้จากเอกสารภูมิหลังของการเปลี่ยนไลเซนส์บน PHP Wiki
  • มีการแนะนำว่านี่เป็นหน้าที่ควรอ่านอย่างยิ่งหากต้องการสะสมความรู้เชิงลึกด้านไลเซนส์ซอฟต์แวร์และการแก้ไขมัน และย้ำว่าการเปลี่ยนไลเซนส์ครั้งนี้เป็นข่าวประเภทที่ไม่ได้ทำให้เราต้องเปลี่ยนอะไรหรือรับรองอะไรใหม่ ทั้งผู้มีส่วนร่วมและผู้ใช้ไม่ได้รับผลกระทบ
    • มีการพูดติดตลกเชิงเตือนสติแบบสมจริง โดยยกกรณี 787MAX และ MCAS ที่เคยเป็น “ข่าวว่าดำเนินไปโดยไม่มีการเปลี่ยนแปลงใหญ่” แต่ในความเป็นจริงกลับมีการเปลี่ยนแปลงมหาศาล
    • มีคำอธิบายรายละเอียดว่า สิ่งที่เปลี่ยนจริง ๆ คือการลบถ้อยคำที่เกี่ยวกับเครื่องหมายการค้า PHP/Zend และเป็นกระบวนการรวมสองโปรเจ็กต์ให้ใช้ไลเซนส์เดียวกัน กล่าวคือเดิมหากต้องการใช้ชื่อ “PHP”, “Zend”, “Zend Engine” จำเป็นต้องได้รับอนุมัติแยกกัน แต่ตอนนี้เปลี่ยนเป็นใช้ข้อกำหนดเดียวกับชื่อของผู้ถือลิขสิทธิ์และผู้มีส่วนร่วมทั้งหมด รวมถึงมีการลบเงื่อนไขเรื่องการระบุ การแก้ไข การรับรอง และการแจ้งเตือน (ข้อ 4~6) ออกด้วย
  • มีคนสงสัยว่าทำไมส่วนสำคัญทั้งหมดในเอกสารไลเซนส์จึงเขียนเป็นตัวพิมพ์ใหญ่ทั้งหมด (ALL CAPS)
    • มีคำอธิบายว่าตามกฎหมายสหรัฐฯ ข้อความยกเว้นการรับประกัน/ความรับผิดจำเป็นต้อง “conspicuous(มองเห็นเด่นชัด)” และวิธีที่ง่ายที่สุดในข้อความธรรมดาก็คือการใช้ตัวพิมพ์ใหญ่ทั้งหมด
    • มีความเห็นว่านี่เป็นวิธีตัดปัญหาข้อถกเถียงเรื่องตัวพิมพ์ใหญ่-เล็กไปเลย เพราะถ้าทุกคำเป็นตัวพิมพ์ใหญ่ทั้งหมด ก็เท่ากับทุกส่วนถูกเน้นเหมือนกัน ความสับสนจึงลดลง
    • มีการอธิบายว่าตามบทบัญญัติของกฎหมายการค้า (UCC) ข้อความต้องถูกเขียนในลักษณะที่บุคคลทั่วไปที่มีเหตุผลย่อมสังเกตเห็นได้แน่นอน และหนึ่งในวิธีนั้นคือการใช้หัวข้อเป็นตัวพิมพ์ใหญ่ขนาดเด่น ดังนั้นเมื่อเขียนทั้งหมดเป็นตัวพิมพ์ใหญ่ ศาลก็อาจมองได้ว่าส่วนสำคัญนั้น “มองเห็นเด่นชัด” เพียงพอ
  • มีคนขอให้ผู้ที่เข้าใจการเปลี่ยนแปลงนี้ดีช่วยอธิบายแบบ ELI5 และสงสัยว่านี่หมายถึงไลเซนส์ของ PHP ทั้งหมดกำลังจะเปลี่ยนใช่หรือไม่
    • มีคนตอบกลับโดยถามก่อนว่า “PHP ทั้งหมด” หมายถึงอะไรอย่างชัดเจน และอธิบายว่าการเปลี่ยนครั้งนี้มีผลกับตัวภาษาเอง นั่นคือ interpreter, runtime และ standard library
  • มีคนสงสัยว่าไลเซนส์ MIT เรียบง่ายกว่ามาก แล้วทำไมไม่ใช้แบบนั้น
    • มีการย้อนถามว่า ความต่างระหว่าง MIT กับ BSD 3-Clause นั้นเรียบง่ายต่างกันอย่างมีนัยสำคัญจริงหรือไม่ และระหว่าง MIT License กับ BSD 3-Clause License มีความต่างที่มีนัยสำคัญจริงหรือเปล่า