femshima
commented
7 months ago softether vpnではライセンスをGPLv2からApacheに変える際，次のような宣誓書を出しているようです． ここでもこのレベルが可能かどうかはわかりませんが… https://ja.softether.org/5-download/src/190121_switch_to_apache_license
Open tarepan opened 7 months ago
femshima
commented
7 months ago softether vpnではライセンスをGPLv2からApacheに変える際，次のような宣誓書を出しているようです． ここでもこのレベルが可能かどうかはわかりませんが… https://ja.softether.org/5-download/src/190121_switch_to_apache_license
qryxip
commented
7 months ago （CORE が MIT なのでそうではないと考えていますが）メンテナ方針として「ENGINE は公開義務を必須にしたい」という方針があれば、ライセンス変更はNoGoかと思います。
私の理解だと「公開義務を必須にしたい」というよりは、「フォークしたものはLGPL-3.0 onlyとなり、プロプライエタリと両立しなくなる(incompatible)ようにしたい」という感じだと思います。ただこの辺については、残念ながら、GitHub上での議論は適さないかもしれません。 (私自身の正直な思いで言えば、MITになってほしくはあります)
コントリビュータが2桁人
PRが一個二個の人だと、連絡が取れるか怪しい方が結構いますね… 連絡が取れなかったら最悪clean-roomingすればいけるかも? (qwertyさんについては、連絡は取れるんじゃないでしょうか。多分)
qryxip
commented
7 months ago いや別にGitHub上で話してもいいか。別に誰かに掘り起こされてどうのこうの言われることは今更無いでしょうし。
また、1 レビュアーとして、自分のコントリビュートが企業等でも自由に使いやすい MIT ライセンスであることは単純に好ましい。
例えば @takana-v さんのBridge Plugin (ITVOICEが利用中)だと、こうなっています。
ライセンスをMIT一本にした場合、このようなことはできなくなると思います。この「デメリット」は、たれぱんさんが挙げてくださった「メリット」を上回るということになってしまうんじゃないかと思っています。
VOICEVOXがVOICEVOXであるためにはVOICEVOXはOSSになれないし、なってはならない。そもそも「OSSである」ことは特に強いメリットを生まない…ということの一環であるという理解を私はしています。少なくとも私はそれを了承してここにいます。
tarepan
commented
7 months ago @qryxip
具体的な利点・欠点の例示ありがとうございます！
前提となる認識合わせをさせてください。
本 issue は「LGPL-3 / hiho独自の dual licence」→「MIT / hiho独自の dual licence」の変更可否基礎議論を意図しています。
ここは共通認識として共有できているでしょうか？（上記事例は独自ライセンス部のみに関わるものに見えたので）
qryxip
commented
7 months ago なるほど。MITにしたまま第二ライセンスは残す感じですか。MIT一本になると思い込んでいました。それならBridge Pluginは影響は受けませんね。
tarepan
commented
7 months ago こちらの書き方としてhihoライセンスに触れなかったのが誤解の元でした🙇 冒頭文を修正しました。
MIT+第2ライセンスの前提のうえで、@qryxip さんはどのような所感でしょうか？
qryxip
commented
7 months ago 個人的な所感としては十分なメリットがあり、よいと思います。デュアルライセンスのままならBridge Pluginは影響を受けませんし。決定権は @Hiroshiba さんにありますが。
問題は数十人の同意ですね… 連絡取れない人に対するclean-rooming処置(外部協力者を募った上で)をする覚悟は実際しておいた方が良いかもしれない…
tarepan
commented
7 months ago 
Hiroshiba
commented
7 months ago すみません、出るのが遅れました！ 一言でいうと、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
commented
7 months ago 詳細なライセンス意図ありがとうございます！
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
commented
7 months ago @Hiroshiba
絶対ダメというわけではないが、
割と強めの反対を貰う可能性が高いなーと実は思っていたので、ちょっと意外でした。
あくまで一方的な貢献がある形ではなく、お互い切磋琢磨できるようにするために、コード公開義務のあるLGPLを選びました。
これについて一点、LGPLv3 onlyでフォークされた場合はダウンストリーム側の変更をアップストリーム(VOICEVOX)側に入れることはできないのではとちょっと思いました。 (まあLGPLv3 onlyでやっていこうという覚悟を決めた人は「ただ乗りしよう」という意識は持っていないでしょうけど)
GLPLv3/hihoでのフォークを前提に置いた形でしょうか?
コアだけMITライセンスなことは当時も気づいてたのですが、かなりVOICEVOXの実情に寄ったコードで特異性が高いため、まあ秘匿的にforkされてコミュニティが崩壊することは無いだろうと思い、そのまま今に至ります。 最近はコアにも汎用的なコードが増えていますが、あまり意見は変わりません（コミュニティは崩壊することはなさそうだなと）。
この辺はエンジンでも変わらないのではという気はしています。今コアに無いのはHTTPサーバー機能と、speaker infoだけな気がします (その結果この問題に直面しているわけですが)。
コミュニティを守れるかという視点が論点だと感じています。
VOICEVOX自体の事情ではなくコミュニティがという話なのであれば、一例としてコミュニティの一員である私は特にフリーライドを恐れはしません。そのときはそのときだと思っています。私の担当のCOREは既にMITですし、(https://github.com/VOICEVOX/voicevox_project/issues/24をやるくらいには)「OSS」という概念を気に入っていてそこそこは重視しているというのもあるのですが。
ただこれはできるだけ多くの人の意見を聞いた方がよいかなとは思います。特にENGINEに関わっている人に。
hihoライセンスを適用すればなんとかできる･･･かも･･･？
たれぱんさんと同意見です。その選択肢は流石に最後にした方がよいかと…
@tarepan
OSS勃興時から続く本質的な議論、「MITで広く企業含めてコントリビュートを求めたほうが最終的に利になる」と「GPLで行き過ぎた closed フリーライドを阻害しないと発展が止まる」だと認識しました。
(ヒホさんにそのような意図があるかどうかはわかりませんが)我々の場合資本を持った企業の他に、プロプライエタリなソフトウェアを開発する個人も考える必要があるかなと思います。OSSだとまず考えなくてよいことではあるのですが…
ゆえに、「ENGINE-CORE間リファクタリングはライセンス関係で不可能になりました」とするか、「ライセンス体系の不備をリファクタリングする季節がとうとう来た、と気合入れる」とするか、が基本的な方向性なのかなと思っています。
その二択になるという視点に同意します。私としては後者になるといいな…という感じでいます (なんでこんな書き方なのかというと、私はENGINEには関わっていないので)
コミュニティが論点ならば、マルチエンジンを手掛けた @sevenc-nanashi さんに意見を伺えればと思います。これまでの議論を聞いた上で、どうでしょう? MIT Licenseにした方がよいでしょうか?
sevenc-nanashi
commented
7 months ago 結論：変えるなら反対はしないです。どちらでもいいかな～って感じ。
ボイボ派生ソフトはこのエンジンをフォークするのが基本的な選択肢だと思っていて、（OpenJtalkで分解 -> FFIでコアを呼び出して合成、は大体共通してる）もしその流れに変更を加えるなら多分ボイボ本体にとっても有用だと思っています（実際はそうじゃないかも？これは要検証）
が、ボイボエンジンをフォークできて改変するレベルの愛があるなら本家にPRしてくれるだろうしMITにしてもいいとは思います。 でも上に書かれてるように今更変更するのは面倒なので（許可取ったりやらなんやら）わざわざ変更することでもないかな～って感じです。
Hiroshiba
commented
7 months ago @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
commented
7 months ago @Hiroshiba
ファイルの一番上にコメントでENGINE側のリンクを書いたりすれば問題ないという認識
ここの認識に相違がありそうです。
私の認識は「『レポジトリ単位ライセンスを使う場合、内部に別ライセンス非適合ファイルは含めない』がOSS全般の慣習」です。
VOICEVOX ENGINE は以下の方式でライセンスを提示しています：
/LGPL_LICENSEこれを「レポジトリ単位ライセンス」とここでは呼称します。
この方式はOSSで非常にメジャーな手法であり、この手法を取った場合「レポジトリ傘下のコードは全て当該ライセンスである」と外部からは認識されると期待されます。
ここが前提として共有できないと、OSSのライブラリを入れる際はライブラリ内全ファイルのライセンスを逐一チェックしなければならないからです（と私は認識しています）。
VOICEVOX CORE は MIT/hiho のレポジトリ単位ライセンスなので、MIT より強い制約をもつ LGPL-3 のファイルを内部に配置できません。
これを「ライセンス非適合」と表現しています。
どの辺が認識相違の原因になっていそうでしょうか？
Hiroshiba
commented
7 months ago @tarepan 確かにMITライセンスなコード内にLGPLコードを置くとだいぶ不便になりそうです。 この議論を突き詰めると「コアをLGPLにするのが良いのでは」になる気も少ししてきました。 あと正直なところ、VOICEVOX内のMITコードが、VOICEVOXのLGPLコードと似てしまったときに誰かが問題を指摘するとはあまり考えられないかもです。
ここの議論は平行線になる気がしているので、どちらかというとMITライセンスにするメリットがあればよいのかなと思いました。
tarepan
commented
7 months ago コアをLGPL
👍
ENGINEのMIT化と同じだけの労力が掛かりますが、1つの明確な解決策です。ライセンス上の問題は一切なくなります。
VOICEVOX内のMITコードが、VOICEVOXのLGPLコードと似てしまったときに誰かが問題を指摘
ENGINE のメジャーコミッターである私はとても悲しいですね…（自分がコミットすると制限あるLGPL-3なのに、管轄外の派生版はなぜかMIT…。OSSとは…）。
ここの議論は平行線
「どっちの方向性かは未だ平行線」というのには同意です。メリット等、更なる基礎検討を積極的にしていきたいです。
ただ、「現状での ENGINE→CORE 移植はライセンス的に黒寄りである」は共通認識になった、で認識合っているでしょうか？
MITライセンスにするメリット
👍
より積極的に MIT 化するメリットを整理することも重要だと考えます。
パッと思いつくのは以下とかでしょうか：
qryxip
commented
7 months ago @tarepan
ただ、「現状での ENGINE→CORE 移植はライセンス的に黒寄りである」は共通認識になった、で認識合っているでしょうか？
私は「黒寄り」に一票入れたいと思います。
@Hiroshiba
コミュニティに関してですが、この話はかなり公開の場でNOと言いにくいと思います。 匿名性を上げた状態で聞いてまわり、責任持って僕が判断するほうが健全に思います
確かにそうですね。ここで聞くべきではなかった。
ただLGPLv3 → MITのコード移植についての見解をある程度は統一しておかないと、質問の内容次第ですが回答がブレそうな気がしています。
Hiroshiba
commented
7 months ago @tarepan
「現状での ENGINE→CORE 移植はライセンス的に黒寄りである」は共通認識になった、で認識合っているでしょうか？
そうですね、そこは同じ認識です！
MITライセンスにするメリット
こちらもなるほどです！ 企業参入があると結構嬉しいだろうなと思いました。
GPL系ライセンスにアレルギー的忌避感のあるエンジニアはそれなりにいる
個人的にはずっと LGPL で慣れたせいか、ほぼ MIT ライセンスと同じ、ぐらいの感覚でした。
ENGINEのMITライセンス化自体は乗り気です。 ただまぁ自分はやらないといけないことがだいぶ溜まっているので、自分がやるなら追加の差し込みタスクがない場合でも早くて３～４ヶ月後になっちゃう気がします。 （溜まってるタスクとしてはコアVVM周り、ソング周り、脱プロプライエタリ周り、など）
@qryxip
ただLGPLv3 → MITのコード移植についての見解をある程度は統一しておかないと、質問の内容次第ですが回答がブレそうな気がしています。
あまり褒められたものではないかもですが、とりあえず応急処置としてはヒホに聞いて「問題ない」となればOK、って感じかなぁと･･･。
qryxip
commented
7 months ago @Hiroshiba
これってダウンストリーム側はLGPLじゃない可能性もあり、ライセンス的にできないという意味でしょうか？
これに答えていませんでした。LGPLv3 onlyのダウンストリームの変更をLGPLv3 OR hihoに還元するのは不可なのではと思った次第です。
ただまぁ自分はやらないといけないことがだいぶ溜まっているので、自分がやるなら追加の差し込みタスクがない場合でも早くて３～４ヶ月後になっちゃう気がします。 （溜まってるタスクとしてはコアVVM周り、ソング周り、脱プロプライエタリ周り、など）
コントリビュータの同意を集めるのだけ先行できたりしませんかね...? GitHub上で全員に@を飛ばす形でいいのではと思っています (その方が同意を得たということを公表できますし)。
参考までに、私が他のOSSでライセンス変更に同意したときのものです:
qryxip
commented
7 months ago あ、これがあったか…
コミュニティに関してですが、この話はかなり公開の場でNOと言いにくいと思います。 匿名性を上げた状態で聞いてまわり、責任持って僕が判断するほうが健全に思います。
Hiroshiba
commented
7 months ago @qryxip
LGPLv3 onlyのダウンストリームの変更をLGPLv3 OR hihoに還元するのは不可なのではと思った次第です。
なるほどです！ これに関しては、そもそもMITやLGPLやonlyかどうかに関係なく、そもそも引用してからコードが消えるまでずっとコピーライトとライセンスは元のライセンスのまま残り続けるのが妥当に思います。
まあでもすごいぶっちゃけると、VOICEVOXのコードをVOICEVOXがコピーして一体権利者のうち誰が文句言うんだろうというのはすごく思います。（もちろんよほど悪徳だったらダメ） ライセンスがずれていることを議論しても平行線なので、どちらかというと「MITになると何が嬉しいか」を議論すると進みやすいのかなーって感じですかねー （ https://github.com/VOICEVOX/voicevox_engine/issues/1085#issuecomment-1968950839 と言ってること同じだった。。）
tarepan
commented
7 months ago VOICEVOX ENGINE ライセンスの LGPL3/hiho → MIT/hiho 移行は、2024年3月現在、以下の整理がなされています。
総論: 「メリット > デメリット、移行コスト大。移行に前向き、相対的優先度は低め」
議論の過程で「移行は問題なさそう」との簡易的意向が得られたコントリビューター： tarepan / Hiroshiba / qryxip / sevenc-nanashi
ライセンス変更の議論を周知し、CORE移植絡みの意図しない著作権侵害を防止する意義があり、また数ヶ月後の着手が想定されているため、本 issue は open を維持します。
github-actions[bot]
commented
1 month ago 本 Issue は直近 180 日間で活動がありません。今後の方針について VOICEVOX チームによる再検討がおこなわれる予定です。
qryxip
commented
1 month ago これについてですが、COREの開発的にやはりいつかは行われて欲しいなと個人的には思ってます。
(直近の予定としてはCOREのソングAPI実装がありますが、まあこれは対象者が限られてるので別個に確認を取ればいいですかね)
(追記) あとpauseLengthもあるか。まあこちらも多分同様
内容
要望概要: 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 のライセンス変更はとにかく時間がかかるため、議論としてはこの段階で始めないと遅くなると思います。