▲

SSPL(Server Side Public License)은 나빠요

 (ssplisbad.com)
7P by xguru 8달전 | favorite | 댓글 4개

SSPL이 나쁜 이유

  • SSPL(Server Side Public License)은 모든 사용자, 기업, 그리고 일반적으로 커뮤니티에게 끔찍한 라이선스임
  • SSPL 라이선스 제품은 오픈소스가 아니며, 클라우드 및 관리 서비스 경쟁자들을 죽이고, 호스팅 가격을 상승시키며, 오픈소스를 죽이는 것을 목표로 함
  • SSPL의 목적은 큰 회사들과 싸우기보다는 투자자들에게 돈을 돌려주는 것에 더 가까울 수 있음

SSPL이란 무엇인가

  • SSPL은 2008년 MongoDB, Inc에 의해 도입되어 MongoDB를 사용하는 것을 제한하기 위한 라이선스임
  • Elasticsearch, Kibana, Graylog과 같은 제품들도 이제 SSPL 라이선스를 사용함
  • 제13조에 따르면, 제품을 직접 고객에게 제공하고자 할 경우 "서비스 소스 코드"를 공개적으로 제공해야 함

SSPL이 모두에게 나쁜 이유

  • SSPL은 몇몇 악의적인 클라우드 회사들이 커뮤니티에 기여하지 않고 이익을 내는 것을 방지하기 위한 좋은 해결책으로 제시되었지만, 실제로는 자유에 대한 위협이자 경쟁자를 죽이는 라이선스임
  • 이 라이선스는 오픈소스였던 제품을 '무료'라는 거짓된 정신 뒤에 숨겨 상업용 제품에 가두는 것에 불과. 이제 이러한 소프트웨어를 "Freemium" 소프트웨어라고 불러야 할지도
  • MongoDB, Elasticsearch, Kibana, Graylog은 더 이상 오픈소스 제품이 아니며, 이들 회사는 이제 고객에게 제품을 제안할 수 있는 사람을 완전히 결정할 수 있음. 이는 경쟁자를 죽이는 것이 됨
  • 경쟁자 없이도 자체 클라우드 호스팅 솔루션을 제공할 수 있게 되었으며, 소스 코드를 공개하지 않고, 그들이 정의한 수수료로 경쟁과 혁신을 죽일 수 있음
  • 이는 고객인 우리에게는 더 이상 클라우드 제공업체를 선택할 수 있는 권한이 없다는 것을 의미
  • 기계적으로 호스팅 가격은 인상될 것이고 우리의 유일한 선택은 자체 인프라에서 호스팅 부분을 관리할 전담팀을 두는 정도임. 바로 지난 몇년간 클라우드 호스팅 솔루션들로부터 피하려고 했던 것들

SSPL을 사용하는 회사들

  • MongoDB 제품은 2018년부터 SSPL 라이선스를 사용하고 있으며, MongoDB, Inc가 그 배후에 있음
  • Elasticsearch 제품은 2021년부터 SSPL 라이선스를 사용하고 있으며, Elastic NV가 그 배후에 있음
  • Graylog 제품은 2020년부터 SSPL 라이선스를 사용하고 있으며, GrayLog, Inc.가 그 배후에 있음

우리가 스스로에게 물어봐야 할 몇 가지 질문들

  • 오픈소스를 더 이상 사용하지 않는 회사가 어떻게 다른 이들에게 "커뮤니티에 환원"하라고 요구할 수 있는가?
  • 자신들의 클라우드 서비스 소스 코드를 공개하지 않는 회사가 어떻게 다른 이들에게 소스 코드를 공개하라고 요구할 수 있는가?
  • 비오픈소스 라이선스를 사용하면서 오픈소스가 자신들의 DNA의 일부라고 선언하는 회사는 어떻게 그럴 수 있는가?
  • 3000명이 넘는 직원 중 몇 명이 자신의 업무와 소스 코드를 커뮤니티와 공유하는가?(스포일러: 훨씬 적습니다)
  • 커뮤니티와 공유하고자 하는 기술 기업인가, 아니면 투자자의 수익을 늘리고자 하는 세일즈 기업인가?

SSPL에 대한 잘못된 주장들

  • "나는 클라우드 제공자가 아니기 때문에 관련이 없다"는 주장은 사실 모든 이들이 이 문제에 관련이 있음을 인식해야 함
  • "이 회사들은 생존을 위해 돈이 필요하다"는 주장은 오픈소스에서 돈이 나쁜 것은 아니지만, SSPL은 올바른 해결책이 아님을 이해해야 함
  • "경쟁자들은 여전히 존재한다. SSPL은 협상 가능하다"는 주장은 실제로 시장을 통제하는 회사가 경쟁자의 가격과 조건을 정할 수 있게 됨을 의미함
  • "SSPL은 큰 클라우드 행위자들과 싸우는 것이며, 작은 사업체에게 좋다"는 주장은 SSPL이 실제로 작은 경쟁자들을 파산시키고 사라지게 할 수 있음을 인식해야 함

오픈소스 프로젝트에 대한 조언

  • SSPL이 처음에는 좋은 해결책처럼 보일 수 있지만, 그 실수를 하지 말 것을 권장
  • 일부 클라우드 제공업체에 문제가 있다면 무시할 수 없으며 우리 모두가 함께 싸워야 함. 오픈소스 세계에서 벗어나서 싸우는 것은 좋은 방법이 아님
  • 수익성이 필요하다면 엔터프라이즈 라이선스와 프리미엄 지원을 이용할 것: "지원이 필요한 경우, 우리는 이를 위한 최고의 팀을 보유하고 있습니다."
  • 카피레프트 라이선스를 사용하여 기업이 커뮤니티에 환원할 수 있도록 할 것: "우리 코드를 수정하면 커뮤니티와 공유하세요"
  • 그래도 SSPL 라이선스를 선택한다면.. 당신은 :
    • 많은 독립 기여자와 대기업 직원 기여자를 잃게 됨
    • 오픈소스 소프트웨어를 개선하기 위해 노력한 기여자를 배신함
    • 오픈소스 세계를 떠나 부분 유료화(Freemium) 소프트웨어를 개발하게 됨
    • 제품을 매우 나쁜 버즈와 연관시킴
    • 전 세계에 제품을 홍보하는 데 도움을 주는 수많은 다양한 플레이어의 혜택을 잃게 되어 프리미엄 지원의 필요성이 증가
▲
aer0700 8달전  [-]

오픈소스 여서 선택할 수 있지만, 오픈소스 여서 선택지에서 배재할 때도 있지요.
Aws에서 몽고db 가져다가 DynamoDB만든 것 때문에 나온 라이센스 일텐데, 오픈소스 좋아하시는 분들 보시기엔 미심쩍을 수 있겠네요.

답변달기
▲
coremaker 8달전  [-]

AGPL 과도 비교해보면 재미있을 것 같네요.
https://sktelecom.github.io/guide/use/obligation/agpl-3.0/

답변달기
▲
xguru 8달전  [-]

도메인명과 사이트명 SSPL is BAD 에서 보이듯이, 의도를 가지고 만들어진 웹사이트 입니다.
비약이 어느 정도 심하기도 하고요. 아래 해커뉴스 의견들과 같이 보시기 바랍니다.

Hacker News 의견

  • SSPL에 대한 원칙적인 반대 의견이 있지만, 그 배경에 대한 이해도 함께 존재함. 기사 13조에 대한 묘사가 객관적 분석보다는 선정적 의도를 가졌다는 비판도 있음.

    • MongoDB와 Elastic이 AWS가 자신들의 제품을 재포장하여 서비스로 제공하고 경쟁자가 될 것으로 예상하지 못했음. Elasticsearch가 사용하던 Apache 라이선스는 이를 허용했지만, 윤리적으로는 막았어야 했다는 의견.
    • AWS가 OEM 계약이나 파트너십을 통해 '윈-윈' 관계를 형성할 수도 있었지만, 그렇게 하지 않아 SSPL 같은 불쾌한 형태의 차단을 유발했다는 지적.
    • SSPL이 투자자들을 기쁘게 하기 위해 만들어졌다는 불만이 있지만, 오픈소스 소프트웨어라 하더라도 회사가 비영리를 목적으로 한 것은 아니므로, Elastic이나 MongoDB를 비난하고 AWS를 비난하지 않는 것에 대한 이해가 안 된다는 의견.

  • SSPL은 사용자에게 나쁜 것으로, SSPL이 독점을 촉진하고 커뮤니티 참여를 줄여 결국 모든 사용자에게 영향을 미친다는 주장.

  • 사람들이 돈을 벌고자 하는 것은 당연한 일이며, SSPL 프로젝트를 사용하지 않기로 선택할 수도 있음. SSPL 라이선스로 발행된 소프트웨어가 없는 것보다는 낫다는 관점 제시.

  • 현재의 생태계가 10년 전과 크게 달라졌으며, 소규모 회사들이 경쟁에서 살아남고 성장할 수 있는 길을 원한다는 의견. BSL(비즈니스 소스 라이선스)과 같은 라이선스가 완벽하지 않을 수 있지만, 건강한 중간길을 찾기 위한 노력으로 볼 수 있음.

  • SSPL에 대한 비판을 하면서 AGPL을 언급하지 않은 것이 이상하다는 의견. 자유 소프트웨어를 사용하고자 하지만 기여를 하고 싶지 않은 사람들에 대한 지적.

  • 어떤 한 쪽에 치우치지 않고, 각 경우에 따라 다르게 접근해야 한다는 의견. SSPL이 클라우드 거대 기업에 맞서 생존하려는 일부 회사들에게는 좋을 수 있지만, 기여자들을 이용하려는 일부 회사들에게는 나쁠 수 있음.

  • MongoDB, Elasticsearch, Graylog 제품을 고객에게 직접 제안하는 것이 금지되어 있음. SSPL의 '직접'이라는 단어가 법적인 논쟁의 여지를 제공하고, 이로 인해 사람들이 우려하는 부분이 있음.

  • FSL(Functional Source License)은 Apache 2.0이나 MIT로 2년 후에 자동으로 변환되는 좋은 대안 라이선스임. 간단하고, 소스를 공개하면서 SaaS 회사가 기능할 수 있는 합리적인 방법을 제공함.

  • SSPL이 2008년에 도입되었다는 잘못된 정보에 대한 정정. 실제로는 2018년에 도입됨.

  • 저작권의 미래에 대한 한 가지 차원적인 관점에 대한 비판.

답변달기