Unityの二重基準論争: VLCを禁止

 (mfkl.github.io)
2 ポイント 投稿者 GN⁺ 2024-01-13 | 1件のコメント | WhatsAppで共有
  • 2019年12月から、Unityストアで VLC for Unity 統合バイナリの配布を開始
  • Unityゲームエンジンと VLC マルチメディアエンジンをつなぐもので、Unityベースのゲームで VLC 技術を基盤とした独自メディアプレーヤーを構築可能
  • Unity と LibVLC はどちらも高い移植性を備えており、クロスプラットフォーム統合に有用
  • その結果、多くのユーザーが Unity アプリやゲームで高性能なマルチメディアソリューションを必要とする際に、Unityストアからこれをダウンロードしていた
  • Windows、UWP、Android を対象としている

Unityストアでの禁止

  • 2023年夏の終わり、Unityから次のようなメールを受け取り、パブリッシャーアカウントが即座に停止された
  • 数か月にわたる遅いメールのやり取りを通じて妥協を試みたが、Unityは LGPL コードをアセットから除外することを含め、Unityストアへの復帰を歓迎しないとした
  • 現在のUnityストアには LGPL 依存関係（例: FFmpeg）を含む数百のUnityアセットがあり、この執行は完全に無作為に見える
  • Unity自身も、エディタとランタイムの両方ですでに LGPL 依存関係を使用中。Unityは Lame、libiconv、libwebsockets、websockify.js などのライブラリを基盤として構築されている
  • Unityは LGPL オープンソースライブラリを利用し恩恵を受けている一方で、Unityストアを通じてはパブリッシャーやUnityユーザーがそれを行えない

Videolabsストアの紹介

  • Unityアセットが削除された後、既存および新規の顧客が VLC for Unity の状況について問い合わせてきた
  • LibVLC SDK と関連技術（例: FFmpeg）を利用している企業は多い
  • そこで Videolabs のWebサイトに簡易ストアを開設し、Unityストアになくても オープンソースの VLC Unity プラグインのバイナリを購入できるようにした

柔軟なマルチメディアコンサルティングパッケージ

  • ユーザーが問題に直面したり新機能を要望したりした際、コミュニティが支援できるものの、少数のボランティアの限られた時間だけでは十分ではない。
  • オープンソースプロジェクトのメンテナーと商用利用者の双方にとって、特定プロジェクトに関する明確な製品・サービス提供が最善である。
  • Videolabsストアでは、LibVLC と FFmpeg 向けに 3時間、10時間、24時間のマルチメディアコンサルティングパッケージを提供している。
  • どのOSプラットフォームやツールキットを使っていても、支援できる。

その他の製品

  • LibVLCSharp 商用ライセンスと LibVLC 電子書籍を Videolabsストアで見つけることができ、Kyber（超低遅延のゲーム/デスクトップストリーミングおよびリモート制御SDK）や Unreal など、他のゲームエンジン統合製品も近日公開予定。

GN⁺の見解:

  • Unityが LGPL ライブラリを使用しながら、Unityストアでは LGPL コードを含むアセットの利用を禁じるのは、二重基準な姿勢と見なせる。
  • この状況はオープンソースコミュニティと商用ユーザーの関係に重要な影響を与える可能性があり、オープンソースプロジェクトの持続可能性に関する議論を促す。
  • Videolabsストアの設立は、Unityストアの制限を回避し、VLC for Unity 統合のようなオープンソースアセットの保守と配布を継続できる新たな方法を示している。

関連記事

1件のコメント

 
GN⁺ 2024-01-13
Hacker Newsの意見

  • LGPL v1の原著者は、1991年ごろにはアプリストアや署名済みバイナリのようなものを想定していなかった。動的リンクは、ユーザーがライブラリコードを簡単にアップグレードできる方法を提供していた。

    • iOSなどではユーザーがライブラリを更新できないため、LGPLコードをそのようなプラットフォームで配布するのは不可能だと考える。
    • Unityのクロスプラットフォーム対応が重要であることを考えると、実際のOS上でのみ配布しない限り、別のライブラリを探すべきだろう。

  • UnityがVLCプロジェクトをLGPLソフトウェアの使用を理由に禁止するのであれば、「相互確証破壊ロビー/ギルド」が必要かもしれない。

    • このギルドは、他のプロジェクトがLGPLコードを使用していることを根拠に、Unityに対して個別訴訟を提起し、差別に関するさまざまな法的先例を活用することになるだろう。
    • このやり方なら、特定のプロジェクトだけを不当に標的にすることは不可能になるだろう。

  • 法の文言と精神の違いを理解する知恵や意志を、どこかで失ってしまった。

    • 富と権力が正しさの判断を圧倒することを許したとき、私たちは魂を売ったのだ。
    • Unityが本当の力を発揮したいのなら、愚かな法律から自分たちを守るために作られた性急な方針を捨てることから始めるべきだ。
    • Unityは特許/著作権/商標トロールと戦うための戦費を蓄え、エコシステム内のプロジェクトを守ることで、他の大企業に手本を示すことができる。

  • "VLC for Unity (Android)", "VLC for Unity (UWP)", "VLC for Unity (Windows)"パッケージが廃止されたというのは、単なる廃止ではなく、禁止に等しい。

  • Unityが独自のマルチメディアエンジンを開発して販売しようとしているのだとしても驚かない。こういう悪しき慣行を見ると、政治に関わりたくなる。

  • UnityストアでLGPLコードを許可しない理由について、合理的な説明がない。Unityストアの仕組みをよく知らないので、何か見落としているのかもしれない。

  • LGPLは、エンドユーザーにLGPL部分を修正版に差し替える権利を与えるが、Unityアプリをダウンロードしたユーザーはアプリの一部を変更できない。

    • したがって、LGPLライブラリを使うソフトウェアは、Unityや大半の現代的なアプリストアで配布しながらLGPLを遵守することはできない。

  • （VideoLAN会長による免責事項）VLC-Unityプラグインは完全にオープンソースであり、十分なスキルを持つ人なら誰でも自分でビルドできる。

    • Unityとの協議を何か月も試みたが、悪夢のようだった。Apple AppStore、Google Playストア、Windowsストアとは何年も議論してきたが、Unityは返答がないか、互いに矛盾する返答、そして明らかな悪意を見せた。
    • 実際のところ、UnityはLGPLとオープンソースを使ってプラットフォームを構築しておきながら、ストアではオープンソースを認めないのか？ LGPLの上に別ライセンスのレイヤーを追加することすらだめなのか？ なぜ私たちはだめなのか？ 他の人たちはどうやっているのか？
    • 非常に腹立たしい。
    • サポートやライセンスを購入する必要がある人たちがいるため（自分でビルドしたくない人、サポート契約を必要とする購買部門など）、小さなストアが必要になる。これは普通よく見るものとは違うが、必要があるからこそ、そのような小規模ストアが存在する。
    • HNユーザーの大半は自分でビルドすべきだ。それをできるだけの十分なスキルがあるべきだ。

  • VLC（およびVideoLAN）のソフトウェア特許に対する立場はよく知られており、ソフトウェア特許を望む人や、ソフトウェア特許による攻撃を受けている人には受け入れがたいかもしれない。

  • ビデオゲーム開発者ではないが、VideoLANがGodot向けのVLCプラグインを作るのがよい判断かどうか気になる。Godotはまだ勢いを増している段階で、Unityのような内蔵メディアスタックを持っているが、かなり制限されている。

  • SteamもGPLライセンスのコードを許可していない。SteamWorksへのリンクが必要なら、その文書を参照してほしい。