▲

PHP, 라이선스를 BSD 3-Clause로 변경 제안중

 (wiki.php.net)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • PHP 프로젝트는 기존 복잡하고 비호환적인 PHP 고유 라이선스와 Zend Engine 라이선스를 BSD 3-Clause(수정 BSD 라이선스) 로 일원화하는 RFC를 논의 중임
  • 새 라이선스 적용 시점은 PHP 9.0으로, 소스 코드·헤더·문서 전반에 BSD 3-Clause가 반영되며, 과거의 특수 조항 및 브랜드 관련 제한이 사라짐
  • OSI·FSF 승인, GPL 호환 등 법적 명확성이 확보되고, 기여자 및 사용자 권리는 기존과 동일하게 보장됨
  • 라이선스 변경을 위해 PHP Group, Perforce Software(구 Zend) 의 공식 동의가 필요하며, 커뮤니티 논의 후 6개월 이상 논의 및 투표 절차를 진행함
  • 이 변경은 PECL/확장 등 외부 프로젝트에도 BSD 3-Clause 선택을 권장하며, “PHP 라이선스” 사용은 권장하지 않음

개요

  • PHP 프로젝트는 오랜 기간 자체적인 오픈 소스 라이선스와 Zend Engine License로 인해 혼란과 논란이 지속되었음
  • 특히 Zend 디렉토리의 소스에 적용되는 Zend Engine License는 OSI 승인 라이선스가 아니어서 복잡함을 더함
  • 이 RFC는 모든 PHP 기여자의 저작권을 보존하면서도 사용자에게 기존 라이선스와 동일한 권리를 부여하는 실용적인 라이선스 단순화를 제안
  • BSD 3-Clause(수정 BSD 라이선스) 를 새로운 공식 라이선스로 채택해, 권리·사용 조건은 유지하면서 복잡성과 오해를 줄이는 것이 목표

제안과 주요 변경 사항

  • 문제의 본질은, 새로운 버전의 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(오픈소스 이니셔티브), FSF 모두에서 승인된 자유 소프트웨어 라이선스이자 GPL 호환임

변경 절차 및 승인

  • RFC는 커뮤니티 공개 논의 후 투표로 확정되며, 공식 동의·투표 이후 적용이 진행됨
  • 라이선스 변경은 PHP Group 및 Perforce Software의 공식 동의가 필요함
  • 과거 소스코드 기여자 권리는 그대로 유지되며, 변경이 기존 권한을 침해하지 않음
  • 커뮤니티에 6개월 이상 논의 기간을 부여한 후 투표로 확정함
  • 변경은 PHP 9.0에서 정식 반영 예정

배경 및 역사적 맥락

  • 초창기 PHP 1·2는 GPL, 이후 Apache 라이선스·커스텀 BSD 기반 라이선스를 거쳐 발전함
  • Zend Engine은 별도 라이선스를 유지했으나, 현재는 사실상 분리 불가한 한 프로젝트로 간주됨
  • 기존 PHP 라이선스의 명칭 사용 제한, 브랜드 보호 조항 등은 타 오픈소스와의 호환성과 배포에 지속적으로 문제를 일으켜 왔음

기존 코드, 확장, 문서 영향

  • 이번 RFC는 php-src 전체(별도 라이선스가 명시된 코드는 제외) 에 적용되며, PECL/확장 등도 BSD 3-Clause 채택을 권장함
  • 신규/기존 PHP 소스 리포 내 PHP License나 Zend Engine License 적용 코드 전체에 영향
  • 기존 라이선스(z.B. timelib 등 별도 라이선스 코드)는 해당 변경의 적용 대상 아님
  • PHP 매뉴얼은 Creative Commons Attribution 3.0 이상 라이선스 계속 유지
  • 기존 확장 모듈/소프트웨어는 PHP License v4(Modified BSD) 적용 선택권 부여
  • 향후 확장 및 새 프로젝트에는 최신 BSD/Apache 등 공인 라이선스 사용 권장

결론

  • PHP 및 Zend Engine의 라이선스 구조가 3-clause BSD로 단순화되어 오픈 소스 생태계 내 명확성, 호환성, 상업적 활용, 법적 안정성이 강화될 전망임
  • 본 제안이 승인 및 적용되면, 사용자는 BSD-3-Clause 기준으로 PHP와 Zend Engine을 자유롭게 이용할 수 있음
  • 프로젝트 내 기여자, 커뮤니티, 주요 기업의 동의와 투표 절차가 완료되어 공식적으로 적용 예정임
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • Meta가 사용하는 언어가 PHP가 아니라 Hack임을 알려줌, 그런데 Hack의 패키징과 문서화, 가용성이 별로임을 언급함, 그 이유로는 Meta 내부에서 보이는 부분이 아니라서 성과평가에 반영되지 않기 때문임, 또 내부 지식 은닉이 곧 일자리 보장과 연결됨을 지적함, 그리고 라이선스 측면에서 Meta, Google, Microsoft, Apple 등 대형 IT 기업들은 AGPL 소프트웨어 사용을 엄격하게 금지함, AGPL의 “Remote Network Interaction” 조항의 모호함 때문에 법적 리스크를 감수하지 않으려는 이유임, 만일 대기업이나 일반적인 사업자가 절대 내 코드를 못 쓰길 원한다면 AGPL을 선택하라는 제안을 덧붙임, 참고: Google의 AGPL 정책 문서
    • 많은 회사들이 AGPL 소프트웨어(예: Grafana, Mastodon, Mattermost 등)를 실제로 내부에서 사용함을 강조함, 다만 외부 유료 고객을 위한 서비스로는 사용 빈도가 적음을 언급함, 개발자로서 나는 거대 기업의 과도한 걱정보다는 내 소프트웨어 사용자들의 자유를 더 중요시함을 밝힘
    • ‘모든 사업자’가 아니라, ‘내 소프트웨어로 독점 네트워크 서비스를 제공하는 회사’만 AGPL의 영향을 받음을 지적함, AGPL의 핵심 의도가 바로 이것임을 설명함, 구글의 정책 근거도 이 때문에 네트워크 제공사임을 명확히 적시함, 대부분 비기술 기업에는 아무 영향이 없으며 신경 쓸 필요도 없음을 덧붙임
    • 오픈소스 스타트업이라면 AWS 같은 메가클라우드에 독식당하는 걸 막으려면 AGPL + 커머셜 듀얼 라이선스(지식재산권 이전 CLA 포함)를 권장함
    • 많은 대기업이 AGPL 소프트웨어를 사용하는 이유는 듀얼 라이선스가 가능하기 때문임을 설명함, 즉 AGPL로 오픈소스임을 광고하면서도 커머셜 라이선스로 이용 시 고객사에 유료 과금이 가능함
    • 최근에는 Go를 많이 쓰고 있다는 생각을 했음, 많은 패키지들이 Go로 다시 쓰여진 것 같았다는 인상을 남김
  • PHP 라이선스와 관련된 내용과 그 역사가 마케팅이나 AI 생성된 내용 없이 한 자리에 정리돼 있어서 매우 좋다는 소감을 전함
    • AI 생성 콘텐츠는 사실 추가적인 정보를 주지 않으며, 쓸데없는 말은 원래부터 존재해왔음, 본질적으로 새로울 것이 없다는 유쾌한 의견을 덧붙임
  • 25년 전 PHP Zend Engine의 소스코드를 직접 공부했을 때, 인생 최초로 삼중 포인터(zval***)를 접한 기억을 떠올림, 이후 PHP로 다양한 일들을 해봤으며, 고등학생 시절 프로그래밍 대회에도 CLI 환경에서 PHP를 사용해서 출전했으나, 당시 스탭들이 언어와 환경에 익숙하지 않아 탈락한 웃픈 경험이 있음, 그 당시 PHP가 허락해준 가능성에 감사를 전함
    • 이 이야기를 재미있게 느꼈으며, 본인은 졸업 프로젝트로 Perl을 활용했던 경험을 공유함
    • 삼중 “네이키드” 포인터에 대해 논리적으로 납득할 접점을 찾기 어렵다고 밝힘, 퍼포먼스 이전에 암시적 간접 참조의 복잡함이 설명이 어려움, 예를 들어 struct의 멤버처럼 명확한 것은 이해 가능하나, 괜히 복잡성을 추가하는 것이 비합리적임, “왜 단순하지 않지?”라는 말을 지인이 자주 했다며 회상함
  • 모든 기여자의 동의를 받지 않을 경우 악의적 기여자가 문제를 일으킬 수 있다는 우려가 있음, 미국 등지에서는 악의적으로 괴롭히기 위한 소송도 얼마든지 가능하며, 모두가 본인 비용으로 대응해야 하니 결과적으로 법적 방어에 과도하게 신경 쓰는 문화가 생김을 이야기함, 그리고 사이드로 리처드 스톨만과 PHP의 GPL 사용 및 그로 인해 듀얼라이선스가 중단된 고전적인 일화를 언급함
    • PHP Group은 “or later” 조항 덕분에, 따로 기여자 동의 없이 라이선스 내용을 수정해서 새 버전을 공개할 수 있음을 설명함
    • 스톨만과의 라이선스 관련 일화가 언급된 주자료가 사실은 MySQL의 GPL 전환과 이로 인한 PHP 라이선스 영향에 가깝다는 점을 지적하며, 스톨만이 싫어해서 GPL을 버릴 이유가 납득이 안 감을 표현함
  • 관련 배경은 PHP 위키의 라이선스 변경 배경 문서에서 확인 가능함
  • 소프트웨어 라이선스와 수정에 대한 전문 지식을 쌓고 싶다면 꼭 읽어봐야 할 페이지임을 추천함, 그리고 이번 라이선스 변경이 우리에게 변화나 재인증을 요구하지 않는 뉴스거리임을 강조함, 기여자 및 사용자 모두 영향 없음
    • 큰 변화 없이 진행된다는 뉴스가 실제로 엄청난 변화를 동반했던 787MAX와 MCAS 사태를 예로 들어 현실적 경각심을 유쾌하게 표현함
    • 실제로 변경된 내용은 PHP/Zend 트레이드마크 관련 문구들이 삭제되고, 두 프로젝트를 하나의 라이선스로 통합하는 과정임을 세부적으로 설명함, 즉 “PHP”, “Zend”, “Zend Engine” 명칭을 사용하려면 기존엔 각각의 별도 승인 필요였으나 이제는 저작권자 및 기여자 명칭에 대해 일괄 적용하도록 바뀜, 또 표기·개정·인증·알림 조항(4~6번)도 함께 삭제됨을 조목조목 안내함
  • 왜 라이선스 문건에서 중요한 부분을 전부 대문자(ALL CAPS)로 작성하는지 궁금증을 제기함
    • 미국 법률상 보증/책임 관련 면책 조항은 “conspicuous(눈에 띄는 것)”이 요구됨, 평문에서 가장 쉬운 표시 수단이 대문자임을 설명함
    • 대·소문자 논란 자체를 없애기 위한 방법임을 말함, 모든 단어를 대문자로 쓰면 전부 강조가 되니까 혼동이 줄어듦
    • 상업법(UCC) 조항에 따르면, 합리적인 사람이 반드시 인지할 수 있도록 적혀 있어야 하며, 그 한 가지 방식으로 제목이 크게 대문자인 경우가 있음, 그래서 전체를 대문자로 하면 법원도 그 중요성을 ‘눈에 띄게’ 인식한다고 판단할 수 있음
  • 변화에 대해 잘 아는 사람이 ELI5 수준으로 설명해주길 요청함, PHP 전체 라이선스가 바뀌는 것인지 궁금해함
    • “PHP 전체”가 정확히 무슨 뜻인지 물으며, 이번 변경은 언어 자체, 즉 인터프리터와 런타임, 표준 라이브러리에 적용되는 것임을 설명함
  • MIT 라이선스가 훨씬 간단한데 왜 그걸 사용하지 않는지 궁금함을 밝힘
답변달기