오픈소스의 딜레마: 자유와 상업성 사이

오픈소스 소프트웨어는 현대 소프트웨어 스택의 근간을 이루고 있습니다. 그러나 오픈소스를 기반으로 비즈니스를 구축하는 기업들은 커뮤니티를 만족시키면서도 제3자가 라이선스를 악용하지 못하도록 하는 문제 사이에서 항상 딜레마를 겪고 있습니다.

많은 기업들이 처음에는 이상적인 오픈소스의 가치를 내세우며 출발했지만, 현실적인 상업적 과제에 부딪히면서 방향을 바꾸는 경우가 많습니다. 특히, 아마존 웹 서비스(AWS)와 같은 클라우드 하이퍼스케일러가 오픈소스를 기반으로 별도의 서비스를 구축하며 기여를 하지 않는 경우, 기업들은 이를 견제하기 위해 라이선스를 변경하는 사례가 늘고 있습니다.

아래는 지난 10년 동안 오픈소스 정책을 변경한 주요 기업들의 타임라인과 배경을 정리한 내용입니다.

---

🕰 오픈소스 라이선스 변경 타임라인

1. Movable Type (2013년)

• 초기 오픈소스 도입: Movable Type은 2007년 GPL 기반의 오픈소스 버전(MTOS)을 출시하며 WordPress와 경쟁했습니다.
• 전환 배경: 그러나 2013년, "MTOS가 상업적 버전의 채택을 방해한다"며 오픈소스를 폐기했습니다.
• 기업의 입장: 커뮤니티가 성장하지 않았고 다운로드 수가 상업용 제품과 비슷한 수준에 그쳤다는 이유로 더 이상 경제적 가치가 없다고 판단.

2. SugarCRM (2014년)

• 초기 오픈소스 모델: 2004년 설립 당시 오픈소스 CRM 커뮤니티 에디션을 제공.
• 전환 배경: 2014년, 오픈소스 제품이 주력 시장(개발자 및 첫 CRM 사용자)의 요구를 충족시키지 못한다는 이유로 중단.
• 지속적 지원: v6.5 버전에 대한 지원은 2018년까지 유지했으나, 이후 완전히 종료.

3. Redis (2018년)

• 변화 시작: 2018년, Redis는 모듈(예: RediSearch)에 Apache 2.0 + Commons Clause를 적용하며 상업적 제한 추가.
• RSAL 도입: 2019년 자체 라이선스인 Redis Source Available License(RSAL)를 도입, 경쟁 서비스(특히 AWS)를 겨냥한 제한.
• 최종 전환: 2023년, BSD 3-Clause에서 RSAL 또는 SSPL로 전환하며 완전한 상업화.

4. MongoDB (2018년)

• SSPL 도입: AWS와 같은 클라우드 하이퍼스케일러의 사용 제한을 위해 AGPL에서 SSPL로 전환.

5. Confluent (2018년)

• 전환 내용: Apache Kafka 기반의 일부 구성 요소를 Apache 2.0에서 Confluent Community License로 변경.
• 제한 조항: 경쟁 서비스가 Confluent의 소프트웨어를 "as-a-service"로 제공하는 것을 금지.

6. Cockroach Labs (2019년)

• 라이선스 변경: Apache 2.0에서 Business Source License(BUSL)로 전환.
• 추가 조치: 2023년, 셀프 호스팅 제품을 단일 엔터프라이즈 라이선스로 통합, 상업적 수익 극대화.

7. Sentry (2019년)

• BSD에서 BUSL로 전환: 경쟁업체가 자사의 코드를 모방하여 직접 경쟁하는 것을 방지하기 위함.
• 새로운 라이선스 도입: 2022년 FSL(Functional Source License)을 도입하며, 오픈소스와 상업적 라이선스의 절충안 제시.

8. Elastic (2021년)

• 오픈소스에서 상업화: Elasticsearch와 Kibana를 Apache 2.0에서 SSPL로 전환.
• 다시 오픈소스로: 2023년, AGPL로 재전환하며 오픈소스 커뮤니티와의 관계를 회복.

9. HashiCorp (2023년)

• Terraform 라이선스 전환: BUSL로 변경하여 경쟁 업체가 기여 없이 소프트웨어를 상업화하지 못하도록 제한.
• 오픈소스 포크 탄생: OpenTofu라는 포크가 등장하며 커뮤니티의 반발을 반영.

10. Snowplow (2024년)

• 전환 배경: Apache 2.0에서 Snowplow Limited Use License로 변경, 모든 상용 사용자는 비용을 지불해야 함.

---

💡 왜 라이선스를 변경하는가?

• "아마존 문제": 클라우드 하이퍼스케일러가 오픈소스를 활용해 수익을 창출하면서도 기여를 하지 않는 사례가 증가.
• 커뮤니티와 상업적 수익의 균형: 기업들은 커뮤니티를 유지하려 노력하지만, 수익을 위해 특정 제한을 두는 방향으로 전환.
• 투자자와 수익 압박: 벤처캐피털과 주주를 만족시키기 위한 경제적 필요성.

---

📈 오픈소스의 미래와 방향

1. 새로운 라이선스 등장: BUSL, SSPL, FSL 등 오픈소스와 상업성을 절충하는 다양한 라이선스가 개발되고 있음.
2. 커뮤니티의 반발: HashiCorp 사례에서 볼 수 있듯, 지나친 상업화는 커뮤니티의 반발을 초래.
3. 균형의 필요성: 기업들은 커뮤니티 신뢰를 유지하면서도 지속 가능한 비즈니스 모델을 개발해야 함.

---

오픈소스의 이상과 상업적 현실 사이의 갈등은 앞으로도 계속될 것입니다. 그러나 이를 통해 오픈소스 커뮤니티와 기업 모두에게 이익이 되는 새로운 협력 모델이 등장할 가능성도 열려 있습니다.