Experiments never fail

며칠 전 컴퓨터프로그램보호위원회에서 주최하는 "오픈소스 라이선스와 비즈니스 전략"이라는 교육프로그램에 다녀왔다. 요즘같이 오픈소스가 중요한 시점에 비즈니스 전략을 어떻게 세울 것인가? 귀가 솔깃해지는 내용. 하지만, 비즈니스에 대한 내용은 숙제로만 남는 듯. 좀 지난 얘기이긴 하지만, 여기에라도 적지 않으면 잊혀질 듯 하여...  

교육은 회사에서 만드는 프로덕트에 OSS를 이용할 것인가, 그렇다면 어떤 장점이 있는가, 어떤 문제들이 있는가에 초점이 맞춰져 있었지만, 나는 좀 다른 관점에서 바라보았다. 회사의 프로덕트 자체를 OSS로 개발 시 어떤어떤 장점들이 있고, 그 장점을 취하고 싶은데, 이것이 나중에 회사의 가치에 어떤 영향을 줄 수 있을 것인가.

대기업에는 OSS 관리 전문팀이 있다고 한다. 이 팀에서는 자사의 프로덕트에 OSS가 들어가 있지 않은가를 늘 확인하고, 그 경우 적절한 대처를 한다. Blackduck 같은 상용프로그램을 사용하여 소스코드에 OSS가 포함되었는가를 검증해 볼 수도 있다. BSD나 MPL, LGPL 등의 라이선스는 문제가 크지 않지만, 문제시되는 라이선스는 GPL. 최근 서버 측 서비스로의 활용까지 제약하는 Affero GPL 라이선스도 있다.



만일 GPL 라이선스 OSS가 사용되었다면, 프로덕트의 성격에 따라서 회사에 심각한 피해를 줄 수도 있다. 특히 임베디드 분야는 실질적인 제품판매와 연결되어 있기 때문에 피해가 두드러진다 . 개발자가 아무 생각 없이 갖다 쓴 OSS로 인해 예기치 않은 피해를 볼 수도 있는 것이다. 만일 해당 OSS의 저작권자 혹은 OSS재단에서 소송을 제기한다면 회사는 소스코드를 공개하거나, 해당 부분을 다시 만들어야 한다. (재판 기간에 판매활동도 할 수 없다.)

내가 속한 분야를 살펴보니, Python, Django는 재배포시 소스코드 공개의무가 없지만, EMBOSS가 GPL이란 것이 눈에 띈다. 하지만 이부분 역시 Python으로 wrapper를 만들어 쓰는 것이라면 별문제는 없어 보인다.

MySQL의 듀얼 라이센스 정책은 OSS의 또다른 비즈니스 모델을 이야기해준다. 내가 만일 MySQL이 포함된 2차 저작물을 만들고, 이를 배포하려면, GPL에 의거 소스코드를 공개해야 한다. 소스코드공개가 부담된다면 상용라이센스를 구매하면 된다.

그럼에도 불구하고, 회사에서 OSS로 프로젝트를 진행하기에는 여전히 많은 부담이 따른다. 프로젝트에 특허기술이 있다고 하더라도 소스를 공개하는 이상 특허권을 주장하기가 모호해진다. 오픈한다고 해서 곧바로 실력 있는 개발자들이 모이는 것도 아니라면, 섣부른 공개는 오히려 기업가치의 하락을 의미할 것이다. 아직은 좀 더 고민이 필요한 부분.