2021.01.28

블로그 | 오픈소스 비즈니스 모델 간 갈등, 공유 소스로 해결하자

Matt Asay | InfoWorld
오픈소스는 결국 커뮤니티인데, 왜 우리는 잘 어울리지 못할까? 최근 엘라스틱(Elastic)과 AWS 간의 다툼을 두고 하는 말이다. 그러나 우리는 오랜 시간 동안 이와 비슷한 문제와 씨름해왔다.
 
엘라스틱은 오픈소스 워즈(Open Source Wars) 최신 에피소드에서 AWS를 향해 “오픈소스 생태계에 특히 중요한 규범과 가치에 부합하지 않는 행동을 한다”며 비난했다. AWS는 오픈소스 규범과 가치를 위반한 것은 엘라스틱이며, 결과적으로 AWS는 “기여자 커뮤니티와 함께 하는 공유 프로젝트 거버넌스 구현을 포함한 건강하고 지속 가능한 오픈소스 환경을 촉진하기 위해” 엘라스틱서치(Elasticsearch)와 키바나(Kibana)를 포크했다고 반박했다.
 
ⓒ dimitrisvetsikas1969
 
필자 개인적으로는 이 충돌이 라이선스의 문제가 아니라고 생각한다. 물론 라이선스 문제가 있기는 하지만, 원인이 아닌 증상일 뿐이다. 문제의 핵심은 오픈소스 소프트웨어로부터 누가 수익을 얻는가에 있다. 문제 해결을 위해서는 새로운 라이선스와 이것을 설명하는 새로운 방법이 필요할 것 같다. (그렇다. 필자는 ‘공유 소스(shared source)’를 제안하려고 한다. 끝까지 읽어 보기 바란다.)
 

팩트 정리

미리 밝히자면 필자는 AWS에서 일한다. 한 가지 더 밝히고 싶은 것은 AWS에서 일한 기간보다 훨씬 더 오래(20년 가까이) 오픈소스에 참여해왔다는 점이다. 필자에겐 오픈소스가 우선이고, 더 중요하다. 이 글은 현재 AWS에서 일하지만 2000년 임베디드 리눅스 벤더 리네오(Lineo)에서 첫 일자리를 구했을 때부터 줄곧 오픈소스를 지지해온 오픈소스 주창자 맷의 관점에서 쓰는 것이다. (세 번째 정보 공개: 필자는 누군가가 오픈소스를 오염시키는 것을 참지 못한다.)

이것을 염두에 두고, 몇 가지 객관적인 진리를 짚고 넘어가자.

1. 많은 사람들이 사용하기를 원하는 훌륭한 오픈소스 소프트웨어를 만들기는 매우 어렵다.

2. 이 훌륭한 오픈소스 소프트웨어에서 수익을 얻기는 그보다 더 어렵다.

3. 내가 좋은 소프트웨어를 만들었다고 해서 그 소프트웨어로부터 수익을 얻을 권리가 나에게 있다는 의미는 아니며, 코드를 오픈소스화한다는 것은 다른 사람에게도 그와 동일한 기회가 있음을 의미한다.

4. 몇몇 기업은 오픈소스 수익화 방법을 다른 기업보다 빠르게 생각해낸다.

지난 수십 년 동안 오픈소스 업계는 지원(나쁜 아이디어!), 오픈 코어(나름의 문제가 있음)와 같은 다양한 오픈소스 비즈니스 모델을 실험했다. 그러나 가장 깔끔하면서 고객과 업체의 이익을 하나로 정렬하는 최선의 방법으로 검증된 모델은 필자가 예전 글에서도 언급한 관리형 클라우드 서비스다.
 
그러나 얼마 전에 팀 브레이가 지적했듯이, 문제는 어떤 개인과 기업이 좋은 소프트웨어를 만드는 데 있어 최고의 역량을 가졌다고 해서 그 코드의 운영화 측면에서도 항상 최고의 역량을 가졌다고 장담할 수는 없다는 것이다. 브레이는 “무로부터 훌륭한 소프트웨어를 만들어내는 자질이 있다고 해서 운영에도 뛰어나다는 보장은 없다”고 말했다. 그 반대도 마찬가지다. 고객은 관리형 클라우드 서비스를 통해 선호하는 오픈소스 소프트웨어에 돈을 썼다.
 
그러나 이 돈이 코드의 출처로 흘러가지 않은 경우가 많았다. 위의 진실 2부터 4까지를 보라.
 
문제임은 분명하지만 누구를 비판해야 할지 판단하기는 어렵다. 클라우드 기업을 비판하는 사람도 있지만 이러한 비판은 어떤 면에서 “고객에게 고객이 원하는 것을 주지 말라”고 말하는 것과 같다. 또한 클라우드 기업이 얻는 가치에 상응하는 기여를 하지 않는다고 주장하는 사람들은 이러한 코드 기여는 일반적으로 환영받지 못하며 오픈소스 개발자들이 정말 원하는 것도 아니란 점을 상기할 필요가 있다. 이들이 원하는 것은 무엇인가? 자신이 작성한 오픈소스에 대한 독점적 수익화다. 경쟁업체만큼 고객의 요구를 잘 충족하지 못하더라도 그 욕구에는 변함이 없다.
 
그렇다면 논점은 “좋은 소프트웨어를 좋은 비즈니스로 전환하는 방법을 알아내는 것은 네 문제”라고 주장하는, 오픈소스 개발자들을 비판하는 사람들로 옮겨간다. 이 말은 피해자를 비난하는 듯한 느낌을 준다. 그러나 이러한 개발자들이 오픈소스 배포의 혜택(커뮤니티!)과 사유 소프트웨어의 수익화 혜택(나!)을 함께 원하는 듯하다는 측면에서 보면 이 논점에는 진실이 있다. 하지만 이 논점은 놓치는 부분이 있다. 오픈소스 개발자에게 필요한 것은 고객의 높아지는 기대치에 부합하는 소프트웨어를 제공하는 데 필요한 운영 측면의 “근육”을 개발하기 위한 더 많은 시간일 수 있다는 점이다.
 

공유 소스의 미래로 돌아가기

그러나 몽고DB(MongoDB), 그리고 지금 엘라스틱 같은 기업은 시간을 벌기 위해 SSPL(Server Side Public License)과 같은 라이선스를 택했다. SSPL은 오픈소스 라이선스가 아니다. 또한 적어도 우리가 생각하는 전통적인 의미에서의 사유 라이선스도 아니다. 그 중간 성격의 라이선스다. 몽고DB의 성공에서 볼 수 있듯이 많은 용도에서 이 유사 오픈소스 방식으로 충분할지도 모른다.
 
우리는 적어도 20년 동안 이 중간 지대를 뭐라고 불러야 할지를 두고 고민해왔다. 필자는 이와 같은 라이선스를 “오픈소스”로 일반화해서는 안 된다고 생각한다. 오픈소스가 아니기 때문이다. 오픈소스에는 20년에 걸쳐 개발되고 보호되는 구체적인 의미가 있다. 그러나 이 라이선스를 악으로 규정해서도 안 된다. 자신이 만든 코드에서 금전적 이익을 얻으려는 개발자들의 노력은 전혀 잘못된 것이 아니기 때문이다.

공유 소스를 고려하면 어떨까?

물론 공유 소스의 역사에는 찝찝한 면이 있다. 마이크로소프트는 오픈소스를 진실되게 포용하지 않으면서 오픈소스를 흉내내기 위해 공유 소스를 사용했었다. 그러나 그 얼룩만 지운다면 실용적인 방법이며, 이러한 기업이 원하는 바를 정확히 표현하는 용어이기도 하다. 즉, 다른 이들과 소스를 공유하되 (항상은 아니지만 일반적으로) 이 소스의 사용을 경쟁 제품 구축으로 제한하는 것이다. 그렇다면 “공유 소스”를 오픈소스가 아니지만 사유도 아닌, 그리고 잠재적인 사용자에게 라이선스를 사용할 때 적용되는 권리와 제한에 대한 대략적인 맥락을 제공하는 라이선스의 범주로 사용하지 못할 이유가 없다. 맷 사이츠는 공유 소스에 대해 다음과 같이 말했다.

“이 논쟁은 자유 소프트웨어(카피레프트) 대 오픈소스에 대한 과거의 토론을 상기시킨다. 라이선스에는 색과 마찬가지로 스펙트럼이 있다. 넓은 범주(빨간색, 녹색)로 기술하고, 거기에 형용사를 붙이거나(진한 빨간색) 특수한 용어를 만들 수도 있다(선홍색).”


SSPL은 “공유 소스이지만 클라우드 제공업체와는 공유되지 않는” 형태가 된다. 물론 그 이상의 의미가 있지만 현재 상황을 이해하기 쉽게 요약하자면 그렇다.
 
이 범주가 필요할까? 필자는 필요하다고 생각한다. 오픈소스 수익화 전쟁에서 누구를 비판해야 하는지를 두고 논쟁할 수 있지만 애초에 전쟁이 있다는 사실, 그 전쟁이 아주 오랜 기간 이어져왔다는 사실은 해결이 필요한 진짜 문제가 있음을 시사한다.
 
개발자들이 공유 소스 라이선스를 포용할까? 확실치 않다. 몇 년 동안 먼저 오픈소스 프로젝트로 쌓아 올린 우호적 정서가 없었다면 현재 SSPL 하에서 몽고DB가 번창할 수 있었을까? 그럴 수도 있고 아닐 수도 있다. 필자는 그건 개발자가 결정할 부분이라고 믿는다. 개발자들이 선택할 수 있는, 명확하고 정확하며 허용과 제약을 이해하기 쉬운 라이선스 범주를 제공하고, 그 이후 어떻게 되는지 지켜보자. editor@itworld.co.kr 



2021.01.28

블로그 | 오픈소스 비즈니스 모델 간 갈등, 공유 소스로 해결하자

Matt Asay | InfoWorld
오픈소스는 결국 커뮤니티인데, 왜 우리는 잘 어울리지 못할까? 최근 엘라스틱(Elastic)과 AWS 간의 다툼을 두고 하는 말이다. 그러나 우리는 오랜 시간 동안 이와 비슷한 문제와 씨름해왔다.
 
엘라스틱은 오픈소스 워즈(Open Source Wars) 최신 에피소드에서 AWS를 향해 “오픈소스 생태계에 특히 중요한 규범과 가치에 부합하지 않는 행동을 한다”며 비난했다. AWS는 오픈소스 규범과 가치를 위반한 것은 엘라스틱이며, 결과적으로 AWS는 “기여자 커뮤니티와 함께 하는 공유 프로젝트 거버넌스 구현을 포함한 건강하고 지속 가능한 오픈소스 환경을 촉진하기 위해” 엘라스틱서치(Elasticsearch)와 키바나(Kibana)를 포크했다고 반박했다.
 
ⓒ dimitrisvetsikas1969
 
필자 개인적으로는 이 충돌이 라이선스의 문제가 아니라고 생각한다. 물론 라이선스 문제가 있기는 하지만, 원인이 아닌 증상일 뿐이다. 문제의 핵심은 오픈소스 소프트웨어로부터 누가 수익을 얻는가에 있다. 문제 해결을 위해서는 새로운 라이선스와 이것을 설명하는 새로운 방법이 필요할 것 같다. (그렇다. 필자는 ‘공유 소스(shared source)’를 제안하려고 한다. 끝까지 읽어 보기 바란다.)
 

팩트 정리

미리 밝히자면 필자는 AWS에서 일한다. 한 가지 더 밝히고 싶은 것은 AWS에서 일한 기간보다 훨씬 더 오래(20년 가까이) 오픈소스에 참여해왔다는 점이다. 필자에겐 오픈소스가 우선이고, 더 중요하다. 이 글은 현재 AWS에서 일하지만 2000년 임베디드 리눅스 벤더 리네오(Lineo)에서 첫 일자리를 구했을 때부터 줄곧 오픈소스를 지지해온 오픈소스 주창자 맷의 관점에서 쓰는 것이다. (세 번째 정보 공개: 필자는 누군가가 오픈소스를 오염시키는 것을 참지 못한다.)

이것을 염두에 두고, 몇 가지 객관적인 진리를 짚고 넘어가자.

1. 많은 사람들이 사용하기를 원하는 훌륭한 오픈소스 소프트웨어를 만들기는 매우 어렵다.

2. 이 훌륭한 오픈소스 소프트웨어에서 수익을 얻기는 그보다 더 어렵다.

3. 내가 좋은 소프트웨어를 만들었다고 해서 그 소프트웨어로부터 수익을 얻을 권리가 나에게 있다는 의미는 아니며, 코드를 오픈소스화한다는 것은 다른 사람에게도 그와 동일한 기회가 있음을 의미한다.

4. 몇몇 기업은 오픈소스 수익화 방법을 다른 기업보다 빠르게 생각해낸다.

지난 수십 년 동안 오픈소스 업계는 지원(나쁜 아이디어!), 오픈 코어(나름의 문제가 있음)와 같은 다양한 오픈소스 비즈니스 모델을 실험했다. 그러나 가장 깔끔하면서 고객과 업체의 이익을 하나로 정렬하는 최선의 방법으로 검증된 모델은 필자가 예전 글에서도 언급한 관리형 클라우드 서비스다.
 
그러나 얼마 전에 팀 브레이가 지적했듯이, 문제는 어떤 개인과 기업이 좋은 소프트웨어를 만드는 데 있어 최고의 역량을 가졌다고 해서 그 코드의 운영화 측면에서도 항상 최고의 역량을 가졌다고 장담할 수는 없다는 것이다. 브레이는 “무로부터 훌륭한 소프트웨어를 만들어내는 자질이 있다고 해서 운영에도 뛰어나다는 보장은 없다”고 말했다. 그 반대도 마찬가지다. 고객은 관리형 클라우드 서비스를 통해 선호하는 오픈소스 소프트웨어에 돈을 썼다.
 
그러나 이 돈이 코드의 출처로 흘러가지 않은 경우가 많았다. 위의 진실 2부터 4까지를 보라.
 
문제임은 분명하지만 누구를 비판해야 할지 판단하기는 어렵다. 클라우드 기업을 비판하는 사람도 있지만 이러한 비판은 어떤 면에서 “고객에게 고객이 원하는 것을 주지 말라”고 말하는 것과 같다. 또한 클라우드 기업이 얻는 가치에 상응하는 기여를 하지 않는다고 주장하는 사람들은 이러한 코드 기여는 일반적으로 환영받지 못하며 오픈소스 개발자들이 정말 원하는 것도 아니란 점을 상기할 필요가 있다. 이들이 원하는 것은 무엇인가? 자신이 작성한 오픈소스에 대한 독점적 수익화다. 경쟁업체만큼 고객의 요구를 잘 충족하지 못하더라도 그 욕구에는 변함이 없다.
 
그렇다면 논점은 “좋은 소프트웨어를 좋은 비즈니스로 전환하는 방법을 알아내는 것은 네 문제”라고 주장하는, 오픈소스 개발자들을 비판하는 사람들로 옮겨간다. 이 말은 피해자를 비난하는 듯한 느낌을 준다. 그러나 이러한 개발자들이 오픈소스 배포의 혜택(커뮤니티!)과 사유 소프트웨어의 수익화 혜택(나!)을 함께 원하는 듯하다는 측면에서 보면 이 논점에는 진실이 있다. 하지만 이 논점은 놓치는 부분이 있다. 오픈소스 개발자에게 필요한 것은 고객의 높아지는 기대치에 부합하는 소프트웨어를 제공하는 데 필요한 운영 측면의 “근육”을 개발하기 위한 더 많은 시간일 수 있다는 점이다.
 

공유 소스의 미래로 돌아가기

그러나 몽고DB(MongoDB), 그리고 지금 엘라스틱 같은 기업은 시간을 벌기 위해 SSPL(Server Side Public License)과 같은 라이선스를 택했다. SSPL은 오픈소스 라이선스가 아니다. 또한 적어도 우리가 생각하는 전통적인 의미에서의 사유 라이선스도 아니다. 그 중간 성격의 라이선스다. 몽고DB의 성공에서 볼 수 있듯이 많은 용도에서 이 유사 오픈소스 방식으로 충분할지도 모른다.
 
우리는 적어도 20년 동안 이 중간 지대를 뭐라고 불러야 할지를 두고 고민해왔다. 필자는 이와 같은 라이선스를 “오픈소스”로 일반화해서는 안 된다고 생각한다. 오픈소스가 아니기 때문이다. 오픈소스에는 20년에 걸쳐 개발되고 보호되는 구체적인 의미가 있다. 그러나 이 라이선스를 악으로 규정해서도 안 된다. 자신이 만든 코드에서 금전적 이익을 얻으려는 개발자들의 노력은 전혀 잘못된 것이 아니기 때문이다.

공유 소스를 고려하면 어떨까?

물론 공유 소스의 역사에는 찝찝한 면이 있다. 마이크로소프트는 오픈소스를 진실되게 포용하지 않으면서 오픈소스를 흉내내기 위해 공유 소스를 사용했었다. 그러나 그 얼룩만 지운다면 실용적인 방법이며, 이러한 기업이 원하는 바를 정확히 표현하는 용어이기도 하다. 즉, 다른 이들과 소스를 공유하되 (항상은 아니지만 일반적으로) 이 소스의 사용을 경쟁 제품 구축으로 제한하는 것이다. 그렇다면 “공유 소스”를 오픈소스가 아니지만 사유도 아닌, 그리고 잠재적인 사용자에게 라이선스를 사용할 때 적용되는 권리와 제한에 대한 대략적인 맥락을 제공하는 라이선스의 범주로 사용하지 못할 이유가 없다. 맷 사이츠는 공유 소스에 대해 다음과 같이 말했다.

“이 논쟁은 자유 소프트웨어(카피레프트) 대 오픈소스에 대한 과거의 토론을 상기시킨다. 라이선스에는 색과 마찬가지로 스펙트럼이 있다. 넓은 범주(빨간색, 녹색)로 기술하고, 거기에 형용사를 붙이거나(진한 빨간색) 특수한 용어를 만들 수도 있다(선홍색).”


SSPL은 “공유 소스이지만 클라우드 제공업체와는 공유되지 않는” 형태가 된다. 물론 그 이상의 의미가 있지만 현재 상황을 이해하기 쉽게 요약하자면 그렇다.
 
이 범주가 필요할까? 필자는 필요하다고 생각한다. 오픈소스 수익화 전쟁에서 누구를 비판해야 하는지를 두고 논쟁할 수 있지만 애초에 전쟁이 있다는 사실, 그 전쟁이 아주 오랜 기간 이어져왔다는 사실은 해결이 필요한 진짜 문제가 있음을 시사한다.
 
개발자들이 공유 소스 라이선스를 포용할까? 확실치 않다. 몇 년 동안 먼저 오픈소스 프로젝트로 쌓아 올린 우호적 정서가 없었다면 현재 SSPL 하에서 몽고DB가 번창할 수 있었을까? 그럴 수도 있고 아닐 수도 있다. 필자는 그건 개발자가 결정할 부분이라고 믿는다. 개발자들이 선택할 수 있는, 명확하고 정확하며 허용과 제약을 이해하기 쉬운 라이선스 범주를 제공하고, 그 이후 어떻게 되는지 지켜보자. editor@itworld.co.kr 

X