序論：作品はエンジンを含んでいない

ゲームエンジンで作られた作品には、作品の外に置かれた部品がある。エディタである。作品を配布するときエンジンの実行部分は配布物のなかに入るが、その作品をもう一度ビルドし直すために要るエディタは入らない。だから「この作品はまだ動くか」と「この作品はまだ作り直せるか」は別の問いになり、後者の答えは作品のファイルを見ても分からない。

答えは、エンジンを配っている側の契約書に書いてある。そこで確かめられるのは、二つのことである。ひとつは、いま持っている複製を使い続けてよいと書いてあること。もうひとつは、その複製が手に入り続けることを誰も引き受けていないことである。

以下では、Epic Gamesの『Unreal Engine』とUnity Technologiesの『Unity』の利用条件、アドビによる『Flash Player』の提供終了、そしてピピン・バーの《The Artist Is Present》（2011年）が2022年に別のエンジンで作り直された記録を並べる。読む順は、契約書が何を約束していないかを確かめてから、約束されなかったものを作品の側が自分で肩代わりしている様子を見る、という順である。

1. 「いかなるバージョンも提供し続ける義務を負わない」

Unreal Engineのエンドユーザーライセンス契約は、契約の変更について第8項(a)にこう書く。

If we make changes to this Agreement, you are not required to accept the amended Agreement, and this Agreement will continue to govern your use of any Licensed Technology you already have access to.
（当社が本契約を変更する場合、お客様は修正契約に同意する必要はなく、本契約は、お客様がすでにアクセス可能なライセンス技術の使用に引き続き適用されます。）

続く一文が、その約束の範囲を決めている。

However, if we make changes to this Agreement, you will not be allowed to access certain Epic services or download the Licensed Technology unless you have accepted the amended Agreement.
（ただし、修正契約に同意しない限り、お客様は特定のEpicのサービスにアクセスすること、またはライセンス技術をダウンロードすることができなくなります。）

守られるのは「すでにアクセス可能な」ものであり、新しく取りに行く経路ではない。そして同じ契約書の第18項(a)、見出しは「Support」だが、中身は義務の否認である。

Epic does not have any support obligations with respect to the Licensed Technology under this Agreement. […] Without limiting the foregoing, Epic does not have any obligation to make new versions of the Licensed Technology available, or to continue to make available for access or download any versions of the Licensed Technology.
（Epicは本契約に基づきライセンス技術に関するサポート義務を一切負いません。［中略］前記を制限することなく、Epicは、ライセンス技術の新しいバージョンを提供する義務も、ライセンス技術のいかなるバージョンについても、アクセスまたはダウンロードのために提供し続ける義務も負いません。）

第8項(a)が与えるのは、手元の複製に対する権利である。第18項(a)は、その複製をもう一度手に入れられるかどうかについて、誰も責任を負わないと明言する。二つを並べると、作品を作り直せるかどうかは契約が決めていない——誰がその複製を保管していたかが決める。

この契約書は、配布のかたちも指定している。第4項は、ライセンス技術を組み込んだ製品を配布するとき、「オブジェクトコードでのみ、かつ本製品の分離不能な部分としてのみ組み込まなければならない」（only in object code and only as an inseparable part of the Product）と書く。第5項(a)(i)によれば、エンジンのコードそのものを渡せる相手は、「お客様が配布しているのと同じバージョンのエンジンコードを使用する許諾を当社から個別に受けている第三者」に限られる。つまり動いている作品のなかのエンジンは読めない形で融合しており、読める形のエンジンを誰かに渡すには、その相手が先に同じ版の許諾を持っていなければならない。

2. Unityでは、同じ一文が一度消えていた

Unity Technologiesは、エディタの利用条件の現行版と過去版をGitHubの公開リポジトリで版管理している。コミットは2016年6月28日から2026年6月26日までの14件で、各コミットが「Unity Software Additional Termsを◯年◯月◯日版に更新」という形をとる。ファイルの中身を版ごとに読むと、既得権を認める一文の出入りが日付つきで追える。

2022年10月13日版では、この一文は第6項「Modifications to these Software Terms and Long-Term Supported versions」のなかにある。条件が不利に変わったときは、いま使っている年次版を従前の条件のまま使い続けることを選んでよい、という内容である。

2023年4月3日版では、第6項ごと無くなっている。この版の節見出しは「1. Unity Software Tier Eligibility」「2. Use Rights」「3. Support」「4. Definitions」の四つで、変更に関する節は無い。冒頭の「What's changed」は「とりわけIndustry Offeringに対応するために更新しました。データ収集および条件の変更に関する節を含め、他の節も更新しています」と書く。何を足したかは書かれているが、既得権の一文を落としたとは書かれていない。

この4月3日版が公開リポジトリに反映されたのは、コミットの日付によれば2023年9月20日である。版に記された日付から5か月半後、Unityが利用実績に応じた課金（Runtime Fee）を発表した2023年9月12日の8日後にあたる。

2023年11月6日版で、一文は戻ってくる。しかも第6項ではなく、第1項より前、本文の三行目に置かれる。

Provided that you comply with Tier Eligibility, if Unity updates the Software Terms (the "Updated Terms") impacting your rights, you may elect to continue to use your current version of the Unity Software subject to the prior accepted Software Terms and Terms of Service (the "Prior Terms") unless such Updated Terms are required by law.
（Tier Eligibilityを遵守していることを条件として、Unityが本ソフトウェア条件を更新しお客様の権利に影響を与える場合、お客様は、法令が要求する場合を除き、従前に承諾した条件のもとで現在のバージョンのUnityソフトウェアを使い続けることを選択できます。）

そして今度は「What's changed」がこう書く——「(ii)当社が本エディタソフトウェア条件を更新した場合、お客様がそのバージョンのUnityを使い続けるかぎり、従前に承諾した版の条件にとどまることを選択できると明記するため」。削ったときは書かれず、戻したときは書かれた。

2026年6月30日版でも、この一文は同じ位置にある。文言はほぼそのままで、例示だけが「2022.1から2022.2へ」から「Unity 6からUnity 6.1へ」に更新されている。

日付 出来事 既得権の一文
2022年10月13日版 条件の改訂 第6項にあり
2023年4月3日版 条件の改訂 第6項ごと無し（削除の告知なし）
2023年9月12日 Runtime Feeの発表 —
2023年9月20日 4月3日版が公開リポジトリへ反映 —
2023年11月6日版 条件の改訂 本文冒頭に復活（告知あり）
2024年9月12日 Runtime Feeの撤回 —
2026年6月30日版 条件の改訂 本文冒頭にあり

3. 版を保つことと、条件を保つことは同じ操作である

2023年11月6日版は、Runtime Feeの適用範囲を定義するときに、版と条件を明示的に結びつけた。第2.2節は「2022 LTS、2021 LTS、2020 LTS、またはそれ以前のバージョン（以下「Prior Released Versions」）」を課金の対象外とし、そのうえで例外を置く——対象となる制作物を2024年に出る次のメジャーリリースへ上げた場合はこの限りでない。

エンジンの版を上げる操作は、そのまま条件を上げる操作である。作品を新しい環境で動かすためにエディタを更新すれば、更新後の条件が適用される。動き続けさせることと、当初の条件のまま置いておくことが、同じ一つのつまみで逆向きに動く。

なお、Runtime Fee自体は2024年9月12日にUnityのCEOマット・ブロムバーグが「ゲーム分野の顧客に対するRuntime Feeを即時に撤回する決定をした」と書いて取り下げられている。ここで見ているのは課金の是非ではなく、課金を書くために持ち出された「どの版か」という区分が、そのまま作品を作り直せる条件になっているという構造である。

4. 手元の複製について、条件は一文しか書いていない

現行のUnity Editor Software Terms（2026年6月30日版、全28,931文字）で、archivを含む語は一度しか現れない。

You may make a single copy of the Unity Editor solely for backup or archival purposes.
（お客様は、バックアップまたはアーカイブの目的にのみ、Unityエディタの複製を1部作成することができます。）

preserv（保存）は0回、museumは0回である。エディタを保管してよいという許諾は、この一文だけである。しかも同じ文書のなかで、Unityが与える各種の権利は繰り返し「non-transferable（譲渡不能）」と書かれている。作品を収蔵する機関がこの1部を引き継げるかどうかは、この文書のなかには書かれていない。

供給の側はどうか。Unityは過去版のダウンロードアーカイブを公開しており、2026年9月4日に確認した時点で、系列のタブは「Unity 6／2023／2022／2021／2020／2019／2018／2017／Unity 5」の9つである。最も古い項目はUnity 5.0.0f4、公開日2015年2月25日で、それ以前のUnity 4やUnity 3の項目は無い。11年半ぶんは自発的に置かれており、それより前は置かれていない。Unity 4で作られた作品をいま作り直そうとする人が、Unityから受け取れるものは無い。

これは義務違反ではない。Unreal Engineの第18項(a)が明文で否認しているものを、Unityは書かないまま任意に供給している、というだけである。任意である以上、いつ止まるかは供給側が決める。

5. 手元の複製そのものが止められた例

「すでにアクセス可能なもの」への権利は、複製が動き続けることまでは含まない。アドビの『Flash Player』が、その実例である。

アドビの提供終了に関する案内（2021年1月13日更新）は、質問と回答の形で書かれている。

Will Adobe make previous versions of Adobe Flash Player available for download after 2020?
No. Adobe has removed Flash Player download pages from its site. Adobe blocked Flash content from running in Flash Player beginning January 12, 2021.
（2020年以降、アドビはFlash Playerの過去のバージョンをダウンロードできるようにしますか。いいえ。アドビは自社サイトからFlash Playerのダウンロードページを削除しました。アドビは2021年1月12日から、Flash PlayerのなかでFlashコンテンツが動くことをブロックしています。）

二つのことが書かれている。一つは、過去版を配らないこと。もう一つは、すでに各人の機械に入っている複製のなかで、コンテンツの実行を止めたことである。Unreal Engineの第8項(a)が守ると書いた「すでにアクセス可能なもの」は、ここでは供給側の操作によって動かなくなった。手元にある、という状態は、動く、という状態と同じではない。

6. 作品の側は、否認された供給を自分で引き受けた

ピピン・バーの《The Artist Is Present》は2011年9月14日に公開された。マリーナ・アブラモヴィッチが2010年にニューヨーク近代美術館で行った同名のパフォーマンスを、シエラ社のアドベンチャーゲームの見た目で作り直した作品で、鑑賞者は行列に並び、順番を待ち、椅子に座って作家の目を見る。作家自身の記述によれば、原作は「ActionScript 3で、FlashBuilder 4.5と、優れたFlixelライブラリを使って書かれた」。

2022年、バーはこれをJavaScriptのライブラリ『Phaser 3』へ移した。作品ページの副題は「The Artist Is Present. Again.」である。

移し替えの実務は、作家自身の制作日誌に残っている。2022年5月5日の記述は、着手の理由をこう書く——「Flashが逝ってしまったいま、現代のブラウザで動くように、2011年の古いゲームを移植しているだけ」。同じ日、彼は出発点も書いている。移植の土台にしたのは2011年の原作のコードではなく、後年の別作品《The Artist is Present 2》のコードと素材である。「不要な場面（アパートと車）を削ったあと核が残ったが、要となる入れ替えは、プレイヤーをマリーナ以外の人物にすることだった」。

そして、原作の再現をどこで諦めたかも書かれている。2022年6月29日の記述である。

The collision approaches and APIs for the old version and the new version feel too distant from one another to just slavishly reproduce the original code. As such I've been trying to make a "reasonable" version of queueing and moving through the world and it's hard.
（古い版と新しい版とで、衝突判定の考え方とAPIが互いに離れすぎていて、元のコードをそのまま忠実に再現するというわけにはいかない。そこで、行列に並んで世界を移動することの「それらしい」版を作ろうとしているのだが、これが難しい。）

作品の中心にあるのは行列である。その行列の挙動が、原作の再現ではなく「それらしい」再構成になったことを、作家が自分で書き残している。5月5日の記述には、原作にあった行列のささやきについて「移植には入らない」とも書かれている。

作り直された版が、供給されないものをどう扱ったかは、公開されているリポジトリのファイルを数えれば分かる。2026年9月4日に取得した内容は次のとおりである。

  • リポジトリの作成は2022年5月3日、コミットは51件、そのすべてが2022年である。2011年の制作の履歴はここには無い。
  • 2011年のActionScriptのソースはflash-builder/src/に16ファイル・95,880バイトが置かれている。これらが最初にコミットされたのも2022年である。
  • 2022年のバー自身のJavaScriptは、js/直下からjs/scenes/までで24ファイル・86,763バイト。
  • エンジンはjs/libraries/に3ファイル・7,071,647バイトが同梱されている。index.htmlが実際に読み込むのはそのうちphaser.min.jsの1,042,822バイトである。
  • 原作の.swfは、リポジトリのリリース資産として保管されている。TheArtistIsPresent.swfが119,868バイト、全画面版が210,676バイト、いずれも2022年6月17日にアップロードされている。動かす手段は無くなっているが、ファイルは残されている。

読み込まれるエンジンの1,042,822バイトは、作家自身が書いたJavaScript全部の12倍にあたる。エンジンは作品の外にある部品ではなく、作品のリポジトリのなかに置かれた複製になっている。

graph TD
    A["《The Artist Is Present》2011年版"] --> B["Flixel（.swfにコンパイル済み・作品の中）"]
    A --> C["Flash Player（各人の機械の中・作品の外）"]
    C --> D["2021年1月12日 アドビがコンテンツの実行をブロック"]
    E["《The Artist Is Present》2022年版"] --> F["phaser.min.js 1,042,822バイト（リポジトリの中）"]
    E --> G["ウェブブラウザ（各人の機械の中・作品の外）"]

7. この図式に収まらないもの——MITライセンスと、それを禁じる規約

供給の義務を否認する契約書だけが選択肢ではない。ゲームエンジン『Godot』のライセンス文は、次の一文で始まる。

Permission is hereby granted, free of charge, to any person obtaining a copy of this software […] to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software […]
（本ソフトウェアの複製を取得するすべての人に対し、無償で、使用・複製・改変・結合・公開・頒布・サブライセンス・販売の権利を含め、制限なく本ソフトウェアを取り扱う許可をここに与える。）

ここでも、誰かが供給し続ける義務は生まれていない。許可の宛先は「複製を取得する人（any person obtaining a copy）」であり、その人に与えられるのは自分でも配ってよいという権利である。MITライセンスが変えているのは供給義務の有無ではなく、誰が複製を保管して配ってよいかという一点である。Unreal Engineが同じ版の許諾を持つ相手にしかエンジンコードを渡させないのに対し、こちらは相手を限定しない。

だから、対立は「保証する側／保証しない側」ではない。三つとも保証はしていない。分かれているのは、供給が止まったときに代わりを務められる人が何人いるか、である。

そして同じ行為が、別の場所では禁じられている。Debianのポリシー第4.13節「Embedded code copies」は、他のパッケージのコードを自分の配布物に同梱することについて、こう書く。

Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way.
（同梱されたパッケージが明示的にそのように使われることを意図している場合を除き、Debianのパッケージはこうした便宜的な複製を使うべきではない。）

理由は脚注に書かれている——同じコードの複製が複数あることは非効率で、静的リンクや共有ライブラリの衝突を起こしやすく、そして「最も重要なことに、重複したコードにおける脆弱性の対処を難しくする」。

保存の側が望むのは、同梱された複製が固定されていることである。運用の側が困るのは、同梱された複製が固定されていることである。同じ性質が、目的によって長所にも短所にもなる。バーのリポジトリに置かれた1,042,822バイトのPhaserは、上流でPhaserがどう変わっても変わらない。だから作品は動き続け、だからその複製には修正が届かない。

8. 消えたのは条項ではなく、説明のほうだった

最後に、この調査のあいだに気づいたことを一つ書く。

Unityが2023年9月12日にRuntime Feeを発表した記事のURLはblog.unity.com/news/plan-pricing-and-packaging-updatesである。2026年9月4日にこのURLを叩くと、302でunity.com/blog/news/plan-pricing-and-packaging-updatesへ送られ、そこから308——恒久的な移動——で/blog/unity-is-canceling-the-runtime-feeへ送られる。発表の記事があった場所に、いま置かれているのは1年後の撤回の記事である。発表の本文は、そのURLでは読めない。

いっぽう、その発表に対応して条項が消え、また戻った経過は、GitHubのコミット履歴に日付つきで残っている。バージョン管理された文書のほうが残り、それを説明した散文のほうが残らなかった。誰かが版ごとの複製を置く仕組みを用意していた文書だけが、あとから読める。

9. 考察：ベンダリング

ここまでに出てきた操作には、ソフトウェア工学に既存の名前がある。ベンダリング（vendoring）——外部の依存物の複製を自分の配布物やリポジトリのなかに取り込み、上流がそれを提供し続けるかどうかに依存しないようにすることである。Go言語の公式リファレンスは、この操作の目的をこう書いている。

Vendoring may be used to allow interoperation with older versions of Go, or to ensure that all files used for a build are stored in a single file tree.
（ベンダリングは、Goの古いバージョンとの相互運用を可能にするため、またはビルドに使われるすべてのファイルが単一のファイルツリーに格納されていることを保証するために使うことができる。）

「ビルドに使われるすべてのファイルが単一のファイルツリーにある」ことは、そのまま作品を作り直せる条件である。そして本稿で見たのは、この操作が三つの異なる立場から現れることである。

  • 作家が自分で行う——バーは、Phaserを自分のリポジトリに置き、動かなくなった.swfをリリース資産として残し、2011年のActionScriptを2022年になって初めてコミットした。
  • 契約が要求する——Unreal Engineの第4項は、配布する製品にエンジンを「オブジェクトコードでのみ、分離不能な部分として」組み込むことを求める。作品はエンジンの複製を、読めない形で抱えることになる。
  • 配布の規約が禁じる——Debianのポリシー第4.13節は、同じ行為を、重複したコードの脆弱性対処が難しくなることを理由に避けるべきものとする。

そしてベンダリングできないものが残る。エディタはできない（複製は1部だけ、譲渡は不能）。ブラウザとOSはできない。Flash Playerはできなかった。作品が自分のなかへ引き入れられなかった部分が、そのまま「作り直せるかどうか」の残余になる。

《The Artist Is Present》が2022年に失ったのは、Flixelでもなければ.swfでもない。それらはリポジトリのなかに複製として残っている。失われたのは、原作の行列の挙動——バーが「そのまま忠実に再現するというわけにはいかない」と書いた部分である。引き入れられたのはファイルであり、引き入れられなかったのは、そのファイルが特定の実行環境の上で見せていた振る舞いだった。

検証できなかったこと・確信度の低い箇所（レビュー用）

  • Unityの2023年9月12日の発表本文は、URLが撤回記事へ恒久リダイレクトしているため読めていない。発表日と発表内容の要旨は、2023年11月6日版の条件がRuntime Feeに言及していること、および2024年9月12日の撤回記事の記述から組み立てた。発表本文からの直接引用は本稿には無い。
  • 「Unity Editor Software Termsには供給の継続に関する規定が無い」という否定形の主張は、GitHubの公開リポジトリにあるUnity Software Additional Terms.mdの各版のみを読んで述べている。別文書であるUnity Terms of Serviceは読んでいないので、そちらに免責がある可能性は残る。
  • Unityのダウンロードアーカイブに「Unity 5より前が無い」ことは、2026年9月4日にブラウザで系列タブと最古項目を確認した結果である。別の経路（直接のダウンロードURLなど）で古い版が取得できるかどうかは確かめていない。
  • 《The Artist Is Present》の2022年版が原作からどれだけ離れたかについては、作家自身の記述と両版のファイル構成のみを根拠にしている。2011年の.swfを実際に動かして比較してはいない。
  • ピピン・バーの制作日誌のうち「移植には入らない」とされた行列のささやきについては、2022年5月5日の一文しか確認できていない。最終的にどう扱われたかは、公開されているコードを読んで確かめてはいない。

参考文献