디지털라이프
저자: 다니엘 스텐버그, 역 송종범
오픈 소스 개발에 열정적인 협력자가 되거나 카피레프트(copyleft, copyright의 반대 개념으로 누구나 저작물에 대한 권리를 공유하는 것)와 일반 공용 라이센스 (GPL)에 반대하는 입장을 취하는 것은 개인의 자유이다. 하지만 이번 기사에서 필자(소프트웨어 개발자들)들은 카피레프트를 어떻게 받아들이게 되었으며 어떻게 그것의 한계에 환멸을 느끼게 되었는지, 그리고 결과적으로 어떻게 외면하게 되었는지에 대해 이야기하고자 한다.
우리는 자발적 참여를 권장하는 입장이다.
오픈 소스[1] 현상이 그 자체로 존속할 수 있는 모델임이 확실해짐에 따라, 상업적인 회사[2]들은 라이센스 문제를 포함하여 오픈 소스 개발 모델에서 그들의 입장을 생각해 보지 않을 수 없게 되었다.
우리는 오픈 소스 사회도 이와 같아야 하며 서로 협력하는 것이 모두에게 최상의 이익이 됨을 믿는다. 이런 협력은 서로간의 합의된 협약 하에서 이루어져야 하며 협력을 위한 최선의 기반은 자발적인 참여라 믿는다.
우리는 카피레프트가 한 측면만의 불평들을 설명하기 때문에 카피레프트(copyleft)야말로 이런 협력의 장애물이라 생각한다. 그리고 상업적인 회사에 의해 카피레프트 라이센스가 사용된다는 근거 없는 두려움에 너무 자주 우리가 사로잡혀 있는 것은 아닌가 하는 생각도 든다. 이 기사에서는 우리가 왜 카피레프트 라이센스 아래에서 우리의 오픈소스 소프트웨어를 발표하면 안 되는 입장을 선택했는 지에 대한 설명을 할 것이다.
참고로 우리의 입장은 카피레프트에 대항하여 논쟁하려는 것이 아니며 단지 촉매로서의 카피레프트의 역할에 대해 알고, 그것을 위한 자리는 지속될 것임을 이해하는 것이 중요하다고 믿는다.
이 기사는 오픈소스 프로젝트에서 라이센스를 선택할 때, 카피레프트가 디폴트가 되어서는 안 된다는 점을 논쟁하고 있다. 오픈소스 소프트웨어에 기여하는 수 많은 이유들이 있으며, 이런 이유들은 거시적으로 존경받아야 마땅하다.
변화기
그러나 우리가 우리의 프로젝트 라이센스로 GPL을 선택했을 때, 그것이 가지고 있는 내면의 의미를 완전히 파악하지 못했고, 우회적으로도 급진적이며 적극적인 정치적 운동도 지원하지도 않았다. 수년이 지나고, 우리는 점점 GPL을 사용하는 것에 대해 불쾌함을 느끼게 되었다. GPL과 관련된 우리의 가장 근본적인 문제는 그것이 광범위하다는 것이었다. GPL은 사용 가능한 상태에서의 모든 것들의 소스 코드가 공공적으로 GPL과 호환되는 협약 아래 가능할 것을 요구했다. 비례적 공정성의 여지는 없었다. quid pro quo(=주는 만큼 받는다)는 정말로 quodque pro quo(=주고 다 받는다)[4]가 되었다. 우리는 타인들의 노력에 우리의 생각을 이용하는 것은 비도덕적이라고 인식하기 이르렀다.
우리의 과도기의 첫 번째 단계는 Mozilla Public Licence(MPL)이 발표되면서부터 시작되었다. 파일 기반 영역의 카피레프트 라이센스는 자유에 대한 우리의 인식에 있어서 훨씬 더 정교했다. 왜냐하면 그것은 "나의 작업"과 "너의 작업" 사이에 좀 더 명확한 구별을 가능하게 했기 때문이다. 이밖에 아무 일도 일어나지 않았다면 우리는 아직도 MPL을 사용했을 것이다.
그러나 그때부터 GPL의 다른 특징들이 우리를 다시 괴롭히기 시작했다. 만일 이런 라이센스들이 "뒤따른 제한들"[GPL section6]을 가지면 GPL은 GPL 라이센스를 가진 코드와 다른 라이센스를 가진 코드의 혼합을 허락치 않았다. 법적인 우위의 부재로, GPL과 다른 라이센스간의 호환성은 자유 소프트웨어 재단에 의해 결정되고 있다.
놀랍게도 비 호환되는 라이센스의 리스트들 중에 MPL이 있었다. 우리는 그들이 같은 정신을 공유한다고 생각했지만, 유일하게 범위를 빗나간 것이다. 우리에게 있어, 더 이상 우리의 프로젝트에 GPL이 포함된 코드를 사용할 의도가 없었기 때문에 호환성 문제는 그 자체로 문제가 아니었다. 대신 우리는 그들의 프로젝트에 우리의 MPL 라이센스를 사용하기를 원하는 그들의 GPL 프로젝트를 원했다. 그래서 우리는 대안들을 연구하기 시작했다.
명백한 대안은 분리된 GPL/MPL의 이중 라이센스를 사용하는 것이다. 이것은 누구든 자신의 프로젝트에 이 두 가지 라이센스들 중 어느 것이라도 사용할 수 있다 것을 의미한다. 자유 소프트웨어 재단은 이미 분리된 라이센스를 양도하고 있다. 분리된 이중 라이센스에 있어서 현재 문제는 이 두 가지 라이센스중 어느 하나를 임의로 제거할 수 있다는 점이다. 이것은 우리의 코드가 GPL 전용 코드가 된다는 것을 의미하는 것 일수도 있으며 이는 다시 MPL로 된 프로젝트에서 이런 새로운 방법의 결합을 금지함으로써 호환성 문제를 다시 소개하는 것이 될 수도 있거나 그 반대가 될 수도 있다. 그당시 우리는 미래에 누구나 양측의 라이센스를 자유롭게 선택할 수 있는 조항을 추가하는 가능성을 모색하고 있었다. 자유 소프트웨어 재단은 이것이 GPL과 모순된다고 주장했다. 왜냐하면 간단히 말해 소프트웨어의 분기들로 GPL 전용을 만드는 것은 불가능했기 때문이다. 우리가 동의하지 않았음에도 불구하고 더 이상 이런 생각은 접어두기로 했다.
과도기의 두 번째 단계는 좀더 변형된 BSD 라이센스나 MIT 라이센스와 같은 수정이 가능한 라이센스[5]에 관하여 조사하기 시작했을 때 나타났다. 초기에 우리는 카피레프트를 완전히 포기할 수 있는가에 대해 의구심을 느꼈다. 그러나 우리는 GPL의 비협력적 속성에 불쾌해서가 아니라 매혹될까봐 이와 같은 포기한 라이센스들에 대한 조사를 착수하지 않았다. 그러나 좀더 숙고하여 소프트웨어 자유에 대한 우리의 생각은 카피레프트 강제 절차와는 어울리지 않는다는 생각에 도달했다. 개발자들의 자유에 있어서 우리는 그들의 노력에 대한 그들의 선택을 믿었다. 원저작자가 아닌 기여자들은 자신의 기여가 가능해져야만 한다면 결정해야만 했다. 커피레프트는 그런 선택을 배제했다.
이익을 추구하는 사용에 대한 우리의 걱정은 놀랍게도 상업적 사용이 거의 없는 것을 관찰함으로써 극복되었고, 상업적 회사는 실제로 자발적으로 참여했다.
이기적 사용에 대한 두려움
GPL을 선택한 주요 동기는 당신이 작성한 코드가 이윤 추구, 즉 상업적 목적를 위해 사용되는 것을 방지하기 위해서이다. 그러나 당신이 작성한 코드가 이용되는 것을 싫어하든, 그것을 사용하는 회사의 개발자 개발자들이 이익을 보든 손해를 보든 이기적인 사용을 막기 위해 자동으로 카피레프트를 선택하는 것보다는 오히려 그 주위의 문제점에 대하여 관망해 볼 수 있어 유익하다. 그리고 상업적 회사들이 코드를 사용하는데 얼마의 비용이 들고 심지어는 그런 이용으로부터 얼마나 코드가 이익인가 고려해보는 것조차 가치 있는 일이다.
일단 우리가 작성한 코드의 이용 유무를 떠나 우리는 개발하는데 재미가 있었다. 몰랐던 부분을 해결하면서 많은 것을 배웠기 때문이다. 풍부한 피드백을 통해 다른 개발자들을 만날 수 있었다. "무임승차"는 우리의 프로젝트를 진행시키는데 아무런 역할도 하지 못한다. 우리는 설령 우리가 이 프로젝트로부터 돈을 벌 수 있다고 하더라도 거래는 하지 않을 것이다. 우리의 코드를 좀더 훌륭한 판매 자원으로 하여 다른 기관이 사용하여 우리를 우울하게 한 이래 카피레프트는 우리에게 어떤 보호도 제공하지 않고 있다.
다음으로, 우리는 대부분의 상업적 회사들이 오픈 소스 프로젝트에 대한 기여의 필요성을 이해한다고 믿는다. 순전히 냉소적인 시각일지라도, 미래의 소프트웨어 기준선에 업그레이드를 쉽게 해주기 때문에 프로젝트를 발전시켜나가는 것은 의미가 있다. 이것은 오픈 소스 프로젝트로 하여금 많은 사람들이 유지를 함께하고 미래 개발을 돌아보게도 해준다. 또한 상업 회사들도 오픈 소스 기여자들의 작업에 지렛대 역할을 한다. 폐쇄적인 소스 정책은 오픈 소스 정책만큼 많은 기여자를 모으지 못한다.
운 좋게도, 우리가 경험한 바로는 대부분의 회사들이 완전히 냉소적이지는 않았다. 그리고 이것에 반대하는 전략적 이유 없이도 그들은 기꺼이 기여한다는 것이다. 우리는 카피레프트 없이 프로젝트에 대해 더욱 조직적인 기여를 받고 있다. 그리고 그것들은 노련한 프로그래머가 제출한 고품질의 기여이다. 모질라 웹브라우저를 포함하여 오픈오피스 오피스 슈트, 아파치 웹서버, BSD운영체제(Free BSD, NetBSD, Open BSD) 그리고 Enhydra 서버같은 몇몇 이름 있는 회사가 자발적으로 기여하는 예들은 수도 없이 많다.
마지막으로 상업적 회사가 코드를 부당하게 이용했음에도 이익을 보고 자유소프트웨어를 사용했음에도 손해를 본 경우에 대해 살펴본 후 왜 LGPL(Lesser General Licenses)로 가면 안 되는 이유를 설명할 것이다.
사용의 장애
오픈 소스 소프트웨어를 사용하는데 있어 상업적 회사는 고유의 비용이 든다. 그것은 단순히 소프트웨어를 다운로딩해서 프로젝트안에 끼워넣는 문제가 아니며 은행으로 가면서 내내 웃을 문제도 아니다.
우리가 코드의 이용에 정당치 않다고 할 지라도, 일부 긍정적인 면들(특히 만일 당신이 회사에서 사용을 사업적으로 원할 때)은 지적할만한 가치가 있다.
우리는 종종 왜 우리가 GNU Lesser General Public License(LGPL)을 사용하지 않는가에 질문을 받는다. LGPL이 우리가 보기에는 좀더 정교해 보이기는 하지만 그것이 Liberated General Public License라 불려야 한다고 우리가 느끼는 만큼 LGPL에는 우리가 다른 라이센스를 선호하는 이유에 대한 의문을 제시할 수 있는 많은 문제들이 있다.
결론
오픈 소스 소프트웨어를 카피레프트 없이 개발한 우리의 경험은 잘못된 사용으로 인한 두려움을 지원해 주지 않는다. 반면, 공헌과 협력의 관점에서 그 이상을 카피레프트를 지원자들과 바꾸어가고 있다.
우리의 경험에 근거를 두고, 우리는 오픈 소스 개발자에게 최소한으로 필요한 카피레프트 양에 대하여 조언하고자 한다.
흥미롭게도, 우리의 소프트웨어 라이센스를 GPL과 호환되도록 바꾸었을 때, 이런 변화를 요구했었던 오픈 소스측의 사람들로부터 어떤 기여도 받지 못했다. 우리의 라이센스는 자유 의사에 의하여 만들어졌기 때문에 우리의 소프트웨어는 오히려 상업적 회사측으로부터 기여를 받았다.
각주
[1] 편의상 우리는 "오픈 소스"(아래 경우에 쓰인바)를 오픈 소스, 자유 소프트웨어, 그리고 이와 유사한 노력들에 사용한다.
[2] 여기서는 주로 상품으로 소프트웨어를 파는 사업 형태의 상업 회사를 지칭한다.
[3] quid pro quo: (라틴어) 주고 받기 (= give and take)
[4] quodque pro quo: (라틴어) 주고 다 받기
[5] "포기 라이센스" 라는 용어를 사용했다. 왜냐하면 그것이 가장 정확하게 라이센스의 목적을 설명해 주기 때문이다. 이런 라이센스들은 세 부분으로 구성되어 있다.
(1) 저작권 고시
(2) 라이센스는 그대로여야 한다고 말하는 조항들
(3) 보장된 포기
만일 소프트웨어가 실패하더라도 마지막 부분은 법적 대응에 대항하여 보호해주려는 의도이다. 이런 라이센스들은 때때로 그들의 기원 때문에 "학문적인 라이센스"로 불리기도 한다.
오픈 소스 개발에 열정적인 협력자가 되거나 카피레프트(copyleft, copyright의 반대 개념으로 누구나 저작물에 대한 권리를 공유하는 것)와 일반 공용 라이센스 (GPL)에 반대하는 입장을 취하는 것은 개인의 자유이다. 하지만 이번 기사에서 필자(소프트웨어 개발자들)들은 카피레프트를 어떻게 받아들이게 되었으며 어떻게 그것의 한계에 환멸을 느끼게 되었는지, 그리고 결과적으로 어떻게 외면하게 되었는지에 대해 이야기하고자 한다.
우리는 자발적 참여를 권장하는 입장이다.
오픈 소스[1] 현상이 그 자체로 존속할 수 있는 모델임이 확실해짐에 따라, 상업적인 회사[2]들은 라이센스 문제를 포함하여 오픈 소스 개발 모델에서 그들의 입장을 생각해 보지 않을 수 없게 되었다.
우리는 오픈 소스 사회도 이와 같아야 하며 서로 협력하는 것이 모두에게 최상의 이익이 됨을 믿는다. 이런 협력은 서로간의 합의된 협약 하에서 이루어져야 하며 협력을 위한 최선의 기반은 자발적인 참여라 믿는다.
우리는 카피레프트가 한 측면만의 불평들을 설명하기 때문에 카피레프트(copyleft)야말로 이런 협력의 장애물이라 생각한다. 그리고 상업적인 회사에 의해 카피레프트 라이센스가 사용된다는 근거 없는 두려움에 너무 자주 우리가 사로잡혀 있는 것은 아닌가 하는 생각도 든다. 이 기사에서는 우리가 왜 카피레프트 라이센스 아래에서 우리의 오픈소스 소프트웨어를 발표하면 안 되는 입장을 선택했는 지에 대한 설명을 할 것이다.
참고로 우리의 입장은 카피레프트에 대항하여 논쟁하려는 것이 아니며 단지 촉매로서의 카피레프트의 역할에 대해 알고, 그것을 위한 자리는 지속될 것임을 이해하는 것이 중요하다고 믿는다.
이 기사는 오픈소스 프로젝트에서 라이센스를 선택할 때, 카피레프트가 디폴트가 되어서는 안 된다는 점을 논쟁하고 있다. 오픈소스 소프트웨어에 기여하는 수 많은 이유들이 있으며, 이런 이유들은 거시적으로 존경받아야 마땅하다.
변화기
인생에 있어서의 변화란 우리 양심의 요구에 따르며 사는 것은 아니다. 변화는 새로운 형태의 인생을 시도하고자 하는 정신적 결심이 아닌 삶에 있어서의 불가능성에서 온다. -- 레오 톨스토이 (1828-1910)우리가 오픈 소스 커뮤니티에 기여하기 시작할 때인 거의 10년 전쯤엔, 우리는 모든 소스 코드의 권한을 GNU General Public License (GPL)에 두었다. 이것이 널리 사용되었으며 "소프트웨어의 자유"가 중요하다는 개념을 느끼기 시작했기 때문이었다. 특히 소프트웨어 개발자들이 소스 코드로의 무제한적인 접근에 대한 개념에 매력을 느껴감에 따라, 다른 사람에게서부터 배우는 것과는 비교할 수 없는 기회를 제공하게 되었다. 더군다나, 우리는 상업적 회사의 사용에 대항하여 보호하는 것을 좋아했고, 우리의 소프트웨어를 변형하거나 확장하는 누구든지 그런 변화들을 돌려주는 것을 기대한다는 것이야말로 정당한 것이라 느꼈다.(quid pro quo3, 주고 받기)[3]
그러나 우리가 우리의 프로젝트 라이센스로 GPL을 선택했을 때, 그것이 가지고 있는 내면의 의미를 완전히 파악하지 못했고, 우회적으로도 급진적이며 적극적인 정치적 운동도 지원하지도 않았다. 수년이 지나고, 우리는 점점 GPL을 사용하는 것에 대해 불쾌함을 느끼게 되었다. GPL과 관련된 우리의 가장 근본적인 문제는 그것이 광범위하다는 것이었다. GPL은 사용 가능한 상태에서의 모든 것들의 소스 코드가 공공적으로 GPL과 호환되는 협약 아래 가능할 것을 요구했다. 비례적 공정성의 여지는 없었다. quid pro quo(=주는 만큼 받는다)는 정말로 quodque pro quo(=주고 다 받는다)[4]가 되었다. 우리는 타인들의 노력에 우리의 생각을 이용하는 것은 비도덕적이라고 인식하기 이르렀다.
우리의 과도기의 첫 번째 단계는 Mozilla Public Licence(MPL)이 발표되면서부터 시작되었다. 파일 기반 영역의 카피레프트 라이센스는 자유에 대한 우리의 인식에 있어서 훨씬 더 정교했다. 왜냐하면 그것은 "나의 작업"과 "너의 작업" 사이에 좀 더 명확한 구별을 가능하게 했기 때문이다. 이밖에 아무 일도 일어나지 않았다면 우리는 아직도 MPL을 사용했을 것이다.
그러나 그때부터 GPL의 다른 특징들이 우리를 다시 괴롭히기 시작했다. 만일 이런 라이센스들이 "뒤따른 제한들"[GPL section6]을 가지면 GPL은 GPL 라이센스를 가진 코드와 다른 라이센스를 가진 코드의 혼합을 허락치 않았다. 법적인 우위의 부재로, GPL과 다른 라이센스간의 호환성은 자유 소프트웨어 재단에 의해 결정되고 있다.
놀랍게도 비 호환되는 라이센스의 리스트들 중에 MPL이 있었다. 우리는 그들이 같은 정신을 공유한다고 생각했지만, 유일하게 범위를 빗나간 것이다. 우리에게 있어, 더 이상 우리의 프로젝트에 GPL이 포함된 코드를 사용할 의도가 없었기 때문에 호환성 문제는 그 자체로 문제가 아니었다. 대신 우리는 그들의 프로젝트에 우리의 MPL 라이센스를 사용하기를 원하는 그들의 GPL 프로젝트를 원했다. 그래서 우리는 대안들을 연구하기 시작했다.
명백한 대안은 분리된 GPL/MPL의 이중 라이센스를 사용하는 것이다. 이것은 누구든 자신의 프로젝트에 이 두 가지 라이센스들 중 어느 것이라도 사용할 수 있다 것을 의미한다. 자유 소프트웨어 재단은 이미 분리된 라이센스를 양도하고 있다. 분리된 이중 라이센스에 있어서 현재 문제는 이 두 가지 라이센스중 어느 하나를 임의로 제거할 수 있다는 점이다. 이것은 우리의 코드가 GPL 전용 코드가 된다는 것을 의미하는 것 일수도 있으며 이는 다시 MPL로 된 프로젝트에서 이런 새로운 방법의 결합을 금지함으로써 호환성 문제를 다시 소개하는 것이 될 수도 있거나 그 반대가 될 수도 있다. 그당시 우리는 미래에 누구나 양측의 라이센스를 자유롭게 선택할 수 있는 조항을 추가하는 가능성을 모색하고 있었다. 자유 소프트웨어 재단은 이것이 GPL과 모순된다고 주장했다. 왜냐하면 간단히 말해 소프트웨어의 분기들로 GPL 전용을 만드는 것은 불가능했기 때문이다. 우리가 동의하지 않았음에도 불구하고 더 이상 이런 생각은 접어두기로 했다.
과도기의 두 번째 단계는 좀더 변형된 BSD 라이센스나 MIT 라이센스와 같은 수정이 가능한 라이센스[5]에 관하여 조사하기 시작했을 때 나타났다. 초기에 우리는 카피레프트를 완전히 포기할 수 있는가에 대해 의구심을 느꼈다. 그러나 우리는 GPL의 비협력적 속성에 불쾌해서가 아니라 매혹될까봐 이와 같은 포기한 라이센스들에 대한 조사를 착수하지 않았다. 그러나 좀더 숙고하여 소프트웨어 자유에 대한 우리의 생각은 카피레프트 강제 절차와는 어울리지 않는다는 생각에 도달했다. 개발자들의 자유에 있어서 우리는 그들의 노력에 대한 그들의 선택을 믿었다. 원저작자가 아닌 기여자들은 자신의 기여가 가능해져야만 한다면 결정해야만 했다. 커피레프트는 그런 선택을 배제했다.
이익을 추구하는 사용에 대한 우리의 걱정은 놀랍게도 상업적 사용이 거의 없는 것을 관찰함으로써 극복되었고, 상업적 회사는 실제로 자발적으로 참여했다.
이기적 사용에 대한 두려움
GPL을 선택한 주요 동기는 당신이 작성한 코드가 이윤 추구, 즉 상업적 목적를 위해 사용되는 것을 방지하기 위해서이다. 그러나 당신이 작성한 코드가 이용되는 것을 싫어하든, 그것을 사용하는 회사의 개발자 개발자들이 이익을 보든 손해를 보든 이기적인 사용을 막기 위해 자동으로 카피레프트를 선택하는 것보다는 오히려 그 주위의 문제점에 대하여 관망해 볼 수 있어 유익하다. 그리고 상업적 회사들이 코드를 사용하는데 얼마의 비용이 들고 심지어는 그런 이용으로부터 얼마나 코드가 이익인가 고려해보는 것조차 가치 있는 일이다.
일단 우리가 작성한 코드의 이용 유무를 떠나 우리는 개발하는데 재미가 있었다. 몰랐던 부분을 해결하면서 많은 것을 배웠기 때문이다. 풍부한 피드백을 통해 다른 개발자들을 만날 수 있었다. "무임승차"는 우리의 프로젝트를 진행시키는데 아무런 역할도 하지 못한다. 우리는 설령 우리가 이 프로젝트로부터 돈을 벌 수 있다고 하더라도 거래는 하지 않을 것이다. 우리의 코드를 좀더 훌륭한 판매 자원으로 하여 다른 기관이 사용하여 우리를 우울하게 한 이래 카피레프트는 우리에게 어떤 보호도 제공하지 않고 있다.
다음으로, 우리는 대부분의 상업적 회사들이 오픈 소스 프로젝트에 대한 기여의 필요성을 이해한다고 믿는다. 순전히 냉소적인 시각일지라도, 미래의 소프트웨어 기준선에 업그레이드를 쉽게 해주기 때문에 프로젝트를 발전시켜나가는 것은 의미가 있다. 이것은 오픈 소스 프로젝트로 하여금 많은 사람들이 유지를 함께하고 미래 개발을 돌아보게도 해준다. 또한 상업 회사들도 오픈 소스 기여자들의 작업에 지렛대 역할을 한다. 폐쇄적인 소스 정책은 오픈 소스 정책만큼 많은 기여자를 모으지 못한다.
운 좋게도, 우리가 경험한 바로는 대부분의 회사들이 완전히 냉소적이지는 않았다. 그리고 이것에 반대하는 전략적 이유 없이도 그들은 기꺼이 기여한다는 것이다. 우리는 카피레프트 없이 프로젝트에 대해 더욱 조직적인 기여를 받고 있다. 그리고 그것들은 노련한 프로그래머가 제출한 고품질의 기여이다. 모질라 웹브라우저를 포함하여 오픈오피스 오피스 슈트, 아파치 웹서버, BSD운영체제(Free BSD, NetBSD, Open BSD) 그리고 Enhydra 서버같은 몇몇 이름 있는 회사가 자발적으로 기여하는 예들은 수도 없이 많다.
마지막으로 상업적 회사가 코드를 부당하게 이용했음에도 이익을 보고 자유소프트웨어를 사용했음에도 손해를 본 경우에 대해 살펴본 후 왜 LGPL(Lesser General Licenses)로 가면 안 되는 이유를 설명할 것이다.
사용의 장애
오픈 소스 소프트웨어를 사용하는데 있어 상업적 회사는 고유의 비용이 든다. 그것은 단순히 소프트웨어를 다운로딩해서 프로젝트안에 끼워넣는 문제가 아니며 은행으로 가면서 내내 웃을 문제도 아니다.
- 평가
- 소프트웨어를 검색하기 위해 철저한 조사가 요구되며 주어진 요구사항을 수행하는 것으로 평가가 이루어질 것이다.
- 정당성
- 기업은 합법적이어야 하고 소프트웨어의 품질 역시 반드시 효율적이어야 한다. 언제나 이것은 주요 작업이다(왜냐하면 소프트웨어에 대하여 잘 알지 못하기 때문). 따라서 보다 정성들인 시험이 요구된다. 형편없는 문서화는 이것을 보다 힘들게 한다.
- 통합
- 일단 소프트웨어가 선택이 되면, 회사는 사용법을 배우고 그들의 프로젝트에 융합되도록 해야 한다.
- 개발 환경
- 빈 틈 없는 통합은 그들의 개발 환경과 도구들이 오픈 소스의 그 것들이 서로 호환될 것을 요구한다.
- 비-기능적 요구들
- 소프트웨어는 다음과 같은 사항들을 고려해서 결정되어야 한다. 충분히 믿을 수 있는가? 반응적인가? 측정 가능한가? 설정이 가능한가? 에러 핸들링 및 기타 대조적인 걱정들이 상업 제품의 요구들과 호환 가능해야 한다.
- 유지
- 회사는 그들의 제품에 대해 계약상 의무를 가지고 있기 때문에, 그들은 향후 소프트웨어의 유지 (심지어는 오픈 소스 소프트웨어가 포기할지라도)를 보장해야 한다.
우리가 코드의 이용에 정당치 않다고 할 지라도, 일부 긍정적인 면들(특히 만일 당신이 회사에서 사용을 사업적으로 원할 때)은 지적할만한 가치가 있다.
- 정보처리 상호운용
- 만일 회사의 애플리케이션이 우리가 만든 코드를 기반으로 작성되었다면 우리의 애플리케이션과 호환되는 기회를 가지게 된다. 이것은 우리의 애플리케이션과 회사의 애플리케이션이 서로 호환되어 잘 사용될 수 있음을 의미한다.
- 역 공학
- 회사에서 우리의 코드를 그들의 제품에 사용하고 확장을 했다면, 기업이 이 코드를 처음부터 다시 쓰는 것보다 우리가 그 확장된 코드를 역 공학하기가 더 쉽다. 이는 코드를 직접적으로 잘 아는 사람이 우리이고 기업은 코드의 일부만을 알기 때문이다.
- 역 이용
- 회사들은 종종 기능적으로 또는 유용한 제품을 만들어 내고자 노력하면서 많은 자원을 소비한다. 우리의 소스코드와 그들의 소스코드가 유사하기 때문에 애플리케이션도 서로 비슷하다. 따라서 우리의 프로젝트에 그들의 아이디어를 쉽게 사용할 수 있으며 그들이 이미 투자한 사항도 쉽게 이용할 수 있다. 코드 재사용은 무제한임을 명심해라. 그리고 아이디어, 디자인, 기능성도 재 사용할 수 있음을 명심해라.
- 표준화
- 우리의 소스 코드는 아주 널리 사용되고 있다. 따라서 여기에 기반을 둔 인터페이스나 프로토콜은 사실상, 그리고 아마도 결국은 합법적으로 표준이 될 가능성이 증가하고 있다. 이러한 것의 전형적인 예가 TCP/IP 프로토콜이다.
- 보증
- 회사는 우리의 코드가 그들이 보증하는 제품에 포함될 정도로 충분히 좋다고 생각해왔다. 따라서 우리는 이력서에 이 사항을 충분히 기입할 수 있으며 심지어는 입사지원을 할 수도 있다고 본다.
우리는 종종 왜 우리가 GNU Lesser General Public License(LGPL)을 사용하지 않는가에 질문을 받는다. LGPL이 우리가 보기에는 좀더 정교해 보이기는 하지만 그것이 Liberated General Public License라 불려야 한다고 우리가 느끼는 만큼 LGPL에는 우리가 다른 라이센스를 선호하는 이유에 대한 의문을 제시할 수 있는 많은 문제들이 있다.
- LGPL의 범위는 너무 조잡하다. 해석하기에 따라 범위가 쉽게 변동된다. 기능적 개체들의 일부 퍼지 개념은 제한적이다("소프트웨어 기능들의 집합 그리고/또는 애플리케이션 프로그램과 편리하게 연결되기 위한 준비된 자료"). LGPL로 되어있는 라이브러리가 다른 라이브러리에 의해 사용되거나 임베디드 웹브라우저와 같은 소프트웨어 요소로 시용된다면 어떻게 될 것인가? [LPGL, section0]
- LGPL은 어느것, 어느 때라도 GPL로의 변환으로 역행할 수 없는 조항을 가지고 있다(특히 변환된 코드의 GPL로 유일한 창조에 있어서).[LGPL, section3]
- 자유소프트웨어 재단은 라이센스들을 다룬다. 새로운 버전의 라이센스를 발표할 수 있으며, 발표된 라이센스는 자동적으로 우리의 소프트웨어에 적용된다. 비록 자유소프트웨어 재단이 현 버전의 정신에서 빗나간 변화를 시도하거나 우리의 의도와 다른 발표를 할 지라도 말이다. 예를 들어 그들은 관점 지향의 착수의 결과가 LGPL의 협약에 종속된다고 할지도 모르지만 우리는 그것을 의도하지는 않았었다. 또 다른 관심은 누가 지금부터 10년간 자유소프트웨어 재단을 책임질 것인가, 또는 만일 자유소프트웨어 재단이 지속되지 않는다면 무슨 일이 일어날 것인 가이다.[LGPL, section11]
- 법에 의해 강제되는 명백한 문제들과 제한점들은 LGPL의 "너의 방법 또는 나의 방법" 스타일 안에서 LGPL에 의해 다루어지며, 즉 그런 제한들은 자동적으로 LGPL로 덮여있는 소프트웨어를 사용하는 너의 모든 권리를 파기한다.[LGPL, section11]
- 목적 파일들은 언제들 실행 가능한 것들이 유포되어야 한다. 이것은 단지 약간의 불편함을 야기시키는 것일지도 모르지만, 심각한 설정 운영비용을 추징할 수도 있고 비현실적인 협약이 되게 할 수도 있다.[LGPL section 6a]
결론
오픈 소스 소프트웨어를 카피레프트 없이 개발한 우리의 경험은 잘못된 사용으로 인한 두려움을 지원해 주지 않는다. 반면, 공헌과 협력의 관점에서 그 이상을 카피레프트를 지원자들과 바꾸어가고 있다.
우리의 경험에 근거를 두고, 우리는 오픈 소스 개발자에게 최소한으로 필요한 카피레프트 양에 대하여 조언하고자 한다.
- 프로젝트에 맞는 최소한의 카피레프트 라이센스를 사용하라. 예를 들어 우리는 증가하는 추세에 있는 범주 없는 포기 라이센스를 가지고 있다. 파일 기반의 MPL, 라이브러리 범위 기반의 LGPL, 그리고 실행 기반의 GPL등이 그것이다.
- 카피레프트가 필요하다면, 오직 애플리케이션의 특별한 코드만 카피레프트 아래 두어라. 일례로 해시 테이블이나 소켓 래퍼는 특별한 애플리케이션이 아니고 다른 프로젝트에서 다시 사용될 수 있다. 따라서 이 코드가 재사용되게 될 곳에서는 그것은 프로젝트들의 카피레프트 범위를 간접적으로 결정하는 것을 방지하는 애플리케이션의 특별한 코드보다 보다 적은 카피레프트를 가지게 될 것이다. 라이센스들을 복합적으로 사용하려고 한다면, GPL 코드는 오직 GPL과 호환되는 라이센스 코드들과만 혼용될 수 있음을 주지하라.
흥미롭게도, 우리의 소프트웨어 라이센스를 GPL과 호환되도록 바꾸었을 때, 이런 변화를 요구했었던 오픈 소스측의 사람들로부터 어떤 기여도 받지 못했다. 우리의 라이센스는 자유 의사에 의하여 만들어졌기 때문에 우리의 소프트웨어는 오히려 상업적 회사측으로부터 기여를 받았다.
각주
[1] 편의상 우리는 "오픈 소스"(아래 경우에 쓰인바)를 오픈 소스, 자유 소프트웨어, 그리고 이와 유사한 노력들에 사용한다.
[2] 여기서는 주로 상품으로 소프트웨어를 파는 사업 형태의 상업 회사를 지칭한다.
[3] quid pro quo: (라틴어) 주고 받기 (= give and take)
[4] quodque pro quo: (라틴어) 주고 다 받기
[5] "포기 라이센스" 라는 용어를 사용했다. 왜냐하면 그것이 가장 정확하게 라이센스의 목적을 설명해 주기 때문이다. 이런 라이센스들은 세 부분으로 구성되어 있다.
(1) 저작권 고시
(2) 라이센스는 그대로여야 한다고 말하는 조항들
(3) 보장된 포기
만일 소프트웨어가 실패하더라도 마지막 부분은 법적 대응에 대항하여 보호해주려는 의도이다. 이런 라이센스들은 때때로 그들의 기원 때문에 "학문적인 라이센스"로 불리기도 한다.
TAG :
이전 글 : 아이포토(iPhoto)와 새로운 아이맥(iMac)
다음 글 : 임베디드 자바
최신 콘텐츠