자신의 프로그램을 GNU 소프트웨어 패키지로 만든다는 것은 명시적으로 GNU 프로젝트에 참여하고 기여하게 된다는 것을 의미합니다. 이것은 프로그램의 개발자와 GNU 프로젝트 양자가 서로 동의했을 때만 가능한 것입니다. 만약 여러분이 만든 프로그램을 GNU 프로젝트에 제공하고자 한다면 <maintainers@gnu.org> 앞으로 영문 메일을 주시기 바랍니다. 한국어 메일의 경우에는 <maintainers@korea.gnu.org> 앞으로 보내 주시면 됩니다.

어떤 사람들은 개작된 버전은 프로그램의 원저작자에게 보내지도록 하는 규정을 GPL에 포함시키자고 제안합니다. 원저작자가 프로그램을 관리할 필요를 계속해서 느끼고 있는 동안에는 이러한 방법이 매우 효과적일 것입니다. 그러나 만약 원저작자가 다른 일로 인해서 프로그램을 계속해서 관리하지 못하는 상황이 발생하거나 다른 사용자들이 느끼는 필요에 관심을 갖지 않을 경우에는 이러한 방법은 좋지 않은 결과를 낳게 됩니다. 이러한 실제적인 문제 이외에, 그러한 방법을 사용하면 사용자들이 서로를 돕는 것을 허용하지 않게 되는 것입니다.

사용자들에 의해서 만들어진 다양한 버전으로 인한 혼란을 방지하기 위해서 개작된 버전들을 통제해야 한다는 의견이 때때로 제안되기도 했습니다. 그러나 우리의 경험으로 볼 때, 그러한 혼동은 중요한 문제가 아닙니다. 많은 종류의 Emacs 변종 버전들이 GNU 프로젝트 외부에서 개발되어 졌지만, 사용자들은 그것을 구별할 수 있었습니다. GPL은 프로그램을 만들거나 개작할 때, 다른 버전을 만든 개발자들의 명성을 보호하고 다른 버전들이 서로 구분될 수 있도록 하기 위해서 새로운 버전을 만든 사람의 이름을 명시하도록 규정하고 있습니다.

그러나 만약 어떠한 방식으로든지 개작된 버전을 공표하고 있다면, 사용자들이 개작된 버전의 소스 코드를 GPL에 따라 이용할 수 있도록 해야만 합니다.

따라서 GPL은 개작한 프로그램을 GPL이 규정한 방식에 따라서 공표할 수 있는 허가를 제공하는 것이며, 개작한 버전을 공표하느냐 마느냐는 여러분 자신의 선택에 달려 있습니다.

만약 여러분이 소스 코드가 동반되지 않은 프로그램을 상업적으로 배포한다면, 소스 코드를 별도로 제공하겠다는 확약이 명시된 서면을 함께 배포할 것을 GPL은 규정하고 있습니다. 만약 여러분으로부터 프로그램을 구입한 사용자가 그 프로그램을 비상업적으로 재배포할 경우에는 그들이 받은 서면을 복사해서 같이 배포해야만 합니다. 이것은 최초의 배포자인 여러분으로부터 프로그램을 직접 구입하지 않은 경우라 하더라고 소스를 제공하겠다는 약정서 또는 그 복사본을 갖고 있는 사람은 누구라도 소스 코드를 제공 받을 권리가 있다는 것을 의미합니다.

서면 약정서가 제3자에게도 유효하도록 하는 이유는 바이너리 프로그램을 간접적으로 받은 사람이라 하더라도 최초의 상업 배포자에게 소스 코드를 요구할 수 있도록 하기 위한 것입니다.

GPL은 자유 소프트웨어에 대한 라이선스입니다. 따라서 GPL 소프트웨어는 비용을 부담하지 않고도 사용하거나 재배포할 수 있습니다.

라이선스를 포함시키는 것보다 라이선스를 열람할 수 있는 인터넷상의 URL을 명기하는 것은 손쉬운 유혹이 될 수 있습니다. 그러나 여러분이 특정한 URL에 대해서 5년이나 10년 뒤까지 유효한 지속성을 보장할 수는 없을 것입니다. 20년 뒤에는 현시점에서 유효한 URL이 더이상 유효하지 않을 수도 있습니다.

네트워크 상의 변화에 무관하게 프로그램의 복제물을 취득한 사람들이 라이선스를 계속해서 읽을 수 있도록 확실하게 보장할 수 있는 방법은 라이선스 사본을 프로그램과 함께 제공하는 것입니다.

서문과 GPL 규정을 실무에 적용하는 방법이 설명된 부분은 5천개의 문자로 구성되어 있으며 전체 GPL 크기의 1/3에 조금 못 미치는 양입니다. 소프트웨어 패키지의 크기가 GPL 보다 작지 않은 경우에는 영향을 미칠 만한 크기는 아니며 만약, 그러한 경우에는 GNU GPL을 사용하기 보다 모든 권리를 허용한다는 간단한 언급을 담은 라이선스를 사용할 수도 있을 것입니다.

특정한 라이선스들은 프로그램 간의 결합이 이루어 지는 방식이 호환성 여부에 영향을 미칠 수 있습니다. 예를 들면, 두개의 모듈이 서로 링크되는 것은 허용하지만 이들을 하나의 모듈로 병합하는 것은 허용하지 않을 수도 있습니다.

     그러나 특별한 예외의 하나로서 자신이 배포할 프로그램의 실행물에
     컴파일러나 커널 등과 같은, 프로그램이 실행될 운영체제의 주요 구성 
     요소로서 (소스나 바이너리의 형태로) 운영체제와 함께 배포되는 
     부분들이 함께 포함되어 배포되지 않는한, 이러한 부분들에 대한 소스
     코드는 배포할 소스 코드 안에 포함시키지 않아도 무방하다. 

만약 이러한 경우에 해당하지 않는 라이브러리에 여러분이 만든 프로그램을 링크하고자 한다면, GPL에 덧붙여서 다음과 같은 형식의 예외 조항을 여러분이 직접 설정할 수 있습니다.

    Copyright (C) yyyy년  <저작권자의 이름>

    이 프로그램은 자유 소프트웨어입니다. 소프트웨어의 피양도자는 
    자유 소프트웨어 재단의 GNU General Public License의 규정에 의해서 
    이 프로그램을, 개작된 2차적 프로그램과 함께 또는 개별적으로 
    재배포할 수 있습니다. 

    이 프로그램은 보다 유용하게 사용될 수 있으리라는 희망에서 배포되고 
    있지만 제품에 대한 어떠한 형태의 보증도 제공하지 않습니다. 보다 
    자세한 사항에 대해서는 GNU General Public License를 참고하시기 
    바랍니다. 

    GNU General Public License는 이 프로그램과 함께 제공됩니다. 만약 
    이 문서가 누락되어 있다면 자유 소프트웨어 재단으로 문의하시기
    바랍니다. 자유 소프트웨어 재단: Free  Software Foundation, Inc., 
    51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA

    특별한 예외로, <저작권자의 이름>은 이 프로그램의 코드를 FOO 
    라이브러리나 FOO와 동일한 라이선스를 사용하는 FOO의 수정 버전과
    링크하는 것을 허용합니다. 두개가 링크된 형태로 함께 배포되는 것도 
    허용됩니다. FOO 라이브러리에 사용된 코드를 제외한 모든 코드들은
    GNU General Public License를 준수해야 합니다. 만약, 이 파일을 
    수정하게 되면, 이 파일에 규정된 예외 조건들을 수정된 파일에 맞게 
    확장해야 될 지도 모르지만, 이것이 의무 조항은 아닙니다. 그렇게 
    하는 것을 원치 않는다면 수정된 버전에서 예외 조건들을 규정하고 
    있는 이 문구를 삭제하시기 바랍니다. 

오직 프로그램의 저작권자만이 법률적으로 유효하게 이러한 예외 규정을 설정할 수 있습니다. 만약 여러분이 프로그램의 전부를 직접 만들었고 여러분의 고용주나 학교가 저작권을 주장하지 않는다면, 여러분이 바로 저작권자이며 이러한 예외 규정을 설정할 수 있습니다. 그러나 다른 사람들이 작성한 GPL 프로그램의 일부를 여러분이 작성한 코드에 포함시키고자 할 경우에는 이러한 예외 규정을 설정할 수 없습니다. 먼저 GPL 프로그램의 저작권자들로부터 이러한 사항에 대한 승인을 받아야만 합니다.

그러나 예외 규정이 포함된 프로그램을 개작할 경우에 있어서, 이러한 예외 규정을 동일하게 적용해야만 할 필요는 없습니다. 예외 규정이 추가된 프로그램을 만들 것인지 아닌지의 여부는 프로그램을 작성하는 사람의 선택입니다.

위와 같이 예외 규정을 추가하면 법률적인 문제는 없앨 수 있겠지만, 자유 소프트웨어가 아닌 라이브러리를 사용하는데 따른 문제는 더욱 심각해 진다고 볼 수 있습니다. 이러한 프로그램들은 자유 소프트웨어 환경에서 완벽하게 사용될 수 없습니다. 만약 여러분의 프로그램이 특정한 작업을 수행하기 위해서 자유 소프트웨어가 아닌 라이브러리에 의존해야 한다면, 자유 소프트웨어 세계에서는 그러한 작업을 할 수 없습니다. 자유 라이브러리가 아닌 라이브러리가 있어야만 실행될 수 있는 프로그램이라면 GNU와 같은 자유 운영체제에는 포함될 수 없기 때문에 결국 자유 세계를 제한하는 것과 같습니다.

따라서 그러한 라이브러리를 사용하지 않고 작업할 수 있는 방법은 없을까와 그러한 라이브러리를 대체할 수 있는 자유 소프트웨어를 만들 수는 없을지에 대해서 먼저 생각해 주시기 바랍니다.

이미 자유 소프트웨어가 아닌 라이브러리를 사용하도록 프로그램이 만들어진 상태라면, 아마도 결정을 바꾸기가 쉽지 않을 것이고 프로그램을 공표하지 않는 것보다는 그 상태로 공표하는 것이 나을 것입니다. 그러나 README 파일 등에 자유 소프트웨어 대체물의 필요성에 대한 언급을 포함시키고 자유 소프트웨어가 아닌 라이브러리가 없이도 동일한 작업을 할 수 있도록 프로그램을 개작하는 것이 필요하다는 사항도 제안해 줄 것을 부탁합니다.

또한 <tasks@gnu.org> 앞으로 자유 소프트웨어가 아닌 라이브러리의 이름과 그 역할을 우리에게 알려주시기 바랍니다. 그러면 동일한 기능을 가진 자유 라이브러리를 개발하도록 개발자들을 격려할 수 있을 것입니다.

그러나 미국에서 저작권을 등록하는 것은 매우 좋은 생각입니다. 이것은 미국내에서 저작권 분쟁이 일어날 경우, 보다 확실한 영향력을 갖게 해 줄 수 있습니다.

여러분의 저작권에 대해서 누군가 문제를 제기할 수 있는 경우는, 여러분이 학생이거나 피고용인이었을 경우입니다. 이 경우, 학교나 고용자는 여러분이 피고용인의 신분으로 회사와 학교를 위해서 일한 것이기 때문에 저작권이 그들에게 있다고 주장할 수 있습니다. 이러한 경우에 있어서 저작권이 누구에게 귀착되는가의 여부는 여러분이 살고 있는 곳의 실정법과 근로 계약서 그리고 여러분이 한 일이 무엇인가와 같은 정황에 따라서 달라질 수 있습니다. 이러한 부분에 대해서 여문의 여지가 있다면 변호사에게 자문을 구해보는 것이 가장 좋은 방법입니다.

여러분이 생각하기에 학교나 회사가 저작권 주장을 제기할 가능성이 있다고 판단된다면, 회사나 학교에서 적법한 권한을 갖고 있는 사람으로부터 저작권 포기 각서에 서명을 받는 방법으로 이러한 문제를 확실하게 해결할 수 있습니다. (여러분의 직속 상관이나 교수는 일반적으로 이러한 저작권 포기 각서에 적법한 서명을 할 수 있는 사람이 아닙니다.)

만약 학교측이 여러분이 만든 프로그램을 자유 소프트웨어로 배포하는 것을 허용하지 않을 것 같은 기미가 보인다면, 초기에 문제를 제기하는 것이 가장 좋은 방법입니다. 개발 중인 프로그램이 보다 유용하게 완성되어 갈수록 학교 당국은 프로그램을 여러분으로부터 격리해서 완성하려는 유혹을 더욱 많이 느끼게 될 것입니다. 개발 초기 단계에는, 여러분에게 보다 많은 영향력이 있습니다.

따라서 우리는 여러분이 프로그램을 절반 정도 완성했을 시점이 되면, ``이 프로그램을 자유 소프트웨어로 배포할 수 있도록 해 주면 완성하겠다.''는 식으로 학교측에 접근하기를 권합니다. 이것을 허세라고 생각하지는 말기 바랍니다. 보다 많은 경우에 있어서 여러분은 다음과 같이 말할 수 있는 용기를 가질 수 있어야만 합니다. ``내가 만든 프로그램은 자유 소프트웨어가 되어야 합니다. 그렇지 않다면 결코 프로그램을 만들지 않을 것입니다.''

여러분이 구한 복제물에 포함되어 있는 라이선스는 저작권자에 의해서 포함된 것으로 간주되고, 또한 적법한 절차에 의해서 복제물을 취득한 것으로 인정되어 여러분이 갖고 있는 복제물에 그대로 적용됩니다.

그러나 개발자 자신이 GPL 위반이 될 수 있는 일을 한다면, 그는 공동체 안에서의 도덕적 지위를 잃게 될 것입니다.

몇몇 프로그램들은 기술적인 이유로 프로그램의 일부분을 출력 결과에 복사하기도 합니다. 예를 들면, Bison의 경우에는 표준 파서 프로그램을 출력 파일로 복사합니다. 이러한 경우에는 출력에 포함된 복사 부분이 최초의 라이선스를 그대로 따르게 됩니다. 프로그램의 입력으로부터 파생된 출력은 입력의 저작권 상태를 동일하게 갖습니다.

그러나 Bison은 자유 소프트웨어가 아닌 프로그램을 만드는데 사용될 수 있습니다. 이것은 Bison 출력 파일에 포함될 표준 파서 프로그램에 대한 사용을 제한없이 허용했기 때문입니다. 이러한 결정을 하게된 이유는 자유 소프트웨어가 아닌 프로그램을 만드는데 사용할 수 있는, Bison과 경쟁이 될만한 도구들이 이미 존재하고 있기 때문입니다.

그러나 공정 사용에 대해서 전세계적으로 통용되는 기준이 존재하지는 않는다는 점에 주의하시기 바랍니다. 어떠한 종류의 사용이 공정 사용인지에 대해서는 국가마다 그 기준이 다릅니다.

따라서 출력물의 사용에 대해서 여러분이 어떠한 영향력을 행사할 수 있는 유일한 경우는 출력물의 핵심 부분이 여러분이 만든 프로그램의 일부분을 복사하는 형태로 만들어 지는 경우입니다. 예를 들면, 이전 질문에 대한 답변과 같이 Bision을 사용해서 만들어진 결과물은 모두 GPL이 됩니다. 하지만 Bision의 경우에는 전략상의 이유로 우리가 특별한 예외 기준을 설정해 놓았다는 것을 이미 말한 바 있습니다.

그렇다면 한가지 가능한 경우를 생각해 봅니다. 그렇게 해야할 기술적인 이유가 특별히 없음에도 불구하고 이 질문의 의도와 같은 목적을 충족시키기 위해서, 고의적으로 프로그램의 일부가 결과물로 복사되도록 만들 수 있을 것입니다. 그러나 복사된 부분이 실제적인 목적으로 사용되지 않는다면 사용자는 그 부분을 삭제하고 단지 나머지 부분만을 사용할 수 있을 것입니다. 그리고 사용자는 복사된 부분에 적용될 배포상의 조건과 규정들을 무시하게 될 것입니다.

그러나 여러분이 만든 코드를 사용하는데 따른 보다 많은 허가 사항을 추가할 수는 있습니다. 만약 원하다면, GPL과 호환되는 보다 유연한 라이선스를 사용할 수 있습니다.

그러나 인터프리터가 라이브러리와 같은 요소와 바인딩되도록 확장되어 있을 경우에는, 인터프리트된 결과로 만들어진 프로그램이 바인딩을 통해서 라이브러리와 링크될 것입니다. 만약 라이브러리가 GPL로 공표된 것이었다면, 인터프리트 되어 만들어진 프로그램은 GPL과 호환되는 형태로 공표되어야 합니다. 이러한 예로 JNI와 자바 네이티브 인터페이스를 들 수 있습니다. 이러한 방법으로 접근되는 라이브러리들은 이들을 호출하는 자바 프로그램과 다이나믹하게 링크됩니다.

또하나의 일반적인 사례는 인터프리터와 이 인터프리터를 사용해서 인터프리트된 라이브러리들이 함께 제공되는 경우입니다. 예를 들면, Perl 인터프리터는 많은 종류의 Perl 모듈들과 함께 제공되고 자바 구현물에는 많은 양의 자바 클래스들이 함께 제공됩니다. 이러한 경우에는 라이브러리와 라이브러리를 호출하는 프로그램이 항상 다이나믹하게 링크되어 함께 사용됩니다.

결과적으로 GPL로 공표된 Perl 모듈이나 자바 클래스를 여러분이 만든 프로그램에 포함시키기로 결정했다면 결합된 Perl이나 자바 프로그램이 실행될 인터프리터들의 라이선스에 상관없이, 여러분의 프로그램은 GPL과 호환되는 방식으로 공표되어야만 합니다.

    프로그램(또는 2차적 프로그램)을 양도할 때는 피양도자의 권리를 제한할 수 
    있는 어떠한 사항도 별항으로 추가할 수 없습니다.

홍보에 대한 부분은 별도의 제한 사항이라고 볼 수 있기 때문에 GPL 호환된다고 볼 수 없습니다. 그러나 개정된 BSD 라이선스에서는 문제의 소지가 되는 구문이 삭제되었습니다.

하지만, 만약 프로그램이 플러그인과 다이나믹하게 링크되는 형식으로 실행되어 서로 함수를 호출하고 자료 구조를 공유하게 된다면 이는 하나의 프로그램을 형성하게 된다고 볼 수 있으므로 플러그인은 메인 프로그램이 확장된 것으로 간주되어야 합니다. 이것은 플러그인에도 GPL이나 GPL과 호환되는 라이선스를 적용해야 한다는 것을 의미합니다.

만약 프로그램이 플러그인과 다이나믹하게 링크되는 형태이지만, 프로그램이 프러그인의 메인 함수를 몇가지 옵션과 함께 호출하고 여기에 대한 리턴값을 기다리는 형태로 만들어 졌다면, 매우 판단하기 어려운 경우가 됩니다.

하지만, 만약 프로그램이 플러그인과 다이나믹하게 링크되는 형식으로 실행되어 서로 함수를 호출하고 자료 구조를 공유하게 된다면 이는 하나의 프로그램을 형성하게 된다고 볼 수 있으므로 플로그인은 메인 프로그램이 확장된 것으로 간주되어야 합니다. 이것은 GPL이 적용된 플러그인을 메인 프로그래과 함께 사용하는 것이 GPL 위반이 된다는 것을 의미합니다. 그러나 이러한 법률적 문제는 여러분이 만든 플러그인의 라이선스에 자유 소프트웨어가 아닌 프로그램과 링크하는 것을 허용하다는 예외 규정을 추가하는 것으로 해결할 수 있습니다.

보다 구체적인 사항에 대해서는 ``자유 소프트웨어가 아닌 라이브러리를 사용하는 자유 소프트웨어의 개발''과 관련된 질문 부분을 참고하시기 바랍니다.

여러분은 언제든지 우리가 만든 코드를 사용하지 않는 선택을 할 수 있습니다.

• 소프트웨어가 작동하기 위해서 FOO라는 라이브러리와 링크되어야 합니다. FOO의 라이선스는 Lesser GPL입니다.
• 제 프로그램은 BAR 프로그램을 실행하기 위해서 시스템 콜을 수행하는데 BAR 프로그램은 QUUX와 링크하는 것을 허용한다는 예외 조항이 추가된 GPL 프로그램입니다.

두개의 모듈을 결합한다는 것은 이들이 보다 큰 하나의 프로그램을 구성하기 위해서 함께 연결된다는 뜻입니다. 이 경우 어느 한쪽이라도 GPL 프로그램이면, 결합된 전체 프로그램 또한 GPL로 공표되어야 합니다. 그렇게 하기 싫다면 프로그램들을 결합하지 않으면 됩니다.

두개의 부분이 결합되어 하나의 프로그램을 구성하고 있는지 아닌지의 여부를 어떻게 결정할 것인가라는 문제는 궁극적으로 판사들이 결정해야 할 법률적인 문제입니다. 그러나 우리는 적정한 기준이 exec와 파이프, rpc, 공유 어드레스 안에서의 함수 호출 등과 같은 통신 매커니즘과 어떤 종류의 정보가 교환되는가 하는 통신상의 내용에 달려있다고 믿고 있습니다.

만약 모듈들이 특정한 실행 파일 안에 함께 포함되어 있다면 이것은 명확히 하나의 프로그램으로 결합되어 있는 것입니다. 만약 모듈들이 공유된 어드레스 공간 안에서 링크되어 실행되도록 설계되어 있다면 이또한 거의 확실히 하나의 프로그램으로 결합되어 있는 것으로 볼 수 있습니다.

이와 대조적으로 파이프와 소켓, 명령행 인자 등은 두개의 독립된 프로그램간의 통신을 위해서 사용되는 매커니즘입니다. 따라서 모듈들이 이러한 형식을 사용한다면 모듈들은 독립된 프로그램으로 볼 수 있습니다. 그러나 통신의 내용과 의미를 충분히 깊게 고려해 볼 때, 복잡한 내부 자료 구조를 교환하는 것 또한 두 개의 부분이 보다 큰 하나의 프로그램을 구성하는 것으로 볼 수 있을 것입니다.

또한 우리는 각각의 기여자들에게 그들의 고용자들이 저작권을 주장할 수 없도록 저작권 포기에 동의한다는 약속을 받도록 요청하고 있습니다.

물론, 모든 기여자들이 그들의 프로그램을 공개 프로그램으로 만들어서 저작권을 포기한다면 GPL을 강제할 수 있는 저작권 자체가 없어지는 것과 같습니다. 그래서 우리는 많은 양의 코드에 대해서는 저작권을 설정하고, 오직 짧은 수정에 대한 부분만을 공개 프로그램으로 만들도록 사람들에게 말하고 있습니다.

만약 여러분이 만든 GPL 프로그램에 대해서 법적 대응을 할 수 있도록 하고 싶다면 이같은 방법을 따르는 것이 좋은 선택입니다. 보다 구체적인 사항에 대해서 알고 싶을 경우에는 <licensing@gnu.org> 앞으로 영문 메일을 보내 주시기 바랍니다.

이러한 사항은 여러분의 프로그램에 GPL 코드를 포함시키기 위해서 충족되어야 할 요구 조건입니다.

그러나 교과서나 매뉴얼과 같이 교육을 위한 자료들에는 GPL보다 GFDL을 사용할 것을 추천합니다.

GPL 프로그램이 통합된 시스템은, GPL 프로그램이 확장된 것이라고 할 수 있습니다. GPL은 GPL 프로그램을 확장한 버전을 공표할 때 그 라이선스로 GPL을 사용해야 한다고 규정하고 있습니다. 여기에는 두가지 이유가 있습니다. 첫번째는 소프트웨어를 취득한 사용자로 하여금 그들이 가질 수 있는 자유를 알게 하려는 것이고, 두번째는 그들이 만든 개선점들을 공동체로 환원하도록 격려하기 위한 것입니다.

그러나 많은 경우에 있어서, GPL 소프트웨어를 독점 시스템과 함께 배포할 수 있습니다. 이것이 가능하기 위해서는 GPL 프로그램과 그렇지 않은 프로그램들이 서로 결합되어 하나의 프로그램으로 작동하는 형태가 아니라 서로 독립적으로 실행되거나 통신하는 형태가 되어야만 합니다.

GPL 소프트웨어가 독점 시스템에 통합된 형태인지 아니면 서로 독립적으로 작동하는 형태인지에 대한 구별은 실제적인 측면과 형식적인 측면으로 구분해서 생각해 볼 수 있습니다. 실제적인 측면에서 볼 때, 두개의 프로그램이 하나의 프로그램을 구성하는 두개의 부분으로 기능하면서 결합되는 경우에는, 두개의 프로그램을 별도의 프로그램으로 취급할 수 없기 때문에 프로그램 모두가 GPL로 취급되어야 합니다. 만약 두개의 프로그램이 커널과 컴파일러(또는 쉘, 에디터)의 경우과 같이 분리된 상태를 유지하면서 원래의 기능을 충분히 수행할 수 있다면 각각의 프로그램들을 별도의 프로그램으로 취급할 수 있습니다.

문제가 되는 것은 GPL 소프트웨어가 포함된 시스템을 배포할 때, 사용자들에게 배포 형식을 어떻게 설명할 것인가 하는 형식적인 측면입니다. 우리가 이러한 부분에 관심을 갖고 있는 것은 집합물에 포함되어 있는 GPL 소프트웨어의 상태를 사용자들이 명확하게 인식하게 되기를 원하기 때문입니다.

만약 시스템의 일부가 독점 소프트웨어라는 사실을 알고 있는 사용자들에게, GPL 소프트웨어가 시스템의 일부로 포함되어 있다고 말하면서 시스템을 배포하게 된다면 사용자들은 GPL 소프트웨어에 대해서 갖게 될 그들의 권리를 확실히 알지 못하게 될 수 있습니다. 그러나 그들이 받은 것이 자유 소프트웨어인데, 여기에 덧붙여서 다른 프로그램들도 함께 받은 것이라는 식의 설명을 전달받을 수 있다면, 그들의 권리는 명확해 질 수 있을 것입니다.

먼저, 일반적인 이유 때문입니다. 만약 A라는 회사가 독점 파일을 만들 수 있도록 허용한다면 B라는 회사에서 그 독점 파일과 링크되는 GPL 소프트웨어를 배포하게 될 수 있는데, 이것은 GPL을 존패 가능성을 위협하기에 충분한 것입니다. 이것은 GPL 소프트웨어의 소스 코드에 대한 모든 종류의 개작과 확장을 억제하는 백지 수표나 다름없습니다.

모든 사용자들이 소스 코드에 접근할 수 있도록 하려는 것이 우리의 목표이기 때문에 우리는 그러한 형태를 허용할 경우에 나타날 결과를 막고자 합니다.

좀더 구체적으로 말한다면, 돈벌레 주식회사의 라이브러리와 링크된 프로그램은 우리가 정의하고 있는 범위 안에서 볼 때, 자유 소프트웨어가 아닙니다. 이 라이브러리는 사용자들이 프로그램을 수정하고 다시 컴파일 하기 위한 소스 코드를 모두 제공하고 있지 않기 때문입니다.

사용자가 소스 코드를 원할 때에는 언제든지 사용자에게 소스 코드를 제공해야 합니다. 만약 특정한 사용자가 익명 FTP를 이용해서 소스 코드를 받을 수 있는 상황이라면 FTP를 이용한 소스 코드의 제공이 서로에게 편리하겠지만, 모든 사람이 네트워크를 사용할 수 있는 것은 아닙니다. 네트워크를 사용할 수 없는 사용자들도 소스 코드를 제공받을 똑같은 권리를 갖고 있습니다. 따라서 소스 코드를 원하는 사용자로부터 서면 요청이 도착한다면 디스크나 테이프 등의 저장 매체에 소스 코드를 담아서 보내주어야만 합니다.

물론, 가장 간단한 방법은 바이너리를 배포할 때 소스 코드를 함께 배포하는 것입니다.

그러나 다른 사이트 어딘가에서 소스 코드를 구할 수 있다고 해서 사람들에게 ``XX 사이트를 참고하라.''고 말하는 것은 충분하지 않다는 것에 주의하기 바랍니다. 그 사이트에서 해당 소스 코드가 내일 삭제될 수도 있으며 동일한 프로그램이라고 하더라도 업그레이드 된 다른 버전의 소스 코드로 대체될 수도 있기 때문입니다. 이 경우 GPL을 만족시키고 있다고 할 수 없습니다. 따라서 소스 코드가 있는 사이트와의 협의를 통해서 바이너리가 제공되는 동안 해당 바이너리에 대한 소스 코드가 함께 제공될 수 있도록 해야만 GPL을 충족시키는 것이 됩니다.

자유 소프트웨어의 개념 중 하나는 사용자이 *그들이 사용하고 있는 프로그램*의 소스 코드를 이용할 수 있어야 한다는 것입니다.

GPL의 주된 목적은 자유 프로그램이 향상되더라도 그 또한 자유 프로그램이 되도록 확실히 보장함으로써 자유 세계를 만드는 것입니다. 만약 GPL 프로그램을 향상시킨 버전을 공표할 경우에는 향상된 버전의 소스 코드 또한 GPL로 공표해야만 합니다.

사용자가 지금으로 부터 1년 후에 소스 코드를 필요로 한다면, FSF로 부터 원하는 버전의 소스 코드를 얻을 수 없을 지도 모릅니다. 우리가 새로운 버전의 소스 코드를 제공하게 되면 사용자들은 diff 파일로 올바른 작업을 할 수 없게 될 것입니다.

따라서 diff 파일이 아닌 완전한 소스 코드 전체를 바이너리와 함께 제공할 필요가 있습니다.

따라서 만약 여러분이 익명 FTP를 통해서 바이너리를 배포하고자 한다면 서명 약정서를 제공할 수 없을 것이므로 소스 코드를 FTP로 함께 제공해야 합니다. 이것은 어려운 일이 아닙니다. 만약 여러분이 프로그램을 배포할 사이트를 찾으려고 한다면, 소스 코드를 함께 제공할 수 있는 충분한 여유를 가진 사이트를 찾아야 할 것입니다.

이러한 경우에는 배포되고 있는 바이너리에 해당하는 소스 코드를 제공해야 하며, 특히 이전 버전이나 최신 버전의 소스 코드가 아닌 바이너리를 만드는데 사용된 동일한 버전의 소스 코드를 제공해야 합니다.

바이너리와 소스 코드의 배포는 상호간의 연결 및 접근이 용이하게 이루어 지는 한, 다른 머신상에서 이루어지는 것이 허용되며 이 경우, 바이너리의 다운로드 정보 근처에 해당 소스 코드를 구할 수 있는 방법을 명시해야 합니다.

배포자들에게 부과된 GPL 규정은 사용자들에게 소스 코드를 구할 수 있는 방법을 확실히 명시하도록 하기 위한 것이지, 사용자들이 원하지 않는데도 불구하고 소스 코드를 다운받도록 강제하기 위한 것이 아닙니다.

그러나 때에 따라서 작전상 후퇴는 좋은 전략이 될 수 있습니다. 때때로 라이브러리에 LGPL을 사용하게 되면 라이브러리의 사용 범위를 확대할 수 있기 때문에 보다 많은 향상을 가져올 수 있으며, 자유 소프트웨어에 대한 지원의 폭을 넓힐 수 있는 등의 긍정적인 결과를 유도할 수 있습니다. 이러한 일이 충분히 많이 이루어 질 경우에는 자유 소프트웨어를 위해서 좋은 일이 될 수 있습니다. 그러나 이러한 일이 얼마나 많이 일어날 수 있을까요? 그러한 상황에서는 단지 일이 좋게 되기를 바랄 수밖에 없습니다.

라이브러리에 대해서 LGPL이 도움이 되는지 잠정적으로 시험해 보기 위해서 LGPL을 사용한 뒤에, 도움이 되지 않을 경우에는 GPL로 라이선스를 변경하는 것이 좋은 방법인 것처럼 보일 수도 있습니다. 그러나 실제로 그것은 좋은 방법이 아닙니다. 일단 특정한 라이브러리에 LGPL을 적용한 뒤에는, 라이선스를 변경하는 것이 무척이나 힘들게 됩니다.

라이브러리 별로 어떤 라이선스를 사용했는 지에 대한 우리의 결정에 대해서는 보다 자세한 문서를 통해서 참고할 수 있습니다.

우리의 목표는 사용자의 수를 최대한 많이 늘리는 것이 아닙니다. 우리의 목표는 가능한 많은 사람들에게 확실한 자유를 주는 것입니다. 일반적으로 독점 소프트웨어 프로젝트는 자유의 향상을 돕기보다 이를 감소시킵니다.

GPL이 아닌 라이선스를 사용하지만, 자유 소프트웨어를 만들기 위한 프로젝트일 경우에는, 이를 지원하기 위해서 때때로 예외 규정을 만들기도 합니다. 그러나 이것은 그렇게 하는 것이 자유 소프트웨어의 향상에 도움이 되는 것이 분명할 때만 가능합니다.

또한 우리는 때때로 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에는 매뉴얼이나 서적에는 해당되지 않고 프로그램에만 적용될 수 있는 많은 조항들이 포함되어 있습니다. 이에 반해서 GFDL에는 자유 매뉴얼의 발행자들에게 이익을 주기 위한 조항들이 포함되어 있습니다.

GFDL을 따르는 저작물들은, 기술적인 부분을 다루는 내용에 대한 개작이 허용됩니다. 그러나 우리가 갖고 있는 정치, 윤리, 법률적 견해에 대한 언급이 포함된 부분에 대한 수정은 허용되지 않습니다. 이러한 형태는 저작권 표시 부분에 개작할 수 없는 부분을 명시해 놓는 형태를 통해서 이루어 지는데, GPL에서는 이러한 사항이 허용되지 않지만 GFDL에서는 ``변경 불가 부분''(invariant section)이라는 규정을 통해서 이것이 가능합니다.

기술적인 내용이 포함된 부분에 대한 수정을 허용하는 것은 매우 중요한데, 그 이유는 프로그램을 개작하는 사람은 자신이 개작한 부분에 해당하는 문서의 설명도 수정할 수 있어야 하기 때문입니다. 프로그램을 수정하면 문서도 함께 수정해야 한다는 것을 강요할 수는 없지만 그렇게 되기를 바란다면, 그들의 길을 방해해서는 안될 것입니다.

법률 문서는 몇몇 측면에 있어서 프로그램과 유사합니다. 따라서 법률 문서를 번역하는 것은 프로그램을 하나의 언어와 운영체제에서 다른 것으로 번역하는 것과 같습니다. 오직 두가지 언어에 능숙한 변호사만이 이 일을 할 수 있으며, 이 경우에도 버그가 포함될 위험이 있습니다.

만약 우리가 GPL 번역문을 공식적으로 승인하게 되면, GPL 원문 뿐 아니라 번역문들이 규정하고 있는 모든 사항들도 인정해야만 합니다. 만약 완벽한 번역이 이루어 졌다면 문제될 것이 없겠지만, 만의 하나 그렇지 못하다면 그 결과는 우리가 바로잡을 수 없는 치명적인 것이 될 수 있습니다.

프로그램에 버그가 포함되어 있을 경우에는 오류를 바로잡은 새로운 버전을 만들면 되고, 결과적으로 이전 버전을 사용하지 않게 될 것 입니다. 그러나 만약 우리가 특정한 번역문에 따른 권리를 인정해 주게 되면 버그라고 판단되어도 나중에 이를 돌이킬 수 있는 방법이 없습니다.

우리를 도와주려고 하는 사람들이 때때로 번역 작업을 해 주겠다는 제안을 해 오기도 합니다. 번역할 사람이 필요하다는 것이 문제였다면, 문제는 해결된 것입니다. 그러나 실제적인 문제의 핵심은 오류가 발생할 위험성이라는 부분이며, 번역을 해 주겠다는 제안은 이러한 위험성을 없앨 수 없습니다. 우리는 변호사가 아닌 사람이 번역한 문서들을 공식적으로 승인할 수 없습니다.

따라서 당분간 우리는 국제적으로 유효한 GPL 번역문을 공식적으로 승인하지 않을 것입니다. 그대신 다음과 같은 2가지 방법을 사용하고 있습니다.

• 비공식 번역문을 소개합니다.

  이것은 GPL을 번역하는 것을 허용하지만, 법적으로 유효한 것으로 승인하지는 않는다는 것을 의미합니다. 비공식 번역문은 법적인 효력이 없습니다. 따라서 번역문에는 다음과 같은 사항이 명시되어 있습니다.

      이 번역문은 자유 소프트웨어 재단이 승인한 공식 문서가 아닙니다.
      GPL을 실무에 적용할 경우, 오직 영문판 GPL에 의해서만 법률적 
      효력이 유효할 수 있다는 점에 유의하시기 바랍니다 
  

  그러나 비공식 번역문은 GPL이 의도하는 것이 무엇인가를 알리는데 도움이 될 수 있으며, 대부분의 사용자들에게는 그것만으로도 충분합니다.

  그러나 상업적 목적을 위해서 GNU 소프트웨어를 사업에 이용하거나 공개 FTP를 이용해서 배포할 경우에는 GPL의 규정을 명확히 하기 위해서 영문판 GPL을 반드시 검토해야 합니다.

• 번역문을 출판하는 것은 한 국가에 대해서만 유효합니다.

  출판된 번역문은 그 국가에서만 유효한 것으로 간주합니다. 이러한 방법을 통해서 번역문에 오류가 있다고 하더라도 그 피해를 최소화 시킬 수 있습니다.

  그러나 이러한 번역문이 만들어 지기 위해서는 동조적이고 능력있는 변호사들의 상당한 노력과 전문 지식이 필요합니다. 따라서 우리는 이러한 번역문이 조만간 만들어 질 수 있으리라는 약속을 쉽게 할 수 없습니다.

그러나 인터프리터가 라이브러리와 같은 다른 요소와의 바인딩을 제공하도록 확장된 경우에는, 인터프리트된 프로그램은 바인딩 과정에서 사용된 요소와 사실상 링크된 것이라고 할 수 있습니다. 이러한 예로 JNI와 자바 네이티브 인터페이스를 들 수 있습니다. 이러한 방식으로 접근되는 라이브러리들은 자바 프로그램이 이들을 호출할 때, 다이나믹하게 링크됩니다.

따라서 만약 이러한 요소들이 GPL과 호환되지 않는 라이선스로 공표되어 있다면, 이것은 GPL과 호환되지 않는 라이브러리와 링크하는 것과 같은 상황이 됩니다. 이것은 다음과 같이 해야 한다는 것을 의미합니다.

1. GPL로 프로그램을 작성해서 공표할 경우에는 GPL과 호환되지 않는 저작물과 링크하는 것을 허용한다는 예외 규정을 명시적으로 포함시킵니다.

2. GPL과 호환되지 않는 저작물과 함께 작동하도록 만든 코드를 GPL로 공표할 경우, 사람들은 이를 GPL과 호환되지 않는 저작물과 함께 사용할 수 있다는 묵시적인 허용으로 간주할 수 있습니다. 만약 이것이 의도하는 것이라면 그러한 사항을 명시적으로 언급하는 것이 좋습니다.

3. 다른 사람의 GPL 코드는 이런 방법으로 링크해서 사용할 수 없고 예외를 설정할 수도 없습니다. 오직 해당 코드의 저작권자만이 예외 규정을 추가할 수 있습니다.

어떤 라이브러리들은 GNU GPL만을 사용해서 공표되는데, 이러한 라이브러리를 사용하기 위해서는 라이브러리를 사용한 저작물 전체에 GPL 호환 라이선스가 적용되어야 합니다. 그러나 일반적으로 다른 플랫폼에서 사용할 수 있는 대용물이 거의 없는 특별한 라이브러들이 많이 존재하기 때문에 간단한 포팅 작업에 이러한 라이브러리를 사용하고 싶지는 않을 것입니다.

만약 여러분이 만든 프로그램이 자유 소프트웨어가 아니라면, 우리 공동체에 대한 기여가 아니며 자유의 가치를 소중하게 생각하는 사람들은 그 프로그램을 사용하지 않을 것입니다. 따라서 그러한 프로그램은 결과적으로 사람들로 하여금 그들의 자유를 포기하게끔 유혹하는 역할을 하게 되어, 오직 자유를 포기한 사람들게만 유용하게 될 것입니다. 먼훗날, 여러분이 걸어온 길을 되돌아 보았을 때 지금까지 한일이 단순히 돈을 벌기 위한 것 이상이었다는 느낌을 갖고 싶다면 여러분이 만든 소프트웨어를 자유 소프트웨어로 만들어야 합니다.

GPL이 규정하고 있는 것은 그가 원한다면 다른 사람에게 복제물을 배포할 자유를 가져야 한다는 것입니다. 일단 저작권자가 프로그램을 배포한 뒤에는, 복재물을 받은 사람은 그가 원하는 누구에게도 프로그램을 재배포할 수 있습니다.

[ 영어 | 이탈리아어 | 포르투갈어 | 폴란드어 | 프랑스어 | 한국어 ]

자유 소프트웨어 재단과 GNU 프로젝트에 대한 질문은 gnu@gnu.org로 보내 주시기 바랍니다.

GNU에 대한 질문 이외에 홈페이지 자체에 대한 질문은 webmasters@gnu.org로 보내 주시고, 그밖의 연락 방법에 대해서는 연락처 안내 부분을 참고하시기 바랍니다.

Copyright (C) 2001 Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA

저작권에 대한 본 사항이 명시되는 한, 어떠한 정보 매체에 의한 본문의 전재나 발췌도 무상으로 허용됩니다.

한국어 번역: 2001년 9월 19일 송창훈 >chsong@gnu.org>

최근 수정일: 2002년 1월 25일 chsong