PACEによるJUCEの買収とJUCE6開発計画が予告された件

4月になってからJUCE方面の動きが大きい。今日はついにPACE社がJUCEを買収したというニュースが出てきた。それなりにセンシティブな話題で、ある程度JUCEにコミットメントがある人には書きにくい話もあると思うので、完全に無責任な立ち位置で書いておこうと思う。

目次

PACEによる買収とjuce-framework/JUCEへの移行

JUCEは(ここでは何度も書いているので今さら感あるけど)クロスプラットフォームでクロスオーディオプラグイン規格の開発フレームワークで、今日まではROLI社が所有する製品だった。商用ライセンスとGPLv3で公開されている。

今回はROLI社が買収されるのではなく、JUCEの開発事業がPACEに買収されるらしい。JUCEはもともとJulian Storerという開発者がJule'sなんちゃら(忘れた)という自分の名前を冠して作ったライブラリで、彼はROLIに所属しているのだけど、最近はSOULというAPL(オーディオプログラミング言語)まわりの仕事をしていて、SOULは事業譲渡の対象ではないようだ。つまりJUCEはPACEのものになるけど、Juleは付いてこないということになる*1。ROLI社は楽器ハードウェアを販売している会社なので(Apple StoreなどでSeaboardやBLOCKSといったROLI製品が販売されているのを見たことがある人もいることだろう)、JUCE以外にもやるべきことはいっぱいある。

買収するほう、PACE社が分かる人がどれくらいいるか、多くはないんじゃないかと思うけど、iLokという製品を聞いたことがある/使っている人はDTMやってる人ならそれなりにいるかもしれない。USBドングルを売っているライセンシング・ソリューションを提供する会社だ。iLokは自分もADCで2年連続で見ているはずなのだけど、会社名までは全く覚えていなかった。最初 IP management company みたいな文言で書かれているのを見て「JUCE完全に身売りしないといけなくなったのか…」と暗い気持ちになったのだけど、製品開発にはノータッチノーサポートでIPだけ吸い取るような買収ではないようだ。

ROLIは実際のところかなり資金難に苦しんでいて、JUCE開発チームも2人か3人くらいで回している状態だった。JUCEにはいわゆる外部コントリビューターのようなものがいない。現時点ではROLIのポリシーなのかJUCEチームのポリシーなのかわからないが、当初はそもそもJuleの個人ユーティリティで彼は要望を受け付けてコードを取り込むのを嫌がって拒否していたようだ。つまりオープンソースではあるがオープン開発ではない。

ごく少人数で回しているJUCE開発は、実のところさまざまな方面で停滞していた。個人的に関心のある範囲だけでも、Projucerはビルドを全面的に面倒見るための機構なのに、痒いところに手が届かず、細々とした改善が求められていた。SteinbergがVST2 SDKを入手できなくしたので全面的なVST3サポートが必須だったのに、Linux版はVST3を全くサポートしなかった。

閑話休題、そこに現在のコロナ禍である。ROLI単独で状況が改善される見込みはほぼ無かった。資金難という話は昨年には出ていたので(昨年はNative Instrumentsなども大規模リストラを行っており、オーディオ開発ソフトウェアの世界は割としんどい年だったようだ)、PACE以外からもいくつか買収提案を受けていたようだ。PACEはJUCEからのシームレスなiLokサポートを実現できれば既成品の販売が強化できるので、それだけでもJUCEを手元に置いておく理由にはなるかもしれない。実のところiLok利用ベンダーとJUCEユーザーはある程度かぶっていたようだ。JUCEチームとしては資金の心配なく開発が継続できれば良いということだろう。JUCEユーザー(音楽ソフト開発者)としてはそれで得られる安心感は確かにある。

とはいえ…iLokである。もともとユーザーにとっては邪魔でしかないUSBドングルのライセンシングソリューションの会社でサポートの評判もいまいちらしく、全く歓迎されるべき事態には見えない。JUCE forumでこの話題が上がったのはこのスレッドだけど、リンク先のgearslutz.comの掲示板には残念がるコメントが散見される。まずタイトルがPace Ilok has bought the Juce Platform :-(である。散見ではあるけど、匿名掲示板でも大規模掲示板でもないことを考えると、十分「大きな」懸念が上がっていると思う。

PACEの買収はどんな影響をもたらすだろうか? 私見としては3つくらい今後の筋書きが考えられる。

  1. 何も変わらない。これが一番ありそうなシナリオだと思う。PACEはiLokの販路が拡大できれば十分なので、JUCEにiLokサポートを追加するような動きは見せるが、JUCEのライセンスモデルを変更したりすることはない。juce_product_unlockingモジュールはもしかしたらiLokサポート用に別モジュールが出来て消滅するかもしれない(が、そのためにはiLokがLinuxをサポートしなければならず、それ無しで移行するとは考えにくい)。
  2. 商用ライセンスに変更が加えられ、商用ライセンス版では特にソフトウェアプロテクションまわりでiLok以外の選択肢を排除するために独自の改良を加えられなくなる可能性が懸念される。こうなると独自にLV2サポートを追加するような変更が加えられなくなる。
  3. GPLv3ライセンスでの提供が廃止される。外部コントリビューションを受け付けていなかったので、PACEはJUCEのライセンスを恣に変更できる。もちろん、これまでにリリースされたバージョンは従前の商用ライセンスとGPLv3で利用できるが、誰かがOSSとしてforkしてメンテナンスする必要がある。幸い(?)本家の開発リソースは小さいのでそこまで劣勢にはならないだろう。ただLGPLで利用できないライブラリはライセンス的に使い勝手が悪いし、商用ユーザーにとってはそっちに協力してもメリットがないので、かなり閉じた世界になりそうではある。

(3)は一番問題のあるシナリオだけど、可能性は限りなく小さいと思う。競合製品を出しているわけでもないPACEにそんなことをするメリットは、悪意の深読みスペシャリストであるわたしにもちょっと思いつかない。JUCEの市場は小さくないけど、独占的とまで言えるほどではない。

…とまあ、懸念事項はあるのだけど、現時点で言えることとしては、少なくともJUCEチームにはいくつかの選択肢があったうえで一番よさそうなものを選んだのだということだ。PACEは少なくとも開発者にとっては親和的であるようだ。JUCEチームによる公式アナウンスには developer-focused company と書かれている。ただそれにしてはgithub organizationsも無いような会社なので、このコメントへはわたしは50%くらいは(良く言えば)リップサービスだなと思っている。

JUCEはROLIのorganizationからは外れて、新しくjuce-frameworkというorganizationの下で公開されることになったようだ。github teamsが価格改定されたこともあるし、タイミングとしては割とラッキーだったのかもしれない。

JUCE6の予告

ともあれ、資金的な困難が解消したこともあってか、JUCEチームは大規模リリースに向けて本格稼働を始めた(あるいはそれを公開するようになった)ようだ。今から4日前、JUCE6のリリースが告知された。個人的には嬉しい事だらけの内容だ。

forum.juce.com

JUCE6は現在すでにある程度コードがgithub上でjuce6というブランチで公開されている。以下の項目以外にもいくつか改善があるので、詳しくは上記アナウンスやgithub上のコミットを眺めてみてほしい。

CMakeサポート

JUCE6最大の変更はProjucerからCMakeへの全面的な移行だ。CMakeサポートはもともと「CLionサポート (beta)」というかたちで実装されていたわけだけど、あくまでビルドが可能というレベルで再利用性は低く、ファイル追加などはProjucer上で行うことが前提となっていた。JUCE6ではこれを全プラットフォームで全面的に使うということを意味している。Projucerは、なくなるわけではなく、CMakeLists.txtを生成するための補完的なツールとして生き残り続けるようだ(そもそも他にもいくつか機能がある)。

昨年12月にJUCE Advent Calendarでわたしは以下のように書いたのだけど、完全にその通りになってくれた。

わたしの個人的な感想としては「もうProjucerのビルドシステムはあきらめてCMakeを使おう」なのですが(パッケージ参照もちゃんと解決できるしVisual StudioでもAndroid StudioでもCLionでも開けるんですよコレ)

完全に余計な話だけど、CMakeサポートはJUCEのオリジナル開発者Julian Storerがやりたがらなかった仕事のひとつなので(「CMakeが嫌だからJUCEを作ったんだ」)、彼が組織上は居なくなるタイミングでCMakeサポートが追加されるというのは何とも象徴的ではある(タイミングの問題であって、CMakeが理由で決別ってことはまあないだろう)。PACEの買収のポジティブな側面として、CMakeサポートは新しくコミュニティからスカウトされてJUCEチームの一員となった開発者が書いている。

これを書いている時点では、examples/CMake/README.mdに詳しいドキュメントがまとめられている。「ドキュメントはわかりやすい場所に置いてほしい」というユーザーフィードバックが開発者に届いていたので、そのうち移動するかもしれない*2

Run Headless (Linux)

JUCEアプリケーションがLinux上ではheadlessでGUIなしで動作するようになった。GUIが無くても良いということは、CIサーバ上で非常に動かしやすくなったということだ。CircleCIを使う記事を去年書いたときにも言及したけど(CIまわりはわたしが自分で書かないと英語圏でも誰も書いていないような状況だった)、これまではX server相当の何かをセットアップしないと何も出来なかった。

atsushieno.hatenablog.com

GUIコードが一切存在しなくても、Projucerでファイルを生成するためにはJUCEアプリであるProjucerが実行できなければならなかったし、これがheadlessで動作しなかった。ビルドファイルをコミットする覚悟があるプロジェクトでも、プラグインのルックアップすらjuce_eventsなしにはできなかったし、juce_eventsだけ使ってjuce_gui_basicsを使わないコードを書くことはほぼ無かっただろう。headless化が具体的にどこまで基盤を変更することになったのかはわからないけど(ソースツリー差分で調べようと思えば調べられそうではある)、juce_events依存部分が整理されたことを期待している。

なおLinuxのみらしい。CIサーバ上でheadlessのメリットがあるのはLinuxくらいなので、これで十分だ(GUIなしのWindowsmacOSがあれば話は別だけど)。

Linux VST3サポート

ついにLinux上でもVST3がサポートされるようになった。だいぶ前にホスト側だけでもと思ってパッチを作ってpull requestを送っていて、最近も「VST3対応しなさそうだから自分で作って公開するか…?」となっていたのだけど、公式対応が出てきたのでこれでひと安心だ(まだリリースされたわけではないが)。

JUCEのアイデンティティクロスプラットフォームでオーディオプラグイン等をビルドできることであり、VST3サポートが無い問題はLinux系音楽開発クラスタにとっては致命的だった。VST2が利用できなくなった結果、VST3という出口のない状態で、JUCEのAPIを使って書いたコードがLinuxでは何の価値も無くなってしまったのだ。LADSPA v1サポートはホストだけだし、そもそもv1にはMIDIサポートが無い。そしてLV2サポートも無い。

これが理由でかつてJUCEを使っていたLinux系のオーディオプロジェクトのいくつかが本家JUCEを捨ててLV2サポートのあるforkやDISTRHOに切り替えたり(dexedやADLplugなど)、あるいはJUCEを捨ててLV2に移行する(sfizzなど)といったトレンドが発生していた*3し、わたしも別のものに移行するかJUCEでないものを作るしか無いと思っていた*4

なお、昨日の時点で関連コードがjuce6ブランチに追加されている。

DSPのビルディングブロック

DSPにはディレイ、コンプレッサー、フェイザーなどいくつかの定番フィルターがあって、それらはもちろん単体でもオーディオプラグインとして機能しうるものだけど、実際のオーディオプラグイン製品とくに楽器の類では、これらをオプションとして最初から組み込んでいるものが多い。そういったアプリケーションを簡単に作れるように、DSPのビルトイン部品が追加された…ということだろう。

WebViewまわりの刷新

最新のWebViewが各プラットフォームで利用できるようになるらしい(一度も使ったことがないのでわからない)。blueprintなど、JUCEでも最近のアプリケーションのGUI部分をjuce_gui_basicsではなく独自に作成するトレンドもあり、WebViewサポートによっていわゆるガワネイティブ的な使い方も出てくるようになる可能性がある。

総括

PACEによる買収は、まだ今後どうなるか分からないのである程度注意しながら様子を見ていきたいけど、とりあえず資金が確保できたことで開発が先に進むようになった側面があるので(OracleによるSun買収もそうだったとは思う)、短期的にはJUCE6のポジティブな計画をたのしみに待ちたい。

*1:まあそうは言っても、JUCEはもともとTracktion社から出てきたもので、彼はtracktion_engineにもcommitしていたりするので、今後もそんな関係かもしれない

*2:わたしが眺めているtheaudioprogrammer discordにbuild-systemというチャンネルがあって、そこで観測した

*3:これはJUCEをLinux方面で使っていないと滅多に目にすることはなかったと思う。iPlug2などLinuxサポートの無いライブラリに比べたらJUCEは比較的マシなほうなのだけど、それでは不十分だったということだ

*4:今でもちょっと思っている節はある