ベンダリングとは、外部の依存物の複製を自分の配布物やリポジトリのなかに取り込み、その依存物を上流が提供し続けるかどうかに依存しない状態にすることをいう。本項の造語ではなく、ソフトウェア工学で用いられてきた術語である。Go言語の公式リファレンス『Go Modules Reference』は、この操作の目的を「Goの古いバージョンとの相互運用を可能にするため、またはビルドに使われるすべてのファイルが単一のファイルツリーに格納されていることを保証するため」と書き、go mod vendorコマンドが「主モジュールのルートにvendorという名前のディレクトリを構成し、主モジュール内のパッケージをビルドおよびテストするために必要なすべてのパッケージの複製を格納する」と定義している（Go Modules Reference）。

この語を作品の存続の問題に置くと、次の三つのことが同時に見えるようになる。

第一に、道具を供給し続ける義務は、どの契約書にも書かれていない。Unreal Engineのエンドユーザーライセンス契約は第8項(a)で「本契約は、お客様がすでにアクセス可能なライセンス技術の使用に引き続き適用されます」と約束し、第18項(a)で「Epicは、ライセンス技術のいかなるバージョンについても、アクセスまたはダウンロードのために提供し続ける義務を負いません」と明言する（Unreal Engine EULA）。与えられているのは手元の複製に対する権利であり、複製を新しく取得できることではない。したがって、その道具を使った作品を将来作り直せるかどうかは、権利の問題ではなく在庫の問題になる。

第二に、ベンダリングは選択とはかぎらない。作家が自分の判断で行うこともあれば、契約が要求することもあり、配布の規約が禁じることもある。Unreal Engineの第4項は、配布する製品にエンジンを「オブジェクトコードでのみ、かつ本製品の分離不能な部分としてのみ」組み込むよう求める。逆にDebianのポリシー第4.13節「Embedded code copies」は、同梱された便宜的な複製を使うべきではないとし、その理由の筆頭に「重複したコードにおける脆弱性の対処を難しくする」ことを挙げる（Debian Policy Manual）。取り込まれた複製が上流から切り離されて固定されるという同じ性質が、保存の側では長所に、運用の側では短所になる。

第三に、取り込めないものが残る。エンジンの実行部分は作品に同梱できるが、作品を作り直すためのエディタは同梱できない。ウェブブラウザもOSも同梱できない。作品が自分のなかへ引き入れられなかった部分が、そのまま作品の存続の残余として残る。

ベンダリングと対になる状態は、依存物をその都度、外部から取得して動かすことである（動的リンク、CDNからの読み込み、インストール済みのプラグインへの依存）。どちらを選ぶかは、通常は配布のしやすさと更新のしやすさの比較として語られる。作品の存続という尺度を持ち込むと、この比較は「誰が複製を保管する立場に立てるか」という別の問いに変わる。

事例

《The Artist Is Present》のエンジンの位置が変わった。ピピン・バーが2011年9月14日に公開したこの作品は、マリーナ・アブラモヴィッチが2010年にニューヨーク近代美術館で行った同名のパフォーマンスを、シエラ社のアドベンチャーゲームの見た目で作り直したものである。作家自身の記述によれば、原作はActionScript 3とFlixelライブラリで書かれ、Flash Playerの上で動いた。2022年、バーはこれをJavaScriptのライブラリ『Phaser 3』へ移した（The Artist Is Present — Description）。公開されているリポジトリを2026年9月4日に確認すると、js/libraries/にPhaserのファイルが3つ、計7,071,647バイト置かれており、index.htmlが読み込むphaser.min.jsは1,042,822バイトある。これに対して、バー自身が書いたJavaScriptは24ファイル・86,763バイトである。エンジンは作品の外にある部品ではなく、作品のリポジトリに置かれた複製になっており、その大きさは作家自身のコードの12倍にあたる（the-artist-is-presentリポジトリ）。原作の.swf（119,868バイト）も、動かす手段が無くなったままリリース資産として同じリポジトリに保管されている。

取り込めなかったものが、作り直しの限界になった。バーは制作日誌の2022年6月29日の項に、「古い版と新しい版とで、衝突判定の考え方とAPIが互いに離れすぎていて、元のコードをそのまま忠実に再現するというわけにはいかない。そこで、行列に並んで世界を移動することの『それらしい』版を作ろうとしている」と書いている（Process journal）。行列はこの作品の中心にある。ファイルは複製として引き入れられたが、そのファイルが特定の実行環境の上で見せていた振る舞いは引き入れられなかった。

取り込めなかった層が、供給側の操作で止められた。アドビは提供終了の案内（2021年1月13日更新）で、Flash Playerの過去のバージョンをダウンロードできるようにするかという問いに「いいえ。アドビは自社サイトからFlash Playerのダウンロードページを削除しました」と答え、さらに2021年1月12日からFlash Playerのなかでコンテンツが動くことをブロックしたと書いている（Adobe Flash Player EOL General Information）。すでに各人の機械に入っていた複製も、これによって動かなくなった。手元にあることと動くことは同じではない。

保管を1部だけ許す条項。Unity Technologiesのエディタ利用条件（2026年6月30日版、全28,931文字）で、archivを含む語は一度しか現れない——「お客様は、バックアップまたはアーカイブの目的にのみ、Unityエディタの複製を1部作成することができます」。preservは0回、museumは0回である。同じ文書のなかで、Unityが与える権利は繰り返し「譲渡不能」と書かれている（Unity Editor Software Terms）。供給の側では、Unityの公開するダウンロードアーカイブが2026年9月4日時点でUnity 5.0.0f4（2015年2月25日公開）を最古の項目としており、それ以前の系列は置かれていない（ダウンロードアーカイブ）。

複製を保管してよい人の数を変えるという解き方。ゲームエンジン『Godot』のライセンス文は、「本ソフトウェアの複製を取得するすべての人」に対して、複製・改変・頒布・サブライセンス・販売を含む権利を無償で与える（Godot LICENSE.txt）。ここでも供給し続ける義務は誰にも生じていない。変わっているのは、供給が止まったときに代わりを務められる人が何人いるか、である。これに対しUnreal Engineの第5項(a)(i)は、エンジンのコードを渡せる相手を「お客様が配布しているのと同じバージョンのエンジンコードを使用する許諾を当社から個別に受けている第三者」に限っている。

この概念から立つ問い

  • 作品を収蔵する機関は、何をベンダリングすることになるのか。エディタの複製が1部しか認められず、しかも譲渡できないとき、機関が引き受けられるのは作品のファイルだけなのか。
  • 読めない形で取り込まれた複製は、取り込まれたことになるのか。Unreal Engineが求める「オブジェクトコードでのみ、分離不能な部分として」の同梱は、作品を動かし続ける役には立つが、作品を作り直す役には立たない。
  • ベンダリングされた複製に修正が届かないことを、作品の側はどう扱うのか。固定されていることが保存の条件であり、同時に運用上の欠陥であるとき、両方を満たす扱いはあるのか。