Unityのオープンソース二重基準：VLCをブロック

 (mfkl.github.io)
4 ポイント 投稿者 GN⁺ 2025-05-08 | 4件のコメント | WhatsAppで共有
  • VLC for Unityは、UnityゲームエンジンとVLCマルチメディアエンジンをつなぐオープンソース統合で、2019年12月からUnity Storeでプラットフォーム別バイナリを配布してきた
  • 2023年夏の終わりにUnityからメールが届いた後、パブリッシャーアカウントが即座にブロックされ、数カ月にわたる協議やLGPLコードを除外する提案にもかかわらず、Storeへの復帰は認められなかった
  • Unity Storeには、FFmpegのようなLGPL依存関係を含むアセットが多数残っており、Unity Editorとランタイム自体もLame、libiconv、libwebsockets、websockify.jsといったLGPLライブラリを使用している
  • アセット削除後、顧客から保守やビルド更新について問い合わせが寄せられたため、Videolabsは自社サイトにVideolabs Storeを開設し、Unity Storeなしでもバイナリ販売を始めた
  • Videolabs Storeは、VLC Unityプラグインのバイナリに加え、LibVLC・FFmpegの商用サポート体制、LibVLCSharpライセンス、LibVLC ebook、Kyber、Unreal統合予定製品も扱う

Unity StoreでブロックされたVLC for Unity

  • VLC for Unityは、UnityベースのゲームでVLCエンジンを活用したメディアプレーヤーを作れるようにするブリッジ統合である
  • UnityはMonoを通じて、LibVLCは自前で高い移植性を備えており、この統合はクロスプラットフォーム利用を目指している
  • Unity Storeでは2019年12月から、VLC for Unityのオープンソース統合バイナリが配布されており、対象プラットフォームは3つだった
    • Windows
    • UWP
    • Android
  • 2023年夏の終わりにUnityがメールを送った後、パブリッシャーアカウントが即座にブロックされた
  • その後、数カ月にわたりメールで妥協点を探り、アセットからLGPLコードを除外することまで提案したが、UnityはStoreへの復帰を認めなかった
    • UnityパッケージからすべてのLGPLコードを削除しても復帰できない、との回答を受けた
  • Unity Storeには、FFmpegのようなLGPL依存関係を含むアセットが現在も数百から数千存在する
  • Unity自体もEditorとランタイムでLGPL依存関係を使用しており、これはUnityで配布されたゲームにも影響する
    • 例示ライブラリとしてLame、libiconv、libwebsockets、websockify.jsが挙げられている
    • Unityのオープンソース依存関係の全リストは別リストで確認できる
  • 主要な対立点は、UnityがLGPLのオープンソースライブラリを使いながら、Unity StoreのパブリッシャーとユーザーによるLGPLベースの配布は認めないという二重基準にある

Videolabs Storeと商用サポート

  • VLC for Unityアセットが削除された後、既存・新規の顧客から保守の有無やビルド更新方法について問い合わせがあった
  • 多くの企業がLibVLC SDKやFFmpegのような関連技術を使用しているため、Videolabsは自社のVideolabs Storeを開設することにした
  • 既存および新規顧客は、Unity StoreなしでもオープンソースVLC Unityプラグインのバイナリを購入できる
  • VLC for Unityはオープンソースなので、ユーザーが自分でビルドすることも可能である
  • Videolabs Storeは、LibVLCとFFmpegについて製品・サービス提供の仕組みを明確にするための窓口となる
  • 一部のユーザーは問題解決や新機能を求めているが、コミュニティと少数のボランティアの限られた時間だけでは対応に限界がある
  • VideolabsチームはVLCとFFmpegの専門家で構成されており、複数のプロトコル・フォーマット・プラットフォームを扱う
  • 提供されるマルチメディアコンサルティングパッケージは3時間、10時間、24時間で、単発サービスまたは月額サブスクリプションとして購入できる
    • サポート範囲には、カスタムビルド、バグ修正、SDK統合、特定要件に関するQ&Aが含まれる
    • OSプラットフォームやツールキットに関係なくサポート可能である
  • StoreにはLibVLCSharp商用ライセンスとLibVLC ebookも含まれる
  • 予定製品として、超低遅延のゲーム・デスクトップストリーミングおよびリモート制御SDKであるKyber、Unrealのような追加ゲームエンジン統合がある

関連記事

4件のコメント

 
sonohoshi 2025-05-10

エンジンもまともに作れない会社が、くだらないことばかりやってるんですね（笑）
 
mhcoma 2025-05-09

漠然として極端な考えですが、技術業界で理解できない問題が起きると、たいていはスーツ組のせいではないかと思ってしまいます。
 
y15un 2025-05-08

Unityはまたか…

ライセンス問題で会社が潰れかけるところまで行ったのに、また人々をイラつかせていますね（笑）
 
GN⁺ 2025-05-08
Hacker Newsのコメント

  • 法務チームが誤った情報を受け取り、契約に入れてしまったのは明らかに見える
    記事で述べられているように、Unityアセットのかなり多くがLGPL依存関係を使っており、Unity自体もLGPLアセットを使用し、Unityで作られたリリース済みゲームにもLGPLアセットが含まれている
    意図としてはおそらく、GPL依存関係だけを除外しようとしていた可能性が高い
    GPLとLGPLには大きな違いがあり、LGPLは一定の条件を守れば、プロプライエタリなアプリケーションがオープンソースライブラリにリンクしてもアプリケーションのソース公開を求めないように設計されたライセンスである
    一方GPLは、GPLコードが含まれる派生物全体をGPLで配布し、ソースコードも公開しなければならないという、より厳格な要求がある

    • Unityアプリの配布方法はよく知らないが、LGPL条件を満たす方法でしか配布されないよう設計されていると考えるなら、少し驚くと思う
      例えば署名が必須のプラットフォームのストアでのみ配布されるアプリは、ユーザーがLGPLコンポーネントを修正できないため、LGPLコンポーネントを含められないと思っていた
      法的な細部はさておき、LGPLはGPLより柔軟ではあるが、それでもかなり制約があるため、プロプライエタリソフトウェアでは構成をシンプルに保つか、関連分野の専門弁護士に相談して準拠状況を慎重に確認すべきである
      その意味で、UnityがLGPLソフトウェアを禁止するのは理解できる。正しく対応できないという意味ではなく、ストアに上がるすべてのアセットをUnityや提供者が毎回法的にレビューするのは現実的ではないからだ
    • ソフトウェアライセンスの話は毎回、論争と相反する解釈の洪水になっていく
      2025年になっても、Hacker NewsでさえLGPLの具体的な意味や実装上の要件を誰も確実には分かっていないというのは奇妙だ
      これほど複雑で混乱しており、解釈に委ねられている状態なら、人々が実際に理解できる、より良い新しいライセンス体系を作る余地は明らかにある
      MITのようなライセンスは誰もが比較的明確に理解しているが、複数のGPL系や、より複雑なカスタムライセンスは、理想的には何かより良いものに置き換えられるべきだ
    • Unity自体やUnityベースのゲームがLGPLコンポーネントを使っているかどうかは本質ではない
      ここで重要なのは、Unity Asset Storeに何を許可するかである
      Unityには、Unityゲームにリンクされ得るものすべてをストアで許可する義務はなく、当時の提供者契約は単にLGPLアセットをストアで販売できないとしていたように見える
      ストアが追加要件を設けることは驚くことでも不当でもなく、第三者コンテンツの配布者としてリスクを減らす理由もある
      また、Unity Asset Storeのアセットは必ずUnityでのみ使わなければならないわけでもなく、一部のアセットはライセンスによって他のエンジンでも使用できる: https://support.unity.com/hc/en-us/articles/34387186019988-C...
      ただし、LGPLコンポーネントが入った他のアセットを引き続き配布しながら、LGPLルールを一貫して適用していないことの方が問題になる
    • LGPLはそれほど単純ではない
      LGPLは基本的に、ユーザーがオープンソースライブラリを修正し、再ビルドし、その新しいライブラリを既存のアプリケーションに再統合できなければならないと要求している
      LGPLライブラリを使う開発者はこれを「可能に」しなければならないが、実際に何を意味するかには解釈の余地が大きい
      弁護士や企業がLGPLを敬遠する理由も、GPLより多くの解釈の余地が含まれているからだ
    • その条件は、ライブラリが動的リンクされていなければならないという意味である
      ここでその前提が成り立つのかはよく分からない

  • Unityの弁護士たちが会社を壊し続けているが、特に驚きはない
    以前そこで働いていたが、技術的成果は誇らしかった一方で、それ以外のほぼすべては恥ずかしかった

  • 訂正: 実際には関係があり、VLCのコア開発者の大半がVideoLabsで働いていた
    元のコメントは残しておく
    このブログ記事は https://videolabs.io にある「VideoLab Store」へリンクしているが、VLC（VideoLANの略であり、VideoLabではない）のロゴに非常によく似ているものの同一ではないロゴを大きく使っている
    ホームページには「Hire the VLC team」という文句まで掲げられている
    私の知る限りVideoLabはVideoLANの非営利団体とは無関係で、VLC開発者であるかのように人々を誤認させようとしているように見えた

    • VideoLANの会長です
      現在VideoLabsはVLCのコア開発者の大半を雇用しており、その人たちがVLC開発の主な原動力です
      このような構成にしている理由は、Videolabsという会社が永続しなくても、VLCは永遠に自由ソフトウェアであり続け、非営利団体も存続し続けるようにするためです
      オープンソースプロジェクトではかなり典型的な構造で、VideoLANの場合、コンサルティングを行う会社が3〜4社あります
    • VideoLabsは、VLC/VideoLANの創設者の一人であり、VideoLAN非営利団体の会長でもある人物が設立した会社です
      本質的には、VLCの主要貢献者の大半を雇用して給与を払い、そのエコシステムで働いてもらい、コンサルティングやその他のサービスでそれを資金面から支える営利法人です
      VLCのコードベースにもかなり多く貢献しています
      パートナーシップで一緒に仕事をした立場から付け加えると、「営利」は主に法的形態にすぎず、考え方としてはそうではありませんでした
    • 投稿者はブログにVideoLANプロジェクトのGitリポジトリへのリンクを目立つように置いており、そこでプロジェクトにも貢献しています: https://code.videolan.org/videolan/LibVLCSharp
      さらにVideolabsは https://www.videolan.org/videolan/partners.html にも掲載されています
      プロジェクト側はその会社をよく知っているようです
    • 紹介ページによると、VideolabsはVideoLANコミュニティから生まれ、モバイル向けVLCポートのメンテナンスから始まりました
      現在はVLCの主要貢献者として、歴史的な開発者たちを雇用し、VLCおよびFFmpegエコシステム周辺のカスタムソリューションを作っています
    • CTOがVideoLAN非営利団体の会長なので、正確な表現のようです
      紹介ページによると、彼らがVLCの主なメンテナーだとのことです

  • 私が間違っていたら訂正してほしい
    私の理解では、LGPL v2 のコードを使うことはコンソールでのリリースでも問題ない。v2 にはTivo化防止条項がないので、ロックされたプラットフォームのせいでエンドユーザーがプログラムを再リンクできなくても問題にならない、という意味だと思う
    しかし websockify.js と、おそらく他の依存関係は LGPL v3 であり、これはエンドユーザーがそのコンポーネントを差し替えられない Nintendo Switch のようなプラットフォームには含められない、という意味に見える
    Unity がこうしたコンポーネントをロックされたプラットフォームでは除外しているのか、それとも単に LGPL v3 に違反しているのか気になる

    • 訂正してみる。幸い、間違っている部分はおそらく 99% が *GPLv3 について間違える点、つまりTivo化防止条項の範囲だと思う
      この条項は、Tivo がやっていたことを防ぐために、かなり狭く書かれている。つまり、ロックされた OS が入った機器を販売し、その中に *GPLv3 ソフトウェアを含める場合を対象にしている
      適用されるには、ソフトウェアが「ユーザー製品」の中で伝達され、その伝達が製品の所有権および使用権を受領者へ移転する取引の一部でなければならない
      「ユーザー製品」とは通常、個人・家族・家庭用に使われる有形の個人財産、または住居空間に組み込まれるよう設計・販売されるものを意味する
      Nintendo Switch の場合、Nintendo は Switch 本体や購入時に同梱されるものに *GPLv3 ソフトウェアを入れられない、という意味になる
      後から入手してインストールする追加ソフトウェア、Nintendo のオンラインストアや物理メディアで販売されるソフトウェアは、Tivo化防止条項の適用対象ではない
      したがって、その条項だけを見れば、Unity がロックされたプラットフォーム向けに *GPLv3 コードを含めることや、開発者が Unity でそのプラットフォーム向けゲームを作ることには問題がない
      問題になり得るのは *GPLv3 の別の部分だ。Apple や Nintendo のようなアプリストアを通じてソフトウェアを配布・購入すると、ダウンロード用コピーを作成して配布する主体は Apple や Nintendo になる
      著作権者から許可を得ていれば問題ないが、こうしたストアを使うには通常、再配布やリバースエンジニアリングを禁止する規約に同意しなければならず、これが *GPLv3 違反になる
      著作権者が使用したすべてのコードの著作権を保有しているなら、Apple や Nintendo に配布許可を与えられる
      しかし、アプリやゲームに第三者の *GPL ライブラリを含めていて、その第三者がストア運営者にそのようなライセンスを付与していないなら、そのアプリやゲームはそのストアで配布できない
    • その通り。今見つけられる関連投稿としては、これが一番よさそう: https://opensource.stackexchange.com/questions/7387/what-is-...
      リンク切れの内容をコピーしたもの
      Apple も Unity と同じ問題を抱えている。macOS で % bash --version を実行すると GNU bash 3.2.57 が出るが、GPL v2 の最後のリリースである 3.2 以降に上げられないため、古いバージョンを自前で保守している
      米国基準では、喫煙し、投票し、参戦できるほど古いバージョンで、Apple はユーザーを zsh に移行させようとしている
      LGPL 2.1 を見たが、ライセンスの “or later” 部分が奇妙だ。ユーザーは裁量で GPL 2.1 以上の任意のバージョンに変更できる
      ただしライブラリ作者は COPYING ファイルに LGPL、正確には LGPL 2.1、または推奨される “LGPL 2.1 or later” を明記しなければならない
      Unity が LGPL コードを「deprecated」と言ったのは、そのコードが LGPL のバージョンを固定していない限り理解できる。上流の LGPL 提供者が bash のように、いつでもライセンスのラグプルをできるからだ
      しかし VLC ライブラリはここで “LGPL 2.1 only” と表示されており、GPL3 にジャンプしない限りラグプルできないと明示的に主張していることになる: https://code.videolan.org/explore/projects/starred
      ただし VLC はライセンスをきちんと含めておらず、COPYING と COPYING.lib は LGPL バージョンを固定するかどうかを述べていない。README.md には libVLC, the engine is released under the LGPLv2 (or later) license. とある: https://code.videolan.org/videolan/vlc
      だから Unity の懸念はある程度もっともらしい。“or later” には v3 が含まれ、v3 はチート対策技術やコンソールのようなものとは特に相性が悪い
      ただ私の推測では、Unity は VLC が実装しているアルゴリズムの特許を持つ第三者を怒らせることを懸念していて、その非公開取引の詳細を隠すために LGPL を口実にしているのだと思う

  • Godot のほうがいい
    最近の Unity は悪いビジネス上の選択だ
    商用エンジンを選ばなければならないなら、少なくともオープンソース開発者を苦しめる代わりに、Apple と戦うために弁護士を使っている Epic Games を選ぶ

  • 興味深いことに、プロバイダー契約には 5.10.4 がないようです: https://unity.com/legal/provider
    以前はこの条項が含まれていました:
    5.10.4 Provider represents and warrants that its Assets shall not contain (a) any software licensed under the GNU General Public License or GNU Library or Lesser General Public License, or any other license with terms that include a requirement to extend such license to any modification or combined work and provide for the distribution of the combined or modified product’s source code upon demand so that Customer content becomes subject to the terms of such license; or (b) any software that is a modification or derivative of any software licensed under the GNU General Public License or Library or Lesser Public License, or any other license with terms similar thereto so that Customer content become subject to the terms of such license.
    しかし Wayback Machine によると、12月3日から12月12日の間に削除されたようです

  • プロジェクトで Unity を本当に使いたいです
    エディターと API は実際に気に入っているし、技術に詳しくない人向けにエディター内でいろいろなツールをかなり簡単に作れます
    ところが Unity は、ユーザーに敵対的な行動、「来年には安定化すると本当に約束する」といったベータ版パッケージ20個、空のプロジェクトでもひどく悪化するパフォーマンスまで、あらゆる段階で使いにくくしています
    今は主に Godot を使っていて悪くはありませんが、Unity と完全に比べられるものではありません

  • Unity が、今では deprecated としているパッケージをアップロードしたという理由でアカウントを永久停止するって？ いったい何を吸っているんでしょうか？

    • Unity が公表していない別の理由で VLC を嫌っているような気がします
      自社のメディアプレイヤーと競合するのでしょうか？ それとも VLC を作った人が Unity 幹部の元恋人と付き合ってでもいたのでしょうか？
    • Unity は「deprecated」という言葉を「removed」や「deleted」の意味で使っているように見えます
      本当にばかげた流行で、みんなで押し返すべきですが、まだそこまでは至っていません
      Unity のメモを解釈すると、VLC ライブラリを Unity Store から削除し、Unity との契約条件違反を理由に VLC グループの Unity Store アカウントを永久停止した、という意味に見えます
      企業風の専門用語は理解しにくいことがあります。もしかすると、それこそが企業風専門用語の主な目的なのかもしれません

  • Unity がまた敵対性を見せました
    こんな理由で開発者を永久停止するのは狂っています

    • 「また」というより、「インストールごとの課金」以前に、すでに Unity らしくダブルダウンしていた時期でした
      これは2023年8月、インストールごとの課金騒動より前に起きたことです

  • 驚きません。Unity は本当にひどい会社です