오픈소스 소프트웨어란 무엇일까? 우리가 흔히 아는 예로 위키피디아를 떠올리면 이해가 쉬울 것이다.
위키피디아는 사람들이 자원하여 협력하여 내용을 담아가는 일종의 백과사전이다. 지식을 공유하여 협업, 개정하는 과정을 통해 발전한다.
Open Source의 정의
- 법적인 관점
자유롭게 열람, 사용, 수정가능하고 타인에게 배포할 수 있도록 만든 모든 것(SW, HW, 설계, 아이디어 등등)
- 절차적인 관점
커뮤니티에서 오픈프로젝트로 집단 협업을 통해 만들어지는것
구글의 tensor flow도 오픈소스로 공개하였다. 왜 자신들이 개발한 튤들을 공개하는 것인가?
그 이유는 더 많은 개발자들을 모아 특정 기술을 더 빨리 발전시키기 위함이다. 사람들에게 공개함으로써 아이디어와 혁신을 수용할 수 있다. 현재 시장은 오픈소스 기반 움직이고 있고 이것이 혁신을 이루는 강력한 도구라는 것이 증명이 되었다.
개발자 입장에서는 오픈소스는 자신의 코드를 공개하여 자신의 것을 발전시키는데 도와주도록 하는 멘토링의 개념으로 바뀌고 있다.
오픈소스 소프트웨어라는 용어는 Free, OSS라는 의미에서 FOSS, Free libre OSS라는 의미에서 FLOSS로도 쓰인다.
오픈소스 프로젝트에 참여하면 다른개발자를 보게 된다. 자신보다 좋은 개발자들의 코드도 보게 되고 의사소통도 더 효율적으로 할 수 있는 경험치를 쌓을 수 있다. 이상적이다. 사용자가 많은 오픈소스의 경우 고객이 자신이 기여한 오픈소스를 사용하는 경험할 수 있다.
Google, MS 등 많은 기업들이 오픈소스에 많이 투자하고있다. 대부분 오픈소스 기반 회사들이다. MS는 2018년 5월에 github을 인수했다.
Open Source License
오늘날 대부분의 OSS 라이센스는 permissive 라이센스이다.
오픈소스의 사용자 입장에서는 소스를 가져다가 자유롭게 변경하고 그것을 공개하지 않아도 되는 높은 자유도를 가지는 것을 의미한다.
그런데 누가 내 것을 가지고 더 좋은 것을 만든 후 공개하지 않는다면 억울한 것이 아닐까? 그럴수도 있지만 큰 장점을 가지고 있다. permissive 라이센스는 커뮤니티에 사람들이 모이므로 공개하지 않을때 보다 커뮤니티 버전의 향상을 더 도모할 수 있다. 공개를 하지 않으면 유지 보수 및 발전에 대해서 경제적으로 효율적이지 못한다는 단점이 존재한다. 중복이나 코드에 대한 기술부채를 그들 스스로 져야 한다. 커뮤니티 공개를 통해 얻을 수 있는 협업과 혁신의 과정에 대한 이점을 얻지 못하는 것이다. 따라서 오픈소스에 기여하는 것은 모두에게 이점을 줄 수있다.
1. 공개sw 라이선스 관리 필요성
내부시스템을 개발할때 공개 sw를 가져와 사용할 수 있다. 하지만 사용시에 라이센스 분쟁이 많이 발생한다. 완제품,툴,유틸리티의 경우 그것을 가져가 사용하는 데 주 목적이 있다. 반면 소스코드나 라이브러리의 경우 완제품이 아니기 때문에 2차 저작물을 만드는데 쓰일 수 있다. 이때 자신의 소프트웨어를 배포할 때 의무사항들이 생기게 된다.
공개sw는 그 유입경로가 매우 다양하기 때문에 공개sw에 따라 내부적으로 정책을 관리,검토하여 임직원들이 공개sw를 절차에 따라 사용할 수 있도록 해야 한다.
공개sw유입경로
- 내부적 검토완료 된 공개sw
- 개발자가 다운로드 한 검토되지 않은 공개sw
- 재사용되는 내부코드에 포함된 공개sw
- 상용 소프트웨어에 포함된 공개sw
- 써드파트 라이브러리에 포함된 공개sw
- 외주개발에서 사용된 공개sw
이러한 복합적인 공개sw라이센스를 식별하지 못하면 여러 법률적 분쟁이나 경제적 손실을 가져올 수도 있다.
따라서 가시화된 공개sw 관리 정책과 절차를 구축해야 한다.
2. 공개sw 라이선스 이해
공개sw도 저작권이 있다. 하지만 저작권자가 자신의 저작권리를 주장하는 방식이 상용소프트웨어와 사뭇 다르다. 사용자에게 부여하는 책임조항(특허포기, 고지의무, 소스공개 등)으로써 그 저작권리를 행사한다. 그리고 저작권자에 따라 책임에 대한 범위가 다를 수 있기에 라이센스의 종류가 2000개가 넘는다.
Copyleft(free software)
소스코드는 누구든지 사용할 수 있도록 공개한다. 라이센스는 원래 저작물 뿐 아니라 파생저작물에도 적용된다.
Permissive(Open source software)
사용에 대해 별다른 요구사항을 부여하지 않음
주요 라이센스 및 의무사항
1. GPL 3.0(General Public license) - StrongCopyleft결합된 모든 코드에 대한 공개해야 한다.
- 특허보복 조항
- DRM금지조항
- 네트웍 서비스(AGPL)
위 3가지는 GPL2.0에 대해 추가된 항목들이다.
- 특허 라이센스 명시
- 공유 : 복제 및 배포 시에, 소스코드 공개 의무 발생한다. 이때 공개 범위는 모든 모듈의 원시코드 및 이와 관련된 인터페이스 파일 전부, 컴파일 및 설치 관련 스크립트 전부가 해당된다. 혹은 3년간 유효한 소스코드 약정서를 제출해도 무방하다. 실행 시 공유주소 영역에서 링크되어 실행된다면 모두 GPL에 적용된다.
GPL예외조항
분리 혹은 독립된 저작물이라고 인정되면 해당 라이센스를 적용하지 않는다. system expection, linking expection - linking 방식으로만 해당 저작물을 사용할 경우, classpath expection 등 다양한 예외조항들이 있다.
2. LGPL(Lesser General Public license) - 공개sw를 라이브러리 형태로 결합할 경우에는 사용자 코드를 공개하지 않아도 된다.
- LGPL에서 라이브러리란 소프트웨어 기능 및 데이터의 집합을 의미한다.
- 라이브러리의 소스코드를 수정해서 복제,배포하는 경우는 전체 라이브러리 소스 코드를 공개해야 한다.
- 링크하여 그대로 사용하는 경우 저작물 출쳐와 고지의무를 다하면 소스코드 공개의 사항은 발생하지 않는다.
3. MPL(Mozilla Public License) - weakCopyleft - 사용자가 일부 수정할 경우 해당 파일만 공개하도록 한다. 특허권리를 주장할 수 없음센
- 수정된 파일에 한하여 코드 공개 의무가 발생한다.
- MPL2.0은 1.0과 대비하여 다른 라이센스로 배포가능하다. 라이센스 양립이 가능하다.
4. EPL(Eclipse Public License) - 수정된 코드를 포함한 모듈단위의 소스코드를 공개하도록 요구한다.특허권리를 주장할 수 없음
5가지 주요공개sw관리 프로세스
- 공개sw 사용 목록 구축
- 알려진 보안취약점 맵핑
- 라이선스와 품직 리스크 식별
- 공개sw 리스크 정책 집행
- 새로운 보안취약점 모니터링