VOICEVOX ENGINE ライセンス変更

[tarepan]

内容

要望概要: VOICEVOX ENGINE のライセンスを LGPL-3 から MIT へ変更可能か検討したい

追記: 暫定まとめ へ議論の内容を暫定的に集約した。

VOICEVOX プロジェクトは傘下レポジトリごとにライセンスが異なる (一覧: #1084)。ENGINE は LGPL-3 + hiho独自 の dual licence であり、この LGPL-3 は MIT や BSD-3 と適合しない。

ところで、VOICEVOX CORE の発展により、ENGINE-CORE 間の機能整理・移植に関する議論が Discord 等で定期的に発生している。機能重複や意味論的な不整合はたしかに存在しており、これらには議論の価値がある。

しかし ENGINE は LGPL-3 であり、MIT/BSD-3 の CORE や OJT-rs とはライセンス非適合である。
現コントリビュータの多くは複数レポジトリに関わっているため、クリーンルーム設計も妥当とは言えない。
ゆえに、ENGINE の現行コードはそもそも CORE や OJT-rs へ移植できない。

また、1 レビュアーとして、自分のコントリビュートが企業等でも自由に使いやすい MIT ライセンスであることは単純に好ましい。

このような背景から、VOICEVOX ENGINE ライセンス変更（LGPL-3/hiho → MIT/hiho）の可否に関する基礎議論を提案します。

（CORE が MIT なのでそうではないと考えていますが）メンテナ方針として「ENGINE は公開義務を必須にしたい」という方針があれば、ライセンス変更はNoGoかと思います。
その辺も踏まえ、機能移植等でライセンス変更が現実的に意味あるものになったこの段階で、ライセンスに関する基礎的な議論をしたいと感じています。

Pros 良くなる点

• コア寄りの移植が可能になる
• 自由度の高いライセンスを求めるユーザー/企業を受け入れ可能になる

Cons 悪くなる点

• （公開義務が無くなる）

実現方法

• コントリビュータへの説明
• コントリビュータからの同意
• ライセンス変更

その他

コントリビュータが2桁人いる OSS のライセンス変更はとにかく時間がかかるため、議論としてはこの段階で始めないと遅くなると思います。

[phenylshima]

softether vpnではライセンスをGPLv2からApacheに変える際，次のような宣誓書を出しているようです．
ここでもこのレベルが可能かどうかはわかりませんが…
https://ja.softether.org/5-download/src/190121_switch_to_apache_license

[qryxip]

（CORE が MIT なのでそうではないと考えていますが）メンテナ方針として「ENGINE は公開義務を必須にしたい」という方針があれば、ライセンス変更はNoGoかと思います。

私の理解だと「公開義務を必須にしたい」というよりは、「フォークしたものはLGPL-3.0 onlyとなり、プロプライエタリと両立しなくなる(incompatible)ようにしたい」という感じだと思います。ただこの辺については、残念ながら、GitHub上での議論は適さないかもしれません。
(私自身の正直な思いで言えば、MITになってほしくはあります)

コントリビュータが2桁人

PRが一個二個の人だと、連絡が取れるか怪しい方が結構いますね… 連絡が取れなかったら最悪clean-roomingすればいけるかも?
(qwertyさんについては、連絡は取れるんじゃないでしょうか。多分)

[qryxip]

個人的な所感としては十分なメリットがあり、よいと思います。デュアルライセンスのままならBridge Pluginは影響を受けませんし。決定権は @Hiroshiba さんにありますが。

問題は数十人の同意ですね… 連絡取れない人に対するclean-rooming処置(外部協力者を募った上で)をする覚悟は実際しておいた方が良いかもしれない…

[tarepan]

Contribution 量目安

Edited lines @2024-02-28T13:30+09:00 by Tarepan

name	add	remove	total
tarepan	27,699	19,466	47165
Hiroshiba	33,482	12,319	45801
aoirint	7,484	3,000	10484
takana-v	5,459	2,502	7961
y-chan	4,882	1,751	6633
sarisia	2,978	521	3499
Patchethium	1,443	1,444	2887
sabonerune	1,879	875	2754
qwerty2501	2,220	308	2528
stmtk1	1,127	1,158	2285
PickledChair	1,469	745	2214
Yosshi999	1,189	551	1740
sevenc-nanashi	398	230	628
buckw6eat	450	198	648
My-MC	678	34	712
whiteball	563	97	660
Segu-g	433	164	597
weweweok	272	189	461
HyodaKazuaki	361	32	393
K-shir0	194	49	243
isnot	191	6	197
siketyan	98	83	181
raa0121	164	7	171
mes51	157	1	158
FujisakiEx	105	0	105
shirowanisan	112	1	113
tantan-tanuki	38	42	80
amamama	63	6	69
Issei0804-ie	59	4	63
oov	46	14	60
ts-klassen	56	3	59
AsPulse	48	4	52
eggplants	38	0	38
qryxip	30	0	30
yamachu	21	2	23
tomoish	9	1	10
yui-tsukuhoshi	10	0	10
Appletigerv	4	2	6
tuna2134	5	1	6
smly	2	1	3
okaits	3	0	3
masinc	1	0	1

[Hiroshiba]

すみません、出るのが遅れました！
一言でいうと、ENGINEをMITライセンス化するのはギリギリOK･･･かも･･･？でも大変そうだし現状だとLGPLが安定かな、という感じです。

そういえばなぜLGPLにしたのかなどを書いていなかったので書こうと思います。

まずLGPLにした背景ですが、VOICEVOX（OSS・製品両方）の発展を守るためです。
基本的に自分の行動はVOICEVOXのミッションの「 VOICEVOX を通じて 音声合成ソフトウェアや音声合成キャラクターをより身近なものにすること」を意識しています。
LGPLにすることで、forkしたコードに公開義務が発生し、仮にforkしたソフトが独自機能を足した場合はVOICEVOXも追従することでミッション達成に近づけると思います。

MITライセンスも検討したのですが、コード公開義務がなくなり、OSSコミュニティや製品を守りづらくなるためやめました。
仮にforkしたソフトウェアがコードを秘匿している状態で有名になった場合、僕たちはVOICEVOXのためにソフトを作っているのか、有名になったそのソフトのために作っているのかわからなくなると思ったためです。
あくまで一方的な貢献がある形ではなく、お互い切磋琢磨できるようにするために、コード公開義務のあるLGPLを選びました。

コアがMITライセンスなのは･･･たしか、どちらかというと意図したものではなかった（本当？）のがそのままになっています。
（このあたり若干あやふやなので間違っているかもしれません）
コアは最初Pythonでのサンプルコードしかなく、そのときにライセンスファイルを置きました。
そのあといろんな方の協力を経て動的ライブラリをリリースしました。

コアだけMITライセンスなことは当時も気づいてたのですが、かなりVOICEVOXの実情に寄ったコードで特異性が高いため、まあ秘匿的にforkされてコミュニティが崩壊することは無いだろうと思い、そのまま今に至ります。
最近はコアにも汎用的なコードが増えていますが、あまり意見は変わりません（コミュニティは崩壊することはなさそうだなと）。

話を戻してエンジンのMITライセンス化ですが、コミュニティを守れるかという視点が論点だと感じています。
なかなか予想が難しいですが、特に意見がなければそのまま念のためLGPLのが安心だけど、MITライセンスにすることでより発展できるのであれば話は別かなと思いました。
ただまあ、正直たぶんどっちのライセンスであってもあまり変わらなそうなのと（要議論かも）、あと許可を集める努力は大変な気はしています。

まとめると、ENGINEはLGPLが安心、MITライセンス化は絶対ダメというわけではないが、そもそも移行コストがかかるのと、今はメリットを感じてないのでまあ反対かなぁ、という感じです。

---

issue冒頭の中身に関して、

しかし ENGINE は LGPL-3 であり、MIT/BSD-3 の CORE や OJT-rs とはライセンス非適合である。
現コントリビュータの多くは複数レポジトリに関わっているため、クリーンルーム設計も妥当とは言えない。
ゆえに、ENGINE の現行コードはそもそも CORE や OJT-rs へ移植できない。

この辺りはhihoライセンスを適用すればなんとかできる･･･かも･･･？

[tarepan]

詳細なライセンス意図ありがとうございます！

VOICEVOX（OSS・製品両方）の発展を守るため ... 秘匿している状態で有名になった場合 ... お互い切磋琢磨できるようにするために、コード公開義務のあるLGPLを選びました

👍
妥当な意見だと感じます。
OSS勃興時から続く本質的な議論、「MITで広く企業含めてコントリビュートを求めたほうが最終的に利になる」と「GPLで行き過ぎた closed フリーライドを阻害しないと発展が止まる」だと認識しました。
前者・後者どちらも理屈が通っており、かつどちらも実例があるため、結論のでない（ケースバイケースの極み）課題だと私も思います。

---

hihoライセンスを適用すればなんとかできる･･･かも

アイデアは理解できますが、私はこの案に反対です。

hihoライセンスは「ソースコードの公開が不要な別ライセンス」というREADMEのたった19文字で「事実上の著作権放棄」を求める、強すぎるライセンスです。
にも関わらずOSSコミュニティが健全に回っているのは、コミュニティが「声保護が核となる『製品版 VOICEVOX』には秘匿化が最重要だよね。そこに関しての規約ならOKでしょう」という、紳士協定としてこの条項を飲んでいるからだと考えます。少なくとも私はそうです。

LGPL-3 で提供したコードをhihoライセンスで MIT 化するということは「声保護関係なく、VOICEVOX のためなら著作権は自由使わせてもらうよ」というメッセージであり、上記の紳士協定が失われると感じます。

just idea としては面白いと思いますが、採用には反対です。

---

ゆえに、「ENGINE-CORE間リファクタリングはライセンス関係で不可能になりました」とするか、「ライセンス体系の不備をリファクタリングする季節がとうとう来た、と気合入れる」とするか、が基本的な方向性なのかなと思っています。

既にCORE側で「ENGINEとのハーモナイズ」的な commit がなされている点、VOICEVOX は既に揺るがないブランドがあり closed フリーライドで揺るがないコミュニティがある点、（また私がMITが好きな点）、から、私は後者の方向性を検討できないかと思っています。
上記の2方向性についてどう感じるか、他の方向性が有り得そうか、意見伺えれば幸いです。

[qryxip]

@Hiroshiba

絶対ダメというわけではないが、

割と強めの反対を貰う可能性が高いなーと実は思っていたので、ちょっと意外でした。

あくまで一方的な貢献がある形ではなく、お互い切磋琢磨できるようにするために、コード公開義務のあるLGPLを選びました。

これについて一点、LGPLv3 onlyでフォークされた場合はダウンストリーム側の変更をアップストリーム(VOICEVOX)側に入れることはできないのではとちょっと思いました。
(まあLGPLv3 onlyでやっていこうという覚悟を決めた人は「ただ乗りしよう」という意識は持っていないでしょうけど)

GLPLv3/hihoでのフォークを前提に置いた形でしょうか?

コアだけMITライセンスなことは当時も気づいてたのですが、かなりVOICEVOXの実情に寄ったコードで特異性が高いため、まあ秘匿的にforkされてコミュニティが崩壊することは無いだろうと思い、そのまま今に至ります。
最近はコアにも汎用的なコードが増えていますが、あまり意見は変わりません（コミュニティは崩壊することはなさそうだなと）。

この辺はエンジンでも変わらないのではという気はしています。今コアに無いのはHTTPサーバー機能と、speaker infoだけな気がします (その結果この問題に直面しているわけですが)。

コミュニティを守れるかという視点が論点だと感じています。

VOICEVOX自体の事情ではなくコミュニティがという話なのであれば、一例としてコミュニティの一員である私は特にフリーライドを恐れはしません。そのときはそのときだと思っています。私の担当のCOREは既にMITですし、(VOICEVOX/voicevox_project#24をやるくらいには)「OSS」という概念を気に入っていてそこそこは重視しているというのもあるのですが。

ただこれはできるだけ多くの人の意見を聞いた方がよいかなとは思います。特にENGINEに関わっている人に。

hihoライセンスを適用すればなんとかできる･･･かも･･･？

たれぱんさんと同意見です。その選択肢は流石に最後にした方がよいかと…

---

@tarepan

OSS勃興時から続く本質的な議論、「MITで広く企業含めてコントリビュートを求めたほうが最終的に利になる」と「GPLで行き過ぎた closed フリーライドを阻害しないと発展が止まる」だと認識しました。

(ヒホさんにそのような意図があるかどうかはわかりませんが)我々の場合資本を持った企業の他に、プロプライエタリなソフトウェアを開発する個人も考える必要があるかなと思います。OSSだとまず考えなくてよいことではあるのですが…

ゆえに、「ENGINE-CORE間リファクタリングはライセンス関係で不可能になりました」とするか、「ライセンス体系の不備をリファクタリングする季節がとうとう来た、と気合入れる」とするか、が基本的な方向性なのかなと思っています。

その二択になるという視点に同意します。私としては後者になるといいな…という感じでいます (なんでこんな書き方なのかというと、私はENGINEには関わっていないので)

---

コミュニティが論点ならば、マルチエンジンを手掛けた @sevenc-nanashi さんに意見を伺えればと思います。これまでの議論を聞いた上で、どうでしょう? MIT Licenseにした方がよいでしょうか?

[sevenc-nanashi]

結論：変えるなら反対はしないです。どちらでもいいかな～って感じ。

ボイボ派生ソフトはこのエンジンをフォークするのが基本的な選択肢だと思っていて、（OpenJtalkで分解 -> FFIでコアを呼び出して合成、は大体共通してる）もしその流れに変更を加えるなら多分ボイボ本体にとっても有用だと思っています（実際はそうじゃないかも？これは要検証）

が、ボイボエンジンをフォークできて改変するレベルの愛があるなら本家にPRしてくれるだろうしMITにしてもいいとは思います。
でも上に書かれてるように今更変更するのは面倒なので（許可取ったりやらなんやら）わざわざ変更することでもないかな～って感じです。

[Hiroshiba]

@tarepan

「ライセンス体系の不備をリファクタリングする季節がとうとう来た、と気合入れる」

こちらちょっと違和感がありました。
issue内のENGINE は LGPL-3 であり、MIT/BSD-3 の CORE や OJT-rs とはライセンス非適合である。も同じ違和感があります。

ENGINEのコードをCOREに移す、またはその逆のことをするのは、適切にライセンス表記すればLGPLであれMITであれ可能だと思います。
ファイルの一番上にコメントでENGINE側のリンクを書いたりすれば問題ないという認識です。
逆に言うとそこはLGPLやMITで差が無いはずで、MITであっても特にできることや手間は変わらない気がします。

@qryxip

割と強めの反対を貰う可能性が高いなーと実は思っていたので、ちょっと意外でした。

ちなみにですが、エディタのLGPLを外すのは相当抵抗あります。

LGPLv3 onlyでフォークされた場合はダウンストリーム側の変更をアップストリーム(VOICEVOX)側に入れることはできないのではとちょっと思いました。

これってダウンストリーム側はLGPLじゃない可能性もあり、ライセンス的にできないという意味でしょうか？
であればcherry-pickして、あと気になるならファイルの一番上コメントを残せば問題なさそうに思いました。

コミュニティが論点ならば

コミュニティに関してですが、この話はかなり公開の場でNOと言いにくいと思います。
匿名性を上げた状態で聞いてまわり、責任持って僕が判断するほうが健全に思います。

[tarepan]

@Hiroshiba

ファイルの一番上にコメントでENGINE側のリンクを書いたりすれば問題ないという認識

ここの認識に相違がありそうです。
私の認識は「『レポジトリ単位ライセンスを使う場合、内部に別ライセンス非適合ファイルは含めない』がOSS全般の慣習」です。

VOICEVOX ENGINE は以下の方式でライセンスを提示しています：

• root に /LGPL_LICENSE
• 個別ファイル冒頭にライセンス表記無し

これを「レポジトリ単位ライセンス」とここでは呼称します。
この方式はOSSで非常にメジャーな手法であり、この手法を取った場合「レポジトリ傘下のコードは全て当該ライセンスである」と外部からは認識されると期待されます。
ここが前提として共有できないと、OSSのライブラリを入れる際はライブラリ内全ファイルのライセンスを逐一チェックしなければならないからです（と私は認識しています）。
VOICEVOX CORE は MIT/hiho のレポジトリ単位ライセンスなので、MIT より強い制約をもつ LGPL-3 のファイルを内部に配置できません。
これを「ライセンス非適合」と表現しています。
どの辺が認識相違の原因になっていそうでしょうか？

[Hiroshiba]

@tarepan
確かにMITライセンスなコード内にLGPLコードを置くとだいぶ不便になりそうです。
この議論を突き詰めると「コアをLGPLにするのが良いのでは」になる気も少ししてきました。
あと正直なところ、VOICEVOX内のMITコードが、VOICEVOXのLGPLコードと似てしまったときに誰かが問題を指摘するとはあまり考えられないかもです。

ここの議論は平行線になる気がしているので、どちらかというとMITライセンスにするメリットがあればよいのかなと思いました。

[tarepan]

コアをLGPL

👍
ENGINEのMIT化と同じだけの労力が掛かりますが、1つの明確な解決策です。ライセンス上の問題は一切なくなります。

VOICEVOX内のMITコードが、VOICEVOXのLGPLコードと似てしまったときに誰かが問題を指摘

ENGINE のメジャーコミッターである私はとても悲しいですね…（自分がコミットすると制限あるLGPL-3なのに、管轄外の派生版はなぜかMIT…。OSSとは…）。

ここの議論は平行線

「どっちの方向性かは未だ平行線」というのには同意です。メリット等、更なる基礎検討を積極的にしていきたいです。
ただ、「現状での ENGINE→CORE 移植はライセンス的に黒寄りである」は共通認識になった、で認識合っているでしょうか？

---

MITライセンスにするメリット

👍
より積極的に MIT 化するメリットを整理することも重要だと考えます。
パッと思いつくのは以下とかでしょうか：

• 企業製マルチエンジン
  • MITなら有料版がコード非開示で作れるため
• 超優秀個人エンジニア製マルチエンジン
  • オープン指向がないが超優秀、な音声合成エンジニアをちらちら見かける
• 更なるオープン感
  • GPL系ライセンスにアレルギー的忌避感のあるエンジニアはそれなりにいる

[qryxip]

@tarepan

ただ、「現状での ENGINE→CORE 移植はライセンス的に黒寄りである」は共通認識になった、で認識合っているでしょうか？

私は「黒寄り」に一票入れたいと思います。

---

@Hiroshiba

コミュニティに関してですが、この話はかなり公開の場でNOと言いにくいと思います。
匿名性を上げた状態で聞いてまわり、責任持って僕が判断するほうが健全に思います

確かにそうですね。ここで聞くべきではなかった。

ただLGPLv3 → MITのコード移植についての見解をある程度は統一しておかないと、質問の内容次第ですが回答がブレそうな気がしています。

[Hiroshiba]

@tarepan

「現状での ENGINE→CORE 移植はライセンス的に黒寄りである」は共通認識になった、で認識合っているでしょうか？

そうですね、そこは同じ認識です！

MITライセンスにするメリット

こちらもなるほどです！
企業参入があると結構嬉しいだろうなと思いました。

GPL系ライセンスにアレルギー的忌避感のあるエンジニアはそれなりにいる

個人的にはずっと LGPL で慣れたせいか、ほぼ MIT ライセンスと同じ、ぐらいの感覚でした。

ENGINEのMITライセンス化自体は乗り気です。
ただまぁ自分はやらないといけないことがだいぶ溜まっているので、自分がやるなら追加の差し込みタスクがない場合でも早くて３～４ヶ月後になっちゃう気がします。
（溜まってるタスクとしてはコアVVM周り、ソング周り、脱プロプライエタリ周り、など）

---

@qryxip

ただLGPLv3 → MITのコード移植についての見解をある程度は統一しておかないと、質問の内容次第ですが回答がブレそうな気がしています。

あまり褒められたものではないかもですが、とりあえず応急処置としてはヒホに聞いて「問題ない」となればOK、って感じかなぁと･･･。

[qryxip]

@Hiroshiba

これってダウンストリーム側はLGPLじゃない可能性もあり、ライセンス的にできないという意味でしょうか？

これに答えていませんでした。LGPLv3 onlyのダウンストリームの変更をLGPLv3 OR hihoに還元するのは不可なのではと思った次第です。

ただまぁ自分はやらないといけないことがだいぶ溜まっているので、自分がやるなら追加の差し込みタスクがない場合でも早くて３～４ヶ月後になっちゃう気がします。
（溜まってるタスクとしてはコアVVM周り、ソング周り、脱プロプライエタリ周り、など）

コントリビュータの同意を集めるのだけ先行できたりしませんかね...? GitHub上で全員に@を飛ばす形でいいのではと思っています (その方が同意を得たということを公表できますし)。

参考までに、私が他のOSSでライセンス変更に同意したときのものです:

• The license is non-free oli-obk/rust-si#17
• Switch binstalk-manifests LICENSE to "Apache-2.0 OR MIT" cargo-bins/cargo-binstall#513
• Switch binstalk-downloader license to "Apache-2.0 OR MIT" cargo-bins/cargo-binstall#542

[qryxip]

あ、これがあったか…

コミュニティに関してですが、この話はかなり公開の場でNOと言いにくいと思います。
匿名性を上げた状態で聞いてまわり、責任持って僕が判断するほうが健全に思います。

[Hiroshiba]

@qryxip

LGPLv3 onlyのダウンストリームの変更をLGPLv3 OR hihoに還元するのは不可なのではと思った次第です。

なるほどです！
これに関しては、そもそもMITやLGPLやonlyかどうかに関係なく、そもそも引用してからコードが消えるまでずっとコピーライトとライセンスは元のライセンスのまま残り続けるのが妥当に思います。

まあでもすごいぶっちゃけると、VOICEVOXのコードをVOICEVOXがコピーして一体権利者のうち誰が文句言うんだろうというのはすごく思います。（もちろんよほど悪徳だったらダメ）
ライセンスがずれていることを議論しても平行線なので、どちらかというと「MITになると何が嬉しいか」を議論すると進みやすいのかなーって感じですかねー
（ #1085 (comment) と言ってること同じだった。。）

[tarepan]

暫定まとめ

VOICEVOX ENGINE ライセンスの LGPL3/hiho → MIT/hiho 移行は、2024年3月現在、以下の整理がなされています。

総論: 「メリット > デメリット、移行コスト大。移行に前向き、相対的優先度は低め」

• メリット
  • ENGINE と CORE を跨いだコード移植・リファクタリングが可能になる
    • 現ライセンスでの移植はライセンス的に黒寄り
    • 応急処置として、現ライセンス下の移植は要メンテナ確認
  • 企業製マルチエンジンの可能性が広がる
    • MIT なら有料版がコード非開示で作れるため
  • 更なるオープン感
    • GPL系ライセンスへの印象は各エンジニアでかなり幅がある
• デメリット
  • closed クローンによるフリーライド、それに起因するコミュニティ崩壊の懸念
• 移行コスト
  • 全コントリビュータへの意向聞き取り・合意形成・ライセンス変更（private を想定）
• 高優先度の他タスク例
  • コアVVM
  • ソング
  • 脱プロプライエタリ

意向確認済み

議論の過程で「移行は問題なさそう」との簡易的意向が得られたコントリビューター： tarepan / Hiroshiba / qryxip / sevenc-nanashi

本 issue 扱い

ライセンス変更の議論を周知し、CORE移植絡みの意図しない著作権侵害を防止する意義があり、また数ヶ月後の着手が想定されているため、本 issue は open を維持します。

[github-actions]

本 Issue は直近 180 日間で活動がありません。今後の方針について VOICEVOX チームによる再検討がおこなわれる予定です。

[qryxip]

これについてですが、COREの開発的にやはりいつかは行われて欲しいなと個人的には思ってます。

(直近の予定としてはCOREのソングAPI実装がありますが、まあこれは対象者が限られてるので別個に確認を取ればいいですかね)

(追記) あとpauseLengthもあるか。まあこちらも多分同様

[qryxip]

これからENGINEの機能をCOREに移植するにあたっては個別に許可を取りたくはあります。ざっとこんな感じ？（ヒホさんは除外しています）

• ソング関連: Yちゃんさん他何人か？実装当初の状態のみに絞ればYちゃんさんだけ？
• モーフィング: mes51さん他何人か？
• AudioQuery.pauseLength{,Scale}: X-20A/momemiさん、サボ寝ルネさん
  • 追加:queryに無音時間調整関連のパラメータを作成 #1308
  • FIX: AudioQueryの互換性の問題を修正 #1425
• モーラマッピング拡張: 黒猫大福さん
  • mora_mapping.py にOpenJTalkに無いKanaを追加 #1473

この中一番大きいのはソング関係ですね。ソング関係のコードはほぼほぼ私の頭の中に入っていないので、YちゃんさんのPRのdiffだけ見ればなんとかなりそう、なのですがsuggestionによるco-authoringがちょっと厄介ですね。"project-s"と呼んでいた頃に絞ればなんとか…？

モーフィングは… 最悪 VOICEVOX/voicevox_core#713 はもう歴史ごと抹消してしまって¹第三者にクリーンルーム実装してもらう、という手もありそうですね。まあそんなにニーズがある機能ではなさそうなのが幸い。

---

¹ 例えばmainブランチでforce pushして「0コミット状態」にする。レビューの残骸は残るだろうけど…

[Hiroshiba]

このissueと内容が異なるので、別issueにしてリンクしたほうがわかりやすいかもです･･･！
（お手数おかけしてしまってすみません 🙇 ）