ElasticSearch를 둘러싼 AWS와 Elastic의 대립
(blog.opsnow.com)최근에 올라온 Elasticsearch의 오픈 소스 포기, SSPL 선언과 AWS가 별도로 Fork 후에 Apache License 2.0의 오픈 소스 커뮤니티를 유지하겠다는 기사들을 접하고 과거부터 벌어진 둘 사이의 대립을 요약해봤습니다.
중간중간 부족하거나 잘못된 부분은 코멘트 주시면 반영될 예정입니다.
전 개인적으로 OSI에서 왜 SSPL을 오픈소스 라이센스 등재 취소를 한 건지 잘 이해가 안가요. AGPL에서 좀 더 구체화한 라이센스인데 SaaS 사업자에게 모든 소스를 공개하라 걸로 이해했는데, OSI는 이를 SaaS를 "제한"하는 걸로 해석하는게 잘 이해가 안가요.
OSI 의 입장문 [1]을 봐도 Elastic의 SSPL도입 의도를 꼬집고 있지 SSPL의 어느 조항이 이용을 "제한"하고 있는지 설명을 안하고요. 내용 읽어보면 AGPL에 비해 "제한"을 두고있는지 잘 모르겠어요. 제가 라이센스 해석을 잘못하고 있는건지...
[1]: https://opensource.org/node/1099
라이센스에 대해서 취소한건 MongoDB였습니다. OSI가 거절한게 아니었어요. 물론 OSI에서도 논란이 있는 부분에 대해서 오픈 소스로 인정하기 어렵다는 반응이긴 하지만, 이런 상황을 사전에 파악하고 MongoDB측에서 신청을 철회해버린 것이죠.
정정 감사합니다. 제가 서술이 좀 부정확했네요. 그래도 MongoDB가 먼저 철회한건 맞긴 하지만 링크에 제시된 OSI 게시물을 봐도 OSI는 현재 버전의 SSPL을 받아들일 생각이 없음을 분명히 하고 있어서...전후관계가 그리 중요한거 같아보이진 않네요.
저도 좀 의문이 있어 검색 중인데요, 이런 자료가 있어서 링크해 봅니다.
https://ceart.kr/component/file/…
발췌
우선 SSPL이 AGPL과 다른 점은 다음과 같다. 이전의 AGPL은 어떤 소프트웨어가 배포되지 않고, 서버 사이드에서 실행될 때도, GPL과 같이 서비스 제공자가 그 소프트웨어에 대하여 행한 수정 및 추가된 부분의 모든 소스코드를 공개해야 한다는 것으로, 서버 그 자체에 한정하고 있는 것에 반하여,
SSPL은 해당 코드뿐만 아니라, As-a-Service 형태로 제공할 때 부수적으로 필요한 관리 소프트웨어, 사용자 인터페이스, API, 자동화 소프트웨어, 모니터링 소프트웨어, 백업 및 저장 소프트웨어 등 As-a-Service 사용자가 실행하는 모든 소프트웨어의 코드를 공개해야 하는 조건이다. 다시 말해 클라우드 사업자들이 MongoDB를 서비스 형태로 제공할 때, 자신의 서비스 경쟁 우위를 유지하기 위해 만든 모든 소프트웨어의 소스 코드까지를 모두 공개해야 한다는 조건인 것이다.
추가로 pdf 보시면 osi 에 부합하지 않는 부분이 어떤 내용인지 설명도 되어 있습니다. 자유의 제약과 별도 저작물 제한이라는 점이라고 하네요.
오...전반적으로 훌륭히 잘 작성된 pdf네요. 링크 감사합니다.
이렇게 보니 AGPL과 다른 점이랑 SSPL을 허용안하는 이유는 이해하겠는데, OSI가 다소 Permissive 함에 치우쳐 있는게 아닌가 하는 생각이 드네요.
관련 글 보기
https://news.hada.io/topic?id=3620 - AWS가 Elasticsearch와 Kibana의 오픈소스 fork 발표
https://news.hada.io/topic?id=3606 - Elastic, AWS가 사용 못하게 라이센스 변경