지난 1월 15일 Elastic은 오픈(개방형) 강화를 위한 변화, Part II라는 글을 공개하고 AWS는 Stepping up for a truly open source Elasticsearch라는 글고 반박하며 대응에 나섰다. 이 이슈가 몇 주간 개발자 커뮤니티의 주목을 끌고 있다.

이건 꽤 복잡한 사건인데 일단 상황을 요약해 보자.

1. 2018년 2월 Elastic은 오픈양을 두 배로 늘립니다라는 글을 통해 Elasticsearch의 상용 확장팩인 X-Pack이 Elastic EULA 라이센스의 적용을 받는 코드로 공개한다고 발표합니다. Elasticsearch의 소스코드는 Apache 2.0이고 상용 기능인 X-Pack이 포함된 폴더는 Elastic 라이센스가 적용된다는 의미이다.
2. Amazon Elasticsearch Service를 운영하는 AWS는 2019년 3월 오픈 소스가 지속하기 위한 노력 – Open Distro for Elasticsearch라는 글을 통해 Elasticsearch에 오픈 소스에 상용 소스 코드가 섞이게 되었고 구분도 명확하지 않아서 문제가 된다며 Open Distro for Elasticsearch를 공개한다. 이 Open Distro for Elasticsearch에는 X-Pack에 포함되어 있던 보안 등의 기능이 포함되어 있다.
3. 2021년 1월 Elastic은 다시 오픈(개방형) 강화를 위한 변화, Part II라는 글을 통해 7.11버전부터 Elasticsearch와 Kibana의 라이센스를 Apache 2.0에서 SSPL(Server Side Public License)과 Elastic 라이센스 듀얼 라이센스로 변경하겠다고 발표한다. 동시에 오픈소스 커뮤니티에 기여하지 않고 이득만 취한다고 AWS를 비난한다.
   
   
   • SSPL(Server Side Public License)은 거의 비슷한 이슈로 MongoDB가 만든 라이센스이다.
   • SSPL이 적용된다는 의미는 Elasticsearch와 Kibana를 서비스로 제공할 때 서비스 제공에 필요한 관리 계층의 코드와 수정 사항도 공개해야 한다는 의미이다.
4. 이에 AWS는 강력히 대응하여 Stepping up for a truly open source Elasticsearch라는 글을 통해 그동안 많은 기여를 했으며 Elasticsearch는 이제 오픈소스가 아니라며 Apache 2.0 라이센스의 Elasticsearch를 포크해서 곧 공개한 후 직접 운영하겠다고 밝힌다.
5. 이 와중에 오픈소스 이니셔티브(OSI)는 The SSPL is Not an Open Source License에서 SSPL이 OSD(The Open Source Definition) 6번 조항 "특정 분야에서 프로그램의 사용을 제한하면 안된다"를 어겼기 때문에 오픈소스가 아니라고 밝힌다. 그래서 Elasticsearch와 Kibana는 소스가 공개된 프로젝트이지만 OSI에서 정의하는 오픈소스라고 말할 수 없게 되었다.

한 줄 요약하면 Elastic이 AWS를 막기 위해 라이센스를 변경했고 AWS가 fork를 발표하면서 양쪽 다 강수를 둔 상태이다.

작년 AWS가 Open Distro for Elasticsearch를 발표했을 때부터 호스팅하는 오픈소스와 클라우드 프로바이더 간에 싸움에 관심을 가지기 시작했고 재작년 stdout.fm 팟캐스트에서도 비슷한 얘기를 나누었다.

1년 넘게 정리해서 글을 써야지 생각했지만 어려운 주제라 미루고 있다가 이번에 다시 이슈가 되면서 정리를 해 봤다. 결론부터 얘기하자면 나는 Elastic쪽에 많이 기울어져 있다.

이 글에서 다루지 않을 내용

AWS와 Elastic의 사건이 최근에 발생해서 그 얘기를 하겠지만 이러한 분쟁은 SaaS 형태로 서비스를 하려는 오픈소스 회사와 수많은 SaaS를 가진 클라우드 프로바이더 간에 계속 발생할 문제라고 생각하고 있다. 그렇다 보니 양사의 세세한 발언이나 과거 제품이나 서비스에서 잘했거나 잘못했던 행위는 중요치 않다고 생각하고 이 글에서 많이 다루진 않을 예정이다.

Elastic이 커뮤니티에 컨트리뷰션을 안 하고 이득을 취하고 있다고 하고 AWS는 업스트림에 계속 코드를 제출하고 있다고 했지만 이 부분도 이글에서는 다루지 않을 예정이다. 어느 정도 기여를 해야 자격이 생긴다는 같은 기준은 있지도 않고 앞으로도 있을 것 같지도 않다. 클라우드 프로바이더 아니라 다른 회사들도 기여를 해야 사용할 자격이 생기는 건 아니다. 이 부분을 얘기하다 보면 주제가 벗어난다고 생각하고 있다.

Elastic의 라이센스 변경은 괜찮은가?

문제가 없다고 생각한다. 현재 Elasticsearch의 저장소를보면 CLA(Contributor License Agreement)를 받고 있기 때문에(CLA를 안 받았으면 문제도 있을 수 있겠지만...) Elastic 직원이 아니더라도 컨트리뷰터가 코드를 제출할 때 CLA로 소유권을 넘겼으므로 라이센스를 Elastic에서 바꿀 수 있다. CLA를 받는 프로젝트도 있고 아닌 프로젝트도 있어서 법적으로 차이를 잘 알지는 않지만, CLA가 있으면 일단 이런 변경을 할 때 가장 쉬운 방법으로 알고 있다. CLA를 받지 않았다면 이런 변경을 할 때 기존 기여자들의 동의를 다 받아야 할 수 있다.

이번엔 결과적으로 오픈소스가 아니라고 판정(?)받은 SSPL로 변경했지만 다양한 사유로 라이센스를 변경하거나 듀얼 라이센스를 적용하는 일은 자주 발생하는 일이고 그 때문에 오픈소스 프로젝트이면서도 CLA를 받는 것이다. 어떤 일이 있을지 모를 미래에 대비하기 위함이다. 안타깝게 오픈소스 이니셔티브(이하 OSI)가 인정한 라이센스가 아니게 되어서 심정적으로 거부감이 있다고 보지만 라이센스가 충돌 나는 것도 아니라서 문제는 없다.

AWS의 fork는 괜찮은가?

AWS는 Elastic의 라이센스 변경에 대한 대응으로 elasticsearch를 포크한다는 강수를 뒀다. 개인적으로 이 수는 Elastic 입장에서는 뼈아픈 강수일 거라고 보인다. AWS에서 맘먹고 지원한다면 충분한 지원을 받은 풀타임 개발자들이 fork된 Elasticsearch를 개발할 수 있다고 생각한다. OSI가 OSD6을 이유로 SSPL은 오픈소스 라이센스가 아니라고 한 것처럼 오픈소스는 당연히 누구나 포크를 할 수 있다. 라이센스에 명시되어 있는 제약사항만 지킨다면 그 외의 행위는 당연히 가능하다. AWS든 누구든 언제든 elasticsearch를 포크해서 공개할 수 있다.(물론 상표권은 다른 이유이므로 공개할 때 elasticsearch라는 이름은 사용할 수 없을 것이다.) 결국 개발자 커뮤니티가 어떤 버전을 선택할 것이냐가 중요한 부분이다.

오픈소스는 기본적으로 저작권을 포기하는 행위이다._{(2021년 2월 10일 수정: 실제로 저작권을 포기한 것은 아니기 때문에 이 문장을 잘못되어 수정한다.)} 오픈소스는 기본적으로 특정 권리를 허락한 것이다. 다른 의미로 말하면 따로 허락을 받지 않고도 할 수 있는 행위를 명시적으로 지정한 것이고 당연히 되돌릴 수는 없다. 그래서 SSPL과 Elastic 라이센스가 적용되는 7.11 버전의 소스 코드는 이 두 라이센스의 제약을 따라야 하지만 Apache 2.0으로 공개된 7.10 버전의 소스 코드는 당연히 Apache 2.0에 따라 사용할 수 있고 여기에는 라이센스 사본과 attribution 만 명시하면 복제/배포/수정의 권한이 허용된다. 저작권을 포기한 입장에서 나중에 저작권을 다시 주장할 수는 없으므로(극단적인 예로 오픈소스 라이센스를 적용하고 수많은 사람이 사용하면 로얄티를 요구한다든지...) 우리는 안심하고 오픈소스를 라이센스 확인 후 가져다가 사용할 수 있는 것이다.

fork의 의미

그동안 포크는 오픈소스를 소유한 회사나 개인이 맘대로 하지 못하게 하는 수단으로 사용되었다. 오픈소스가 되어도 창시자나 메인테이너를 가진 회사는 라이센스 외에도 맘대로 할 수 있는 부분이 있고, 운영하면서 발생하는 다양한 이슈가 있다. 오픈소스는 이제 모두의 소유이므로 커뮤니티에 인정받지 못하는(혹은 해당 개발자가 더는 메인테인하지 않으면...) 다른 개발자가 언제든 포크해서 다른 버전으로 개발을 이어갈 수 있다. 포크가 꼭 분쟁에 대한 수단으로만 쓰이는 것은 아니지만 여기서는 글 주제에 맞게 커뮤니티가 회사가 개인이 맘대로 하지 못하게 하는 압박의 수단으로 쓰이는 데 더 집중해 보자.

내가 본 가장 대표적인 사례는 node.js와 io.js이다. 당시 Node.js의 BDFL을 수년간 풀타임으로 지원하던 Joyent(현재는 삼성에 인수됨)의 행보가 커뮤니티의 마음에 들지 않았다. 정확히 Joyent가 뭘 하려고 했는지는 밝혀지지 않았고 실제로는 뭘 하려고 했다기보다는 아무것도 하지 않았다. Node.js의 릴리스가 안 되기 시작하고 개발속도가 느려지자 커뮤니티는 io.js로 포크하는 결정을 내리고 대부분의 개발자도 io.js로 넘어가기 시작했다. 이에 Joyent는 백기를 들고 커뮤니티와 함께 Node.js 재단을 만들기고 합의하고 소유하고 있던 Node.js 상표권도 재단에 넘기면서 마무리되고 현재 재단 하의 Node.js까지 오게 되었다.(이때도 초기 Node.js 성장에 Joyent의 기여는 누구도 부정하지 못할 정도라고 생각한다.)

이렇게 포크는 오픈소스의 아주 강력한 수단이고 오픈소스의 특성상 개발자 커뮤니티의 외면을 받으면 순식간에 분위기가 달라진다. 여기서 다른 점은 이 Fork를 한 주체가 커뮤니티가 아니라 Elastic보다도 훨씬 큰 회사인 Amazon이라는 점뿐이다. 워낙 큰 기업이라 골목상권 침해(?) 같은 느낌이 있지만, Amazon이라고 포크를 못 할 이유는 없다. 어쨌든 Amazon이 이 강수를 둔 덕에 Elastic은 자신의 복제품이나 다름없는 Amazon 버전의 Elasticsearch 제품과 경쟁 제품을 만들어야 하는 상황에 빠졌다.

그럼 양쪽 다 괜찮으니 아무런 문제가 없는가?

그렇다면 이 글을 쓰지 않았을 것이다. 이건 꽤 어려운 사건이라고 생각하는데 앞으로도 FOSS 생태계(Free and open-source software)에도 영향을 줄 것이기 때문이다.

과거 얘기를 잠시...

리처드 스톨만으로 대표되는 Free Software Foundation가 1980년대에 만들어지고 에릭 레이먼드가 성당과 시장을 쓰면서 1990년대 후반에 만든 오픈소스 이니셔티브(OSI)로 행보가 이어졌다고 생각하고 있다. 그리고 오픈소스는 점점 발전해서 소프트웨어 개발에 주류로 자리 잡게 되었다.

오픈소스 개발을 하다가 시장이 커지다 보니 회사가 되기도 하고 제품 자체를 처음부터 오픈소스로 만들기도 한다. 아마 개발자 생태계가 오픈소스에 친화적이다 보니 개발자를 대상으로 하는 소프트웨어의 경우 개발자한테 인정을 받아야 할 것이고 어떤 부분에서는 마케팅적으로도 효과적이라고 생각했을 수도 있겠다. 굳이 비유하면 많은 소셜미디어 스타트업이 일단 사용자 수를 확보한 후에 수익 방법을 만드는 것과 비슷하게 오픈소스 회사들도 먼저 개발자들한테 선택을 받아야 한다. 처음부터 수익 방법까지 고려한 회사들도 있는지 모르겠지만 오픈소스 사이의 경쟁에서 이기기도 무척 어렵기 때문에 대부분은 수익화 방법은 미처 준비하지 못했다고 생각한다.

이런 상황 가운데 몇몇 오픈소스는 엔터프라이즈급(?) 소프트웨어로 커지고 사용자가 많아지면서 안정성과 개선 속도, 사용자 지원을 위해서 꽤 큰 규모의 회사로 커지기 시작했고 클라우드의 발전과 맞물려서 모든 사용자가 다 직접 운영하기 어려운 형태가 많으므로 SaaS 형태의 수익화라는 자연스러운 수순으로 흘러갔다. 그리고 이미 거대한 클라우드 프로바이더가 있고 고객들이 비슷한 요구를 많이 하므로 클라우드 프로바이더도 오픈소스를 이용해서 SaaS로 서비스를 하면서 이 둘이 충돌하고 문제가 발생한다.

비슷한 상황이 mongoDB와 Confluent, redislabs에서도 발생했다.(사족이지만 내가 듣기에는 redislabs은 다른 회사들과는 달리 원래부터 redis를 만들면서 큰 회사는 아니라고 한다.) 이 회사들도 Elastic과 상황이 비슷하고 mongoDB가 그래서 SSPL을 만들었다.

오픈소스 생태계에 도움이 되는가?

어떤 면에서는 기업 간의 분쟁이기도 하지만 오픈소스 생태계가 크게 성장하고 클라우드 시장이 거대해 지면서 새로 발생한 이슈라고 생각하고 앞으로도 계속 발생할 문제이다. 그래서 어떤 방향으로 움직여야 오픈소스 생태계가 앞으로도 오픈소스 생태계가 더 건강해질 수 있을까로 생각하니 결론을 내기가 쉬웠다. 그래서 처음에 얘기한 대로 Elastic 쪽에 손을 들어주게 됐다.

왜냐하면 클라우드 프로바이더가 너무나도 유리한 위치에 있기 때문이다. 오픈소스 프로젝트 혹은 회사는 개발자 생태계 내에서 치열한 경쟁을 이겨내야 하지만 클라우드 프로바이더는 기다리고 있다가 새롭게 주류가 된 오픈소스가 있으면 SaaS로 제공하면 된다. 이미 많은 개발자는 클라우드 안에서 서버를 운영하는 상황이다. 고객들도 많이 SaaS로 제공해달라고 요청을 했을 테고 실제고 AWS 쓰는데 AWS 내에서 바로 쓸 수 있으면 편하므로 당위성도 있고 지지도 어느 정도 받을 수 있다.(그래서 fork를 했을 것이다)

이런 일이 반복되면 SaaS로 제공하기 좋은 형태는 굳이 힘들여서 열심히 만들지 않을 것이다. 아무래도 "재주는 곰이 넘고 돈은 되놈이 번다"는 느낌을 지울 수가 없다. 오픈소스에서는 계속 새로운 프로젝트가 나오면서 더 발전해야 하는데 더는 시도하지 않으면 발전도 사라질 것이다.

그럼 어떻게 해야 하지?

이건 이 글을 쓰면서 다른 사람의 생각이 궁금해서 요즘 인기 있는 Clubhouse에 방을 만들어서 다른 사람들과 얘기를 나누어 보았다. 예전 같으면 퇴근하고 사람들하고 얘기하면서 자연스럽게 얘기해 봤겠지만, 요즘은 못 그러다 보니 다른 사람들은 어떻게 생각하는지 궁금했다. 준비 없이 했는데 좋은 분들이 의견도 많이 내주시고 방에 들어온 분들도 많아서 1시간 반이나 재밌게 얘기하고 더 명확하게 정리되었다.

뭘 해야 할지 구체적으로는 잘 생각나지 않는다. 하지만 개발자로서 클라우드 프로바이더의 이런 움직임이 불편하다는 주장을 계속할 수 있다고 생각한다. 나도 업무를 하면서 클라우드 프로바이더가 제공하는 SaaS를 쓰지 않고 직접 설치해서 운영하는 선택을 하기는 쉽지 않다. 하지만 개발자 대부분이 오픈소스 저자들과 협업하지 않고 단독으로 SaaS를 제공하는 것을 불편해한다면 아마 그들도 무시할 순 없으리라 생각한다.

그냥 내 희망적 추측이지만 Elastic과 분쟁과 Open Distro for Elasticsearch를 발표한 이후 개발자 반응을 의식해서 작년에 나온 Amazon Managed Service for Grafana는 Grafana Labs와 협업해서 출시한 게 아닐까 상상해 본다. 이 사건을 신경 쓰고 있어서 그런지 몰라도 이번에 유독 Grafana Labs와 협업해서 출시했다는 걸 강조한다는 기분이 들었다. 물론 회사 간의 협업은 서로 제시하는 조건이 있을 테니 결렬된 이유는 알기도 어렵고 결렬된 걸 문제 삼을 수는 없다.

오픈소스 라이센스는 현재로 괜찮을까?

OSI도 20년 전에 만들어졌고 지금 사용하는 Apache, BSD, MIT 등 대부분은 20년 정도가 되었다. 라이센스이므로 IT 발전처럼 달라질 필요는 없지만 20년간 달라진 환경에 여전히 유효한가? 라는 의문은 가져볼 수 있다. 다른 의미로 말하면 정말 SSPL은 오픈소스로 안 받아주는 것이 맞는가? 라는 질문을 해볼 수 있고(받아들여져야 한다는 것이 아니다.) 훨씬 엄격한 라이센스를 주장했던 FSF에서 OSI로 바뀌었듯이 다시 흐름이 바뀌지 말라는 보장도 없다.

결국 오픈소스 라이센스도 오픈소스 개발을 더 활발하게 하려는 것이고 FSF가 있던 시절엔 그렇게 엄격해야 할 이유가 있었고 그 뒤에는 OSI가 했던 것처럼 더 열린 라이센스가 합리적이었다고 생각하면 지금은 어떤가? 라는 생각을 해볼 수 있다고 생각한다. 물론 특정 기업을 막는다기보다 장기적으로 오픈소스에 긍정적인 영향을 미칠 수 있도록 하기 위해서 고민해 볼 만하다.

_{(2021년 2월 10일 추가)}혹시나 하는 마음에 이 부분은 지금 상황에 대해서 더 다양하게 고민해 보자는 의미이지 SSPL을 OSI 승인 라이센스로 받아들여져야 한다거나 Elastic도 오픈소스로 인정해 줘야 함을 주장하려는 것은 아니다. 다른 분이 알려주셔서 알게 되었는데 이 글에서는 OSD6 조항을 위반했다고 간단하게 언급했지만 SSPL은 라이센스 상으로도 많은 문제가 있다고 한다.

마지막으로... 오픈소스 회사만 있는 것은 아니다.

이 사건에 집중하다 보니 생각하지 못하고 있던 것을 사람들하고 얘기하다가 깨달았다. 이 글의 주제 상 오픈소스 회사를 얘기했지만 오픈소스 생태계에는 회사만 있는 것이 아니다. 예전 발표에서도 얘기한 적이 있는데 우리가 익숙한 유명 프로젝트도 버스 팩터가 높지 않은 경우가 많다. 작은 프로젝트는 말할 것도 없고 많이 쓰이는 프로젝트도 한두 명이 개인 시간을 헌신해서 프로젝트를 지탱하는 경우가 허다하고 전체 생태계로 보면 이런 사람들이 더 많을 것이고 더 중요하다. 이 사람들이 오픈소스 생태계를 지탱하고 있다고 생각한다.

상장한 오픈소스 기반의 회사도 많고 큰 규모의 오픈소스 회사도 있어서 이런 회사들이 더 눈에 띄기 쉽지만 뒤에서 개인적으로 기여하는 사람들을 놓치면 안 된다고 생각한다. 이들이 모두 IPO 해서 큰돈을 벌어야 한다고 생각하는 것은 아니지만 생계에 문제가 있을 정도가 되면 당연히 안 되고 적절한(기준은 없지만) 보상은 받을 수 있어야 한다고 본다.

이 글에서 클라우드 프로바이더를 얘기한 것과 비슷하게 회사 중심의 오픈소스도 조심해야 할 필요가 있다고 생각한다. 많은 회사들이 오픈소스를 신경 써서 풀타임 오픈소스 개발을 지원하는 회사가 점점 많아지는 것은 좋은 일이나 오픈 소스의 주도권이 대기업으로 넘어가는 것은 조심할 필요가 있다고 생각한다. 그렇게 회사에서 지원을 받지 않고 오픈소스에 기여하는 사람들이 훨씬 많다.

생태계에서도 이런 부분을 신경 쓰고 있어서 최근 몇 년간 오픈소스 개발자를 지원하는 기부 분야가 많이 발전했다. 대표적으로 Open Collective가 있고 GitHub Sponsors가 있다. 개인적으로는 오픈소스를 사용하는 수많은 IT 회사도 서비스를 만드는데 오픈소스로부터 많은 이득을 얻고 있으므로 더 적극적으로 이런 기부를 해야 한다고 생각한다.