오픈소스 라이선스에 따라 소스코드 공개 의무가 달라진다
상태바
오픈소스 라이선스에 따라 소스코드 공개 의무가 달라진다
  • 신상수 선임
  • 승인 2019.11.04 04:17
  • 조회수 4554
  • 댓글 0
이 콘텐츠를 공유합니다

회사 내부 시스템을 재구축하려는 A회사가 있다. 이 회사에서 일하고 있는 B대리는 시스템 구축 비용의 절감을 위해 적극적으로 오픈소스를 검토하고 있다. 상용 DBMS 대신 MariaDB나 PostgreSQL을 이용하고 상용 WAS 대신 Tomcat 등을 사용하고자 한다. 이 외에도 되도록 모든 분야에 오픈소스를 도입하고자 한다.

B대리는 화면을 위한 UI 구성, 문서 출력 폼을 만들어 주는 레포팅 툴의 사용을 위해서 다양한 제품을 검토하던 중, 오픈소스이면서 동시에 상용 솔루션이 있는 것을 발견하였다. 이 일을 계기로 B대리는 오픈소스에도 라이선스가 있다는 사실을 알게 되었다.

  

오픈소스 도입의 장점

근 기업들이 시스템 구축을 위해서 오픈소스를 적극적으로 검토 및 사용하고 있다. 오픈소스 소프트웨어를 사용하는 것은 점점 대세로 자리 잡아가고 있다. 그 이유는 다음과 같다.

▶ 소프트웨어 도입 비용을 대폭 절감할 수 있다
▶ 특정 벤더의 과도한 유지보수 비용 요구 등으로부터 벗어날 수 있다
▶ 오픈소스 생태계가 형성되어 상용 소프트웨어보다 기능 개선 속도가 더 빠르다
▶ 클라우드 환경 확산으로 오픈소스 소프트웨어를 사용하는 것이 더 편리하다
▶ 오픈소스 개발자와 믿을 만한 오픈소스 벤더를 소싱하는 것이 쉬워졌다

오픈소스를 도입하는 것은 모든 기업들의 과제가 되어 있다. 간단한 업무에 적용하는 차원을 넘어서 핵심 업무에까지도 적용 범위는 확대되고 있다. DBMS에서도 오픈소스 DBMS의 선호도는 상용 소프트웨어 DBMS를 넘어서고 있다.
 

투이톡_오픈소스_1.jpg
[그림 1] 2019년 DBMS 선호도 (Source: ScaleGrid, https://dev.to/scalegrid/2019-postgresql-trends-report-private-vs-public-cloud-migrations-database-combinations-top-reasons-used-jea)

 

오픈소스에도 라이선스가 있다

그러나 B대리가 발견한 것과 같이 오픈소스에도 라이선스가 있다. 오픈소스 소프트웨어 라이선스는 일반 상용 소프트웨어 라이선스와 다르게 사용 로열티를 지급하지 않는다. 다만 사용하는데 있어서 지켜야 될 의무가 있다. 주요 의무사항으로는 저작권/개발자 및 기여자 정보의 표시, 코드 수정 시 수정한 정보 표시, 라이선스 정보의 제공, 동일한 라이선스로 재배포, 소스코드의 공개가 있다.

 

투이톡_오픈소스_2.jpg  
[그림 2] 오픈소스 라이선스 유형별 권리 (source: https://www.umass.edu/tto/inventors-artists/inventors/open-source-guide)

기업 시스템을 오픈소스 소프트웨어로 구축하기 전, 첫 번째로 검토해야 할 것은 오픈소스 여부에 관계없는 상업적 사용에 대한 대가 지불이 필요한지 여부이다. 오픈소스는 무료 소프트웨어(프리웨어)라기보다 소스 코드가 공개되어 배포 될 수 있는 소프트웨어이기 때문이다. 따라서 오픈소스 소프트웨어 도입 목적이 비용절감이라면 오픈소스라 하더라도 소프트웨어 사용에 따른 대가가 필요해 원하는 목적을 이루지 못할 수 있다.

두 번째로 검토해야 할 것은 오픈소스 소프트웨어를 이용하여 만든 파생저작물에 대한 의무 사항이다. 대표적인 오픈소스 라이선스인 GPL 2.0 라이선스의 경우, 해당 라이선스를 가진 오픈소스 소프트웨어를 이용하여 소프트웨어를 제작한 당 소프트웨어 역시 GPL 2.0 라이선스를 따르게 의무사항으로 되어 있다. 따라서 GPL 2.0 라이선스에 따라 소스코드를 공개하여야 하는 의무가 발생한다. 이러한 특징을 가진 라이선스는 Copyleft로 통칭된다.
 

투이톡_오픈소스_3.jpg

[그림 3] GPL 2.0 라이선스 감염

 
라이선스 유형에 따라 기업 시스템도 오픈소스가 되어야 한다

Copyleft 라이선스 오픈소스 소프트웨어 파생저작물에 대한 의무사항은 완제품이 아닌 솔루션 및 라이브러리 형태 오픈소스가 기업 시스템의 일부에 사용되는 경우 문제가 된다. 별도로 분리하여 이용하는 형태로서 기업 시스템의 구축에 사용되는 DBMS, 웹 서버, WAS 등은 그 자체 소프트웨어를 이용하는 경우로서 라이선스의 파생저작물에 대한 의무에서 벗어날 수 있는 길이 있다.

그러나 솔루션이나 라이브러리 형태 오픈소스 소프트웨어를 이용한 기업 시스템 전체가 파생저작물로서 하나의 소프트웨어로 해석 할 수 있다. 따라서 이를 활용한 기업 시스템을 구축한 경우 전체 기업 시스템의 소스를 전체 공개할 의무가 발생하고, 이에 따라 공개를 해야 하는 문제가 발생할 수 있다.

 

투이톡_오픈소스_4.jpg  
[그림 4] Permissive License와 Copyleft License (source: http://blog.thehyve.nl/blog/open-source-software-licenses-3)

 

Permissive 라이선스가 대안이 될 수 있다

그렇다면 위 사례의 B대리는 어떤 대안이 있을 수 있을까? 다행히 오픈소스 중에서도 상업적인 활용과 라이브러리나 제품에 포함이 되더라도 소스코드 반환 라이선스가 감염 되지 않는 이 Permissive 라이선스도 있다. 대표적인 예로 MIT License, Apache 2.0, BSD License이다. 이러한 이유로 시장에서도 이러한 라이선스를 채택하고 활용하고, 공개하는 등 이러한 소프트웨어가 지속적으로 증가하고 있다.

 

투이톡_오픈소스_5.jpg
[그림 5] Top Open Source Licenses in 2018 (source: Whitesource, The complete guide for open source licenses 2019)

Permissive 라이선스는 소스코드의 공개 의무가 없다. 때문에 기업 시스템을 구축 시 이를 활용한 라이브러리가 포함이 되더라도 소스코드 공개의 문제가 해결된다. 따라서 B대리의 사례처럼 재구축 사업을 위한 오픈소스 소프트웨어의 사용을 검토할 경우 Permissive 라이선스를 가진 소프트웨어를 이용하여 시스템 아키텍처로 기업 시스템을 구축해야 문제가 생기지 않을 것이다.

투이톡_오픈소스_6.jpg  
[그림 6] Perssive Vs. Copyleft 선호도 (source: Whitesource, The complete guide for open source licenses 2019)

- 끝 -

 

댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.