오늘 페이스북 타임라인을 읽다보니 '리눅스 HWP 공개 라이브러리 개발' 건에 대한 라이선스 이야기를 하는 글들이 보이네요. 저도 예전에 FCKEditor를 적용한 제품때문에 LGPL의 정체가 뭔지 몰라서 어려웠던 기억이 납니다. 글타래를 읽다보니 LGPL에 대해서 애매한 이야기들이 좀 있는것 같아서 정리해봅니다.
1. 공통적으로 지킬 것
일단 OSI(Open Source Initiative)에 등록되어 있는 오픈소스SW 라이선스는 GPL이건 LGPL 이건 상관없이 공통적으로 지켜야 하는 내용이 두가지 있습니다.
가. 저작권 관련 문구 유지
- 가져다 쓰는 것은 자유롭게 하고 개발자의 정보는 삭제하지 않는 것이죠. 이것은 원 저작권자의 인격을 보호하기 위한 사항으로 마음대로 삭제하시면 안됩니다.
나. 제품명 중복 방지
- 아파치, 리눅스 같은 프로젝트명을 선택하면 안된다는 의미입니다.
두 가지 모두 무엇인가를 직접 만들어본 사람이라면 상식적인 수준에서 지켜야 하는 것이죠.
2. LGPL 라이선스를 가져다 쓰는데 소스코드를 공개해야만 하나요?
LGPL은 GPL의 조건이 너무 엄격해서 사람들이 쓰는 것을 꺼려할까봐 이를 감안해서 만든 라이선스 입니다. 따라서 GPL과는 다르게 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다. LGPL 전문에 있는 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다. 따라서 자기가 만든 소스코드의 공개없이 가격을 받는 상용제품으로 판매하셔도 됩니다.
다만, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.
3. LGPL을 가져와서 개발하고 GPL 라이선스로 변경해도 될까요?
대답은 변경해도 됩니다. 아래 내용을 보시면 "양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다"라고 표기되어 있습니다. 하지만 GPL 소스코드를 가져와서 임의로 LGPL로 변경하는 것은 안됩니다.
http://olis.or.kr/ossw/license/license/detail.do?lid=1005&mapcode=¤tPage=
제3조.
당신은 양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다. 이를 가능케 하기 위해서는 본 라이선스를 언급하는 모든 사항들을 GNU 일반 공중 라이선스 버전2의 사항들로 대체시켜야 한다. (만약 GNU 일반 공중 라이선스 버전 2 이후에 신규 버전이 공표되었을 경우에는 원한다면 신규 버전을 사용할 수 있다.) 그 외에 다른 사항들은 변경할 수 없다.
복제물에 대해 이러한 수정이 이루어졌을 경우에는 라이선스를 다시 변경하는 것은 불가능하며, 따라서 해당 복제물을 기반으로 만들어진 모든 저작물과 복제물에는 GNU 일반 공중 라이선스가 적용되어야 한다.
이러한 선택 사항은 라이브러리의 코드 일부분을 라이브러리가 아닌 프로그램에 포함시키고자 할 경우에 유용하다.
하지만 LGPL을 제외한 나머지 라이선스는 원 저작자가 아닌 사람이 임의로 라이선스를 변경할 수 없습니다. LGPL은 명확하게 전문에 표기하였기 때문에 문제가 없지만 다른 오픈소스SW 라이선스는 이를 허용하지 않습니다.
4. 더 궁금하시면
다른 오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.
- 한국저작권위원회 라이선스 설명 : http://olis.or.kr/ossw/license/license/list.do
- 공개SW역량플라자 라이선스 설명 : http://www.oss.kr/45607
- 공개SW 라이선스 가이드 다운로드 http://www.oss.kr/?mid=oss_license&page=3&document_srl=70139
- 오픈소스 라이선스 해설 http://www.oss.kr/oss_license/92922
그림출처 : http://terokarvinen.com/freehelia_licenses_and_the_definition_of_free_software.html
'오픈소스SW' 카테고리의 다른 글
| 공개SW 개발자대회 멘토링 이야기 (0) | 2014.08.03 |
|---|---|
| Vagrant 이용한 LAMP+Tomcat 개발환경구축 (0) | 2013.11.04 |
| 오픈소스SW 라이선스 LGPL 바로알기 (8) | 2013.10.24 |
| 공개SW 클라우드 플랫폼 (0) | 2012.07.28 |
| 레드마인 - CentOS 5.x + Redmine 2.x 설치 (0) | 2012.07.11 |
| MP4Box in CentOS 6.x 64Bit (0) | 2012.05.18 |
-
-
오픈비 chaeya
2013.11.16 01:57 신고
GPL이 유료는 아니구요~ 오히려 소스코드를 같이 공유하고 발전시키자는 의미의 규제가 더 강한것이 GPL입니다. GPL, LGPL은 두가지 모두 무료입니다.
-
-
-
Snooey
2013.12.11 13:44
안녕하세요. 라이센스 문제를 불러일으켰던 장본인으로써 인사 드립니다.
솔직히 이야기해서 1항의 가 항은 라이센스 파일 내에는 절대 강제하는 부분이 아닙니다.
또한, 만약 그 내용이 강제되고 있어서 동일 라이센스의 파생 소스에 해당 정의가 추가되는 것이 옳은 방법이라면 한 네댓번 프로젝트가 분기되면 소스파일 반절 이상이 아마 라이센스 도배만으로 이루어졌으리라 생각됩니다.
하지만 실제 그런 일은 GPL에서도 발생하고 있지 않은 부분입니다.
프로젝트명 자체가 갈라지는 게 아닌 같은 프로젝트로써 공생을 하는 관계라면 라이센스 자체에 수정을 가할 필요는 없지만, 만약 프로젝트가 분기되어 프로젝트 명칭이 달라지는 경우에는 라이센스 소유자 자체를 변경하는 것이 전혀 이상하지 않은 것으로 알고 있습니다.
소스에 대한 소유를 인정하는 GPL 계열 라이센스의 특징을 생각한다면 틀린 사용법이 아닌데도, 왠지 국내는 라이센스 저작권자 수정에 굉장히 민감하더군요.
제 생각엔 진짜 원 저작자를 존중한다면 오히려 라이센스에 저작권자 도배질보다는 오류 수정이나 기능 기부 등 소스적으로 제공해서 더 나은 소프트웨어를 위해 제공하는 게 맞을텐데 말이죠.
이런 논리가 국내 일부 오픈소스 개발자에겐 안 통하는 것 같아 좀 씁쓸합니다.(...)
(추가)
생각지도 못한 내용이었는데 잘못을 지적받아 조금 더 씁니다.
프로젝트 분리로 인해 소유자가 바뀌는 경우, 원 저작권 자체를 완전히 지우는 것은 금지이고, 라이센스 전문 하단에 원 저작권 항목을 붙이는 것이 맞다고 하더군요.
잘못 알고 있던 부분이라 죄송합니다.(...)-
오픈비 chaeya
2013.12.15 23:15 신고
방문해주셔서 감사합니다. 원 저작자에 대한 존중도, 상호 협력을 통한 좋은 소스코드도 오픈소스 프로젝트의 중요한 요소라고 생각됩니다. 이런 이슈를 통해서 향후 오픈소스 커뮤니티에 대한 지원정책이 좀 더 개선되고 좋아진다면 좋겠네요.
-
