KisakCODがHacker Newsで注目、しかしオープンなCall of Dutyコードには新たなリスクも

KisakCODがHacker Newsで注目を集めた。その主張は印象的だ。プロプライエタリな出自を持つCall of Duty 4のマルチプレイヤーを、オープンかつコンパイル可能なコードとして再構築するという。調査時点でプロジェクトには640件のコミットがあり、使い捨ての技術デモではなく、継続的なエンジニアリングが行われていることをうかがわせる。しかし公開されたコードは、保存、セキュリティ、ライセンス、制御をめぐる、より難しい対立も露わにしている。

KisakCODリポジトリでは、このソフトウェアをMOD開発者とCall of Duty 4愛好者向けの、完全にビルド可能なオープンソース再実装と説明している。マルチプレイヤー、専用サーバー、シングルプレイヤーのビルドターゲットが含まれる。これらを実行するには、正規のCall of Duty 4インストールから取得したゲームファイルが依然として必要だ。

この区別によって、KisakCODは無料の代替ゲームとは一線を画す。実行技術を再構築する一方で、Activisionの商用アセットはリポジトリの外に置かれている。この手法により、開発者は従来のMODツールより深いアクセスを得られるが、元のソフトウェアをめぐる権利所有の問題が解消されるわけではない。

このプロジェクトには、発売から約20年になるゲームで知られているエクスプロイトについての直接的な警告もある。メンテナーは、バイナリの悪用を排除できないとして、オンラインプレイをサンドボックス化するよう推奨している。オープン開発は修正を後押しできる一方、読み取り可能なコードは、古いネットワーク挙動の詳細な地図を攻撃者に与える可能性もある。

これが注目の背景にある中心的な緊張関係だ。KisakCODはクラシックなマルチプレイヤーシステムをコミュニティで維持する可能性を示す一方、通常のMODがめったに直面しない法的・セキュリティ上の不確実性も引き継いでいる。

KisakCODがHacker Newsで注目された理由

KisakCODは、古い商用実行ファイルを、愛好者がコンパイル、調査、改変できる開発基盤へと変える。

このプロジェクトは、記事ブリーフにリンクされたHacker Newsの議論に登場した。提供されたスナップショットでは、この投稿は33ポイントと3件のコメントを記録していた。フロントページとしては控えめな数字だが、この話題はソフトウェア保存とリバースエンジニアリングに対するHacker Newsの長年の関心に合致する。

リポジトリが提供するのは、抽出されたスクリプトやActivisionの実行ファイルを包むランチャーだけではない。ソースツリーには、エンジンシステム、ゲームロジック、スクリプト、依存関係、CMake設定が含まれる。開発者は複数のビルド種別に対応したVisual Studioプロジェクトを生成できる。

現在のビルド手順では、Windows、Visual Studio 2022、CMake 3.16以降、そしてMicrosoftの旧DirectX SDKが必要となる。SteamとCall of Duty 4のコピーも必要だ。ユーザーは元のゲームファイルと複数のランタイムライブラリを、生成されたビルドディレクトリへコピーしなければならない。

これらの要件は、実際に何が変わったのかを示している。KisakCODは、Call of Duty 4の完全な代替品を単体ダウンロードとして配布するものではない。プレイヤーがすでに所有している必要があるファイルに依存する、再ビルド可能な実装を提供する。

このアーキテクチャはMOD開発者にとって重要だ。従来の改造は通常、元のゲームが公開したインターフェースの範囲で動作する。ソースレベルの再実装であれば、貢献者はより下位のエンジン層を変更し、障害を追跡し、診断機能を追加し、システムを他のプラットフォームへ移植できる。

開発者によれば、作業は2025年3月4日ごろに始まり、Availと「Destructive Interface」とされる2人の協力者が参加した。2026年8月までに、公開リポジトリには数百件のコミットと数十件のフォークが表示されていた。この経緯から、Hacker Newsへの登場はプロジェクトの開始日ではなく、発見の契機だったといえる。

KisakCODは同じグループによる先行プロジェクトにも続くものだ。Kisak-Strikeは改変可能なCounter-Strike: Global Offensiveのコードベースに焦点を当て、kisak-thugはTony Hawk's Undergroundを対象としていた。開発者はKisakCODを、最初は空のソースツリーから完成させた同グループ初の逆コンパイルプロジェクトだと説明している。

逆コンパイルは、機械命令を人間が読めるソースコードの近似形へ変換する。元のコメントや命名の選択、すべての高水準構造を自動的に再現するものではない。開発者は不完全な出力を解釈し、型を復元し、ファイルを再構築し、コンパイル済みゲームと挙動を比較して検証する必要がある。

逆コンパイルと単なる逆アセンブルの違いは、このプロジェクトの魅力を説明する一助となる。逆アセンブルでは低水準のプロセッサ命令を確認できる。KisakCODは、開発者がビルド、デバッグ、変更できる保守可能なCおよびC++の生成を目指している。

GPL-3.0ライセンスにより、コピーレフト条件の下での改変と再配布が認められている。ただし、再構築されたコードにライセンスを付与しても、元のゲームに関連するあらゆる権利が独立して解決されるわけではない。この未解決の境界は、プロジェクトの貢献者や認知度が高まるほど重要になる。

デバッグシンボルが再実装を可能にした

KisakCODが存在するのは、非常に詳細な開発アーティファクトによって、途方もないリバースエンジニアリングの課題が、厳しいながらも管理可能なものへと絞り込まれたためだ。

プロジェクトの開発記録によると、Call of Dutyのリリースには広範なデバッグ情報が残されていた。この資料には、少なくとも2つのWindows Program Databaseファイル、6つのXbox 360 PDBまたはmapファイル、そしてELFシンボルを含むMacintoshバイナリが含まれていた。

PDBファイルは、開発者がコンパイル済みWindowsソフトウェアをデバッグする際に役立つ情報を格納する。ビルドによっては、関数名、ローカル変数、ファイルパス、型、ソース構成が明らかになる。mapファイルは、コンパイル済み関数をオブジェクトファイルおよびアドレスに対応付けられる。

これらのアーティファクトが元のソースコードを提供するわけではない。しかし、通常は情報が削ぎ落とされた製品版バイナリが隠しているラベルや構造上の手掛かりを復元する。この利点により、再構築時に必要となる手探りの推論は減少した。

あるWindowsビルドには、名前付きローカル変数とアサーションが含まれていたとされる。アサーションは、テスト中に無効なプログラム状態を検出するために開発者が挿入するチェックだ。そのメッセージからは、内部ファイルパス、想定値、開発者が意図した制御フローが明らかになることがある。

Xbox 360のmapファイルは、もう一つ重要な層を提供した。開発記録によると、特定のコンパイル済みオブジェクトファイルにどの関数が属しているかを特定できた。チームはこれらの対応関係を用いて、もっともらしいソースディレクトリとファイルレイアウトを再現した。

それでも再構築には相当な手作業が必要だった。初期段階では、開発者はリバースエンジニアリングアプリケーションIDAが生成した関数群を処理するため、IDAPythonスクリプトを使用した。その後、誤った出力を取り除き、定義を復元し、ファイルごとにコンパイルエラーを修正した。

チームはこの工程を複数の段階に分けた。まず推定されるソース構造をマッピングし、次に再構築した関数でファイルを埋めた。後続の工程では、型エラー、コンパイラ失敗、リンカー問題、ランタイムの不具合に対処した。

このワークフローは、デバッグシンボルが工程を自動化しなかった理由を説明する。逆コンパイルされた出力は、データ型、関数シグネチャ、構造体レイアウト、コンパイラ最適化を誤認することがある。たった一つの誤った仮定でも、ビルドには成功するが正しく動作しないプログラムが生まれうる。

あるバグは、Booleanの戻り値を完全な整数として扱ったことに起因した。別の問題では、逆コンパイラが導入したキャスト不足が関係していた。チームはさらに、レンダリングの失敗、不正なライティング、壊れたラグドール、物理演算エラー、データベース読み込みの障害、チーム選択時のクラッシュにも遭遇した。

Call of Duty 4のエンジン系統は、追加の参照点を提供した。開発者はフレームワークの一部に、公開されているJedi Academyコードを参照したという。ただし、同コードをCall of Dutyビルドへ改造したのではなく、空のファイルからKisakCODを始めたとしている。

プロジェクトはサードパーティーコンポーネントとの整合も取る必要があった。Call of Duty 4は物理演算に、Open Dynamics Engineの改変版を使用している。チームはゲームの挙動を旧版ODEリリースと比較し、その後Infinity Wardが加えたとみられる変更を復元した。

オーディオと映像は別種の問題を生んだ。Call of Duty 4はRAD Game ToolsのプロプライエタリなBinkおよびMiles技術を使っていた。チームは互換性のある開発コンポーネントを探し、報道によればMiles 7.2eを中心にオーディオ再構築を適応させた。

これらの依存関係は、「オープンソースのCall of Duty」という単純な呼称を複雑にする。再構築されたエンジンコードは、商用アセット、歴史的なSDK要件、プロプライエタリなランタイム部品と並存している。リポジトリはプログラムの多くを公開できても、すべての依存関係を個別に自由なものにはできない。

それでもこの手法は重要だ。デバッグシンボル、クロスプラットフォームビルド、参照エンジン、繰り返しのテストにより、機械コードから動作するマルチプレイヤークライアントへ至る道筋が生まれた。忘れられた開発アーティファクトが、保存活動が理論にとどまるか実行可能なものとなるかを左右しうることを示している。

オープンなCall of Dutyコードがクローズドエンジンモデルに圧力をかける

主な対立は、コミュニティによる保存と、本来の開発サイクルを超えて存続したマルチプレイヤーエンジンに対するパブリッシャーの統制との間にある。

Call of Duty 4は2007年に、MODサポートと専用サーバーソフトウェアを備えて登場した。そのGSCゲームプレイスクリプトは、コミュニティがカスタムモードや野心的な変換を作るのに十分アクセスしやすかった。後にProModは、より速い移動と厳格なゲームプレイ選択を軸に競技マルチプレイヤーを洗練させた。

これらのツールはプレイヤーに相当な自由を与えたが、エンジン自体はクローズドなままだった。MOD制作者は、すべてのレンダラー、ネットワーク機能、物理演算パスを自由に調査することなく、公開されたスクリプティングおよびアセットシステムを通じて作業できた。KisakCODはこの技術的な上限を取り払おうとしている。

圧力は直接的な商業競争から来るものではない。KisakCODには依然として元のコピーが必要で、現在のCall of Duty市場ではなく愛好者を対象にしている。その挑戦は構造的なものだ。コミュニティは、パブリッシャーを待たずにエンジン変更を提案できるようになる。

この能力が最も重要になるのは、公式メンテナンスが鈍化した後だ。従来のMODでは、サポート対象インターフェースの下に埋もれた脆弱性やアーキテクチャ上の制約を常に修正できるとは限らない。ビルド可能なコードベースなら、メンテナーはネットワークパケットからサーバー、ゲームシステムまでのデータを追跡できる。

これは、元のパブリッシャーが優先しなかったプラットフォーム対応も支える。あるコミュニティ開発者は、ウィンドウ処理と入力にSDL3を使ったArmベースmacOS移植を試していると報告した。この取り組みでは、32ビットポインタに結び付いたfast fileの読み込み前提を修正する必要があった。

fast fileは、メモリに読み込まれ、実行時に修復されるパッケージ化されたゲームデータベースだ。シリアライズされたポインタとアーキテクチャ固有のレイアウトは、エンジンを元の32ビット環境の外へ移す際の障害となる。ソースへのアクセスにより、こうした前提は置き換え可能なほど可視化される。

移植に成功すれば、単に対応OSが一つ増えるだけではない。KisakCODが、最初の再構築で使用された限定的なツールチェーンから独立したかを試すことになる。移植性は、このプロジェクトが保守可能なソフトウェアを生み出したかどうかを測る最も明確な指標の一つだ。

同じ原則はマルチプレイヤー基盤にも当てはまる。専用サーバーの運用者は、接続処理、認証経路、性能ボトルネック、サーバールールを調査できる。MOD制作者は、望む変更がネイティブなエンジン挙動に依存する場合、スクリプティング層より下で作業できる。

パブリッシャーによる管理は依然として重要だ。ActivisionはCall of Dutyフランチャイズと保護対象となるゲーム素材を所有している。Microsoftは2023年にActivision Blizzardを買収し、主要な開発者・ゲームプラットフォームも運営する同社の下にカタログの管理責任を置いた。

KisakCODは、MicrosoftやActivisionが認可したソース公開ではない。そのGPLライセンスはリポジトリの保守者によるものであり、Call of Duty 4のエンジンを公開するという原パブリッシャーの公的な決定によるものではない。

この違いにより、KisakCODは所有者が意図的にソースコードを公開したゲームとは区別される。公式リリースでは、どのコードがライセンス対象なのかを定められ、除外される商標、アセット、ミドルウェア、ネットワークサービスについても明確にできる。リバースエンジニアリングされたリポジトリでは、同等の認可なしにそれらの境界を確立しなければならない。

それでも、このプロジェクトはクローズドな保存戦略の実務的な弱点を示している。プレイヤーは古いゲームのコピーを合法的に保持できても、互換性のあるOS、サーバー、ドライバー、セキュリティサポートを失う可能性がある。ディスクやダウンロード版を所有していても、機能するマルチプレイヤー環境が保証されるわけではない。

KisakCODは、ソースレベルの保守によってその失敗に対応する。パブリッシャーのモデルは中央集権的な所有権を守り、保存モデルは技術的なコントロールを分散させる。老朽化したプロプライエタリゲームが抱えるすべての問題を、どちらの側も解決するわけではない。

プロジェクトの影響は、Hacker Newsでの注目度よりも、コントリビューターの振る舞いに左右される。慎重な移植、テスト、脆弱性修正は、保存の意義を裏付ける。一方で、無秩序な再配布や安全でない公開サーバーは、この手法への反論を強めるだろう。

セキュリティと所有権をめぐる問題は未解決のまま

読みやすいソースコードは防御側によるCall of Duty 4の修正を助けうるが、KisakCODはオンラインプレイが安全であることも、法的に争いがないことも確立していない。

このリポジトリには、異例なほど直接的なセキュリティ注意書きがある。Call of Duty 4は既知のエクスプロイトを抱える古いゲームであり、オンラインでバイナリを悪用される可能性がゼロではないと警告している。保守者は、追加の隔離策としてサンドボックスの利用を提案している。

この警告は、愛好家がプロジェクトを評価する際の基準となるべきだ。ビルドに成功したことは、堅牢化されたマルチプレイヤークライアントと同義ではない。互換性テストは期待される機能が動くかを問うのに対し、セキュリティテストは悪意ある入力に対してプログラムがどう振る舞うかを問う。

古いネットワークコードは、多くの場合、現在とは大きく異なる脅威環境を前提にしている。境界チェック、パケット解析、認証、依存関係の読み込み、メモリ管理はいずれも精査に値する。再構築されたコードには、小売版の実行ファイルにはなかった不具合が入り込むこともある。

オープンな開発は、その精査に利点をもたらす。コントリビューターは、テスト中に無効なメモリアクセスを検出するコンパイラ機能であるAddressSanitizerを追加できる。開発アカウントによれば、チームはクラッシュやメモリ破損の挙動を調査する際にこれを使用したという。

防御側は脆弱な経路を調べ、リグレッションテストを作成し、パッチを公開でレビューできる。サーバー運営者はビルドを比較し、個々のコード変更を追跡できる。こうした利点は、クローズドな実行ファイルから得られる限定的な可観測性を上回る。

攻撃者も同じ可視性を得る。関連するすべての関数を自力で再構築しなくても、未検証の入力や脆い前提を特定できる。したがって公開ソースは、脆弱性の発見と悪用の双方における経済性を変える。

その均衡は保守の質に依存する。対応の速いプロジェクトなら、開示をパッチやより安全なデフォルト設定へと結び付けられる。人員の限られたプロジェクトでは、発見された弱点を塞ぐよりも速く攻撃対象領域を公開してしまう可能性がある。

レビュー時点で、このリポジトリには23件の未解決issueがあり、表示された未処理のpull requestはなかった。このスナップショットはコード品質を測るものではなく、issue数は頻繁に変動する。ただし、KisakCODが完成済みの互換性レイヤーではなく、現在も進行中のエンジニアリングプロジェクトであることは示している。

ライセンスは別の不確実性を生む。このリポジトリはコードをGPL-3.0としている。通常これは、指定条件の下で受領者に対象コードの使用、研究、改変、再配布を認めるものだ。しかし、リポジトリのライセンスが及ぶのは、それを適用する人物が保有する権利だけである。

リバースエンジニアリングは、特に相互運用性のために必要な場合、状況によっては合法となりうる。Electronic Frontier Foundationが示したリバースエンジニアリングの枠組みでは、著作権、営業秘密、契約、回避禁止、通信に関する法律が関連領域として挙げられている。

EFFは、裁判所が相互運用性のための一部の中間的複製をフェアユースとして認めてきたと指摘する。同時に、結論は事実関係、ライセンス、管轄に左右されることも強調している。KisakCODは、再構築されたすべてのコンポーネントがそのような理屈で保護されると確立する公的な法的判断を受けていない。

したがって、その実装手法が重要になる。クリーンルーム方式の再実装では通常、原作の動作を研究する人々と、文書化された仕様に基づいて代替コードを書く人々を分ける。これに対しKisakCODの公開された開発アカウントは、シンボル、マップファイル、バイナリとの比較を支援として用いた直接的な逆コンパイルを説明している。

その説明だけで適法性が自動的に決まるわけではない。ただし、読者がこのプロジェクトをCall of Duty 4の認可済みオープンソース版として安易に提示すべきではないことを意味する。これは、保守者が選んだライセンスを伴う第三者による再構築だ。

商用ミドルウェアは配布をさらに複雑にする。ビルド手順では外部DLLとオリジナルのゲームファイルが必要になる。これらの要件は、リポジトリが完全な代替品として機能することを防ぐ助けになるが、依存関係を適切に取得・利用する責任はユーザーに残る。

商標とゲームアセットは別個の層を加える。エンジンの挙動が独立して再現されていても、マップ、テクスチャ、サウンド、ストーリーコンテンツ、キャラクターデザイン、Call of Dutyという名称は保護されたままでありうる。コンパイル可能なソースコードが、それらの素材をパブリックドメインにするわけではない。

そのためコントリビューターにとって、出所は機能性と同じくらい重要だ。パッチでは、それが観察、公開済みの参照コード、オリジナル実装、逆コンパイラ出力のいずれに由来するのかを説明すべきである。明確な記録があれば、技術的なレビューが容易になり、新たなコントリビューションをめぐる曖昧さも減る。

ユーザーが直面する判断はより単純だ。実験的なオンラインビルドは信頼できないソフトウェアとして扱い、実用的な範囲で隔離し、互換性が安全性を意味するとは考えないことだ。プロジェクトがセキュリティレビューと修正済み脆弱性の種類を文書化するまでは、公開サーバーには特に注意が必要である。

保存におけるトレードオフから見るKisakCOD

KisakCODは内部の仕組みを公開することで挙動を保存するが、その忠実性は技術的負債とプロプライエタリ素材への依存も保存する。

ゲーム保存は多くの場合、アセットと実行ファイルから始まる。これらの成果物は、互換性レイヤー、仮想マシン、エミュレーターを通じて動作し続けられる。しかし、各手法はOS、プロセッサの挙動、グラフィックスAPI、オンラインサービスに関する前提に依存する。

ソースレベルの再実装は、保存の対象を移す。固定された実行ファイルだけを保存する代わりに、新たな実行ファイルを生成できるだけの理解済みロジックを保存する。開発者はゲームプレイの挙動を保ちながら、時代遅れのインターフェースを置き換えられる。

KisakCODの現時点のWindows要件は、この移行がなお不完全であることを示している。Visual Studio、DirectX SDK、オリジナルのランタイムコンポーネントが、プロジェクトを古いMicrosoftソフトウェア環境につなぎ留めている。コードはオープンだが、完全なビルドチェーンはまだ広範に移植可能ではない。

このプロジェクトはまた、ゼロからモダンなエンジンを設計するのではなく、癖まで再構築する。その選択は、オリジナルのマップやゲームプレイとの互換性を保つ助けになる。一方で、現代のソフトウェアなら捨てるような前提を保持することにもなりうる。

物理演算はそのトレードオフをよく示す。報道によれば、チームはソルバーやアロケーションの挙動を含む、Infinity WardによるOpen Dynamics Engineへの変更を再現する必要があった。すべてを新しい物理スタックに置き換えれば保守は簡単になるかもしれないが、移動、衝突、マルチプレイヤーの同期が変わる可能性がある。

レンダリングも同様の問題を抱える。モダンなグラフィックスレイヤーは移植性を改善できるが、微妙な違いがライティングやアセットの挙動を変える可能性がある。開発履歴には、小さな再構築エラーによって生じた黒いモデル、不正確なライトグリッド、欠落したシェーダー、その他の不具合が記されている。

ネットワーク互換性には、さらに高い精度が求められる。マルチプレイヤーのクライアントとサーバーは、状態、タイミング、メッセージレイアウト、予測について合意していなければならない。よりクリーンな実装でも、オリジナルのプロトコルが期待する挙動を変えれば失敗しうる。

このためKisakCODは、起動するかどうかだけで評価すべきではない。より強い試金石は、独立した開発者がサブシステムを変更しても、無関係な挙動を繰り返し壊さずに済むかどうかだ。文書化、テスト、再現可能なビルド、コードレビューがその結果を決める。

比較可能なプロジェクトには、いくつかの道筋がある。オリジナルのアセットをユーザー自身が用意することを求めながら、ゲームエンジンを再実装するものもある。クリーンルーム開発で挙動を再現するものもある。公式なソース公開はより明確な許可から始まるが、それでも商用ミドルウェアを省くことが多い。

KisakCODは商業的に管理されたエンジンを直接再構築しているため、より定着していない立場にある。その選択は、豊富なデバッグシンボルにも助けられ、忠実性と速度をもたらした。同時に、完全に独立した代替エンジンよりも大きな出所の負担を生んだ。

リポジトリのGPLライセンスは、コントリビューターがその負担を受け入れるなら、共同保守のコモンズを支えうる。対象コードが配布される際、改善はライセンスの下で引き続き利用可能でなければならない。これにより、コミュニティの修正を対応するソースを返さずに私的フォークが取り込むことを防げる。

しかし、ライセンスは健全なコミュニティを保証しない。オープンリポジトリには、パッチをレビューし、範囲を定義し、アーキテクチャを文書化し、セキュリティ報告に対応する保守者が必要だ。その作業がなければ、コードの公開は持続可能なプロジェクトではなく、保存の証拠になる。

Hacker Newsでの注目は、この点で役立つ可能性がある。経験豊富なシステム開発者なら、小規模なチームが見落としたコンパイラ由来のアーティファクト、ネットワークエラー、古いグラフィックス上の前提を見抜けるかもしれない。また、プロジェクトの主張やライセンス選択に対して、より厳しい検証をもたらすこともできる。

最良の結果は、無制限のノスタルジーサーバーが一夜にして現れることではない。Call of Duty 4の所有者が正規のコピーを現代のシステムでも機能させ続けられる、文書化されテスト可能なエンジンになることだ。その目標には、技術的な野心とともに節度が求められる。

Hacker Newsでの注目が次に検証すべきこと

KisakCODが持続的な保存インフラになるのか、それとも印象的だが危険な再構築にとどまるのかを示すシグナルは3つある。

第一のシグナルは、オリジナルの保守者環境の外で再現可能なビルドができることだ。別の開発者がリポジトリをクローンし、正規のゲームファイルを用意し、文書化された手順に従って、一致する機能的なターゲットを生成できるべきである。自動チェックでは、コンパイルと中核的な挙動をカバーする必要がある。

このシグナルは、再現性が個人的な専門知識を移転可能な保守へと変えるため、プロジェクトを強化する。セットアップの失敗が繰り返されれば、KisakCODが意図する利用者にとって完全にビルド可能だという主張は弱まる。

クロスプラットフォームの進展も、この第一のテストに含まれる。報じられたArm macOSでの実験では、fast-fileシステムにおける32ビット前提がすでに明らかになった。独立した移植が動作すれば、コントリビューターがプラットフォーム依存を安全に置き換えられるほどエンジンを理解していることが示される。

第二のシグナルは、公開されたセキュリティプロセスです。このプロジェクトには、明確な報告窓口、既知の脆弱性クラスに対する修正の文書化、そして悪意あるネットワーク入力を想定した回帰テストが必要です。セキュリティアドバイザリでは、継承されたCall of Dutyの欠陥と、再構築時の誤りを区別すべきです。

この点で意義ある進展があれば、オープンな保守体制を支持する根拠が強まります。ソースの公開が、攻撃者の調査コストを下げるだけでなく、防御側を助けることを示せるからです。未修正の報告や、安易に運用される公開サーバーは、その根拠を弱めるでしょう。

既存の警告は責任あるものですが、出発点にすぎません。ユーザーにサンドボックスの利用を勧めることは、リスクを個人へ移転することになります。保存プロジェクトには最終的に、強化されたデフォルト設定と、露出したシステムをどのようにレビューしたかの記録が必要です。

第三のシグナルは、権利保有者とインフラプラットフォームの対応です。MicrosoftまたはActivisionは、このリポジトリを黙認する可能性も、変更を求める可能性も、許容範囲を明確化する可能性も、削除を求める可能性もあります。GitHubも、公開性に影響する法的申し立てを受ける可能性があります。

公開が継続しても、正式な承認を意味するわけではありません。それでも、オリジナルアセット、ミドルウェア、ブランディング、再構築されたコードに関する明確な境界線は、不確実性を減らします。削除要請やリポジトリの大規模な書き換えは、プロジェクトの現在の保存方針を直接的に弱めることになります。

権利保有者の対応と併せて、コントリビューターの来歴にも注意を払うべきです。メンテナーは、再構築した関数の出典を記録し、起源が不明瞭な成果物を拒否することで、自らの立場を強化できます。曖昧な追加は、ライセンス上の主張を評価しにくくするでしょう。

現時点のHacker Newsでの議論は、これらの結果を予測するには規模が小さすぎます。スターやフォークが測るのは関心であって、互換性、安全性、法的な持続可能性ではありません。リポジトリにおける次の技術的マイルストーンのほうが、より確かな証拠をもたらすでしょう。

KisakCODはすでに、古いデバッグ成果物がプロプライエタリなマルチプレイヤーエンジンへの深いアクセスを可能にし得ることを示しています。しかし、そこから生まれたコードが、安全で移植性が高く、制度面でも安定したコミュニティを支えられることまでは示していません。

このプロジェクトに関心を持つ開発者は、まずビルド要件とセキュリティ警告を読み、公開サーバーへ接続する前にissue履歴を確認すべきです。保存活動の支持者は、再現可能な移植、セキュリティ修正、権利保有者の反応を追跡する必要があります。これらのシグナルが、このHacker Newsでの発見がCall of Duty 4のマルチプレイヤーにとって永続的な拠点となるのか、それとも一般プレイヤーにはなお不確実性が大きすぎる注目すべきコードベースにとどまるのかを決めるでしょう。