내 생각에 플래시와 플렉스 업계 사람들은 여러 소스 코드 라이센스의 의미를 잘 모르는 듯하다. 우리는 회사가 성장함에 따라 중요 고객의 중대한 프로젝트를 여러 개 맡았고, 나는 소스 코드 라이센스를 배워 우리 팀에게 가르쳐야 했다.
나는 소스 코드 라이센스가 매우 중요한 주제라고 생각하여, 많은 노력을 들여 오늘날 플래시 커뮤니티에서 널리 쓰이는 소스 코드 라이센스들을 수집했다. 이 글을 여러분의 블로그에 링크한다거나 동료들과 공유하여 주변으로 퍼뜨리기를 권한다. 아마 이 글은 소스 코드를 공유하는 개발자들이 적당한 라이센스를 고르고(나는 LGPL 소스 코드를 보는데 넌더리가 난다), 커뮤니티가 공유 소스 코드를 합법적으로 사용하는 데 도움이 될 것이다.
이 모든 라이센스를 힘들게 조사했지만, 내가 법률가도 이 주제의 전문가도 아니기 때문에 이 글이 정확하거나 올바르다고 말하지는 못하겠다. 그리고 이 글은 코드를 무료로 배포하고 서비스 지향 개발 사업을 운영하는 한 사람의 관점에서 쓰인 것이다. 함의는 개발하는 제품에 따라 다양할 것이다.
이제부터 매우 널리 쓰이는 오픈 소스 라이센스들의 개요를 볼 것이다. 꽉 막힌 라이센스에서 너그러운 라이센스 순으로 나열했다.
암시적 저작권 (명시된 라이센스 없음)
상업적 사용
변경
출처 표시
불가능
불가능
해야 함
개요(Overview)
명백한 라이센스 없이 배포된 소스 코드는 권리 소멸 상태고(아래를 보라) 무료이며 마음대로 써도 된다...는 오해가 만연하다. 실은 정반대다. 라이센스 없이 배포된 소스 코드는 저작권법 하에 암시적 보호를 받는다. 이는 저작권 통지가 없어도 적용된다.
함의(implication)
제작자가 특별히 허가하지 않은 이상 프로젝트에 라이센스 없는 코드를 쓰는 것은 불법이다. 제작자의 권리가 갖는 강제성은 소스 코드에 관해서는 조금 막연하지만(특히 여러분이 배포에 앞서 소스 코드를 꽤 고쳤다면), 나중에 후회하느니 안전하게 가는 게 낫다.
라이센스가 명시되지 않았고 공용으로 배포된 코드를 사용하려면, 그 개발자와 만나서 코드를 MIT 라이센스 하에 재배포하길 요청하는 걸 권한다.
GNU는 GPL 라이브러리와 관련된 소스 코드에 반드시 GPL을 적용해야 함을 뜻하는 "바이러스성" 라이센스다. 자유 소프트웨어 재단(Free Software Foundation)에 따르면 동적 연결 라이브러리도 여기에 포함된다.
함의
GPL 라이브러리는 상업 프로젝트에 무료로 쓸 수 있다. 하지만 여러분의 프로젝트에 소스 코드 전체를 사용한다면, 프로젝트의 복제품을 획득한 사람이 그것을 GPL 하에 사용하게 만들어야 한다. 이것은 여러분의 고객의 경쟁자가 그 코드를 얻어서 자신을 위해 합법적으로 배포할 수도 있다는 것을 뜻한다. 이걸 허락하는 고객이 있을까?
애플리케이션은 절대로 최종 사용자의 것이 아니므로 서버 사이드 코드는 예외임을 주의하라. 엄밀하게 말하면 GPL은 플래시가 들어 있는 클라이언트 기계에서 실행되는 웹 애플리케이션에 적용되지만, 설치되지 않는 소프트웨어는 토론을 더 많이 해볼 주제다.
여러분은 프로그램에 눈에 잘 띄는 저작권 통지를 표시하고 라이센스의 전문을 제공해야 한다. 이것이 웹 애플리케이션에 정확히 얼마나 적용되는가는 명확치 않지만, 애플리케이션의 about 상자에 통지와 라이센스 문서에 대한 링크를 넣으면 족할 듯하다.
가능하지만 직접적 파생물은 LGPL 하에 배포해야 한다. AS3에서 이 요구 조건을 충족하기는 기술적으로 어렵다.
소스, 배포판
개요
LGPL은 한 가지 중요한 차이만 빼면 GPL과 판박이다. 여러분의 소스 코드를 LGPL 하에 배포하지 않아도 프로젝트에 LGPL 라이브러리를 동적으로 연결할 수 있다. 단 수정 버전이나 하위클래스 같은 LGPL 코드의 직접적 파생물은 LGPL 하에 배포해야 한다.
또다른 요구 사항은 여러분의 프로젝트에 쓰인 LGPL 라이브러리가 리버스 엔지니어링되는 것, 사용자가 이 라이브러리를 새로운 버전으로 교체하는 것을 허락해야 한다는 것이다.
함의
동적 연결 라이브러리가 AS3에서 기술적으로 가능하다 할지라도 간단한 방법이 없다. 런타임에 클래스를 불러오는 것은 쉽지만 여러분의 바이너리 안에 컴파일하지 않은 라이브러리에 기대어 컴파일하는 것은 조금 너저분하다.
게다가 사용자가 웹 애플리케이션 안의 LGPL 라이브러리를 교체할 수 있어야 한다는 요구 사항을 어떻게 만족시킬지도 막연하다.
그리고 LGPL 하의 코드를 서브클래싱*할 때는 조심해야 한다. 하위클래스는 직접적 파생물로 간주되고 LGPL의 대상이 되는데, 이는 하위클래스를 프로젝트에 동적으로 연결해야 함을 뜻한다(그렇지 않으면 여러분의 프로젝트가 싸그리 LGPL의 대상이 된다).
* 하위 클래스를 만드는 작업
LGPL과 GPL의 출처 표시 함의는 같다. 저작권 공지와 라이센스 전문, 더불어 LGPL 라이브러리의 소스 코드를 포함했다는 정보를 실어야 한다.
MPL은 매우 너그러운 라이센스다. 상업적 사용과 변경을 허락하고, MPL 하에 놓이게 되는 코드의 범위도 매우 좁다. 원래 MPL 라이브러리의 일부를 수정 또는 복사한 코드를 포함하는 파일만 MPL 하에 재배포하면 된다. LGPL과 달리 동적 연결에 관한 요구 사항은 없다. 여러분의 프로젝트 안에 라이브러리를 컴파일할 수 있다.
함의
MPL 라이브러리에서 수정한 부분을 알리는 것 외에 중요한 요구 사항은, 프로젝트에 쓴 MPL 라이브러리를 어디서 얻는지에 대한 지침을 화면 가장자리 같은 곳에 포함해야 한다는 것 뿐이다. 여러분의 클라이언트가 이 조건을 수락한다면 프로젝트에 MPL 코드를 사용하는 것이 문제가 되지는 않을 것이다.
아파치 라이센스 버전 2.0의 조건은 BSD 라이센스와 비슷하지만 보다 일반적이고 뚜렷하여 지적 재산 문제를 더 포괄적으로 포함한다. AL2 하의 소스 코드는 사실상 어느 목적으로든 쓸 수 있지만 소스 코드에 관련 IP, 라이센싱, 출처 알림을 모두 넣어야 한다. 또 이런 공지들을 "NOTICE" 파일이나 여러분의 바이너리에서 적당한 위치에 표시해야 한다.
콜드 퓨전 커뮤니티에선 ASL2가 인기 있는 라이센스다.
함의
BSD 라이센스와 마찬가지로 AL2 라이브러리를 쓸 때는 주로 출처 표시 요구 사항만 신경쓰면 된다. 소스 코드에 공지를 넣어야 하고, NOTICE 파일이나 애플리케이션 화면에 공지를 표시해야 한다. 후자는 원래 배포에 NOTICE 텍스트 파일이 포함된 경우에만 필요하다.
크리에이티브 커먼즈는 개발자가 필요한 조건을 선택하는, 조합식 라이센스를 제공한다. 예를 들어 나는 상업적 사용, 변경을 허용하고 출처는 표시하지 않아도 된다는 라이센스나 상업적 사용과 수정을 허락하지 않으며 출처는 표시해야 하는 라이센스를 만들 수 있다. GPL, LGPL, BSD 라이센스, 권리 소멸 상태로도 만들 수 있다.
크리에이티브 커먼즈 라이센스의 매우 좋은 점 중 하나는 사람이 읽을 수 있는 개요와 완전한 법적 텍스트를 포함해야 한다는 것이다.
"조합식" 크리에이티브 커먼즈 라이센스는 소프트웨어 사용을 위해 계획된 게 아님을 숙지하자.
"공유" 소스 코드에 라이센스가 없다면 저작권법으로 보호받으며 상업 프로젝트에서 쓰는 건 상당히 위험하다.
GPL 라이센스와 LGPL 라이센스는 매우 제한적이고, 이 라이센스들 하의 코드를 상업 프로젝트에 쓰는 것은 어려우며 불가능할 수 있다. 전자는 이 라이센스들의 바이러스성 조항 때문이고, 후자는 요구 사항을 충족하기가 기술적으로 어렵기 때문이다.
이 글에서 나열한 다른 라이센스들은 좀 더 너그럽고, 많은 경우 이 라이센스들 하의 라이브러리를 사용할 수 있다. 사용할 수 있느냐는 당신의 클라이언트가 소스 코드, 문서, 컴파일된 애플리케이션에 저작권과 라이센스 정보를 싣는 것을 용인하느냐에 전적으로 달려 있다.
어느 라이센스 하에 배포된 공용 소스 코드든, 여러분은 프로젝트에 그걸 쓰기 전에 먼저 클라이언트에게 사용을 밝힐 책임이 있다는 걸 기억하는 게 가장 중요하다. 클라이언트에게 여러분이 그렇게 하려는 이유를 간결하게 설명하는 데 이 지침이 아마 도움이 될 것이다.
최소한의 성실함을 지키고, 라이센스 하에 소스 코드를 배포하는 누구든 그렇게 할 권리가 있음을 알리려 하는 것은 좋은 생각임을 숙지하라. 여러분이 위의 라이센스들 중 하나 아래에 '관례에 어긋나게(incorrectly)' 배포된 소스 코드를 '섞어 쓴다(incorporate)'면, 내포하는 의미가 정확히 무엇인가는 조금 불명확하지만 좋지는 않을 것 같다.
나는 개발자들이 공유할 코드를 MIT 라이센스 하에 배포하기를 강력히 추천한다. 나는 고통스러운 제한이나 요구 사항을 강제하려는 게 아니라 다른 개발자들이 나날이 할 일을 돕기 위해서 소스 코드를 배포한다. 유용한 코드를 (GPL처럼) 구속하는 게 아니라 무료 공유를 추천하는 게 내 목표다. 나는 출처 표시를 항상 감사해 하지만 어떤 프로젝트에서는 그게 어렵다는 것도 이해한다.
또 나는 개발자들이 공유 라이브러리 소유자가 라이센싱을 아직 바꾸지 않았다면 MIT으로 바꾸라고 청원하길 추천한다.
제가 잘못한 것이 있나요? 추가할 더 많은 정보를 가졌나요? 댓글로 알려주세요. 알려주는 대로 더 정확한 정보로 이 글을 기쁘게 수정하겠습니다.
