유니티의 오픈소스 이중잣대: VLC 차단

 (mfkl.github.io)
4P by GN⁺ | ★ favorite | 댓글 4개
  • 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시간이며, 1회성 서비스나 월 구독으로 구매할 수 있음
    • 지원 범위는 커스텀 빌드, 버그 수정, SDK 통합, 특정 요구사항에 대한 질의응답을 포함함
    • 운영체제 플랫폼이나 툴킷과 관계없이 지원 가능함
  • Store에는 LibVLCSharp 상용 라이선스와 LibVLC ebook도 포함됨
  • 예정 제품으로는 초저지연 게임·데스크톱 스트리밍 및 원격 제어 SDK인 Kyber, Unreal 같은 추가 게임 엔진 통합이 있음

함께 보면 좋은 글 β

sonohoshi   [-]

엔진도 제대로 못만드는 회사가 뻘짓이란 뻘짓은 다 하눈군요ㅋㅋ

답변달기
mhcoma   [-]

막연하고 극단적인 생각이지만 기술업계에서 이해할 수 없는 문제가 생기면 거의 양복쟁이들 탓이 아닌가 싶네요.

답변달기
y15un   [-]

유니티가 또...

라이선싱 관련으로 회사가 망하기 전까지 가봤으면서 또 사람들을 빡치게 만드네요ㅎㅎ

답변달기
GN⁺   [-]
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년에도 HN에서조차 LGPL의 구체적 의미나 구현 요구사항을 아무도 확실히 모른다는 게 이상함
      이렇게 복잡하고 혼란스럽고 해석에 맡겨지는 상태라면, 사람들이 실제로 이해할 수 있는 더 나은 새 라이선스 체계를 만들 여지가 분명 있음
      MIT 같은 라이선스는 모두가 비교적 명확히 이해하지만, 여러 GPL 계열과 더 복잡한 맞춤형 라이선스들은 더 나은 무언가로 대체되는 게 이상적임
    • Unity 자체나 Unity 기반 게임이 LGPL 구성요소를 쓰는지는 핵심이 아님
      여기서 중요한 건 Unity Asset Store에 무엇을 허용하느냐임
      Unity가 Unity 게임에 링크될 수 있는 모든 것을 스토어에 허용해야 할 의무는 없고, 당시 제공자 계약은 단순히 LGPL 에셋을 스토어에서 팔 수 없다고 했던 것으로 보임
      스토어가 추가 요구사항을 두는 건 놀랍거나 부당하지 않으며, 제3자 콘텐츠 배포자로서 위험을 줄이는 이유도 있음
      또 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에는 티보화 방지 조항이 없어서, 최종 사용자가 잠긴 플랫폼 때문에 프로그램을 다시 링크할 수 없어도 문제가 없다는 뜻임
    하지만 websockify.js와 아마 다른 의존성들은 LGPL v3이고, 이는 최종 사용자가 해당 구성요소를 교체할 수 없는 Nintendo Switch 같은 플랫폼에 포함될 수 없다는 의미로 보임
    Unity가 이런 구성요소를 잠긴 플랫폼에서 제외하고 있는 건지, 아니면 단순히 LGPL v3를 위반하고 있는 건지 궁금함

    • 바로잡아보겠음. 다행히 틀린 부분은 아마 99%가 *GPLv3에 대해 틀리는 지점인 티보화 방지 조항의 범위임
      이 조항은 Tivo가 하던 일을 막기 위해 꽤 좁게 작성됐음. 즉, 잠긴 운영체제가 들어간 기기를 팔면서 *GPLv3 소프트웨어를 포함하는 경우를 겨냥함
      적용되려면 소프트웨어가 “사용자 제품” 안에서 전달되고, 그 전달이 제품의 소유 및 사용 권리가 수령자에게 이전되는 거래의 일부여야 함
      “사용자 제품”은 보통 개인·가족·가정용으로 쓰이는 유형 개인 재산이거나 주거 공간에 편입되도록 설계·판매되는 것을 뜻함
      Nintendo Switch의 경우 Nintendo는 Switch 자체나 구매 시 함께 제공되는 것에 *GPLv3 소프트웨어를 넣을 수 없다는 뜻임
      나중에 받아 설치하는 추가 소프트웨어, Nintendo 온라인 스토어나 물리 매체로 판매되는 소프트웨어는 티보화 방지 조항의 적용 대상이 아님
      따라서 그 조항만 놓고 보면 Unity가 잠긴 플랫폼용으로 *GPLv3 코드를 포함하거나, 개발자가 Unity로 그 플랫폼용 게임을 만드는 데에는 문제가 없음
      문제가 될 수 있는 건 *GPLv3의 다른 부분임. Apple이나 Nintendo 같은 앱 스토어를 통해 소프트웨어를 배포하고 구매하면, 다운로드 사본을 만들고 배포하는 주체는 Apple이나 Nintendo임
      저작권자로부터 허락을 받았으면 괜찮지만, 이런 스토어를 쓰려면 보통 재배포나 역공학을 금지하는 약관에 동의해야 하고, 이것이 *GPLv3 위반임
      저작권자가 사용한 모든 코드의 저작권을 보유했다면 Apple이나 Nintendo에 배포 허가를 줄 수 있음
      그러나 앱이나 게임에 제3자 *GPL 라이브러리를 포함했고 그 제3자가 스토어 운영자에게 그런 라이선스를 부여하지 않았다면, 그 앱이나 게임은 해당 스토어에서 배포될 수 없음
    • 맞음. 지금 찾을 수 있는 관련 글로는 이게 제일 나아 보임: 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가 구현한 알고리즘에 특허를 가진 제3자를 화나게 하는 걸 걱정하고 있고, 그 비공개 거래의 세부사항을 숨기려고 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는 정말 끔찍한 회사임

답변달기