非公式パッチ

非公式パッチは、コミュニティ パッチとも呼ばれ、元の開発者の関与なしにユーザー コミュニティなどの第三者によって作成されたソフトウェアのパッチです。通常のパッチと同様に、バグや欠陥を軽減します。非公式パッチは、 modやクラックなどの他のサードパーティ ソフトウェアの適応とは対照的に、通常、ソフトウェアの意図された使用方法を変更しません。

非公式パッチを作成する一般的な動機は、元のソフトウェア開発者またはプロバイダーによる 技術サポートが不足していることです。理由としては次のようなものが考えられます。

• ソフトウェア製品が定められた寿命に達した^[1]、および/または後継製品に置き換えられた（計画的陳腐化）^[2]
• ソフトウェアは元々大幅に異なる環境で動作するように設計されており、改善/最適化 (移植)が必要になる場合があります。
• 開発者は廃業しており、もう利用できない^[3]
• サポートが経済的に実行可能ではない（例：小規模市場向けのローカライズ）
• 正式な解決策では時間がかかりすぎる場合に、時間的に緊急を要する問題（例：セキュリティホール）を迅速に解決する^{[4] [5] [6]}
• 公式開発者は問題に対処できない^[7]

非公式パッチはファンパッチやコミュニティパッチと呼ばれることもあり、通常は未解決のバグを修復し、新しいオペレーティングシステム、ディスプレイ解像度の向上^{[8] [9]}、新しいディスプレイ形式などの技術的な互換性修正を提供することを目的としています。

非公式パッチはPCプラットフォームで最も一般的ですが、エミュレーションコミュニティなどの文脈ではコンソールゲーム用のパッチも見つかります。^[10]

非公式パッチは技術的な修正に限定されません。ソフトウェア、特にゲームのファン翻訳は、ソフトウェアが現地でリリースされていない場合によく作成されます。 ^{[11]ファン翻訳は、西洋市場向けにローカライズされていないことが多い}日本のロールプレイングゲームで最も一般的です。^{[12] [13]}

非公式パッチの別のバリエーションは、個々のパッチがオンラインでのみ、または小さな増分更新としてのみ利用可能な場合に、公式パッチを組み合わせた スリップストリームのようなパッチです。

最も一般的なケースは、ソフトウェアのソースコードと元の開発ツールが利用できないことです。したがって、問題のあるソフトウェアのバイナリは、リバースエンジニアリングとデバッグによって実行時に分析する必要があります。問題が見つかった場合は、プログラムに修正を適用する必要があります。構成ファイルやレジストリの小さな変更のみが必要な場合もあれば、バグを修正するために実行ファイル自体のバイナリハックが必要な場合もあります。ソフトウェア開発キット（例：改造用）が利用できる場合は、コンテンツの修正を簡単に作成できますが、そうでない場合はコミュニティが独自のツールを作成する必要があります。これらの見つかった修正は通常、ユーザーが展開可能なパッチ（例：NSIS、Innosetupを使用）にパックされます。

ソースコードが利用可能であれば、サポートは最も効果的に提供できます。ソースコードは意図的に公開される場合もあれば^{[14] [15] [16]、}漏洩によって^{[17] [18] [19]}、または手違いによって公開される場合もあります。 ^{[20]たとえば、} Thiefシリーズのゲームエンジンで起こったことです。^{[21] [22]}ファンが元のプログラムバイナリからソースコードを完全にリバースエンジニアリングすることもあります。^{[23]ソースコードが利用可能であれば、}ソースポートを使用して完全に異なるが最近のプラットフォームのサポートも可能になります。

非公式パッチの法的影響を直接扱った裁判例はないが、関連する問題で同様の裁判が行われている。Galoob v. Nintendoの裁判では、ユーザーが許可されていないパッチをシステムに適用することは著作権侵害ではないと判断された（ただし、その範囲はGame Genieに非常に限定されていた）。一方、Micro Star v. FormGen Inc.の裁判では、ユーザーが作成したマップは元のゲームの二次的著作物であると判断された。Sega v. Accoladeの裁判では、第9巡回区控訴裁判所は、リバースエンジニアリングの過程でコピーを作成することは、それが著作権で保護されたコード内の「アイデアと機能的要素」にアクセスする唯一の方法であり、「そのようなアクセスを求める正当な理由がある場合」には、フェアユースであるとの判決を下した。米国の著作権法17 US Code § 117によれば、プログラムのコピーの所有者は、著作権者の許可を得ることなく、 ^[24]「保守または修理」の必要に応じてそれを変更することができる。シカゴのイリノイ大学のダニエル・J・バーンスタイン教授も同様の主張をしている。^[25]

同様のユーザー権利は、欧州の著作権法でも認められている。合法的に入手した著作権保護ソフトウェアの無許可の変更がフェアユースに該当するかどうかという問題は、法律上未解決の領域である。^[26]ヘルブラウン法律事務所の記事では、ファン翻訳の文脈で、改変を加えた完全なゲームの再配布はフェアユースに該当しない可能性が高いが、修正をパッチとして配布することは法的に許容される可能性があると述べている。ただし、この結論は法廷で検証されていない。^[27]

非公式パッチの受け止め方は様々だが、概して著作権者は曖昧な態度をとっている。ソフトウェアが商業的に採算が取れないと見なされた場合、著作権者は非公式パッチを収益源として見なさないため無視する。^{[11] [28]非公式パッチやファン翻訳プロジェクトに対して}停止命令 が出されたケースはまれにある。^{[29] [30]}

著作権者は、ソフトウェアコミュニティのパッチや修正の取り組みを積極的にサポートすることがあり、^[31]ソフトウェアコミュニティが自らソフトウェアサポートを継続できるようにするソフトウェアライセンスの下でソースコードを公開することもあります。 ^{[16] [14] [15] [32] [33] [34]}このようなソフトウェアの例は、後からソースコードが公開された商用ビデオゲームの一覧にあります。

フリーおよびオープンソース ソフトウェア運動は、非公式パッチの根本的な問題、つまり、ソース コードが欠落しているためにバイナリのみで配布されたソフトウェアでユーザーによる自己サポートが制限される問題を解決するために、1980 年代に設立されました。フリーおよびオープンソース ソフトウェアは、配布されたソフトウェアにソース コードの可用性を要求します。これにより、プロプライエタリ ソフトウェアのバイナリのみのユーザーによるパッチ適用に伴う技術的な問題や法的な不確実性が回避されます。

• ファンの労働
• サーバーエミュレーター
• 送信元ポート
• 修理の権利