CKEditor는 더이상 오픈소스만으로 제공되지 않는다

오픈소스 프로젝트를 이용하는데 있어 주의해야 하는 것 중 하나가 LISENCE를 잘 살펴보아야 하는 것인데, 이 프로젝트는 프로젝트를 사용함으로 인해 이 사용한 프로젝트에 법적인 제약이 걸리게 된다.
단적으로 GPL Lisence의 경우에는 이 소스를 사용한 프로젝트의 전체 소스를 공개해야 한다.
반면 MIT Lisence의 경우에는 이러한 제약이 거의 없고 상업적 이용되 허용된다.

CKEditor Pricing을 살펴보면, OpenSource Project와 상업적 용도가 구별되어있다는 것을 알 수 있다.
CKEditor가 상당히 안정화됨에 따라 이와 같은 가격정책을 취한 것으로 생각되는데, 일반적으로 소스를 오픈하지 않는 프로젝트라면 SummerNote를 쓸 수 밖에 없는 상황이 아닌가 싶다.

CKEditor도 Lisence가 GPL, LGPL, MPL 이 세 가지로 나누어져 있는데 이 세 라이센스 중 한 가지를 따라야 하며, 법적(legal)하게 SourceCode를 public하게 만들어두어야만 한다.
Standard Lisence의 경우에는 OpenSource용이고, 이 경우 Commercial하게 사용하지는 못한다. 즉, 오픈소스 프로젝트에 Support 가격이 들어간 것일 뿐인 것이다.

오픈소스는 어떻게 운영되는가

오픈소스 프로젝트는 기본적으로 개발자들의 열정으로 이루어진다.
사회 공헌적 성격도 있고, 자신이 만든 소스를 여러 사람들이 사용해 더 큰 생태계로 발전해 나가기를 희망하는 것도 있다.
기업이 공개하는 오픈소스의 경우에는 자사의 서비스와 연계되어있는 경우나 자사가 이용하는 라이브러리/프레임워크가 전 세계에서 널리 사용되어 보편화 되고 이로 인해 시장 점유율이라는 것과 이쪽 분야에 대한 전반적 발전을 이끌어 낼 수 있다는 점에서 의미가 있다. (단적인 예시로 구글의 TensorFlow가 공개된 이후 TensorFlow가 학계에서 무척 많이 이용되고 있으며 관련 연구의 진척이 폭발적으로 일어나고있다.)

오픈소스 프로젝트 개발팀은 어떻게 밥먹고 사는가

MySql와 같은 유명 오픈소스 프로젝트들은 크게 두가지 방법으로 서비스를 제공한다.
일반 사용자들을 위한 것, 그리고 기업 사용자들을 위한 것.
회사나 공공기관의 경우에는 솔루션 도입에 앞서 염두에 두는 것이 ‘가격’만이 아니라 ‘유지보수’, 즉 이용중에 접하는 버그 혹은 에러상황에 대해 내부에서 프로젝트 전체를 관리하지 않고서도 자사의 서비스를 안정적으로 유지할 수 있느냐, 그리고 이 솔루션 도입시 에러를 내지 않는다는 (혹은 에러를 빠르게 해결 가능하다는) 보증이 필요한 것이다.

따라서 개발팀은 프로젝트는 공개하되, 개발팀 차원에서 지원이 필요한 경우에 계약을 통해 돈을 받고 유지보수를 계속 하는 것이다.

여담

오픈소스 프로젝트는 사실 PullRequest에 의해 진행되는 면도 무시할 수 없다. 그러나, Core개발자들이 풀타임으로 일하지 않는다면 OpenSSL의 HeartBleed와 같은 문제가 언제든 발생할 수 있다.

OpenSSL는 대다수의 프로젝트에서 의존성으로 사용되는 어머어마하게 많이 사용되는 프로젝트임에도 풀타임 개발자가 한명뿐이었다는 점, 오픈소스 프로젝트가 갖게 되는 가장 심각한 문제를 명백하게 보여준다.
모두가 관리하는 것이 아니라 모두가 방치했을 수 있다는 점, 그리고 빠른 패치와 업그레이드가 오히려 문제를 가져올 수 있다는 점, 그리고 이 문제는 소수가 사용하는 내부 시스템이 아니라 전세계의 대다수의 서비스가 사용하는 의존성 패키지였다는 점.
공유지의 비극이 일어난 상황이라고 보아도 무방하지 않을까…