PHP đang được đề xuất đổi giấy phép sang BSD 3-Clause

• Dự án PHP đang thảo luận một RFC nhằm thống nhất giấy phép riêng của PHP và giấy phép Zend Engine vốn phức tạp, không tương thích thành BSD 3-Clause (giấy phép BSD đã sửa đổi)
• Thời điểm áp dụng giấy phép mới là PHP 9.0; BSD 3-Clause sẽ được phản ánh trên toàn bộ mã nguồn, header và tài liệu, đồng thời các điều khoản đặc thù trước đây và hạn chế liên quan đến thương hiệu sẽ bị loại bỏ
• Được OSI và FSF phê duyệt, tương thích GPL, giúp bảo đảm tính rõ ràng về pháp lý, trong khi quyền của người đóng góp và người dùng vẫn được giữ nguyên như trước
• Để thay đổi giấy phép, cần có sự đồng ý chính thức của PHP Group và Perforce Software (trước đây là Zend), sau đó sẽ trải qua quy trình thảo luận cộng đồng trong ít nhất 6 tháng và bỏ phiếu
• Thay đổi này cũng khuyến nghị các dự án bên ngoài như PECL/extension lựa chọn BSD 3-Clause, và không khuyến khích sử dụng “PHP License”

---

Tổng quan

• Trong thời gian dài, dự án PHP đã liên tục đối mặt với sự nhầm lẫn và tranh cãi do giấy phép mã nguồn mở riêng và Zend Engine License
• Đặc biệt, Zend Engine License áp dụng cho mã nguồn trong thư mục Zend không phải là giấy phép được OSI phê duyệt, khiến sự phức tạp càng tăng
• RFC này đề xuất một cách đơn giản hóa giấy phép theo hướng thực dụng: vẫn bảo toàn bản quyền của mọi người đóng góp cho PHP, đồng thời trao cho người dùng các quyền giống như giấy phép hiện tại
• Mục tiêu là chọn BSD 3-Clause (giấy phép BSD đã sửa đổi) làm giấy phép chính thức mới, giữ nguyên quyền và điều kiện sử dụng nhưng giảm bớt độ phức tạp và hiểu nhầm

Đề xuất và các thay đổi chính

• Bản chất của vấn đề là công bố phiên bản mới của PHP License và Zend Engine License để chính thức áp dụng Modified BSD License (BSD-3-Clause, được cả OSI/FSF phê duyệt)
• PHP License hiện tại (version 3.01) và Zend Engine License (version 2.00) về cơ bản gần như giống Modified BSD, ngoại trừ một số điều khoản đặc thù, nên không có thay đổi thực chất về quyền hạn
• Sau khi cập nhật giấy phép:
  • Không có thay đổi nào về các quyền được cấp cho người đóng góp và người dùng
  • Phối hợp với PHP Group và Perforce Software để loại bỏ các điều khoản riêng gắn với từng nhóm cụ thể
  • PHP và Zend Engine sẽ được cung cấp theo giấy phép được OSI phê duyệt, tương thích GPL
• Việc sử dụng PHP License cũ và Zend Engine License không còn được khuyến khích
• Tệp LICENSE và các header giấy phép trong mã nguồn cũng sẽ được thay bằng định dạng mới

Tóm tắt nội dung giấy phép

• BSD 3-Clause cho phép tự do sao chép, sửa đổi và phân phối, với điều kiện phải giữ thông báo bản quyền và điều khoản miễn trừ trách nhiệm, đồng thời cấm sử dụng trái phép tên gọi và thương hiệu
• BSD-3-Clause là giấy phép phần mềm tự do được cả OSI (Open Source Initiative) và FSF phê duyệt, đồng thời tương thích GPL

Quy trình thay đổi và phê duyệt

• RFC sẽ được chốt bằng bỏ phiếu sau khi thảo luận công khai trong cộng đồng, và việc áp dụng sẽ được tiến hành sau khi có đồng ý chính thức và bỏ phiếu
• Việc đổi giấy phép cần có sự đồng ý chính thức của PHP Group và Perforce Software
• Quyền của các bên từng đóng góp mã nguồn trước đây vẫn được giữ nguyên, và thay đổi này không xâm phạm các quyền hiện có
• Cộng đồng sẽ có thời gian thảo luận ít nhất 6 tháng trước khi chốt bằng bỏ phiếu
• Thay đổi dự kiến sẽ được phản ánh chính thức trong PHP 9.0

Bối cảnh và lịch sử

• Các phiên bản đầu tiên như PHP 1 và 2 dùng GPL, sau đó phát triển qua giấy phép Apache và giấy phép tùy biến dựa trên BSD
• Zend Engine từng duy trì giấy phép riêng, nhưng hiện nay trên thực tế được xem là một phần không thể tách rời của cùng một dự án
• Các hạn chế về việc sử dụng tên gọi trong giấy phép PHP cũ, cũng như các điều khoản bảo vệ thương hiệu, lâu nay đã liên tục gây ra vấn đề về khả năng tương thích và phân phối với các dự án mã nguồn mở khác

Ảnh hưởng tới mã hiện có, extension và tài liệu

• RFC lần này áp dụng cho toàn bộ php-src (trừ các phần mã có ghi rõ giấy phép riêng), đồng thời khuyến nghị PECL/extension cũng áp dụng BSD 3-Clause
• Ảnh hưởng tới toàn bộ mã trong các kho mã nguồn PHP mới/cũ đang dùng PHP License hoặc Zend Engine License
• Các giấy phép hiện có khác (ví dụ mã dùng giấy phép riêng như timelib) không thuộc phạm vi áp dụng của thay đổi này
• Tài liệu hướng dẫn PHP sẽ tiếp tục giữ giấy phép Creative Commons Attribution 3.0 trở lên
• Các extension module/phần mềm hiện có sẽ được trao quyền lựa chọn áp dụng PHP License v4 (Modified BSD)
• Với extension và dự án mới trong tương lai, khuyến nghị dùng các giấy phép được công nhận như BSD/Apache mới nhất

Kết luận

• Cấu trúc giấy phép của PHP và Zend Engine sẽ được đơn giản hóa thành BSD 3-Clause, qua đó tăng tính rõ ràng, khả năng tương thích, khả năng khai thác thương mại và độ ổn định pháp lý trong hệ sinh thái mã nguồn mở
• Nếu đề xuất này được phê duyệt và áp dụng, người dùng sẽ có thể tự do sử dụng PHP và Zend Engine theo BSD-3-Clause
• Việc áp dụng chính thức sẽ diễn ra sau khi hoàn tất sự đồng thuận của những người đóng góp trong dự án, cộng đồng và các doanh nghiệp chủ chốt, cùng quy trình bỏ phiếu

[GN⁺]

Ý kiến trên Hacker News

• Có người nhắc rằng ngôn ngữ Meta dùng không phải PHP mà là Hack, đồng thời nói thêm rằng việc đóng gói, tài liệu hóa và mức độ sẵn có của Hack đều không tốt lắm; lý do là vì đó không phải phần lộ ra bên ngoài trong nội bộ Meta nên không được phản ánh vào đánh giá thành tích, và còn chỉ ra rằng việc che giấu tri thức nội bộ cũng gắn với bảo đảm việc làm. Về mặt giấy phép, các tập đoàn IT lớn như Meta, Google, Microsoft, Apple đều cấm rất nghiêm ngặt việc sử dụng phần mềm AGPL, vì họ không muốn chấp nhận rủi ro pháp lý do tính mơ hồ của điều khoản “Remote Network Interaction” trong AGPL. Họ còn nói thêm rằng nếu thực sự muốn các tập đoàn lớn hay doanh nghiệp thông thường tuyệt đối không dùng mã của mình thì hãy chọn AGPL. Tham khảo: tài liệu chính sách AGPL của Google
  • Nhấn mạnh rằng nhiều công ty thực tế vẫn dùng phần mềm AGPL trong nội bộ (ví dụ: Grafana, Mastodon, Mattermost...), chỉ là ít dùng hơn cho các dịch vụ phục vụ khách hàng trả phí ở bên ngoài; với tư cách lập trình viên, tôi coi trọng tự do của người dùng phần mềm của mình hơn là nỗi lo thái quá của các tập đoàn khổng lồ
  • Chỉ ra rằng không phải “mọi doanh nghiệp”, mà chỉ những “công ty cung cấp dịch vụ mạng độc quyền bằng phần mềm của tôi” mới bị AGPL tác động; đây chính là ý đồ cốt lõi của AGPL. Họ giải thích rằng ngay cả cơ sở cho chính sách của Google cũng ghi rõ điều này vì Google là nhà cung cấp dịch vụ mạng; phần lớn doanh nghiệp không thuộc lĩnh vực kỹ thuật hầu như không bị ảnh hưởng gì và cũng không cần bận tâm
  • Nếu là startup mã nguồn mở thì để tránh bị các siêu đám mây như AWS chiếm sạch, nên dùng AGPL + giấy phép kép thương mại (kèm CLA chuyển giao quyền sở hữu trí tuệ)
  • Giải thích rằng lý do nhiều tập đoàn lớn dùng phần mềm AGPL là vì có thể triển khai giấy phép kép; tức là vừa quảng bá là mã nguồn mở theo AGPL, vừa có thể thu phí khách hàng doanh nghiệp khi họ dùng theo giấy phép thương mại
  • Gần đây tôi có cảm giác Go đang được dùng rất nhiều, như thể rất nhiều package đã được viết lại bằng Go
• Người viết nói rất thích vì các nội dung liên quan tới giấy phép PHP và lịch sử của nó được tổng hợp gọn ở một nơi mà không có marketing hay nội dung do AI tạo ra
  • Nội dung do AI tạo thật ra không bổ sung thêm thông tin gì, còn những lời thừa thãi thì vốn dĩ đã luôn tồn tại; về bản chất chẳng có gì mới, đó là một nhận xét vui vẻ được bổ sung thêm
• Họ nhớ lại lần đầu tiên trong đời gặp con trỏ ba cấp (zval***) là khi tự học trực tiếp mã nguồn của PHP Zend Engine cách đây 25 năm; sau đó đã làm đủ thứ với PHP, thậm chí thời trung học còn dùng PHP trong môi trường CLI để đi thi lập trình, nhưng vì ban tổ chức lúc đó không quen ngôn ngữ và môi trường này nên đã bị loại trong một trải nghiệm vừa buồn vừa buồn cười. Họ bày tỏ sự biết ơn với những khả năng mà PHP khi đó đã mở ra
  • Có người thấy câu chuyện này thú vị và chia sẻ rằng bản thân từng dùng Perl cho đồ án tốt nghiệp
  • Họ nói rất khó tìm được điểm tựa hợp lý để chấp nhận các con trỏ “trần” ba cấp về mặt logic; ngay cả trước khi bàn đến hiệu năng thì độ phức tạp của tham chiếu gián tiếp ngầm đã rất khó giải thích. Ví dụ những thứ rõ ràng như thành viên của struct thì còn hiểu được, còn việc tự dưng thêm phức tạp như vậy là không hợp lý. Họ nhớ lại một người quen thường nói: “Sao không làm cho đơn giản hơn?”
• Có lo ngại rằng nếu không nhận được sự đồng ý của mọi người đóng góp thì một người đóng góp có ác ý có thể gây rắc rối; ở Mỹ và những nơi khác hoàn toàn có thể có các vụ kiện chỉ nhằm quấy rối ác ý, và ai cũng phải tự bỏ tiền ra ứng phó, nên rốt cuộc hình thành một văn hóa quá chú trọng tới phòng vệ pháp lý. Nhân đó họ cũng nhắc tới giai thoại kinh điển về Richard Stallman, việc PHP dùng GPL và vì thế mà mô hình giấy phép kép bị dừng lại
  • Giải thích rằng nhờ điều khoản “or later”, PHP Group có thể sửa nội dung giấy phép và phát hành phiên bản mới mà không cần xin lại sự đồng ý riêng của từng người đóng góp
  • Chỉ ra rằng tài liệu gốc có nhắc tới giai thoại liên quan giấy phép với Stallman thực ra gần với việc MySQL chuyển sang GPL và ảnh hưởng kéo theo tới giấy phép PHP hơn; họ bày tỏ rằng khó hiểu nếu nói bỏ GPL chỉ vì Stallman không thích
• Có thể xem bối cảnh liên quan tại tài liệu nền về thay đổi giấy phép trên wiki PHP
• Có người khuyên đây là trang rất đáng đọc nếu muốn tích lũy kiến thức chuyên sâu về giấy phép phần mềm và việc sửa đổi giấy phép, đồng thời nhấn mạnh rằng lần thay đổi giấy phép này không phải kiểu tin tức buộc chúng ta phải thay đổi gì hay tái chứng nhận gì cả; cả người đóng góp lẫn người dùng đều không bị ảnh hưởng
  • Có người đùa theo hướng thực tế rằng tin tức kiểu “triển khai mà không có thay đổi lớn” đôi khi lại đi kèm thay đổi cực lớn, lấy ví dụ vụ 787MAX và MCAS
  • Họ giải thích chi tiết rằng nội dung thay đổi thực tế là xóa các câu chữ liên quan tới trademark PHP/Zend và hợp nhất hai dự án vào một giấy phép duy nhất; tức là trước đây nếu muốn dùng các tên “PHP”, “Zend”, “Zend Engine” thì cần các phê duyệt riêng tương ứng, còn giờ được đổi thành áp dụng thống nhất cho tên của chủ sở hữu bản quyền và người đóng góp. Ngoài ra các điều khoản về ghi chú/sửa đổi/chứng nhận/thông báo (mục 4~6) cũng bị xóa cùng lúc
• Có người nêu thắc mắc vì sao trong các văn bản giấy phép, những phần quan trọng lại được viết toàn bộ bằng chữ in hoa (ALL CAPS)
  • Theo pháp luật Mỹ, các điều khoản miễn trừ về bảo hành/trách nhiệm phải mang tính “conspicuous” (dễ nhận thấy), và trong văn bản thường cách dễ nhất để làm nổi bật là viết in hoa
  • Họ nói đây cũng là cách để loại bỏ luôn tranh cãi về chữ hoa/chữ thường; nếu tất cả từ đều viết in hoa thì mọi thứ đều được nhấn mạnh, nên giảm bớt nhầm lẫn
  • Theo các điều khoản của luật thương mại (UCC), nội dung phải được viết sao cho một người hợp lý chắc chắn có thể nhận ra, và một trong các cách là dùng tiêu đề lớn bằng chữ in hoa; vì vậy nếu viết toàn bộ bằng chữ in hoa thì tòa án cũng có thể coi mức độ quan trọng đó là “dễ nhận thấy”
• Có người muốn ai hiểu rõ thay đổi này giải thích theo mức ELI5, và thắc mắc không biết có phải toàn bộ giấy phép của PHP đang được đổi hay không
  • Có người hỏi lại “toàn bộ PHP” chính xác là ý gì, rồi giải thích rằng lần thay đổi này áp dụng cho bản thân ngôn ngữ, tức trình thông dịch và runtime, cùng thư viện chuẩn
• Có người nói giấy phép MIT đơn giản hơn nhiều, và thắc mắc tại sao không dùng nó
  • Có người hỏi ngược lại rằng liệu sự khác biệt giữa MIT và BSD 3 điều khoản có thực sự đơn giản đến mức đáng kể về mặt thực chất hay không, và giữa giấy phép MIT với giấy phép BSD 3 điều khoản có khác biệt ý nghĩa nào đáng kể hay không