오픈소스로 성공한 회사들이 라이선스를 바꾸고 있다. 관대한 아파치·MIT 라이선스로 사용자를 모은 뒤, 어느 순간 AGPL이나 BSL(Business Source License) 같은 더 제한적인 라이선스로 갈아타는 흐름이 몇 년째 이어진다. 이걸 두고 "배신"이라는 비판과 "생존을 위한 불가피한 선택"이라는 옹호가 팽팽하게 부딪힌다.
나는 이 문제를 선악으로 가르기 어렵다고 본다. 여기엔 오픈소스라는 이상과 회사를 굴려야 하는 현실이 정면으로 충돌하는, 구조적인 딜레마가 깔려 있다.
진짜 위협은 사용자가 아니라, 코드를 그대로 가져다 파는 대형 클라우드였다.
개발사가 오픈소스로 키운 소프트웨어를 클라우드 사업자가 매니지드 서비스로 되팔며 수익을 가져가자, 만든 쪽이 돈을 못 버는 구조가 라이선스 전환을 불렀다.
클라우드무임승차 전환의 가장 큰 방아쇠 |
BSL시한부 몇 년 뒤 오픈 소스로 전환 |
포크반발 커뮤니티가 갈라서기도 |
신뢰비용 한 번 바꾸면 되돌리기 힘듦 |
왜 관대한 라이선스로 시작했다가 바꾸나
순서를 보면 이해가 쉽다. 초기엔 사용자가 절실하다. 그래서 MIT·아파치처럼 "마음대로 써도 된다"는 라이선스로 진입 장벽을 없애고 커뮤니티를 키운다. 이 전략은 잘 통한다. 수많은 회사가 이렇게 표준으로 자리 잡았다.
문제는 성공한 다음이다. 소프트웨어가 널리 쓰이면, 대형 클라우드 사업자가 그 코드를 그대로 가져다 자기 플랫폼에서 매니지드 서비스로 판다. 운영과 마케팅 규모에서 원 개발사가 이길 수 없다. 만든 쪽은 유지보수 부담을 다 지면서 수익은 클라우드가 가져가는, 억울한 구도가 만들어진다. 라이선스 전환은 바로 이 무임승차를 막으려는 방어 조치다.
AGPL과 BSL은 무엇이 다른가
AGPL은 여전히 오픈소스로 인정되는 라이선스지만, "네트워크로 서비스하면 수정 코드도 공개하라"는 강한 조건을 건다. 클라우드가 몰래 개조해 서비스로 파는 걸 어렵게 만든다. BSL은 성격이 다르다. 기술적으로는 "소스가 공개된" 상태지만, 상업적 경쟁 용도의 사용을 일정 기간 제한한다. 그리고 보통 몇 년이 지나면 자동으로 진짜 오픈소스 라이선스로 전환되는 시한부 조항을 둔다. "지금은 우리를 보호하되, 미래엔 공개하겠다"는 절충인 셈이다.
커뮤니티는 왜 반발하나
반발의 핵심은 신뢰다. 사용자와 기여자들은 "이건 자유롭게 쓸 수 있다"는 약속을 믿고 시간과 코드를 보탰다. 그런데 회사가 성공한 뒤 규칙을 바꾸면, 그 신뢰가 배신당했다고 느낀다. 특히 무료로 기여한 외부 개발자들은 "내 노동이 이제 회사의 상업적 이익을 위해 갇혔다"고 여긴다.
그 결과가 포크다. 커뮤니티가 전환 직전 버전을 갈라내 독자적으로 이어가는 것이다. 때로는 대형 사업자들이 이 포크를 후원하며 원 개발사와 정면으로 경쟁하기도 한다. 라이선스를 바꿔 클라우드를 막으려다, 오히려 커뮤니티를 잃고 경쟁 포크를 키우는 역설이 벌어질 수 있다.
| 항목 | AGPL / BSL 전환 | MIT / 아파치 유지 |
|---|---|---|
| 주 목적 | 클라우드 무임승차 차단 | 최대한 넓은 채택 |
| 수익 방어 | 강함 | 약함 |
| 커뮤니티 신뢰 | 흔들릴 위험 | 유지에 유리 |
| 포크 리스크 | 높음 | 낮음 |
정답은 없지만 방향은 있다
나는 오픈소스 회사가 돈을 벌 방법을 찾아야 한다는 데 전적으로 동의한다. 지속 가능하지 않은 이상은 오래 못 간다. 다만 라이선스 전환은 마지막 카드에 가깝다. 한 번 신뢰를 깨면 되돌리기 어렵기 때문이다. 처음부터 수익 모델을 분명히 하고, 바꿔야 한다면 커뮤니티와 충분히 소통하며, 시한부 조항처럼 미래의 개방을 약속하는 방식이 그나마 상처를 줄인다. 오픈소스의 다음 장은 결국 "이상과 생존을 어떻게 화해시키느냐"에 달려 있다.
자주 묻는 질문
BSL은 오픈소스인가요?
엄밀히는 아니다. 소스 코드가 공개돼 있지만 상업적 경쟁 용도를 일정 기간 제한하기 때문에, 자유로운 사용을 전제로 하는 오픈소스의 정의에는 부합하지 않는다. 다만 보통 몇 년 뒤 진짜 오픈소스 라이선스로 자동 전환되는 조항을 둔다.
왜 굳이 성공한 뒤에 라이선스를 바꾸나요?
성공하기 전에는 채택을 늘리는 게 최우선이라 관대한 라이선스가 유리하고, 성공한 뒤에는 대형 클라우드의 무임승차라는 위협이 현실화되기 때문이다. 두 국면에서 최적의 전략이 정반대라 전환이 일어난다.
라이선스 전환의 가장 큰 리스크는 무엇인가요?
커뮤니티 신뢰의 상실과 그로 인한 포크다. 반발한 사용자와 기여자들이 전환 직전 버전을 갈라내 독자 프로젝트로 이어가면, 원 개발사가 오히려 경쟁자를 키우는 결과가 될 수 있다.
사용자 입장에서는 어떻게 대비해야 하나요?
핵심 인프라로 채택할 때는 라이선스 변경 가능성을 미리 염두에 두는 것이 좋다. 어떤 라이선스인지, 회사의 수익 모델이 무엇인지, 커뮤니티 거버넌스가 얼마나 독립적인지를 함께 살피면 갑작스러운 전환의 충격을 줄일 수 있다.
댓글 0