GNU GPL에 대한 빈번한 질문들(http://www.gnu.org/licenses/gpl-faq.ko.html에서 발췌)이 번역문은 가능한 한도 내에서 대한민국 저작권법과 컴퓨터 프로그램 보호법에서 정의하고 있는 용어를 사용하고 있습니다. 현행 대한민국 법률에 포함되어 있지 않은 내용과 용어들에 대해서는 저작권 심의 조정 위원회와 컴퓨터 법률 관련 논문들에서 제안하고 있는 용어를 사용했습니다. “GPL”은 무슨 뜻입니까?”GPL”은 “General Public License”의 약자입니다. 가장 널리 알려진 라이선스인 GNU General Public License는 줄여서 GNU GPL이라고 부릅니다. GNU GPL을 가리키는 것이 분명할 때에는 더욱 줄여서 GPL이라고 부르기도 합니다. 자유 소프트웨어란 GPL을 따르는 소프트웨어를 의미하는 것입니까?그렇지 않습니다. GNU GPL 이외에도 많은 종류의 자유 소프트웨어 라이선스가 있습니다. 우리는 현재까지 파악하고 있는 자유 소프트웨어 라이선스 목록을 유지하고 있는데, 이 문서를 참고해 주시기 바랍니다. 모든 사용자에게 특정한 종류의 자유를 제공하는 라이선스는 모두 자유 소프트웨어 라이선스라고 할 수 있습니다. 다른 종류의 자유 소프트웨어 라이선스 보다 GPL을 사용해야 하는 이유가 있습니까?GNU GPL을 사용하게 되면 한 프로그램으로부터 파생되고 향상된 모든 버전의 프로그램들이 공표될 때, 계속해서 자유 소프트웨어로 남아 있게 됩니다. 그렇게 되면 여러분이 만들었던 프로그램으로부터 개작된 독점 소프트웨어가 만들어져서 여러분의 프로그램과 경쟁하게 되는 위험을 막을 수 있습니다. 그러나 특별한 상황에서는 GPL보다 유연한 라이선스를 사용하는 것이 좋을 수도 있습니다. GNU 소프트웨어들은 모두 GNU GPL을 라이선스로 사용하고 있습니까?대부분의 GNU 소프트웨어들은 GNU GPL을 사용하고 있지만, 몇몇 종류의 프로그램이나 프로그램의 일부분들은 GNU Lesser GPL과 같은 보다 유연한 라이선스를 사용하고 있습니다. 우리는 자유 소프트웨어를 위한 전략적인 이유 때문에 이러한 이중적인 라이선스 적용을 사용하고 있습니다. 프로그램에 GPL을 적용하면 모두 GNU 소프트웨어가 되는 것입니까?누구나 자신의 프로그램을 GPL로 공표할 수 있지만, 그것만으로 GNU 패키지가 되는 것은 아닙니다. 자신의 프로그램을 GNU 소프트웨어 패키지로 만든다는 것은 명시적으로 GNU 프로젝트에 참여하고 기여하게 된다는 것을 의미합니다. 이것은 프로그램의 개발자와 GNU 프로젝트 양자가 서로 동의했을 때만 가능한 것입니다. 만약 여러분이 만든 프로그램을 GNU 프로젝트에 제공하고자 한다면 <maintainers@gnu.org> 앞으로 영문 메일을 주시기 바랍니다. 한국어 메일의 경우에는 <maintainers@korea.gnu.org> 앞으로 보내 주시면 됩니다. GPL 위반이라고 생각되는 일을 발견했을 때는 어떻게 해야 하나요?신고해야 합니다! 먼저, 여러분이 할 수 있는 최선의 범위에서 GPL 위반 여부를 판단해 본 뒤에 그 사실을 해당 GPL 프로그램의 저작권자나 출판자에게 알려주시기 바랍니다. 저작권자가 자유 소프트웨어 재단 즉, Free Software Foundation으로 표시되어 있다면 <license-violation@gnu.org> 앞으로 영문 메일을 주시기 바랍니다. 영어에 익숙하지 않다면 <license-violation@korea.gnu.org> 앞으로 한국어 메일을 주시기 바랍니다. 저작권자를 명확히 알 수 없는 경우에는 프로그램의 메인테이너에게 연락하시면 됩니다. 대부분의 경우에 있어서 메인테이너는 저작권자 자신이거나 저작권자에게 연락할 수 있는 방법을 알고 있는 사람입니다. GPL이 사용자들에게 자신이 개작한 버전을 공표하는 것을 허용하는 이유는 무엇입니까?자유 소프트웨어가 갖고 있는 가장 중요한 측면은 사용자들이 서로 자유롭게 협력할 수 있다는 점입니다. 따라서 버그를 수정하고 개선된 부분을 서로 공유하고자 하는 마음을 갖고 있는 사람들에게 그러한 형태를 허용하는 것은 절대적으로 필요합니다. 어떤 사람들은 개작된 버전은 프로그램의 원저작자에게 보내지도록 하는 규정을 GPL에 포함시키자고 제안합니다. 원저작자가 프로그램을 관리할 필요를 계속해서 느끼고 있는 동안에는 이러한 방법이 매우 효과적일 것입니다. 그러나 만약 원저작자가 다른 일로 인해서 프로그램을 계속해서 관리하지 못하는 상황이 발생하거나 다른 사용자들이 느끼는 필요에 관심을 갖지 않을 경우에는 이러한 방법은 좋지 않은 결과를 낳게 됩니다. 이러한 실제적인 문제 이외에, 그러한 방법을 사용하면 사용자들이 서로를 돕는 것을 허용하지 않게 되는 것입니다. 사용자들에 의해서 만들어진 다양한 버전으로 인한 혼란을 방지하기 위해서 개작된 버전들을 통제해야 한다는 의견이 때때로 제안되기도 했습니다. 그러나 우리의 경험으로 볼 때, 그러한 혼동은 중요한 문제가 아닙니다. 많은 종류의 Emacs 변종 버전들이 GNU 프로젝트 외부에서 개발되어 졌지만, 사용자들은 그것을 구별할 수 있었습니다. GPL은 프로그램을 만들거나 개작할 때, 다른 버전을 만든 개발자들의 명성을 보호하고 다른 버전들이 서로 구분될 수 있도록 하기 위해서 새로운 버전을 만든 사람의 이름을 명시하도록 규정하고 있습니다. GPL은 개작된 버전의 소스 코드를 공중(公衆, 불특정 다수)에게 공개하도록 요구하고 있습니까?GPL은 개작된 버전 각각이 모두 공표되도록 규정하고 있지 않습니다. 만약 여러분이 GPL 프로그램을 개작한 뒤에 개인적인 목적으로 사용하고 있다면 개작된 소스 코드를 공개하지 않아도 무방합니다. 이것은 개인뿐 아니라 단체나 법인, 기업에 대해서도 마찬가지입니다. 이 경우 해당 단체나 법인, 기업은 개작한 프로그램을 외부로 공표하지 않고 오직 내부적으로만 사용해야 합니다. 그러나 만약 어떠한 방식으로든지 개작된 버전을 공표하고 있다면, 사용자들이 개작된 버전의 소스 코드를 GPL에 따라 이용할 수 있도록 해야만 합니다. 따라서 GPL은 개작한 프로그램을 GPL이 규정한 방식에 따라서 공표할 수 있는 허가를 제공하는 것이며, 개작한 버전을 공표하느냐 마느냐는 여러분 자신의 선택에 달려 있습니다. GPL 제3조 (b)항에 언급된 “제3자에게도 유효한 서면(written offer valid for any third party)”이란 어떤 의미입니까? 이것은 전세계에 있는 누구에게도, 어떠한 GPL 프로그램에 대해서도 그 소스 코드를 얻을 수 있도록 해야 한다는 것을 의미합니까?“제3자에게도 유효한”이라는 말의 의미는 서면을 갖고 있는 사람은, 그가 누가 되었든지 서면상의 약속을 보장받을 권리가 있다는 것입니다. 만약 여러분이 소스 코드가 동반되지 않은 프로그램을 상업적으로 배포한다면, 소스 코드를 별도로 제공하겠다는 확약이 명시된 서면을 함께 배포할 것을 GPL은 규정하고 있습니다. 만약 여러분으로부터 프로그램을 구입한 사용자가 그 프로그램을 비상업적으로 재배포할 경우에는 그들이 받은 서면을 복사해서 같이 배포해야만 합니다. 이것은 최초의 배포자인 여러분으로부터 프로그램을 직접 구입하지 않은 경우라 하더라고 소스를 제공하겠다는 약정서 또는 그 복사본을 갖고 있는 사람은 누구라도 소스 코드를 제공 받을 권리가 있다는 것을 의미합니다. 서면 약정서가 제3자에게도 유효하도록 하는 이유는 바이너리 프로그램을 간접적으로 받은 사람이라 하더라도 최초의 상업 배포자에게 소스 코드를 요구할 수 있도록 하기 위한 것입니다. 소스 코드 없이 바이너리만 배포할 경우, 소스 코드를 메일이나 서면 주문에 따라 제공하는 대신 단순히 FTP로 제공하는 것이 가능합니까?만약 요청하는 사람이 있다면, 소스 코드를 물리적인 매체에 담아서 제공해야 합니다. 이것은 메일이나 서면 주문을 받았을 경우에 소스 코드를 보내 주어야 한다는 것을 의미합니다. 물론, 메일 주문 방법에 덧붙여서 FTP를 통해서 사람들이 소스 코드를 다운받을 수 있도록 제공하는 것은 좋은 일입니다. FTP를 통한 방법은 사용자들의 입장에서 볼 때 편리한 방법일 수 있지만 그렇지 않을 수도 있습니다. 만약 FTP에 의한 방법이 충분히 편리하다면 메일을 통해서 소스 코드를 주문하는 방법을 택하는 사람은 없을 것이므로 소스 코드를 발송하지 않아도 될 것입니다. 이는 상업 배포자들에게 좋은 일입니다. 그러나 누군가 메일이나 서면을 통해서 소스 코드를 주문했다면, 배포자는 그의 요구를 충족시켜 주어야 합니다. GPL에 의하면 개작된 버전을 공표하게 되면 임의의 제3자 또는 공중에게 라이선스를 허용해야 한다고 되어 있는데, 여기서 말하는 제3자란 정확히 누구를 말하는 것입니까?GPL은 개작된 버전을 배포할 때 개작된 버전에 대한 라이선스를 임의의 제3자에게 허용해야 한다고 규정하고 있습니다. 임의의 제3자(any third party) 또는 불특정 다수 또는 공중(公衆)이라는 말은 한마디로 모든 사람을 의미합니다. 그러나 이것이 물리적으로 어떤 형태를 취해야 한다는 것을 규정하는 것은 아니며, 단지 GPL에 의해서 배포자로부터 라이선스를 부여받게 된다는 것을 의미하는 것입니다. GPL은 돈을 벌기 위해 프로그램을 판매하는 것을 허용합니까?그렇습니다. GPL은 모든 사람들이 이렇게 하는 것을 허용합니다. 프로그램을 판매할 수 있는 권리는 자유 소프트웨어에 대한 정의의 일부입니다. GPL은 소프트웨어를 받은 모든 사람에게 비용을 징수하거나 소프트웨어를 받은 사실을 통지하도록 하는 형식을 허용합니까?그렇지 않습니다. 실제로 그러한 요구 사항은 프로그램을 자유롭지 못하게 만드는 것과 같습니다. 프로그램을 구했을 때 그에 대한 비용을 지불해야만 하거나 그 사실을 통지해야만 한다면 그 프로그램은 자유 소프트웨어가 아닙니다. 자유 소프트웨어에 대한 정의를 다시 한번 읽어봐 주시기 바랍니다. GPL은 자유 소프트웨어에 대한 라이선스입니다. 따라서 GPL 소프트웨어는 비용을 부담하지 않고도 사용하거나 재배포할 수 있습니다. 저는 제 저작물에 제 이름을 표시하고 싶습니다. 사람들로 하여금 제가 만든 것이라는 사실을 알게 하고 싶은 것입니다. GPL을 사용해도 이러한 사항이 유효할 수 있습니까?영문으로 보통 credit으로 표시되는 성명 표기 사항은 여러분의 저작물에 대해서 확실하게 보장될 수 있습니다. 한국의 법률상으로는 저작권법 제12조에 따른 성명표시권이 여기에 해당됩니다. GPL은 모든 복제물에 적절한 저작권 표시를 하도록 규정하고 있습니다. 왜 GPL 프로그램의 모든 복제물에 GPL 사본을 포함시키도록 규정하고 있습니까?저적물에 라이선스의 사본을 포함시키는 것은 프로그램의 복제물을 취득한 사람들로 하여금 그들의 권리를 알 수 있도록 하기 위한 것이므로 매우 필수적인 일입니다. 라이선스를 포함시키는 것보다 라이선스를 열람할 수 있는 인터넷상의 URL을 명기하는 것은 손쉬운 유혹이 될 수 있습니다. 그러나 여러분이 특정한 URL에 대해서 5년이나 10년 뒤까지 유효한 지속성을 보장할 수는 없을 것입니다. 20년 뒤에는 현시점에서 유효한 URL이 더이상 유효하지 않을 수도 있습니다. 네트워크 상의 변화에 무관하게 프로그램의 복제물을 취득한 사람들이 라이선스를 계속해서 읽을 수 있도록 확실하게 보장할 수 있는 방법은 라이선스 사본을 프로그램과 함께 제공하는 것입니다. 저작물이 라이선스 문서 자체보다 작은 양일 때는 어떻게 해야 합니까?그러한 경우에는 프로그램 상의 모든 권리를 허용한다는 언급을 담은 간단한 라이선스를 사용할 수 있을 것입니다. 지면이나 공간을 절약하기 위해서 GPL의 전문(preamble)이나 규정들을 실무에 적용하는 방법(Appendix: How to apply these terms to your new programs) 부분을 생략해도 무방합니까?전문과 GPL을 실무에 적용하는 방법은 GPL 전체를 구성하는 하나의 통합된 부분입니다. 따라서 생략될 수 없습니다. GPL 전체를 그대로 유지해 주시기 바랍니다. 실제로 GPL 그 자체는 카피레프트가 아니라 저작권이 설정된 카피라이트이기 때문에 단지 GPL을 있는 그대로 복제하는 것만이 허용됩니다. 서문과 GPL 규정을 실무에 적용하는 방법이 설명된 부분은 5천개의 문자로 구성되어 있으며 전체 GPL 크기의 1/3에 조금 못 미치는 양입니다. 소프트웨어 패키지의 크기가 GPL 보다 작지 않은 경우에는 영향을 미칠 만한 크기는 아니며 만약, 그러한 경우에는 GNU GPL을 사용하기 보다 모든 권리를 허용한다는 간단한 언급을 담은 라이선스를 사용할 수도 있을 것입니다. 두개의 라이선스가 호환(compatible) 된다는 말은 무슨 뜻입니까?두개의 프로그램이나 핵심 부분들을 결합해서 보다 큰 저작물을 만들기 위해서는 두개의 프로그램을 사용하는데 따른 승인을 얻을 필요가 있습니다. 만약 두개의 프로그램에 대한 각각의 라이선스가 이러한 형태를 허용한다면 이들은 서로 호환되는 것입니다. 그러나 두개의 라이선스를 동시에 만족시킬 방법이 없다면, 이들은 서로 호환되지 않는 것입니다. 특정한 라이선스들은 프로그램 간의 결합이 이루어 지는 방식이 호환성 여부에 영향을 미칠 수 있습니다. 예를 들면, 두개의 모듈이 서로 링크되는 것은 허용하지만 이들을 하나의 모듈로 병합하는 것은 허용하지 않을 수도 있습니다. 어떤 라이선스가 GPL과 호환된다는 것은 어떤 의미입니까?어떤 라이선스가 GPL과 호환된다는 것은 GPL로 배포된 코드와 그렇지 않은 코드를 결합해서 보다 큰 프로그램을 만들 수 있다는 것을 의미합니다. GPL은 이러한 형태를 허용하고 있으며, 특정한 라이선스 또한 이러한 형태를 허용하고 있다면 해당 라이선스는 GPL과 호환되는 것입니다. 자유 소프트웨어가 아닌 라이브러리를 사용하는 자유 소프트웨어를 개발하고 있습니다. 이 경우, GPL을 라이선스로 사용하게 되면 어떠한 법적 문제가 일어날 수 있습니까?링크하려고 하는 라이브러리가 GPL이 규정하는 다음과 같은 예외 조항에 해당되는 지 살펴보기 바랍니다. 만약 그렇다면 라이브러리를 사용하기 위해서 특별히 해야 할 일은 없습니다. 다시 말해서, 링크하고자 하는 라이브러리가 독점 운영체제의 주요 구성 요소로 함께 제공되고 있는 경우에는 GPL 프로그램을 링크해서 사용해도 됩니다. 그러나 특별한 예외의 하나로서 자신이 배포할 프로그램의 실행물에 컴파일러나 커널 등과 같은, 프로그램이 실행될 운영체제의 주요 구성 요소로서 (소스나 바이너리의 형태로) 운영체제와 함께 배포되는 부분들이 함께 포함되어 배포되지 않는한, 이러한 부분들에 대한 소스 코드는 배포할 소스 코드 안에 포함시키지 않아도 무방하다. 만약 이러한 경우에 해당하지 않는 라이브러리에 여러분이 만든 프로그램을 링크하고자 한다면, GPL에 덧붙여서 다음과 같은 형식의 예외 조항을 여러분이 직접 설정할 수 있습니다. Copyright (C) yyyy년 <저작권자의 이름> 이 프로그램은 자유 소프트웨어입니다. 소프트웨어의 피양도자는 자유 소프트웨어 재단의 GNU General Public License의 규정에 의해서 이 프로그램을, 개작된 2차적 프로그램과 함께 또는 개별적으로 재배포할 수 있습니다. 이 프로그램은 보다 유용하게 사용될 수 있으리라는 희망에서 배포되고 있지만 제품에 대한 어떠한 형태의 보증도 제공하지 않습니다. 보다 자세한 사항에 대해서는 GNU General Public License를 참고하시기 바랍니다. GNU General Public License는 이 프로그램과 함께 제공됩니다. 만약 이 문서가 누락되어 있다면 자유 소프트웨어 재단으로 문의하시기 바랍니다. 자유 소프트웨어 재단: Free Software Foundation, Inc., 59 Temple Place – Suite 330, Boston, MA 02111-1307, USA 특별한 예외로, <저작권자의 이름>은 이 프로그램의 코드를 FOO 라이브러리나 FOO와 동일한 라이선스를 사용하는 FOO의 수정 버전과 링크하는 것을 허용합니다. 두개가 링크된 형태로 함께 배포되는 것도 허용됩니다. FOO 라이브러리에 사용된 코드를 제외한 모든 코드들은 GNU General Public License를 준수해야 합니다. 만약, 이 파일을 수정하게 되면, 이 파일에 규정된 예외 조건들을 수정된 파일에 맞게 확장해야 될 지도 모르지만, 이것이 의무 조항은 아닙니다. 그렇게 하는 것을 원치 않는다면 수정된 버전에서 예외 조건들을 규정하고 있는 이 문구를 삭제하시기 바랍니다. 오직 프로그램의 저작권자만이 법률적으로 유효하게 이러한 예외 규정을 설정할 수 있습니다. 만약 여러분이 프로그램의 전부를 직접 만들었고 여러분의 고용주나 학교가 저작권을 주장하지 않는다면, 여러분이 바로 저작권자이며 이러한 예외 규정을 설정할 수 있습니다. 그러나 다른 사람들이 작성한 GPL 프로그램의 일부를 여러분이 작성한 코드에 포함시키고자 할 경우에는 이러한 예외 규정을 설정할 수 없습니다. 먼저 GPL 프로그램의 저작권자들로부터 이러한 사항에 대한 승인을 받아야만 합니다. 그러나 예외 규정이 포함된 프로그램을 개작할 경우에 있어서, 이러한 예외 규정을 동일하게 적용해야만 할 필요는 없습니다. 예외 규정이 추가된 프로그램을 만들 것인지 아닌지의 여부는 프로그램을 작성하는 사람의 선택입니다. 위와 같이 예외 규정을 추가하면 법률적인 문제는 없앨 수 있겠지만, 자유 소프트웨어가 아닌 라이브러리를 사용하는데 따른 문제는 더욱 심각해 진다고 볼 수 있습니다. 이러한 프로그램들은 자유 소프트웨어 환경에서 완벽하게 사용될 수 없습니다. 만약 여러분의 프로그램이 특정한 작업을 수행하기 위해서 자유 소프트웨어가 아닌 라이브러리에 의존해야 한다면, 자유 소프트웨어 세계에서는 그러한 작업을 할 수 없습니다. 자유 라이브러리가 아닌 라이브러리가 있어야만 실행될 수 있는 프로그램이라면 GNU와 같은 자유 운영체제에는 포함될 수 없기 때문에 결국 자유 세계를 제한하는 것과 같습니다. 따라서 그러한 라이브러리를 사용하지 않고 작업할 수 있는 방법은 없을까와 그러한 라이브러리를 대체할 수 있는 자유 소프트웨어를 만들 수는 없을지에 대해서 먼저 생각해 주시기 바랍니다. 이미 자유 소프트웨어가 아닌 라이브러리를 사용하도록 프로그램이 만들어진 상태라면, 아마도 결정을 바꾸기가 쉽지 않을 것이고 프로그램을 공표하지 않는 것보다는 그 상태로 공표하는 것이 나을 것입니다. 그러나 README 파일 등에 자유 소프트웨어 대체물의 필요성에 대한 언급을 포함시키고 자유 소프트웨어가 아닌 라이브러리가 없이도 동일한 작업을 할 수 있도록 프로그램을 개작하는 것이 필요하다는 사항도 제안해 줄 것을 부탁합니다. 또한 <tasks@gnu.org> 앞으로 자유 소프트웨어가 아닌 라이브러리의 이름과 그 역할을 우리에게 알려주시기 바랍니다. 그러면 동일한 기능을 가진 자유 라이브러리를 개발하도록 개발자들을 격려할 수 있을 것입니다. 제가 만든 프로그램을 GPL에 따라 공표(公表 – 공개적으로 발표함) 하고자 하는데, 프로그램에 대한 저작권을 어떻게 인정받을 수 있습니까?베른 협약에 따라서 모든 저작물은 창작과 동시에 자동으로 저작권을 인정받게 됩니다. 따라서 누군가가 저작권에 대한 문제를 제기해 오지 않는한, 여러분이 만든 프로그램에 대한 저작권을 인정받기 위해서 별도로 취해야 할 절차는 없습니다. 한국의 경우에도 저작권법 제10조 2항에 따라서 “저작권은 저작한 때부터 발생하며 어떠한 절차나 형식의 이행을 필요로 하지 않는다.”라는 동일한 내용의 조항을 명기하고 있습니다. 그러나 미국에서 저작권을 등록하는 것은 매우 좋은 생각입니다. 이것은 미국내에서 저작권 분쟁이 일어날 경우, 보다 확실한 영향력을 갖게 해 줄 수 있습니다. 여러분의 저작권에 대해서 누군가 문제를 제기할 수 있는 경우는, 여러분이 학생이거나 피고용인이었을 경우입니다. 이 경우, 학교나 고용자는 여러분이 피고용인의 신분으로 회사와 학교를 위해서 일한 것이기 때문에 저작권이 그들에게 있다고 주장할 수 있습니다. 이러한 경우에 있어서 저작권이 누구에게 귀착되는가의 여부는 여러분이 살고 있는 곳의 실정법과 근로 계약서 그리고 여러분이 한 일이 무엇인가와 같은 정황에 따라서 달라질 수 있습니다. 이러한 부분에 대해서 여문의 여지가 있다면 변호사에게 자문을 구해보는 것이 가장 좋은 방법입니다. 여러분이 생각하기에 학교나 회사가 저작권 주장을 제기할 가능성이 있다고 판단된다면, 회사나 학교에서 적법한 권한을 갖고 있는 사람으로부터 저작권 포기 각서에 서명을 받는 방법으로 이러한 문제를 확실하게 해결할 수 있습니다. (여러분의 직속 상관이나 교수는 일반적으로 이러한 저작권 포기 각서에 적법한 서명을 할 수 있는 사람이 아닙니다.) 제가 만든 프로그램을 학교측이 학교의 독점 소프트웨어 제품에 포함시키려고 한다면 어떻게 해야 합니까?오늘날, 많은 대학들은 기업과 거의 다를 것 없이 행동하며 그들이 개발한 정보와 지식의 사용을 제한하는 방법으로 기금을 조성하려고 합니다. (그러한 문제에 대한 일반적인 토론 내용과 그 영향에 대해서는 2000년 3월호 월간 아틀란틱지에 실린 “케프트 대학”이라는 제목의 기사를 참고하시기 바랍니다.) 만약 학교측이 여러분이 만든 프로그램을 자유 소프트웨어로 배포하는 것을 허용하지 않을 것 같은 기미가 보인다면, 초기에 문제를 제기하는 것이 가장 좋은 방법입니다. 개발 중인 프로그램이 보다 유용하게 완성되어 갈수록 학교 당국은 프로그램을 여러분으로부터 격리해서 완성하려는 유혹을 더욱 많이 느끼게 될 것입니다. 개발 초기 단계에는, 여러분에게 보다 많은 영향력이 있습니다. 따라서 우리는 여러분이 프로그램을 절반 정도 완성했을 시점이 되면, “이 프로그램을 자유 소프트웨어로 배포할 수 있도록 해 주면 완성하겠다.”는 식으로 학교측에 접근하기를 권합니다. 이것을 허세라고 생각하지는 말기 바랍니다. 보다 많은 경우에 있어서 여러분은 다음과 같이 말할 수 있는 용기를 가질 수 있어야만 합니다. “내가 만든 프로그램은 자유 소프트웨어가 되어야 합니다. 그렇지 않다면 결코 프로그램을 만들지 않을 것입니다.” 프로그램에 GPL을 적용하는 방법을 구체적으로 설명해 주시겠습니까?GPL 규정들을 실무에 적용하는 방법 문서를 참고하시기 바랍니다. 매뉴얼에 GFDL을 적용하는 방법을 구체적으로 설명해 주시겠습니까?GFDL 규정들을 실무에 적용하는 방법 문서를 참고하시기 바랍니다. 어떤 사람이 GPL 프로그램을 GPL이 아닌 다른 라이선스로 취득했다는 말을 들었습니다. 가능한 얘기입니까?GNU GPL은 사용자들이 프로그램에 다른 종류의 라이선스를 추가할 수 있는 권리를 허용하지 않습니다. 그러나 프로그램의 저작권자는 몇 종류의 라이선스를 함께 사용해서 프로그램을 배포할 수 있습니다. 이럴 경우, 그 중 하나가 GNU GPL이 될 수 있습니다. 한국내에서 배포되고 있는 프로그램의 경우 OpenOffice가 이러한 예를 따르고 있다고 할 수 있습니다. 여러분이 구한 복제물에 포함되어 있는 라이선스는 저작권자에 의해서 포함된 것으로 간주되고, 또한 적법한 절차에 의해서 복제물을 취득한 것으로 인정되어 여러분이 갖고 있는 복제물에 그대로 적용됩니다. 제가 만든 프로그램을 GNU GPL로 공표하고 싶습니다. 그런데 동일한 코드를 자유 소프트웨어가 아닌 프로그램에서도 사용하고 싶습니다. 이러한 이중적인 사용이 가능한지요?자유 소프트웨어가 아닌 프로그램을 공표하는 것은 윤리적으로 볼 때 언제나 좋지 못한 것이지만, 법률적인 측면에서 보면 그렇게 하는데 따른 어떠한 장애도 없습니다. 만약 여러분이 해당 코드의 저작권자라면 여러번에 걸쳐서 다른 종류의 라이선스로 프로그램을 공표하는 것이 가능합니다. GPL 프로그램을 만든 개발자 자신도 GPL에 구속됩니까? 개발자가 한 행동이 GPL 위반이 되었던 사례가 있습니까?엄밀하게 말해서, GPL이란 프로그램을 사용하고 배포 및 개작할 수 있도록 개발자로부터 임의의 제3자에게 부여되는 라이선스입니다. 따라서 저작권자는 자신의 프로그램에 대해서 무엇을 하든지 간에 라이선스에 종속되지 않기 때문에 GPL 위반이 성립될 수 없습니다. 그러나 개발자 자신이 GPL 위반이 될 수 있는 일을 한다면, 그는 공동체 안에서의 도덕적 지위를 잃게 될 것입니다. GPL로 프로그램을 배포했던 개발자가 후에 누군가에게 그 프로그램에 대한 독점적인 사용권을 줄 수가 있습니까? 그렇지 않습니다. GPL에 의해서 공중이 이미 프로그램을 사용할 수 있는 권리를 갖고 있기 때문에 그러한 권리는 철회될 수 없습니다. GPL로 배포되는 에디터를 자유 소프트웨어가 아닌 소프트웨어를 개발하는데 사용하는 것이 가능합니까? 또한 GPL을 따르는 도구들을 이용해서 자유 소프트웨어가 아닌 코드들을 컴파일하는 것이 가능합니까?가능합니다. 에디터와 개발 도구들에 대한 저작권은, 도구들을 이용해서 만들어진 코드에 영향을 미치지 않습니다. 몇몇 프로그램들은 기술적인 이유로 프로그램의 일부분을 출력 결과에 복사하기도 합니다. 예를 들면, Bison의 경우에는 표준 파서 프로그램을 출력 파일로 복사합니다. 이러한 경우에는 출력에 포함된 복사 부분이 최초의 라이선스를 그대로 따르게 됩니다. 프로그램의 입력으로부터 파생된 출력은 입력의 저작권 상태를 동일하게 갖습니다. 그러나 Bison은 자유 소프트웨어가 아닌 프로그램을 만드는데 사용될 수 있습니다. 이것은 Bison 출력 파일에 포함될 표준 파서 프로그램에 대한 사용을 제한없이 허용했기 때문입니다. 이러한 결정을 하게된 이유는 자유 소프트웨어가 아닌 프로그램을 만드는데 사용할 수 있는, Bison과 경쟁이 될만한 도구들이 이미 존재하고 있기 때문입니다. GPL 프로그램의 소스 코드에도 “공정 사용(fair use)”이 적용될 수 있습니까?그렇습니다. 공정 사용(fair use)이란 저작권자의 배타적인 권리를 제한하는 것으로, 공공 도서관이나 교육 기관에서의 사용과 같이 공적 목적이나 학술적 발전을 위해서 저작물의 복제 및 사용을 허가하는 것을 말합니다. 한국의 경우에는 “저작권법 제2장 6절 저작재산권의 제한” 부분에 이러한 사항이 규정되어 있습니다. 따라서 공정 사용의 경우에는 GPL이나 기타 다른 종류의 라이선스에서 개발자가 어떠한 종류의 제한을 설정했다 하더라도 개발자의 승인없이 소스 코드를 사용할 수 있습니다. 그러나 공정 사용에 대해서 전세계적으로 통용되는 기준이 존재하지는 않는다는 점에 주의하시기 바랍니다. 어떠한 종류의 사용이 공정 사용인지에 대해서는 국가마다 그 기준이 다릅니다. 제가 만든 프로그램의 작업 결과물이 GPL이 되도록 할 수 있습니까? 예를 들면, 하드웨어를 디자인하는 프로그램을 만들었다고 할 때, 다른 사람이 이 프로그램을 이용해서 만든 디자인을 자유 소프트웨어가 되도록 할 수 있습니까?일반적으로 이것은 법률적으로 불가능합니다. 저작권법은 프로그램을 사용해서 만들어진 출력 데이터에 대한 권리를, 개발에 사용된 프로그램의 저작권자에게 인정하고 있지 않습니다. 한국의 경우 저작권법과 컴퓨터 프로그램 보호법 2개의 법이 여기에 해당됩니다. 만약 프로그램의 사용자가 자신의 데이터를 입력하거나 변환하기 위해서 여러분이 만든 프로그램을 사용했다고 하면 출력물에 대한 저작권은 프로그램을 사용한 사람에게 있는 것이지 여러분에게 있는 것이 아닙니다. 보다 일반적인 경우에 있어서, 프로그램이 입력을 단지 다른 형태로 번역하는 형태였다고 하면 출력을 만들어 내는데 사용된 입력 자료의 저작권 설정이 출력 결과물에도 그대로 적용됩니다. 따라서 출력물의 사용에 대해서 여러분이 어떠한 영향력을 행사할 수 있는 유일한 경우는 출력물의 핵심 부분이 여러분이 만든 프로그램의 일부분을 복사하는 형태로 만들어 지는 경우입니다. 예를 들면, 이전 질문에 대한 답변과 같이 Bision을 사용해서 만들어진 결과물은 모두 GPL이 됩니다. 하지만 Bision의 경우에는 전략상의 이유로 우리가 특별한 예외 기준을 설정해 놓았다는 것을 이미 말한 바 있습니다. 그렇다면 한가지 가능한 경우를 생각해 봅니다. 그렇게 해야할 기술적인 이유가 특별히 없음에도 불구하고 이 질문의 의도와 같은 목적을 충족시키기 위해서, 고의적으로 프로그램의 일부가 결과물로 복사되도록 만들 수 있을 것입니다. 그러나 복사된 부분이 실제적인 목적으로 사용되지 않는다면 사용자는 그 부분을 삭제하고 단지 나머지 부분만을 사용할 수 있을 것입니다. 그리고 사용자는 복사된 부분에 적용될 배포상의 조건과 규정들을 무시하게 될 것입니다. 어떤 경우에, GPL 프로그램이 만든 결과물에도 GPL이 적용됩니까?프로그램의 일부분이 결과물로 복사될 때만 가능합니다. GPL 모듈에 제가 만든 모듈을 추가했을 경우에, 제가 만든 모듈에 대한 라이선스로 GPL을 사용해야만 합니까?GPL은 결합된 프로그램 전체가 GPL로 공표될 것을 요구합니다. 따라서 여러분이 만든 모듈의 라이선스는 GPL이 되어야 합니다. 그러나 여러분이 만든 코드를 사용하는데 따른 보다 많은 허가 사항을 추가할 수는 있습니다. 만약 원하다면, GPL과 호환되는 보다 유연한 라이선스를 사용할 수 있습니다. 만약 라이브러리가 LGPL이 아닌 GPL로 공표되어 있다면 이 라이브러리를 사용하는 프로그램은 GPL 프로그램이 되어야 합니까?그렇습니다. 실제적으로 프로그램이 라이브러리를 포함한 상태로 실행되기 때문에 GPL이 되어야 합니다. 만약 특정한 프로그래밍 언어에 대한 인터프리터가 GPL로 공표되어 있다면 이러한 인터프리터를 사용해서 만들어진 프로그램에도 GPL과 호환되는 라이선스가 적용되어야 합니까?인터프리터가 단순히 한 언어를 인터프리트하는 역할을 하는 경우에는 그렇지 않습니다. 인터프리터에 있어서 인터프리트된 프로그램은 단순히 데이터일 뿐입니다. GPL과 같은 자유 소프트웨어 라이선스는 저작권법에 기초하고 있기 때문에 인터프리터를 사용해서 만들어진 데이터를 제한할 수 없습니다. 어떠한 데이터에 대해서도 인터프리터를 사용할 수 있으며, 인터프리트된 데이터에 대한 어떠한 요구도 할 수 없습니다. 그러나 인터프리터가 라이브러리와 같은 요소와 바인딩되도록 확장되어 있을 경우에는, 인터프리트된 결과로 만들어진 프로그램이 바인딩을 통해서 라이브러리와 링크될 것입니다. 만약 라이브러리가 GPL로 공표된 것이었다면, 인터프리트 되어 만들어진 프로그램은 GPL과 호환되는 형태로 공표되어야 합니다. 이러한 예로 JNI와 자바 네이티브 인터페이스를 들 수 있습니다. 이러한 방법으로 접근되는 라이브러리들은 이들을 호출하는 자바 프로그램과 다이나믹하게 링크됩니다. 또하나의 일반적인 사례는 인터프리터와 이 인터프리터를 사용해서 인터프리트된 라이브러리들이 함께 제공되는 경우입니다. 예를 들면, Perl 인터프리터는 많은 종류의 Perl 모듈들과 함께 제공되고 자바 구현물에는 많은 양의 자바 클래스들이 함께 제공됩니다. 이러한 경우에는 라이브러리와 라이브러리를 호출하는 프로그램이 항상 다이나믹하게 링크되어 함께 사용됩니다. 결과적으로 GPL로 공표된 Perl 모듈이나 자바 클래스를 여러분이 만든 프로그램에 포함시키기로 결정했다면 결합된 Perl이나 자바 프로그램이 실행될 인터프리터들의 라이선스에 상관없이, 여러분의 프로그램은 GPL과 호환되는 방식으로 공표되어야만 합니다. 저는 마이크로소프트의 Visual C++ (또는 VIsual Basic)으로 윈도우즈용 응용 프로그램을 만들고 있습니다. 이 프로그램을 GPL로 만들려고 하는데 GPL은 이러한 프로그램이 실행될 때, Visual C++ (또는 Visual Basic)의 라이브러리와 다이나믹 링킹되는 것을 허용합니까?그렇습니다. 런타임 라이브러리는 일반적으로 여러분이 사용하고 있는 컴파일러나 인터프리터와 함께 제공되기 때문에 이러한 형태는 가능합니다. 최초의 BSD 라이선스가 GPL과 호환되지 않는 이유는 무엇입니까?GPL에는 없는 특정한 제한들이 포함되어 있기 때문입니다. BSD 라이선스에는 프로그램의 홍보에 대한 규정이 있습니다. GPL에는 다음과 같은 부분이 있습니다. 프로그램(또는 2차적 프로그램)을 양도할 때는 피양도자의 권리를 제한할 수 있는 어떠한 사항도 별항으로 추가할 수 없습니다.홍보에 대한 부분은 별도의 제한 사항이라고 볼 수 있기 때문에 GPL 호환된다고 볼 수 없습니다. 그러나 개정된 BSD 라이선스에서는 문제의 소지가 되는 구문이 삭제되었습니다. 플러그인 (plug-in)을 사용하는 프로그램을 GPL로 공표한다고 할 때, 플러그인의 라이선스에 대한 조건이 있습니까?그것은 프로그램이 플러그인을 어떤 방식으로 실행시키는 지에 달려있습니다. 만약 프로그램이 플러그인을 실행하기 위해서 fork와 exec를 사용한다면 플러그인은 별도의 프로그램이라고 볼 수 있으므로 플러그인을 사용하는 프로그램의 라이선스에는 플러그인에 대한 별도의 규정이 필요없습니다. 하지만, 만약 프로그램이 플러그인과 다이나믹하게 링크되는 형식으로 실행되어 서로 함수를 호출하고 자료 구조를 공유하게 된다면 이는 하나의 프로그램을 형성하게 된다고 볼 수 있으므로 플러그인은 메인 프로그램이 확장된 것으로 간주되어야 합니다. 이것은 플러그인에도 GPL이나 GPL과 호환되는 라이선스를 적용해야 한다는 것을 의미합니다. 만약 프로그램이 플러그인과 다이나믹하게 링크되는 형태이지만, 프로그램이 프러그인의 메인 함수를 몇가지 옵션과 함께 호출하고 여기에 대한 리턴값을 기다리는 형태로 만들어 졌다면, 매우 판단하기 어려운 경우가 됩니다. 자유 소프트웨어가 아닌 프로그램을 대상으로 하는 플러그인을 GPL로 만드는 것이 가능합니까?프로그램이 플러그인을 실행하기 위해서 fork와 exec를 사용한다면 플러그인은 별도의 프로그램이라고 볼 수 있으므로 플러그인을 사용하는 프로그램의 라이선스에는 플러그인에 대한 요구 조건이 필요없습니다. 따라서 플러그인을 GPL로 만들 수 있습니다. 여기에는 특별한 요구 사항이 없습니다. 하지만, 만약 프로그램이 플러그인과 다이나믹하게 링크되는 형식으로 실행되어 서로 함수를 호출하고 자료 구조를 공유하게 된다면 이는 하나의 프로그램을 형성하게 된다고 볼 수 있으므로 플로그인은 메인 프로그램이 확장된 것으로 간주되어야 합니다. 이것은 GPL이 적용된 플러그인을 메인 프로그래과 함께 사용하는 것이 GPL 위반이 된다는 것을 의미합니다. 그러나 이러한 법률적 문제는 여러분이 만든 플러그인의 라이선스에 자유 소프트웨어가 아닌 프로그램과 링크하는 것을 허용하다는 예외 규정을 추가하는 것으로 해결할 수 있습니다. 보다 구체적인 사항에 대해서는 “자유 소프트웨어가 아닌 라이브러리를 사용하는 자유 소프트웨어의 개발”과 관련된 질문 부분을 참고하시기 바랍니다. 코드를 GPL 프로그램과 링크시켜야만 제가 만들고자 하는 독점 프로그램을 만들 수 있습니다. 이것은 제가 만든 프로그램이 GPL 프로그램이 되어야 한다는 것을 의미합니까?그렇습니다. 그렇다면 링크하고자 하는 프로그램을 Lesser GPL 라이선스로 사용할 수 있는 방법은 없습니까?프로그램의 저작권자에게 요청할 수는 있습니다. 그러나 대부분의 저자들은 굳은 자세를 유지할 것이고 거절할 것입니다. GPL의 기본적인 개념은, “우리가 만든 코드를 여러분의 프로그램에 포함시키고자 한다면, 여러분이 만든 프로그램 또한 자유 소프트웨어가 되어야 한다.”는 것입니다. 그것은 여러분이 만든 프로그램을 공동체의 일부로 환원시키기 위해서 일종의 압력을 행사하는 것과 같습니다. 여러분은 언제든지 우리가 만든 코드를 사용하지 않는 선택을 할 수 있습니다. 저는 다양한 라이선스가 적용된 여러 개의 컴포넌트들과 링크되어 실행되는 응용 프로그램을 만들고 있습니다. 그 때문에 제가 만든 프로그램의 라이선스를 어떻게 설정해야 할지 매우 혼란스럽습니다. 어떻게 해야 할까요?이 질문에 답하기 위해서는, 먼저 프로그램이 사용하는 컴포넌트들의 이름과 각각의 라이선스에 대해서 알아야 합니다. 그리고 프로그램의 라이브러리가 어떠한 방식으로 컴포넌트를 호출하는 지에 대한 간략한 설명이 필요합니다. 다음의 예와 같은 설명이 포함된 질문이 필요합니다. 소프트웨어가 작동하기 위해서 FOO라는 라이브러리와 링크되어야 합니다. FOO의 라이선스는 Lesser GPL입니다. 제 프로그램은 BAR 프로그램을 실행하기 위해서 시스템 콜을 수행하는데 BAR 프로그램은 QUUX와 링크하는 것을 허용한다는 예외 조항이 추가된 GPL 프로그램입니다. “단순 집합(aggregation)”과 “두개의 모듈을 결합하여(combine) 하나의 프로그램으로 만든다”는 의미의 차이는 무엇입니까?두 프로그램의 단순 집합이란 CD-ROM이나 하드 디스크 등에 이들을 단순히 함께 저장한 것을 말합니다. 우리는 이 말을 프로그램들이 하나의 프로그램의 일부로서가 아닌 독립된 프로그램들로 취급될 때 사용합니다. 이 경우, 하나의 프로그램에 GPL이 적용된다고 해도 다른 프로그램에는 전혀 영향을 미치지 않습니다. 영어로 aggregation이라는 단어는 저작권법 상에서 집합 저작물이라는 용어로 사용되고 있습니다. 독립된 저작물을 의미하는 independent works는 독자적 저작물이라는 용어를 사용합니다. 두개의 모듈을 결합한다는 것은 이들이 보다 큰 하나의 프로그램을 구성하기 위해서 함께 연결된다는 뜻입니다. 이 경우 어느 한쪽이라도 GPL 프로그램이면, 결합된 전체 프로그램 또한 GPL로 공표되어야 합니다. 그렇게 하기 싫다면 프로그램들을 결합하지 않으면 됩니다. 두개의 부분이 결합되어 하나의 프로그램을 구성하고 있는지 아닌지의 여부를 어떻게 결정할 것인가라는 문제는 궁극적으로 판사들이 결정해야 할 법률적인 문제입니다. 그러나 우리는 적정한 기준이 exec와 파이프, rpc, 공유 어드레스 안에서의 함수 호출 등과 같은 통신 매커니즘과 어떤 종류의 정보가 교환되는가 하는 통신상의 내용에 달려있다고 믿고 있습니다. 만약 모듈들이 특정한 실행 파일 안에 함께 포함되어 있다면 이것은 명확히 하나의 프로그램으로 결합되어 있는 것입니다. 만약 모듈들이 공유된 어드레스 공간 안에서 링크되어 실행되도록 설계되어 있다면 이또한 거의 확실히 하나의 프로그램으로 결합되어 있는 것으로 볼 수 있습니다. 이와 대조적으로 파이프와 소켓, 명령행 인자 등은 두개의 독립된 프로그램간의 통신을 위해서 사용되는 매커니즘입니다. 따라서 모듈들이 이러한 형식을 사용한다면 모듈들은 독립된 프로그램으로 볼 수 있습니다. 그러나 통신의 내용과 의미를 충분히 깊게 고려해 볼 때, 복잡한 내부 자료 구조를 교환하는 것 또한 두 개의 부분이 보다 큰 하나의 프로그램을 구성하는 것으로 볼 수 있을 것입니다. 왜 자유 소프트웨어 재단은 FSF가 저작권을 갖고 있는 프로그램에 기여하고 있는 사람들에게, 저작권을 자유 소프트웨어 재단으로 양도하도록 하고 있습니까? 제가 GPL 프로그램의 저작권자라면, 저 또한 저작권을 자유 소프트웨어 재단으로 양도해야 합니까?우리 변호사들의 자문에 따르면, 법정에서 GPL을 위반한 사람에 대해서 우리가 가장 유리한 입장을 취할 수 있는 방법은 저작권 소유 문제를 가능한 가장 단순하게 유지하는 것이라고 합니다. 그래서 우리는 기여자들에게 그들이 기여한 부분에 대한 저작권을 자유 소프트웨어 재단 측에 양도하든지 아니면, 공개 프로그램(public domain)으로 만들어서 저작권을 포기하도록 요청하고 있습니다. 또한 우리는 각각의 기여자들에게 그들의 고용자들이 저작권을 주장할 수 없도록 저작권 포기에 동의한다는 약속을 받도록 요청하고 있습니다. 물론, 모든 기여자들이 그들의 프로그램을 공개 프로그램으로 만들어서 저작권을 포기한다면 GPL을 강제할 수 있는 저작권 자체가 없어지는 것과 같습니다. 그래서 우리는 많은 양의 코드에 대해서는 저작권을 설정하고, 오직 짧은 수정에 대한 부분만을 공개 프로그램으로 만들도록 사람들에게 말하고 있습니다. 만약 여러분이 만든 GPL 프로그램에 대해서 법적 대응을 할 수 있도록 하고 싶다면 이같은 방법을 따르는 것이 좋은 선택입니다. 보다 구체적인 사항에 대해서 알고 싶을 경우에는 <licensing@gnu.org> 앞으로 영문 메일을 보내 주시기 바랍니다. GNU GPL로 배포되는 소프트웨어의 일부를 개작해서 제가 만든 새로운 프로그램에 포함시켰을 경우에, 이 프로그램을 상업적으로 배포하거나 판매하는 것이 가능합니까?개작한 프로그램을 상업적으로 판매하는 것은 가능합니다. 그러나 이 경우에도 GNU GPL의 기준에 따라서 판매 및 배포가 이루어져야 합니다. 다시 말해서, GPL에 규정된 대로 사용자들이 소스 코드를 이용할 수 있도록 해야 하고 이들이 프로그램을 재배포하거나 개작하는 것 또한 허용해야 합니다. 이러한 사항은 여러분의 프로그램에 GPL 코드를 포함시키기 위해서 충족되어야 할 요구 조건입니다. 저는 C와 C++ 프로그래밍 언어를 사용하고 있는데, GCC를 이용해서 컴파일하고 있습니다. 제가 만든 프로그램을 GCC의 라이선스와 같은 GPL로 공표해야만 합니까?GCC를 사용해서 만들어진 프로그램의 라이선스와 GCC의 라이선스는 별개의 문제입니다. GPL을 소프트웨어가 아닌 다른 부문에도 적용할 수 있습니까?GPL은 저작물의 “소스 코드”가 무엇으로 구성되는가라는 점이 명확히 구분될 수 있는 한, 어떠한 종류의 저작물에도 적용할 수 있습니다. GPL에서는 소스 코드를, “저작물을 개작하기 위해서 선호되는 형태”라고 정의하고 있습니다. 그러나 교과서나 매뉴얼과 같이 교육을 위한 자료들에는 GPL보다 GFDL을 사용할 것을 추천합니다. 다음과 같은 상황이 있습니다. X가 프로젝트의 V1 (첫번째 버전)을 GPL로 공표했습니다. Y가 V1에 기반한 새로운 코드를 작성하고, V1을 개작하는 작업으로 두번째 버전인 V2의 개발에 기여했습니다. 이제, X가 V2를 GPL이 아닌 라이선스로 교체하려고 합니다. 이 경우, X는 Y의 허가를 받아야 합니까?그렇습니다. Y는 GPL 프로그램이었던 V1을 기반으로 작업을 했기 때문에 그가 만든 개작물을 GNU GPL로 공표되어야 합니다. 따라서 Y가 V2를 다른 라이선스로 공표하기 위해서는 Y의 동의가 필요합니다. GPL 소프트웨어를 독점 시스템 안에 통합시키고 싶습니다. 가능합니까?GPL 소프트웨어는 독점 시스템 안에 통합될 수 없습니다. GPL의 목적은 모든 사람들에게 프로그램에 대한 학습과 개작, 복제와 재배포의 자유를 부여하기 위한 것입니다. 만약 GPL 프로그램을 자유 소프트웨어 시스템이 아닌 곳에 통합시킨다면, 그것은 GPL 소프트웨어를 자유 소프트웨어가 아닌 것으로 만드는 결과가 됩니다. GPL 프로그램이 통합된 시스템은, GPL 프로그램이 확장된 것이라고 할 수 있습니다. GPL은 GPL 프로그램을 확장한 버전을 공표할 때 그 라이선스로 GPL을 사용해야 한다고 규정하고 있습니다. 여기에는 두가지 이유가 있습니다. 첫번째는 소프트웨어를 취득한 사용자로 하여금 그들이 가질 수 있는 자유를 알게 하려는 것이고, 두번째는 그들이 만든 개선점들을 공동체로 환원하도록 격려하기 위한 것입니다. 그러나 많은 경우에 있어서, GPL 소프트웨어를 독점 시스템과 함께 배포할 수 있습니다. 이것이 가능하기 위해서는 GPL 프로그램과 그렇지 않은 프로그램들이 서로 결합되어 하나의 프로그램으로 작동하는 형태가 아니라 서로 독립적으로 실행되거나 통신하는 형태가 되어야만 합니다. GPL 소프트웨어가 독점 시스템에 통합된 형태인지 아니면 서로 독립적으로 작동하는 형태인지에 대한 구별은 실제적인 측면과 형식적인 측면으로 구분해서 생각해 볼 수 있습니다. 실제적인 측면에서 볼 때, 두개의 프로그램이 하나의 프로그램을 구성하는 두개의 부분으로 기능하면서 결합되는 경우에는, 두개의 프로그램을 별도의 프로그램으로 취급할 수 없기 때문에 프로그램 모두가 GPL로 취급되어야 합니다. 만약 두개의 프로그램이 커널과 컴파일러(또는 쉘, 에디터)의 경우과 같이 분리된 상태를 유지하면서 원래의 기능을 충분히 수행할 수 있다면 각각의 프로그램들을 별도의 프로그램으로 취급할 수 있습니다. 문제가 되는 것은 GPL 소프트웨어가 포함된 시스템을 배포할 때, 사용자들에게 배포 형식을 어떻게 설명할 것인가 하는 형식적인 측면입니다. 우리가 이러한 부분에 관심을 갖고 있는 것은 집합물에 포함되어 있는 GPL 소프트웨어의 상태를 사용자들이 명확하게 인식하게 되기를 원하기 때문입니다. 만약 시스템의 일부가 독점 소프트웨어라는 사실을 알고 있는 사용자들에게, GPL 소프트웨어가 시스템의 일부로 포함되어 있다고 말하면서 시스템을 배포하게 된다면 사용자들은 GPL 소프트웨어에 대해서 갖게 될 그들의 권리를 확실히 알지 못하게 될 수 있습니다. 그러나 그들이 받은 것이 자유 소프트웨어인데, 여기에 덧붙여서 다른 프로그램들도 함께 받은 것이라는 식의 설명을 전달받을 수 있다면, 그들의 권리는 명확해 질 수 있을 것입니다. GPL 프로그램을 개작한 뒤에 돈벌레 주식회사가 만든 독점 라이브러리와 링크시키고 싶습니다. 이 경우, 라이브러리의 소스 코드를 제가 배포할 수는 없지만 만약 프로그램을 개작하고자 하는 사람이 있다면 라이브러리를 직접 구입하는 형식을 취하면 될 것입니다. 그런데, GPL에서 이러한 형태를 금지하는 이유는 무엇입니까? 여기에는 두가지 이유가 있습니다. 먼저, 일반적인 이유 때문입니다. 만약 A라는 회사가 독점 파일을 만들 수 있도록 허용한다면 B라는 회사에서 그 독점 파일과 링크되는 GPL 소프트웨어를 배포하게 될 수 있는데, 이것은 GPL을 존패 가능성을 위협하기에 충분한 것입니다. 이것은 GPL 소프트웨어의 소스 코드에 대한 모든 종류의 개작과 확장을 억제하는 백지 수표나 다름없습니다. 모든 사용자들이 소스 코드에 접근할 수 있도록 하려는 것이 우리의 목표이기 때문에 우리는 그러한 형태를 허용할 경우에 나타날 결과를 막고자 합니다. 좀더 구체적으로 말한다면, 돈벌레 주식회사의 라이브러리와 링크된 프로그램은 우리가 정의하고 있는 범위 안에서 볼 때, 자유 소프트웨어가 아닙니다. 이 라이브러리는 사용자들이 프로그램을 수정하고 다시 컴파일 하기 위한 소스 코드를 모두 제공하고 있지 않기 때문입니다. GPL 프로그램을 소스 코드 없이 바이너리 형태로만 배포하려고 합니다. 판매 후에 소스 코드를 제공해 줄 것을 주문하는 사용자들에게 소스 코드를 보내주는 대신에, 단지 인터넷상에 소스 코드를 올려놓으면 안될까요?GPL 소프트웨어의 소스 코드를 익명 FTP 사이트에 올려놓는 것은 언제나 환영할 만한 일입니다. 그러나 이것이 GPL에 규정된 제3항을 충족시키지는 못합니다. 사용자가 소스 코드를 원할 때에는 언제든지 사용자에게 소스 코드를 제공해야 합니다. 만약 특정한 사용자가 익명 FTP를 이용해서 소스 코드를 받을 수 있는 상황이라면 FTP를 이용한 소스 코드의 제공이 서로에게 편리하겠지만, 모든 사람이 네트워크를 사용할 수 있는 것은 아닙니다. 네트워크를 사용할 수 없는 사용자들도 소스 코드를 제공받을 똑같은 권리를 갖고 있습니다. 따라서 소스 코드를 원하는 사용자로부터 서면 요청이 도착한다면 디스크나 테이프 등의 저장 매체에 소스 코드를 담아서 보내주어야만 합니다. 물론, 가장 간단한 방법은 바이너리를 배포할 때 소스 코드를 함께 배포하는 것입니다. 바이너리와 소스 코드를 인터넷 상의 다른 사이트에 올려놓아도 괜찮습니까? GPL에는 바이너리가 제공되는 곳과 같은 위치로부터 소스 코드를 복사해 갈 수 있도록 해놓아야 한다고 규정하고 있습니다. 그러나 소스 코드를 다른 사이트에 올려놓은 뒤에 이들에 대한 링크나 상호 참조 정보를 명시해서, 각각의 바이너리에 대한 소스 코드에 접근할 수 있도록 해 놓았다면 우리는 이러한 형태도 “같은 위치”에 있는 것으로 간주합니다. 그러나 다른 사이트 어딘가에서 소스 코드를 구할 수 있다고 해서 사람들에게 “XX 사이트를 참고하라.”고 말하는 것은 충분하지 않다는 것에 주의하기 바랍니다. 그 사이트에서 해당 소스 코드가 내일 삭제될 수도 있으며 동일한 프로그램이라고 하더라도 업그레이드 된 다른 버전의 소스 코드로 대체될 수도 있기 때문입니다. 이 경우 GPL을 만족시키고 있다고 할 수 없습니다. 따라서 소스 코드가 있는 사이트와의 협의를 통해서 바이너리가 제공되는 동안 해당 바이너리에 대한 소스 코드가 함께 제공될 수 있도록 해야만 GPL을 충족시키는 것이 됩니다. GPL 프로그램을 확장한 버전을 바이너리 형태로 배포하고자 합니다. 바이너리와 함께 확장되기 이전의 소스 코드를 제공해도 괜찮습니까? 안됩니다. 바이너리와 동일한 버전에 대한 소스 코드를 제공해야 합니다. 동일한 버전이란, 사용자들이 빌드했을 때 배포된 바이너리와 동일한 바이너리를 생성할 수 있는 코드를 의미합니다. 자유 소프트웨어의 개념 중 하나는 사용자이 *그들이 사용하고 있는 프로그램*의 소스 코드를 이용할 수 있어야 한다는 것입니다. GPL의 주된 목적은 자유 프로그램이 향상되더라도 그 또한 자유 프로그램이 되도록 확실히 보장함으로써 자유 세계를 만드는 것입니다. 만약 GPL 프로그램을 향상시킨 버전을 공표할 경우에는 향상된 버전의 소스 코드 또한 GPL로 공표해야만 합니다. 바이너리를 배포하려고 하는데, 소스 코드 전체와 함께 배포하는 것이 여의치 않은 상황입니다. 수정된 부분에 대한 diff 파일만을 바이너리와 함께 사용자들에게 제공하고 소스 코드의 기본 부분은 FSF로부터 다운받도록 제안하는 것이 가능할까요? 이것은 GPL을 준수하려는 선의를 가진 생각에서 비롯된 요청으로 여겨집니다. 그러나 이러한 방법으로 소스 코드를 제공하는 것은 GPL을 충족시키는 것으로 볼 수 없습니다. 사용자가 지금으로 부터 1년 후에 소스 코드를 필요로 한다면, FSF로 부터 원하는 버전의 소스 코드를 얻을 수 없을 지도 모릅니다. 우리가 새로운 버전의 소스 코드를 제공하게 되면 사용자들은 diff 파일로 올바른 작업을 할 수 없게 될 것입니다. 따라서 diff 파일이 아닌 완전한 소스 코드 전체를 바이너리와 함께 제공할 필요가 있습니다. 바이너리는 익명 FTP를 통해서 공개하지만, 소스 코드는 이를 요청하는 사람들에게만 보내주고 싶습니다. 이러한 형태가 허용됩니까?GPL은 바이너리를 소스 코드와 함께 배포하지 않는 경우에는, 사용자가 소스 코드를 요청하면 소스 코드를 제공하겠다는 서면 약정서를 함께 제공하도록 규정하고 있습니다. 왜냐하면 이것이 사용자들로 하여금 소스 코드를 얻을 수 있도록 우리가 보장할 수 있는 유일한 방법이기 때문입니다. 따라서 만약 여러분이 익명 FTP를 통해서 바이너리를 배포하고자 한다면 서명 약정서를 제공할 수 없을 것이므로 소스 코드를 FTP로 함께 제공해야 합니다. 이것은 어려운 일이 아닙니다. 만약 여러분이 프로그램을 배포할 사이트를 찾으려고 한다면, 소스 코드를 함께 제공할 수 있는 충분한 여유를 가진 사이트를 찾아야 할 것입니다. 이러한 경우에는 배포되고 있는 바이너리에 해당하는 소스 코드를 제공해야 하며, 특히 이전 버전이나 최신 버전의 소스 코드가 아닌 바이너리를 만드는데 사용된 동일한 버전의 소스 코드를 제공해야 합니다. 바이너리와 소스 코드의 배포는 상호간의 연결 및 접근이 용이하게 이루어 지는 한, 다른 머신상에서 이루어지는 것이 허용되며 이 경우, 바이너리의 다운로드 정보 근처에 해당 소스 코드를 구할 수 있는 방법을 명시해야 합니다. 어떤 방법으로 바이너리를 다운받은 사용자 각각이 소스 코드도 다운받았는 지 알 수 있습니까?이러한 사항을 알 필요는 없습니다. 사용자들에게 그들이 필요로 하는 바이너리와 소스 코드를 이용할 수 있는 방법을 명시해 주는 것만으로 배포자에게 부과된 요구 사항은 충족된 것입니다. 소스 코드를 다운받을지, 다운받지 않을 지는 사용자들의 선택에 달린 것입니다. 배포자들에게 부과된 GPL 규정은 사용자들에게 소스 코드를 구할 수 있는 방법을 확실히 명시하도록 하기 위한 것이지, 사용자들이 원하지 않는데도 불구하고 소스 코드를 다운받도록 강제하기 위한 것이 아닙니다. 일부 GNU 라이브러리들은 Lesser GPL이 아닌 GPL로 배포되고 있습니다. 그 이유는 무엇입니까?라이브러리에 Lesser GPL을 사용하는 것은 자유 소프트웨어의 발전을 후퇴시키는 것과 같습니다. 이것은 사용자들의 자유를 지키려는 우리의 노력을 부분적으로 중단한다는 것을 의미합니다. 또한 Lesser GPL의 규정 중 일부는, GPL 소프트웨어를 기반으로 만들어진 저작물들은 모두 공유되어야 한다는 규정을 보류한 것입니다. 이러한 경우 상황은 점점 더 나빠질 뿐입니다. 그러나 때에 따라서 작전상 후퇴는 좋은 전략이 될 수 있습니다. 때때로 라이브러리에 LGPL을 사용하게 되면 라이브러리의 사용 범위를 확대할 수 있기 때문에 보다 많은 향상을 가져올 수 있으며, 자유 소프트웨어에 대한 지원의 폭을 넓힐 수 있는 등의 긍정적인 결과를 유도할 수 있습니다. 이러한 일이 충분히 많이 이루어 질 경우에는 자유 소프트웨어를 위해서 좋은 일이 될 수 있습니다. 그러나 이러한 일이 얼마나 많이 일어날 수 있을까요? 그러한 상황에서는 단지 일이 좋게 되기를 바랄 수밖에 없습니다. 라이브러리에 대해서 LGPL이 도움이 되는지 잠정적으로 시험해 보기 위해서 LGPL을 사용한 뒤에, 도움이 되지 않을 경우에는 GPL로 라이선스를 변경하는 것이 좋은 방법인 것처럼 보일 수도 있습니다. 그러나 실제로 그것은 좋은 방법이 아닙니다. 일단 특정한 라이브러리에 LGPL을 적용한 뒤에는, 라이선스를 변경하는 것이 무척이나 힘들게 됩니다. 라이브러리 별로 어떤 라이선스를 사용했는 지에 대한 우리의 결정에 대해서는 보다 자세한 문서를 통해서 참고할 수 있습니다. GPL로 배포되는 GNU 프로그램 하나를 우리가 진행하고 있는 독점 소프트웨어 프로젝트에 사용하려고 하는데, GPL에 의하면 이러한 형태가 인정되지 않는 것 같습니다. 우리에게 예외를 인정해 줄 수 없을까요? 그렇게 되면 프로그램을 사용하는 사람들의 수가 더욱 많아 질 수 있을 거라고 생각합니다.미안하지만, 우리는 어떠한 예외도 인정할 수 없습니다. 그것이 옳지 않은 일이기 때문입니다. 우리의 목표는 사용자의 수를 최대한 많이 늘리는 것이 아닙니다. 우리의 목표는 가능한 많은 사람들에게 확실한 자유를 주는 것입니다. 일반적으로 독점 소프트웨어 프로젝트는 자유의 향상을 돕기보다 이를 감소시킵니다. GPL이 아닌 라이선스를 사용하지만, 자유 소프트웨어를 만들기 위한 프로젝트일 경우에는, 이를 지원하기 위해서 때때로 예외 규정을 만들기도 합니다. 그러나 이것은 그렇게 하는 것이 자유 소프트웨어의 향상에 도움이 되는 것이 분명할 때만 가능합니다. 또한 우리는 때때로 GNU 패키지들의 배포 규정을 변경하기도 하는데, 이또한 그렇게 하는 것이 자유 소프트웨어의 증진을 위해서 유익하다고 판단되는 경우에 한합니다. 따라서 만약 여러분이 우리에게 예외를 인정해 달라는 요청을 할 경우에는 매우 설득력 있는 이유를 제시해야만 합니다. 프로그램에 “GPL 버전 2 또는 그 이후의 버전이 적용됩니다.”라는 말이 포함되어 있는 이유는 무엇입니까?자유 소프트웨어 재단은 GPL의 내용을 명확히 하거나 이전 버전에서 금지되었던 사항을 허용하기 위해서, 또는 규정을 더욱 철저히 적용하기 위해서 때때로 GPL을 개정하기도 합니다. (최근 개정은 1991년도에 이루어 졌습니다.) 따라서 이러한 문구를 각각의 프로그램에 포함시킴으로써 나중에 GPL이 개정되더라도 이미 배포된 GNU 소프트웨어에 상관없이 GNU 소프트웨어 전체에 대해서 통일된 배포 규정을 적용시킬 수 있습니다. 만약 이러한 문구가 누락된다면, 개정될 GPL의 내용에 대해서 이미 배포되어 있는 GPL 소프트웨어의 수많은 저작권자들과 오랫동안 협의 과정을 거쳐야 하는데, 이것은 거의 불가능한 일입니다. 실제적인 관점에서 볼 때, 이것은 GNU 소프트웨어에 대한 배포 규정을 통일적으로 조정하는 것이 불가능하게 된다는 것을 의미합니다. “GPL 버전 2 또는 그 이후의 버전이 적용됩니다.”라는 문구가 프로그램에 명시되어 있고, 새로운 버전의 GPL이 발표되었다고 가정해 봅시다. 만약 개정된 버전의 GPL에 새로운 허가 조항이 추가되어 있다면 이 조항은 모든 사용자들이 쓰고 있는 프로그램에 즉시 적용될 수 있습니다. 그러나 개정된 GPL이 이전 버전보다 더 많은 제약을 가하고 있다면 현재 사용되고 있는 프로그램에는 이러한 제약이 적용되지 않아도 무방합니다. 왜냐하면 버전 2의 GPL을 그대로 적용해서 사용하는 것이 가능하기 때문입니다. “GPL 버전 2 또는 그 이후의 버전이 적용됩니다.”라는 말이 명시된 프로그램을 사용하는 사용자는 새로운 버전의 GPL이 발표되었다고 하더라도 GPL 버전 2의 규정에 따라서 언제든지 이 프로그램을 사용하고 개작하는 것이 허용됩니다. 새롭게 개정된 버전의 GPL에 포함된 보다 엄격한 제한 조건들을 현재 사용하고 있는 소프트웨어에 적용할 필요가 없을 경우에 이것은 매우 유용한 방법입니다. GPL 버전 3이 발표되었을 때, 버전 3의 규정들을 적용하고 싶다면 GPL 프로그램 개발자들은 “GPL 버전 3 또는 그 이후의 버전이 적용됩니다.”는 말로 대치하면 됩니다. 그러나 새로운 버전의 GPL이 공표되었다고 하더라도, 개발자에게는 새로운 버전의 GPL을 사용해야 할 의무가 없습니다. 그들이 이전 버전의 GPL을 보다 선호한다면 원하는 버전의 GPL을 사용하면 됩니다. 매뉴얼에는 GPL을 사용하지 않는 이유가 무엇입니까?매뉴얼에 GPL을 사용하는 것도 가능합니다. 그러나 매뉴얼의 경우에는 GNU 자유 문서 라이선스 (GFDL)를 사용하는 것이 보다 좋은 선택입니다. GPL은 프로그램을 위해서 설계된 것입니다. 따라서 GPL에는 매뉴얼이나 서적에는 해당되지 않고 프로그램에만 적용될 수 있는 많은 조항들이 포함되어 있습니다. 이에 반해서 GFDL에는 자유 매뉴얼의 발행자들에게 이익을 주기 위한 조항들이 포함되어 있습니다. GFDL을 따르는 저작물들은, 기술적인 부분을 다루는 내용에 대한 개작이 허용됩니다. 그러나 우리가 갖고 있는 정치, 윤리, 법률적 견해에 대한 언급이 포함된 부분에 대한 수정은 허용되지 않습니다. 이러한 형태는 저작권 표시 부분에 개작할 수 없는 부분을 명시해 놓는 형태를 통해서 이루어 지는데, GPL에서는 이러한 사항이 허용되지 않지만 GFDL에서는 “변경 불가 부분”(invariant section)이라는 규정을 통해서 이것이 가능합니다. 기술적인 내용이 포함된 부분에 대한 수정을 허용하는 것은 매우 중요한데, 그 이유는 프로그램을 개작하는 사람은 자신이 개작한 부분에 해당하는 문서의 설명도 수정할 수 있어야 하기 때문입니다. 프로그램을 수정하면 문서도 함께 수정해야 한다는 것을 강요할 수는 없지만 그렇게 되기를 바란다면, 그들의 길을 방해해서는 안될 것입니다. 다른 언어로 번역된 GPL이 존재합니까?영어가 아닌 다른 언어로 번역된 GPL 문서를 갖는 것은 매우 유용할 것입니다. 우리에게 번역문을 작성해서 보내주는 분들도 있습니다. 그럼에도 불구하고, 우리는 어떠한 번역문도 공식적으로 인정하지 않고 있습니다. 그렇게 하기에는 위험 부담이 너무 크기 때문입니다. 법률 문서는 몇몇 측면에 있어서 프로그램과 유사합니다. 따라서 법률 문서를 번역하는 것은 프로그램을 하나의 언어와 운영체제에서 다른 것으로 번역하는 것과 같습니다. 오직 두가지 언어에 능숙한 변호사만이 이 일을 할 수 있으며, 이 경우에도 버그가 포함될 위험이 있습니다. 만약 우리가 GPL 번역문을 공식적으로 승인하게 되면, GPL 원문 뿐 아니라 번역문들이 규정하고 있는 모든 사항들도 인정해야만 합니다. 만약 완벽한 번역이 이루어 졌다면 문제될 것이 없겠지만, 만의 하나 그렇지 못하다면 그 결과는 우리가 바로잡을 수 없는 치명적인 것이 될 수 있습니다. 프로그램에 버그가 포함되어 있을 경우에는 오류를 바로잡은 새로운 버전을 만들면 되고, 결과적으로 이전 버전을 사용하지 않게 될 것 입니다. 그러나 만약 우리가 특정한 번역문에 따른 권리를 인정해 주게 되면 버그라고 판단되어도 나중에 이를 돌이킬 수 있는 방법이 없습니다. 우리를 도와주려고 하는 사람들이 때때로 번역 작업을 해 주겠다는 제안을 해 오기도 합니다. 번역할 사람이 필요하다는 것이 문제였다면, 문제는 해결된 것입니다. 그러나 실제적인 문제의 핵심은 오류가 발생할 위험성이라는 부분이며, 번역을 해 주겠다는 제안은 이러한 위험성을 없앨 수 없습니다. 우리는 변호사가 아닌 사람이 번역한 문서들을 공식적으로 승인할 수 없습니다. 따라서 당분간 우리는 국제적으로 유효한 GPL 번역문을 공식적으로 승인하지 않을 것입니다. 그대신 다음과 같은 2가지 방법을 사용하고 있습니다. 비공식 번역문을 소개합니다. 이것은 GPL을 번역하는 것을 허용하지만, 법적으로 유효한 것으로 승인하지는 않는다는 것을 의미합니다. 비공식 번역문은 법적인 효력이 없습니다. 따라서 번역문에는 다음과 같은 사항이 명시되어 있습니다. 이 번역문은 자유 소프트웨어 재단이 승인한 공식 문서가 아닙니다. GPL을 실무에 적용할 경우, 오직 영문판 GPL에 의해서만 법률적 효력이 유효할 수 있다는 점에 유의하시기 바랍니다 그러나 비공식 번역문은 GPL이 의도하는 것이 무엇인가를 알리는데 도움이 될 수 있으며, 대부분의 사용자들에게는 그것만으로도 충분합니다. 그러나 상업적 목적을 위해서 GNU 소프트웨어를 사업에 이용하거나 공개 FTP를 이용해서 배포할 경우에는 GPL의 규정을 명확히 하기 위해서 영문판 GPL을 반드시 검토해야 합니다. 번역문을 출판하는 것은 한 국가에 대해서만 유효합니다. 출판된 번역문은 그 국가에서만 유효한 것으로 간주합니다. 이러한 방법을 통해서 번역문에 오류가 있다고 하더라도 그 피해를 최소화 시킬 수 있습니다. 그러나 이러한 번역문이 만들어 지기 위해서는 동조적이고 능력있는 변호사들의 상당한 노력과 전문 지식이 필요합니다. 따라서 우리는 이러한 번역문이 조만간 만들어 질 수 있으리라는 약속을 쉽게 할 수 없습니다. GPL과 호환되지 않는 라이선스를 사용하는 프로그래밍 언어에 대한 인터프리터가 있다면, GPL 프로그램을 이러한 인터프리터 상에서 실행할 수 있습니까?인터프리터가 단지 언어를 인터프리트하는 역할만을 수행할 경우에는 가능합니다. 인터프리트된 프로그램은 인터프리터의 입장에서 볼 때, 단순한 데이터에 불과하기 때문입니다. 이러한 경우 GPL은 프로그램을 처리하는데 사용되는 툴을 제한하지 않습니다. 그러나 인터프리터가 라이브러리와 같은 다른 요소와의 바인딩을 제공하도록 확장된 경우에는, 인터프리트된 프로그램은 바인딩 과정에서 사용된 요소와 사실상 링크된 것이라고 할 수 있습니다. 이러한 예로 JNI와 자바 네이티브 인터페이스를 들 수 있습니다. 이러한 방식으로 접근되는 라이브러리들은 자바 프로그램이 이들을 호출할 때, 다이나믹하게 링크됩니다. 따라서 만약 이러한 요소들이 GPL과 호환되지 않는 라이선스로 공표되어 있다면, 이것은 GPL과 호환되지 않는 라이브러리와 링크하는 것과 같은 상황이 됩니다. 이것은 다음과 같이 해야 한다는 것을 의미합니다. GPL로 프로그램을 작성해서 공표할 경우에는 GPL과 호환되지 않는 저작물과 링크하는 것을 허용한다는 예외 규정을 명시적으로 포함시킵니다. GPL과 호환되지 않는 저작물과 함께 작동하도록 만든 코드를 GPL로 공표할 경우, 사람들은 이를 GPL과 호환되지 않는 저작물과 함께 사용할 수 있다는 묵시적인 허용으로 간주할 수 있습니다. 만약 이것이 의도하는 것이라면 그러한 사항을 명시적으로 언급하는 것이 좋습니다. 다른 사람의 GPL 코드는 이런 방법으로 링크해서 사용할 수 없고 예외를 설정할 수도 없습니다. 오직 해당 코드의 저작권자만이 예외 규정을 추가할 수 있습니다. GPL을 법률적으로 강제할 수 있는 사람은 누구입니까?GPL은 저작권에 관련된 라이선스이기 때문에 소프트웨어의 저작권자가 GPL을 법률적으로 강제할 수 있는 사람 중 하나입니다. 만약 여러분이 GPL 위반을 목격하게 되면 해당 소프트웨어의 개발자들에게 그 사실을 알려주시기 바랍니다. 그들은 저작권자 자신이거나 저작권자와 연락할 수 있는 사람들입니다. 자바와 같은 객체 지향 언어에 있어서 GPL로 공표된 클래스를 수정없이 사용해서 서브 클래스를 생성했을 경우, 서브 클래스가 포함된 전체 프로그램에는 GPL이 적용됩니까? 서브 클래스를 만드는 것은 2차적 저작물을 만드는 것과 같습니다. 따라서 GPL 라이선스를 사용하는 클래스로부터 파생된 서브 클래스를 이용해서 만들어진 전체 프로그램에는 GPL이 적용됩니다. 프로그램을 GNU/리눅스에서 사용할 수 있도록 포팅했다면, 이 프로그램을 GPL이나 그밖의 자유 소프트웨어 라이선스로 공표해야만 합니까? 일반적으로 말하면, 그렇지 않습니다. 그것이 법률적인 요구 사항은 아닙니다. 보다 자세히 말하면, 사용하고 있는 라이브러리가 무엇이며 라이브러리의 라이선스가 무엇인지에 달려있습니다. 대부분의 시스템 라이브러리들은 라이선스로 GNU Lesser GPL이나, 어떤 프로그램과도 링크할 수 있다는 예외 조항이 설정된 GNU GPL을 사용하고 있습니다. 이러한 라이브러리들은 자유 소프트웨어가 아닌 프로그램에서 사용될 수 있습니다. 그러나 LGPL의 경우에는 준수해야 할 몇가지 규정들이 있습니다. 어떤 라이브러리들은 GNU GPL만을 사용해서 공표되는데, 이러한 라이브러리를 사용하기 위해서는 라이브러리를 사용한 저작물 전체에 GPL 호환 라이선스가 적용되어야 합니다. 그러나 일반적으로 다른 플랫폼에서 사용할 수 있는 대용물이 거의 없는 특별한 라이브러들이 많이 존재하기 때문에 간단한 포팅 작업에 이러한 라이브러리를 사용하고 싶지는 않을 것입니다. 만약 여러분이 만든 프로그램이 자유 소프트웨어가 아니라면, 우리 공동체에 대한 기여가 아니며 자유의 가치를 소중하게 생각하는 사람들은 그 프로그램을 사용하지 않을 것입니다. 따라서 그러한 프로그램은 결과적으로 사람들로 하여금 그들의 자유를 포기하게끔 유혹하는 역할을 하게 되어, 오직 자유를 포기한 사람들게만 유용하게 될 것입니다. 먼훗날, 여러분이 걸어온 길을 되돌아 보았을 때 지금까지 한일이 단순히 돈을 벌기 위한 것 이상이었다는 느낌을 갖고 싶다면 여러분이 만든 소프트웨어를 자유 소프트웨어로 만들어야 합니다. 자신들이 직접 만들지 않은 GPL 프로그램을 인터넷으로 공개하지 않고, 비용을 받고 제공해 주는 업체를 발견했습니다. 이는 GPL 위반이 아닙니까? 그렇지 않습니다. GPL은 프로그램을 배포하는데 인터넷을 사용하도록 규정하고 있지 않습니다. 또한 특정인에게 프로그램을 재배포하도록 규정하고 있지도 않습니다. 그리고 프로그램을 재배포할 것을 결정했다고 하더라도, 그 프로그램의 복제물을 특정인에게 배포해야 한다고 규정하고 있지는 않습니다. GPL이 규정하고 있는 것은 그가 원한다면 다른 사람에게 복제물을 배포할 자유를 가져야 한다는 것입니다. 일단 저작권자가 프로그램을 배포한 뒤에는, 복재물을 받은 사람은 그가 원하는 누구에게도 프로그램을 재배포할 수 있습니다. ——————————————————————–자유 소프트웨어 재단과 GNU 프로젝트에 대한 질문은 gnu@gnu.org로 보내 주시기 바랍니다. GNU에 대한 질문 이외에 홈페이지 자체에 대한 질문은 webmasters@gnu.org로 보내 주시고, 그밖의 연락 방법에 대해서는 연락처 안내 부분을 참고하시기 바랍니다. Copyright (C) 2001 Free Software Foundation, Inc., 59 Temple Place – Suite 330, Boston, MA 02111, USA 저작권에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 무상으로 허용됩니다. 첨부 파일과거 URLhttp://www.ipleft.or.kr/bbs/view.php?board=ipleft_5&id=216