AviUtl用外部音声処理拡張編集プラグインのライセンスについて
2025/11/03 追記
VST3 SDK Version 3.8.0 から MIT ライセンスに変更されたため、この記事を読む必要はありません！
使用したいがライセンス問題があり、なるたけ解消のためのお力添えができればと考えたため、書きました。
GPLやSteinberg公式の情報を参考にすべきかとと思い、できる限り公式情報から引っ張ってきたつもりです。
この記事に書いてあることは、個人的解釈による情報が含まれています。
用語
このプログラムは以下の二種類の分類が可能です。それぞれの側面で適切なライセンス形態が違うため、分けて書きます。
拡張編集プラグイン側 (以下「プラグイン側」と記載
patch.aul で拡張編集プラグインとして読む側のプログラム (Win32としてビルドする側)
VSTHost側
拡張編集プラグイン側からexecで呼び出し、プロセス間通信で情報交換をする側のプログラム (x64でビルドする側)
要点
1. AviUtlプラグインのライセンスをGPLにしてよい
いいえ。GPLは動的リンクでも伝播するためAviUtlにGPLが適用され、AviUtlのソースコード開示義務が発生する
2. VST3 SDKを用いることを想定したソースコード(VSTHost側)のライセンスはGPLv3でなければならない
いいえ。GPLライブラリを後からリンクするソフトウェアモジュール部は、GPLと両立する他ライセンスを適用しても良い
3. GPLv3 として VST3 SDK を用いる際、リンクしたバイナリは GPLv3 として頒布しなければならない
はい。また、VST3 SDK ガイドラインに従い、 About などにロゴを表示しなければならない
4. GPLv3 としてバイナリを公開する際に、VST3 SDK は再頒布してはならない
いいえ。再頒布してはならないという条項があるのは「Proprietary Steinberg VST3 License」のみ
5. データ通信のみを行うプラグイン側には VST3 SDK を利用していないため、ソースコードにMITライセンスを適用してもいい
はい。もちろん。
6. プラグイン側には VST3 SDK を利用していないため、バイナリにMITライセンスを適用してもいい
一応可能とは考えられ、そうしなければならないが、法的にはグレーで何とも言い難い。「複雑なデータ構造」「密接な通信」がどこからかが曖昧であるため。ただ、現状よりVSTHostとプラグインをより疎にするための方法はある。
状況
1.
初期公開時の、v0.0.1においては全てにMITライセンスが適用されていました。
2.
人からのアドバイスによってソース全体にGPLv3を適用したようですが、これは悪手です。
GPLは動的リンクによっても伝播するため、プラグインから拡張編集/AviUtlにライセンスが伝播し、AviUtl全体のソースコード開示義務が発生します。(要点1)
私が考えるベストプラクティス
1. ソースコードについて
「全ソースにMITを適用した状態で公開」の状態で問題ないはずです。(要点2, 5)
GPLのライブラリをリンクをしたバイナリにはGPLが適用されますが、リンクされる前のソースコードであればGPLと両立する他ライセンスが適用できるはずです。(要点2)
この文章を読むにあたって、私は各単語を以下のように解釈しています。
プログラム == バイナリ
ソフトウェアモジュール == SDKを省いた状態でのソースコード
つまり、「全ソースにMITを適用した状態で公開」の状態で問題ないということになります。
例として
FFMS2 でも LGPL や GPL な FFmpeg をリンクしますが、ソースコードは MIT ライセンスです。 2. バイナリ頒布について
2.1 とりあえずのバイナリライセンスについて
プラグイン側は VST SDK を用いていないため、バイナリも MIT ライセンスでの頒布が可能です。
VSTHost側は VST SDK を用いているため、自身でビルドしてもらう形で様子を見るのはアリだと思います。
2.2 VSTHost の バイナリ頒布について
VSTHostのバイナリ頒布を可能にしたい場合についてですが、これはそれなりに手間がかかるので可能であればになります。(要点3)
1. こちらに従い、Readmeやプログラム上のAboutメニューにlogoを掲載するよう変更します。
2. いつも通りビルドし、頒布時の zip に VST SDK を含めます。
VST3 SDK は GPLv3 を適用している場合、 VST SDK を含めて再頒布が可能です。(要点4)
再頒布が不可能なのは「Proprietary Steinberg VST3 License」を適用した場合であるはずです。
再頒布不可能条項は以下のように、「Proprietary Steinberg VST3 License」の章として書かれているためです。
a) Proprietary Steinberg VST3 License
The Software Development Kit may not be distributed in parts or its entirety
without prior written agreement by Steinberg Media Technologies GmbH.
ライセンスについて、GPLv3を採用した場合にはソースもGPLv3を適用しなければならないとSteinberg側が書いていますが、これは前述の通りリンクした際にのみGPLv3が伝播するはずです。これは VST SDK を含め zip にまとめた状態に対する記述である可能性が高いです。
VST SDKのURLだけではだめかというと、VST SDK が更新された場合のバージョン不一致によりソースコード開示義務が果たせなくなるため難しそうです。
情報が古すぎです。こちらは2011年8月での記事ですが、2017年3月に公開されたVersion 3.6.7にてライセンス形態が変更されています。
Licensing has changed! Please read the new VST 3 Licensing Issues.
手順 2 以降について、毎回頒布時にzipにpackするのは手間なため、以下の方法を取ることも可能です。
2. 以下のURLのリポジトリをForkします。
Fork するのは、ソースコード開示要求をされた際にVST3 SDKが非公開になっていることを防ぐためです。
非公開にならないだろうと思われる場合は Fork しなくてもいいです。ただし、非公開になった場合にはGPL違反になることを念頭に置いておく必要があります。（実際に L-SMASH Works では FFmpeg などを Fork していません）
3. ForkしたリポジトリのSDKを用いて、VSTHostをビルドします。
4. ビルドしたバイナリに以下の情報を記載したテキストファイルをつけてzipでまとめて頒布します。
利用した VST SDK のリポジトリURLとハッシュ情報
頒布zipにソースコード自体を同梱せずにURLの記載を用いることでもよいというのは以下の条項をHTTPとして解釈すれば可能だと思います。
ハッシュ情報を記載しなければならないのは、バイナリを構成したソースコードをバージョンを明示しておくことで固定する必要があるためです。
ここまでで以下の問題が解消できました
動的リンクでのライセンス伝播問題
VSTHost 頒布時の VST SDK ソースコード同梱問題による GPL 違反
3. プロセス間通信について
これは議論の余地があります。
あるプログラムとそのプラグインが単一の結合されたプログラムと考えられるのはどのようなときですか?(#GPLPlugins)
それはプログラムがどのようにプラグインを呼び出すかに依ります。メイン・プログラムがforkやexecでプラグインを呼び出し、複雑なデータ構造を共有することで密接な通信をしたり、複雑なデータ構造をやりとりする場合、単一の結合されたプログラムとなるでしょう。メイン・プログラムが単純なforkやexecを使ってプラグインを呼び出し、密接な通信を確立しないのであれば、プラグインは別のプログラムと言えるでしょう。
「複雑」や「密接」がどこからどこまでというのは、なんとも言い難いです。(要点6)
「2つのプログラムの『密接さ』を低減する」ためには、個人的に以下のことをしたらよいかと考えたため、一応書き残しておきます。
1.
VSTHostソースは別リポジトリで頒布
プラグイン側はReadmeで「こちらからビルド/DLしてaviutl.exeと同一ディレクトリに導入を」みたいなリンクを貼る
2.
VSTHostプロジェクトからAviUtlの文字を消す
VSTHostのコマンドライン引数にそれぞれのNAME_BASEを指定する方法を取る
VSTHostのReadmeに引数と通信方法についての説明を明記
これにより、
VSTHostは単一プログラムで、プラグイン側と直接的な結合を望んだものではない
プラグイン側では汎用的なVSTHostプラグラムがあったので、プロセス間通信で使用させてもらう
といった大義名分を言い張ることが可能とはなります。
（それがどのような法的効力があるのかは専門家ではないため説明はできませんが）
以上です。
長文にも関わらず、最後まで読んでいただきありがとうございました。
2025/06/24追記
ただのアイデアのみ
拡張編集プラグイン側からVSTという文言を完全に削除
拡張編集プラグイン側のReadmeに以下の情報の記載
データ交換方式
exeをどのディレクトリにおけば良いか
exeの引数仕様
Host側exeは--supported引数により「対応拡張子」情報をstdoutで返すように
拡張編集プラグインは<aviutl.exeのdir>/audio_exeのようなディレクトリ内を探索し、--supported引数で呼び出すことで、リストを構築
こうすることで、拡張編集プラグインは「外部exeをaudio_pluginとして呼び出すプラグイン」として頒布が可能であり、VSTに特定したものではなくなる。以下のものも対応できるようになるかも。
CLAP
AAX
2025/06/25追記
ちょっとした表記揺れと意図が正確に伝わらないと考えた箇所の言い回しの修正を行いました。
昨日、とりあえずのアイデアを記載しただけなのだが、対応が速すぎる。
ありがとうございます。使わせていただきます。