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]

いや別にGitHub上で話してもいいか。別に誰かに掘り起こされてどうのこうの言われることは今更無いでしょうし。

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

例えば @takana-v さんのBridge Plugin (ITVOICEが利用中)だと、こうなっています。

• https://twitter.com/taka7n/status/1620397138390941696
• https://github.com/voicevox-bridge/bridge-plugin/blob/5ecbf000c0ac592048a42156d5831f69eb1457c4/LICENSE

ライセンスをMIT一本にした場合、このようなことはできなくなると思います。この「デメリット」は、たれぱんさんが挙げてくださった「メリット」を上回るということになってしまうんじゃないかと思っています。

VOICEVOXがVOICEVOXであるためにはVOICEVOXはOSSになれないし、なってはならない。そもそも「OSSである」ことは特に強いメリットを生まない…ということの一環であるという理解を私はしています。少なくとも私はそれを了承してここにいます。

[tarepan]

@qryxip
具体的な利点・欠点の例示ありがとうございます！

前提となる認識合わせをさせてください。
本 issue は「LGPL-3 / hiho独自の dual licence」→「MIT / hiho独自の dual licence」の変更可否基礎議論を意図しています。
ここは共通認識として共有できているでしょうか？（上記事例は独自ライセンス部のみに関わるものに見えたので）

[qryxip]

なるほど。MITにしたまま第二ライセンスは残す感じですか。MIT一本になると思い込んでいました。それならBridge Pluginは影響は受けませんね。

[tarepan]

こちらの書き方としてhihoライセンスに触れなかったのが誤解の元でした🙇 冒頭文を修正しました。

MIT+第2ライセンスの前提のうえで、@qryxip さんはどのような所感でしょうか？

[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 のファイルを内部に配置できません。
これを「ライセンス非適合」と表現しています。
どの辺が認識相違の原因になっていそうでしょうか？