OSS

GitHub Enterprise Server 3.20の主な新機能 GitHub Enterprise Server（GHES）3.20が2026年3月17日に一般提供（GA）を開始した。今回のリリースでは、デプロイの効率性、監視機能、コードセキュリティ、ポリシー管理の各領域で大幅な強化が行われている。 注目すべき新機能として、まずイミュータブルリリースが導入された。GitHubリリースに不変性を付与できるようになり、公開後のリリースアセットの追加・変更・削除をロックし、リリースタグの移動や削除も防止する。これにより、サプライチェーン攻撃から配布アーティファクトを保護できる。また、以前パブリックプレビューだったバックアップサービスがGAとなった。GHES内蔵のマネージドサービスとして、従来のbackup-utilsに代わるバックアップ手段を提供する。なお、backup-utilsはバージョン3.22で廃止予定となっている。 プルリクエストのマージ体験も刷新され、ステータスチェックがステータス別にグループ化（失敗チェックが先頭表示）され、自然順ソートで整理されるようになった。高可用性構成では、プライマリデータノードからCPU集約型タスクをオフロードするための追加ノードをデータセンターに配置できるようになり（パブリックプレビュー）、水平スケーリングが可能となった。さらに、エンタープライズオーナーがエンタープライズチームを作成・管理し、組織横断のガバナンスを簡素化できる機能も追加されている。 Dependabotによるnpmマルウェア検出 同日、Dependabotにnpm依存パッケージのマルウェア検出機能が追加された。有効化すると、DependabotがnpmパッケージをGitHub Advisory Databaseのマルウェアアドバイザリと照合し、既知の悪意あるバージョンへの依存を検出してアラートを発行する。 この機能はオプトイン方式で、リポジトリ・組織・エンタープライズのセキュリティ設定から有効化できる。マルウェアアラートはCVEベースの脆弱性アラートとは別カテゴリとして表示され、トリアージの効率化が図られている。2022年にパブリック・プライベートパッケージの名前衝突による誤検知問題で一度停止されていたが、オプトイン制御やマルウェアバージョンのみのデフォルトアラート、CVEアラートとの明確な分離といった再設計を経て復活した。今後はOpenSSF Malware Streamsプロジェクトとの統合を通じ、npm以外のエコシステムへの対応拡大も予定されている。 CodeQL 2.24.3：Java 26サポートと解析精度の向上 2026年3月10日にリリースされたCodeQL 2.24.3では、Java 26のサポートが追加された。Java解析においてMaven POMファイルからJavaバージョンを自動選択する仕組みが導入され、可能な場合はすべてのMavenプロジェクトでJava 17以上を使用してビルド互換性を向上させる。GHES 3.20自体もCodeQLの強化を多数含んでおり、C/C++リポジトリのビルドなしスキャン（build-mode none）のGA化、全サポート言語でのインクリメンタル解析、Swift 6.2/6.2.1やKotlin 2.2.0x/2.2.2xへの対応などが盛り込まれている。 その他の言語別改善としては、JavaScript/TypeScriptでmobx-reactおよびmobx-react-liteのobserverラップReactコンポーネントのサポート、PythonでAntiSSRFライブラリによるSSRFサニタイゼーションバリアの追加、isSafe(x) == trueやisSafe(x) != falseといったガード条件の自動処理が含まれる。 Actions Runner Controller 0.14.0：マルチラベル対応とオートスケーリング安全性の強化 2026年3月19日にリリースされたActions Runner Controller（ARC）0.14.0では、ランナースケールセットへのマルチラベルサポートが実現した。従来は1スケールセットにつき1ラベルしか設定できず、OS・ハードウェア・ネットワーク構成の組み合わせごとに別のスケールセットが必要だったが、複数ラベルを1つのスケールセットに定義しruns-on宣言で組み合わせて指定できるようになった。 オートスケーリングの安全性も向上し、ランナーが終了コード7で終了した場合にコントローラーがそのランナーセットのオートスケーリングを停止する仕組みが導入された。これにより、新しい構成のロールアウト中に古いランナーがプロビジョニングされるリスクが軽減される。リスナーPodにはデフォルトでkubernetes.io/os: linuxのnodeSelectorが追加され、混合OSクラスターでのWindows Nodeへの誤スケジューリングも防止される。また、actions/scalesetライブラリが唯一のAPIクライアントとして採用され、内部アーキテクチャが整理された。

概要 PHPプロジェクトは、長年にわたって使用されてきた独自の二重ライセンス構造を廃止し、広く認知されたBSD 3条項ライセンス（Modified BSD License）に統一するRFC（Request for Comments）の投票を行っている。Ben Ramseyが主導するこの提案は、2026年4月4日まで投票が続けられており、現時点で賛成49票、反対0票、棄権2票と圧倒的な支持を集めている。採択には3分の2以上の賛成が必要だが、事実上可決は確実な情勢だ。 現行ライセンスの問題点 PHPは現在、コードベースの大部分をカバーするPHP License v3.01と、Zend/ディレクトリに適用されるZend Engine License v2.00という2つの独自ライセンスを使用している。この構造は2006年から続いているが、いくつかの深刻な問題を抱えていた。PHP License v3.01は2020年にOSIのレガシー承認プロセスを通じて承認されたものの、標準的な審査ではなく歴史的使用実績に基づく承認であった。Zend Engine License v2.00に至ってはOSI承認すら存在しない。さらに両ライセンスはGPLと互換性がなく、商用採用の障壁となっていた。Debianがこのライセンス下のPHP拡張機能の配布を拒否する事例も複数発生しており、ディストリビューターやコントリビューターに混乱をもたらしてきた。 なぜBSD 3条項ライセンスなのか RFCの分析によると、現行の両ライセンスから条件4・5・6（PHP GroupやPerforce固有の条項）を除去すると、残る条件1〜3はBSD 3条項ライセンスと同一になる。つまり、ユーザーやコントリビューターの権利を一切変更することなく、OSI承認済みかつGPL互換の標準ライセンスに移行できるという理論的根拠がある。FSF（Free Software Foundation）もBSD 3条項ライセンスをGPL互換の自由ソフトウェアライセンスとして認定しており、これにより他のOSSプロジェクトとの親和性が大幅に向上する。 歴史的経緯 PHPのライセンスの複雑さは、プロジェクトの長い歴史に根差している。PHP 1〜2はGPLv2でライセンスされていたが、PHP 3でGPLv2とApacheスタイルのカスタムライセンスの二重ライセンスに移行。PHP 4以降は、Richard Stallmanとの論争を経て独自のPHP Licenseに切り替えられた。Zend Engineには、共同創設者のAndi Gutmansが「Zend EngineはPHP以外の製品でも使用できるように設計された」と説明したように、スタンドアロンでの商用利用の余地を残すため別個のライセンスが設けられた。しかし25年の歳月を経て「両者は分離できないほど密接に絡み合っている」状態となり、別ライセンスの意義は失われていた。 合意形成と今後の影響 ライセンス変更にあたっては、PHP Groupの全メンバー（Rasmus Lerdorf、Andi Gutmans、Zeev Suraskiら10名）の承認と、Zend Licenseの権利を持つPerforce Software社からの法的な同意書が取得済みである。実装はphp-srcおよびweb-phpのプルリクエストとして既に準備されており、LICENSEファイルの置き換え、ソースファイルヘッダーの更新、ウェブサイトドキュメントの修正が含まれる。既存のPHP License v3.01で公開されている拡張機能は、アップグレード条項に基づき任意でBSD 3条項ライセンスへ移行可能だ。なお、PHPマニュアルはCreative Commons Attribution 3.0のまま変更されない。四半世紀にわたるライセンスの混乱が解消されることで、PHPエコシステム全体の法的明確性と他プロジェクトとの互換性が大きく改善されることが期待される。