오픈소스 소프트웨어란 소프트웨어의 저작권 소유자가 소스코드를 자유롭게 사용하고 변경, 배포 할 수 있도록 모두에게 공개한 소프트웨어를 말한다. 다만 오픈소스에는 라이센스 조건이 붙는 경우가 많다. 모두가 자유롭게 사용하고 변경, 배포할 수 있지만 지켜야 할 사항이 존재하는 것이다. 오픈소스 라이센스를 제대로 이해하지 않고 사용할 경우 법적 소송에 휘말려 금전적 피해를 입게 될 가능성도 있다. 따라서 오픈소스를 도입해 서비스를 개발하기 전에 도입하려는 오픈소스의 라이센스 조건을 제대로 알고 있어야 한다.
목차
저작권(Copyright)
저작권(Copyright)이란 창작물의 원작자가 소유한 법적인 권리를 말한다. 창작물을 만들기 위해 들어간 원작자의 노력과 창작물에 대한 저자의 가치를 보호하기 위해 존재하는 법적인 장치다. 저작권이 있는 소프트웨어를 사용하기 위해서는 로열티를 지불하고 사용해야한다. 요즘도 오픈소스가 아닌 소프트웨어를 사용하기 위해서는 시리얼을 구입하거나 사용권을 구독해야한다.
소프트웨어의 저작권에 반대되는 개념으로 Copyleft라는 개념이 있다. MIT 연구원이었던 리차드 스톨만이 GNU 프로젝트를 시작하며 소프트웨어는 좀 더 공유되기 쉽고, 연구되기 쉬워야 한다고 주장하며 Free Software Foundation을 설립했다. Free Software Foundation의 Free는 공짜라는 의미가 아니라 자유롭다는 의미다.
오픈소스 소프트웨어의 지지자들은 역시 Free Software에 대한 열렬한 지지자인 경우가 많다. 다만 소프트웨어 개발 프로젝트를 유지하기 위한 기업으로부터의 스폰싱이나 유료 서비스로의 사용에 대한 관점은 약간 차이가 있다. 소스코드의 결과물을 사용할 경우 무조건 소스코드를 오픈해야한다는 조건이 있는 라이센스도 있고, 아무런 조건없이 재 라이센싱만 없으면 사용할 수 있는 라이센스도 있다. 이 때문에 오픈소스의 다양한 라이센스들이 생겨났고, 우리의 머리가 아픈것이다.
오픈소스를 사용하는 이유
기업들이 오픈소스 소프트웨어를 도입하는 가장 큰 이유는 비용 절감이다. 오픈되어 있지 않은 소프트웨어에는 저작권이 있고, 사용하려면 로열티를 지불해야한다. 또 한, 소프트웨어 공급자에 의존적이게 만드는 경향이 있어 특정 소프트웨어에 락인되어 버리는 경향도 있다. 오픈소스는 상대적으로 표준화가 잘 되어 있어 여차하면 다른 프로젝트로 변환할 수 있는 여지가 많다.
오픈소스는 개발 사이클을 단축시켜준다. 커뮤니티에서 진행되는 오픈소스 프로젝트는 굉장히 빠른 사이클로 배포된다. 버그가 리포팅되면 수 많은 개발자들이 달려들어서 문제를 해결하고 빠른시일내에 새로운 버전이 배포된다. 동일한 이유로 새로운 기능이 빠르게 출시되며 커뮤니티에서 발견된 보안취약점은 굉장히 빠른 속도로 패치가되어 공개된다.
또 한, 오픈소스를 도입한 전세계의 수 많은 사이트들이 테스트 베드가 되어 프로젝트의 신뢰를 높여준다.
오픈소스 라이센스 범주
위와 같은 이유로 오픈소스의 도입은 기업입장에서는 굉장히 매력적이다. 하지만 발목을 잡는게 오픈소스와 함께 공개되어 있는 라이센스다. 라이센스는 오픈소스를 사용하이 위해 지켜야하는 조건들이 나열되어 있는 문서다. 조건을 충족하지 않으면 법적인 소송에 휘말려 금전적인 손해를 입고, 기업의 브랜드 이미지가 훼손되기도 한다. 따라서 오픈소스 도입에는 반드시 라이센스 분석이 필요하다.
오픈소스의 라이센스는 그 숫자가 굉장히 많다. 모든 라이센스를 다 분석할 수는 없다. 특히 개발자들이 이런 라이센스 조항들을 읽고 해석하는 것은 큰 낭비다. 기업에는 법무팀이 있을 테니 법무팀에서 사용하는 오픈소스의 라이센스를 반드시 검토해줘야한다.
그럼에도 개발자 역시 오픈소스의 라이센스를 어느정도 알고 있어야 오픈소스를 서비스에 빠르게 도입할 수 있다. 많은 오픈소스 라이센스가 있지만 크게 3가지 범주로 분류할 수 있다. 비슷한 라이센스 의무가 부과되고, 소스코드 공개 의무에 대해서도 비슷한 접근을 하고 있기 대문이다.
Permissive
좀 더 허용적인 라이센스들이다. BSD, MIT, Apache 등의 라이센스가 이 범주에 들어간다. 오픈소스 소프트웨어를 사용하고 재배포하는데 필요한 조건이 최소한이다. 이들 라이센스는 일반적으로 라이센스의 귀속 통지를 보관하거나 전달하는 것으로 제한된다.
Weak Copyleft
소프트웨어를 사용할 때 소스코드의 일부를 공개해야하는 라이센스다. 일반적으로 수정된 오픈소스 소프트웨어를 재배포 할 때 원본 소스코드 뿐만아니라 수정된 소스코드도 함께 공개해야한다. 이 범주에서는 LGPL이 대표적이다.
Strong Copyleft
흔히 오픈소스 잘 못쓰면 피본다는 말을 할 때 언급되는 라이센스들이다. 오픈소스와 결합된 모든 소스코드를 공개해야하는 라이센스다. 대표적으로 GPL 라이센스와 SSPL 라이센스 등이 있다.
GPL-2.0
Free Software Foundation의 대표 라이센스다. Free Software 철학에 기반해 만들어진 라이센스이기 때문에 "자유롭게 가져가 썼으니 너의 코드도 공개해랴"라는 원칙을 가지고 있다. 이 라이센스를 이용하 만든 소프트웨어는 동일한 GPL 라이센스를 사용해아하며 소스코드를 공개해야한다. 정확히는 당장 소스코드를 공개 안해도 되지만 누군가가 소스코드의 공개를 요청하면 USB에 담아서 우편으로 보내더라도 소스코드는 공개해야한다.
정리하면 GPL은 다음 원칙을 지켜야한다.
- 프로그램은 상용으로도 사용할 수 있다
- 프로그램은 항상 소스코드와 함께 배포되어야 한다
- 프로그램의 소스코드를 자유롭게 변경할 수 있다
- 변경된 프로그램 역시 소스코드를 공개해야한다
- 변경된 프로그램 역시 GPL 라이센스를 따라야한다 (전염성 조항)
GPL-Exception
GPL 라이센스에서 몇 가지 예외가 포함된 라이센스다. 대표적으로 리눅스 커널이 GPL-Exception 라이센스를 따른다. 리눅스 커널은 GPL-2.0 라이센스로 배포된다. 때문에 리눅스 커널의 소스코드가 모두 공개되어 있고, 공개된 커널 소스코드를 수정해서 만드는 제조사들의 커널들도 오픈소스로 공개되어야 한다.
다만 리눅스 운영체제에서 동작하는 사용자 프로그램들의 소스코드까지 모두 공개해야할 경우 리눅스 생태계의 발전이 매우 저해된다. 예를 들어 마이크로소프트의 오피스가 리눅스 버전을 지원하려면 소스코드를 공개... 해야한다. 이런 프로그램들은 리눅스 커널이 제공하는 시스템 콜을 사용하게 되기 때문이다.
따라서 약간의 수정조항이 추가되었다. GCC 런타임 라이브러리를 이용해 컴파일한 프로그램, GCC 헤더 파일은 GPL 라이센스의 영향을 받지 않는다. 예외가 적용되는 폰트를 사용해 문서를 작성하거나 문서에 글꼴이 포함되는 경우, 문서는 GPL 라이센스의 영향을 받지 않는다.
AGPL-3.0
네트워크 서버에서 사용하기 위해 만들어진 GPL 라이센스의 변종이다. 네트워크 서버의 경우 소프트웨어가 외부에 배포되지 않고 서비스 형태로 제공되기 때문에 라이센스 의무가 부과되지 않았었는데, AGPL은 네트워크를 통한 서비스 제공을 외부 배포로 간주한다.
네트워크 서버와 클라우드 도메인에 적용되는 라이센스로 GPL 라이센스와 비슷하다.
SSPL-1.0
몽고DB에 의해서 도입된 라이센스다. 클라우드 서비스 제공자에게 좀 더 강력한 의무를 부과하기 위해 AGPL 라이센스를 기반으로 만들어졌다. 엄밀하게 오픈소스 라이센스라고 부르기는 애매하다.
단순히 몽고 DB를 서비스의 저장용 DB로만 사용하는 경우, 연결되는 앱에는 소스코드 공개 의무가 발생하지 않는다. 하지만 몽고DB 소스코드를 수정하지 않더라도 데이터 저장을 서비스의 일부로 제공하는 경우 라이센스 의무가 발생한다.
LGPL
LGPL 라이센스의 L은 Lesser 혹은 Library를 의미한다. GPL 라이센스보다 조금은 약한 정도의 라이센스다.
GPL 라이센스의 경우 GPL 라이센스가 적용되어 있는 라이브러리를 가져다 사용하는 모든 소프트웨어에서도 GPL 의무가 부과되는 전염성 조항이 있다. 따라서 노력을 들여 소스코드를 작성해 소프트웨어를 개발하더라도 모든 것을 공개해야하는 부담이 있다. 모든 것을 공개해야한다는 부담은 오픈소스 라이브러리의 경쟁력을 약화할 수 있는 문제를 내포한다.
LGPL 라이센스는 라이브러리를 동적 혹은 정적 링킹으로 사용하는 경우, LGPL 라이센스의 라이브러리를 사용했다는 점만 명시하면 된다. 다만 LGPL 라이브러리 자체를 수정해서 새로운 라이브러리를 배포하는 경우에는 전체 코드를 공개해야한다.
BSD
BSD 라이센스는 가장 허용적인(Permissive) 라이센스 중 하나다. 버클리대학에서 개발한 운영체제인 BSD 유닉스 계열에서 주로 채택하고 있는 라이센스다. BSD 라이센스가 적용된 코드는 누구나 자유롭게 사용할 수 있고, 소스코드를 공개하지 않아도 되며, 상업적인 목적으로 소스코드를 돈 받고 팔아도 된다. 사실상 무제한 라이센스다.
다만 소프트웨어를 이용해서 발생할 수 있는 모든 리스크와 그 결과는 본인이 감수하도록 한다.
MIT
이름에서 알 수 있듯이 MIT 대학에서 만든 소프트웨어 라이센스다. BSD 라이센스를 기반으로 만든 라이센스이기 때문에 거의 비슷하다. 소프트웨어를 자유롭게 사용하되 출처 표기를 명확하게 해야한다.
Apache
웹 서버 Apache로 유명한 아파치 재단에서 만든 라이센스로 Apache HTTP 서버를 배포하기 위해 사용된 라이센스다. BSD 라이센스처럼 자유롭게 사용하지만 대신 출처 표기를 명확하게 해야한다. 소스코드의 상태 변화에 대해 명시해야하고, 트레이드 마크를 사용할 수 없다.
즉, 아파치 라이센스로 배포된 소프트웨어는 그 소프트웨어가 특허출원이 되어 있어도 사용자에게 특허 사용료를 요구할 수 없다는 조항이 들어가 있다. 소스코드만 공개해두고 특허를 걸어서 소송을 제기하는 상황을 명시적으로 막아둔 것이다. 이 때문에 개발자들이 가장 선호하는 라이센스 중 하나가 되었다.
마치며
이 블로그 포스트는 라이센스 분쟁이 생겼을 때 참고할 수 있는 문서가 아님을 다시한번 언급한다. 본인이 사용하는 오픈소스 소프트웨어의 라이센스는 본인들이 직접 파악하고 사용해야한다. 사내 법무팀이나 자문 변호사가 있는 경우 그 쪽으로 문의해서 정확한 법적인 내용을 알고 사용하는게 좋다.
오픈소스 소프트웨어의 사용이 늘어남에 따라 관련 법적 분쟁도 늘어나고 있는 추세다. 오픈소스를 도입한 기업이나 도입을 고려하고 있는 기업이라면 사내 개발자들에게 오픈소스 라이센스 이용절차를 제공해야하며, 관련 프로세스와 가이드, 정책 등을 반드시 수립해야한다. 오픈소스 라이센스의 법적인 문제를 개발자의 책임으로 전가하기엔 너무 복잡하다.
댓글