오픈소스 바르게 사용하기
소프트웨어를 개발하면서 많은 오픈소스를 사용하게 됩니다. 공개되어 있기 때문에 쉽게 사용할 수 있지만 그만큼 놓치기 쉬운 부분이 저작권 침해와 관련된 오픈소스 라이선스입니다.
오픈소스를 바르게 사용하기 위해 주의해야 할 오픈소스 라이선스와 저작권의 개념에 대해 알아보겠습니다.
우리가 아는 오픈소스
1991년 8월 26일에 Linus Torvalds는 취미 삼아 만든 커널을 UNIX의 교육용 버전인 MINIX의 메일링 그룹에 공개했습니다. 이 커널이 우리가 잘 알고 있는 운영체제인 Linux의 시작입니다.
Linux는 지금까지도 전 세계에서 수많은 개발자가 개발에 관여하고 있는 대표적인 오픈소스입니다. Linux를 기반으로 Fedora, Ubuntu, CentOS 등 다양한 Linux 배포판이 파생됐고, 모바일 운영체제인 Android 역시 Linux 커널을 기반으로 만들어졌습니다. "GNU/Linux Distribution Timeline" 사이트를 살펴보면 Chromium OS도 Linux에서 시작됐음을 알 수 있습니다.
운영체제 외에도 브라우저, 프런트엔드 플랫폼, 웹 애플리케이션 서버 등 다양한 종류의 오픈소스가 있습니다.
- Chromium: Google의 브라우저인 Chrome의 기반이 되는 오픈소스입니다. 네이버가 만든 브라우저인 웨일도 Chromium을 기반으로 합니다.
- Bootstrap: 트위터가 공개한 반응형 웹 프런트엔드 플랫폼입니다. 오픈소스로 공개된 덕분에 많은 개발자가 손쉽게 반응형 웹 페이지를 개발할 수 있게 됐습니다.
- Tomcat: 웹 개발 환경에서 빠질 수 없는 웹 애플리케이션 서버로, 많은 개발자가 참여하고 있는 오픈소스입니다.
오픈소스와 저작권
누구나 글, 그림, 소스 코드와 같은 창작물을 만들면 그 창작물에 대해 저작권을 갖게 됩니다. 공개된 소스 코드인 오픈소스에도 저작권이 있습니다.
공개되어 있는 소스 코드는 모두 사용할 수 있을까요
법에서는 창작물의 저자는 다른 사람이 그 창작물로 할 수 있는 일의 범위를 정할 수 있는 권리를 갖고 있다고 가정합니다. 그래서 일반적으로 저작권자의 허락 없이는 창작물에 대한 사용, 복사, 배포, 수정이 불가능합니다.
오픈소스에서는 저작권자가 소스 코드의 사용 범위와 사용자의 의무 사항을 라이선스에 명시해 둡니다. 공개되어 있는 소스 코드지만 여전히 저작권이 존재하기 때문에 라이선스를 확인하지 않고 사용하면 저작권을 침해할 가능성이 있습니다. 오픈소스를 사용할 때는 반드시 라이선스를 확인하고 의무 조항을 준수해야 합니다.
오픈소스는 '무료'일까요
오픈소스에 관해 많이 하는 질문이 "오픈소스는 무료입니까?"입니다. 실제로 비용이 들지 않는다는 점은 오픈소스의 매력 중 하나입니다. 그러나 '무료'가 오픈소스의 전부는 아닙니다.
오픈소스 프로젝트의 대부분은 누구나 목적에 관계없이 소스 코드를 사용하고, 수정하고, 공유하는 것을 허용하기 때문에 프로젝트가 무료로 제공되는 경우가 많습니다.
하지만 '무료'는 오픈소스를 정의하는 용어가 아닙니다. 저작권자가 라이선스에 명시한 무료 사용 조건과 의무 사항을 지키는 경우에만 무료로 사용할 수 있습니다. 오픈소스 프로젝트 중에는 예외로 유료로 사용할 수 있게 하는 듀얼 라이선스를 적용하거나 무료 라이선스 버전에는 기능을 제한하는 등의 방법으로 과금하는 프로젝트도 있습니다.
오픈소스를 사용할 때 주의할 점
오픈소스를 사용할 때는 오픈소스의 출처와 저작권, 라이선스 정보를 남겨 두어야 합니다.
저작권과 라이선스 주석을 유지해야 합니다
많은 오픈소스는 소스 코드의 시작 부분에 저작권과 라이선스 정보를 주석으로 명시해 둡니다. 그리고 대부분의 오픈소스가 저작권과 라이선스 정보 표기를 의무 조항으로 두고 있습니다.
하지만 오픈소스를 사용할 때 무심코 이 주석을 지우는 경우가 있습니다. 만약 이후 자신의 프로젝트를 오픈소스로 공개할 때를 대비해서라도 프로젝트에 사용한 오픈소스의 출처를 밝히고 저작권과 라이선스 정보를 유지해야 합니다. 소스 코드 유지 보수 및 관리를 위해서도 출처를 남겨 두는 습관은 중요합니다.
다음은 네이버의 오픈소스 프로젝트 중에 하나인 Pinpoint의 소스 코드에 있는 주석입니다. Pinpoint가 사용한 오픈소스인 jQuery UI의 Datepicker 위젯에 있는 저작권 및 라이선스 정보를 주석에서 삭제하지 않고 그대로 두었습니다.
파일 단위나 함수 단위의 오픈소스도 출처를 꼭 명시해야 합니다
오픈소스를 파일이나 모듈 단위로 일부만 사용할 때는 출처나 저작권, 라이선스 정보를 누락하기 쉽습니다. 만약 별도의 저작권과 라이선스 표기가 없더라도 자신이 작성한 소스 코드가 오픈소스로 공개될 때를 대비해 출처를 명시해 자신의 코드를 다른 사람의 코드와 구분할 수 있게 해야 합니다.
다음은 네이버의 오픈소스 프로젝트 중에 하나인 egjs의 소스 코드에 있는 주석입니다. AngularJS의 validate-commit-msg.js 파일을 수정해서 사용했음을 명시하고 있습니다.
오픈소스 라이선스
오픈소스 라이선스는 오픈소스로 배포된 소스 코드를 사용할 때 지켜야 하는 규약 등을 명시한 것입니다. 라이선스에 명시된 조항을 지킨다면 해당 소스 코드를 사용할 수 있다는, 일종의 허락입니다. 라이선스에서 명시한 사용 조건을 이행하지 않거나 라이선스 표기가 되어 있지 않은 소스 코드를 임의로 사용하면 저작권 침해에 해당될 수 있으니 오픈소스 라이선스를 주의해서 확인해야 합니다.
이 절의 내용은 "오픈소스 소프트웨어 라이선스 가이드 3.0"의 내용을 기반으로 작성되었습니다.
오픈소스 라이선스 주요 요구 사항
오픈소스 라이선스에서 사용자가 따를 것을 요구하는 주요 의무 사항은 다음과 같습니다.
저작권, 개발자 및 컨트리뷰션 정보의 표시
컨트리뷰션은 오픈소스 프로젝트에 참여하고 기여하는 행동입니다. 대부분의 오픈소스 라이선스는 개발자와 컨트리뷰션에 관한 정보와 저작권에 관한 정보를 제품에 표시하거나 포함하도록 요구합니다.
소스 코드를 수정한 정보의 표시
사용자가 소스 코드를 수정했을 때에는 원본과 구별할 수 있게 수정한 사람, 수정 일자 등 수정에 관한 내용을 포함하도록 요구합니다.
라이선스 정보의 제공
많은 오픈소스 라이선스는 사용자가 오픈소스에 관한 권리를 잘 이해할 수 있도록 배포자로 하여금 해당 라이선스의 사본을 함께 첨부할 것을 요구합니다.
동일한 라이선스로 재배포
라이선스에 따라 큰 차이를 보이는 부분은 'copyleft'에 관한 사항입니다. GPL(GNU General Public License)을 대표로 하는 copyleft 라이선스는 사용자가 소프트웨어를 수정한 후 배포하고자 할 때 수정된 소프트웨어도 동일한 라이선스로 배포할 것을 요구합니다.
소스 코드의 제공
copyleft 조항을 포함하는 라이선스는 소프트웨어를 배포할 때 소스 코드까지 함께 배포하도록 요구합니다.
주요 오픈소스 라이선스 특징 비교
다음은 주요 오픈소스 라이선스의 무료 이용 여부, 배포 허용 여부, 소스 코드 공개 의무 등을 비교한 내용입니다.
| 무료 이용 가능 |
배포 허용 가능 |
소스 코드 취득 가능 |
소스 코드 수정 가능 |
2차적 저작물 재공개 의무 |
독점 SW와 결합 가능 |
|
|---|---|---|---|---|---|---|
| MIT License | O | O | O | O | X | O |
| BSD 2-Clause BSD 3-Clause |
O | O | O | O | X | O |
| Apache License 2.0 | O | O | O | O | X | O |
| GPLv2 GPLv3 |
O | O | O | O | O | X |
| LGPLv2 | O | O | O | O | O | O |
| MPL | O | O | O | O | O | O |
각 라이선스의 상세 내용과 라이선스 문구는 다음 사이트에서 살펴볼 수 있습니다.
오픈소스 라이선스 확인과 준수
오픈소스를 사용하기 전에 라이선스를 확인하고 라이선스의 의무 사항을 준수해야 합니다.
오픈소스 라이선스 확인
오픈소스의 라이선스는 보통 소스 코드 저장소의 최상위 디렉터리에 있는 LICENSE 문서나 README 문서에서 볼 수 있습니다. 그 외에도 오픈소스 라이선스는 다음과 같은 방법으로 확인할 수 있습니다.
만약 라이선스 정보를 찾지 못했다면 사용 목적에 맞게 소스 코드를 사용할 수 있는지 저작권자에게 확인해야 합니다.
별도의 홈페이지가 있는 경우
오픈소스 프로젝트가 별도의 홈페이지를 운영하고 있을 때는 홈페이지의 다음과 같은 곳에서 라이선스를 확인할 수 있습니다.
- LICENSE 메뉴
- 소프트웨어 설명 내 표기
- 소스 코드 내 COPYING 문서, README 문서
- 소스 코드 내 주석
다음은 Tomcat 홈페이지에서 확인할 수 있는 Tomcat의 라이선스 정보입니다.
GitHub 저장소가 있는 경우
오픈소스 프로젝트를 GitHub에서 운영할 때는 다음과 같은 곳에서 라이선스를 확인할 수 있습니다.
- README 문서
- 소스 코드 내 COPYING 문서, LICENSE 문서
- 소스 코드 내 주석
다음은 Bootstrap의 GitHub 저장소에 있는 README 문서에서 확인할 수 있는 라이선스 정보입니다.
검색으로 찾은 소스 코드인 경우
Google이나 Stack Overflow에서 검색해 찾은 소스 코드나 블로그에 올라온 소스 코드를 사용할 때는 다음과 같은 곳에서 라이선스를 확인할 수 있습니다.
- 소스 코드 내 주석
- 개발자의 답변
다음은 Stack Overflow의 답변에 있는 소스 코드에서 확인할 수 있는 라이선스 정보의 예입니다.
의무 사항 준수
저작권과 라이선스 정보 표기 등 오픈소스 라이선스에서 명시하고 있는 의무 사항은 다음 예와 같은 형식으로 준수할 수 있습니다.
애플리케이션으로 배포하는 경우
오픈소스를 사용한 프로젝트를 애플리케이션으로 배포할 때는 애플리케이션의 설정 메뉴 하위에 법적 공지나 오픈소스 라이선스 메뉴를 두어 저작권과 라이선스 정보를 표기할 수 있습니다.
다음은 iOS용 네이버 지도 앱의 설정 > 오픈소스 라이선스 메뉴를 통해 저작권 정보와 라이선스 정보 표기 의무를 준수한 예입니다.
오픈소스로 재배포하는 경우
오픈소스를 사용한 프로젝트를 오픈소스로 다시 배포할 때는 새로운 프로젝트의 NOTICE 문서나 서드파티 관련 메뉴에서 저작권과 라이선스 정보를 표기할 수 있습니다.
다음은 Pinpoint 프로젝트의 NOTICE 문서를 통해 저작권 정보와 라이선스 정보 표기 의무를 준수한 예입니다.
오픈소스를 사용하다 보면
오픈소스를 사용하다 보면 버그를 찾아 수정해야 할 때가 있습니다. 이때 자신의 소스 코드에서만 버그를 수정하면 오픈소스의 다음 버전에서는 해당 버그가 수정되지 않을 것 입니다. 그러면 오픈소스가 업데이트될 때마다 매번 그 버그를 찾아 수정해야 할 수도 있습니다. 발견한 버그와 직접 수정한 소스 코드가 원래의 오픈소스에 적용될 수 있게 저작권자에게 연락해 보는 것은 어떨까요.
다음은 네이버의 개발자가 Hadoop YARN을 사용하다 발견한 버그를 이슈로 등록하고, 직접 해당 이슈를 해결한 사례입니다.
버그 수정뿐만 아니라 불편한 사항이나 새로운 의견을 오픈소스 프로젝트에 알리는 것만으로도 컨트리뷰션의 시작이 될 수 있습니다. 컨트리뷰션 방법은 "컨트리뷰션 시작하기"에서 살펴볼 수 있습니다.