LazarusLicense
- lazarus license관련번역
번역진행
이화영 (Hwa Young Lee)
License 번역문
사용과 관련된 라이센싱
프리 파스칼 라이센싱은 비교적 자유로운데 여기에는 LGPL/GPL 라이센싱과 관련한 실용적인 문제와 사람들의 우려를 피하기 위한 몇 가지 추가 조항들도 포함된다. 주요 차이점이라면, 공유된 연결만 허용하는 LGPL뿐 아니라 FPC 런타임 라이브러리로의 정적 연결을 허용한다는 점이다. 런타임 라이브러리에선 그러한 예외조항을 만드는 경우가 꽤 흔하다 [GPL with linking exception]. LGPL은 공유된 오브젝트의 연결을 목표로 한다는 점에서 예외에 속하는데, FPC 수정은 한 걸음 더 나아가 정적 연결까지 허용한다.
기본 라이센싱 원칙은 FPC와 그 라이브러리는 책임을 지는 방식으로 사용이 가능해야 한다고 규정한다. 즉, 최종 사용자로 연결되는 모든 것은 라이센스를 혼란스럽게 만드는 추가 조항들이 없이 전형적인 상용 프로그램에서 사용 가능해야 함을 의미한다. 이는 정적 연결에 관한 이중 해석 또는 의혹을 제거한 추가 조항들과 함께 LGPL 라이센스를 선택함으로써 실현된다. 이렇게 결합된 라이센스는 (LGPL 공식 문서+추가 FPC의 명확화) 보통 “FPC modified LGPL”이라 부르며, 다음을 조건으로 한다:
특별 예외사항으로, 해당 라이브러리의 저작권 소유자들은 당신에게 독립적 모듈과 관련된 라이센스와 상관 없이 그 모듈로 해당 라이브러리를 연결할 수 있도록 허용하는 바이다. [...]
위의 조항은 주로 LGPL에서 "공유된 연결만" 과 "리버스 엔지니어링(reverse engineering)" 조항에 대한 (정당화되기까지한) 불확실성을 피하기 위함이다.
라자루스 또한 동일한 기본 원칙을 따른다.
FPC (컴파일러/IDE/라자루스 프로그램) 자체와 관련된 라이센싱
End binary는 대부분 GPL이다. 하지만 GPL 프로그램으로 만든 제품들이 자동으로 GPL 대상이 되는 것은 아니기 때문에 코어 컴파일러 바이너리 자체를 수정하거나 통합할 때만 적용된다 (정적 연결).
GPL의 실제 의미와 관련해 많은 오해가 있으므로 궁금하면 직접 질문하길 바란다! FPC는 종종 교육용 프로그래밍 프로젝트에서 백엔드 컴파일러로서 사용되기 때문에 필자는 그 환경에 대해 많이 알려진 소문들이 틀렸음을 증명하고자 한다:
- 내부 스크립팅을 위해 필자의 애플리케이션과 함께 FPC를 배포할 경우, 필자는 FPC 소스 또한 패키지해야 할 것이다. (일부 저작권 부록에선 FPC 사이트에 실은 링크로 충분하지만 최소 3년간은 소스를 개인적으로 보관해야 한다. 아래 절을 참고하라.)
- FPC를 수정하여 필자의 애플리케이션과 함께 배포할 경우 (연결되지는 않은), 필자의 애플리케이션을 오픈소스로 해야 한다. (애플리케이션을 GPLed 코드로 연결 시에만 해당. 패키지할 경우, 사이트나 배포 매체에 수정하는 것만으로 (또는 더 나은 수정된 소스) 충분하다.)
- GPL 코드로 연결 시, 필자는 나만의 소스를 개방해야 한다. (단, 배포시에만 개방한다. 라자루스 라이센싱 절을 참고한다.) FPC는 보통 GPL 코드로의 연결할 필요가 없도록 설치된다.
요약하자면, GPL은 사용자가 core FPC end-binary를 자신의 애플리케이션으로 통합할 때에만 적용되고, 단순한 호출 시에는 적용되지 않는다. 한 가지 만족스럽지 못한 점이 있는데, 이는 라자루스 라이센싱 관련 절을 참고한다.
(참고: 엄격히 말하자면 GPL은 "비용을 부담하는 명목상 요금"을 지불하는 구매자의 요청 시 소스를 제공해야 한다고 명시하지만, 작업(work) 또한 비용에 속하므로 사용자는 작업에 대한 상업적 시간급을 기반으로, 사례별 최대 25-50 유로까지 부과할 수 있다. 사실상 이러한 방안이 문제가 되지 않는 이유는 어차피 모든 사람이 다운로드할 것이며 특혜를 위해 실제로 금액을 지불할 이는 소수에 불과하기 때문이다.)
GPL 관련 소스 보유
GPL에 따라 무언가를 배포할 때는 GPLed part의 (당신과 제3자의 parts) 완전한 소스를 3년간 보관하여 소스 요청을 충족시켜야 한다 (가능성은 희박하지만, 명목상 요금을 부과하여).
보통 라자루스 애플리케이션에서는 이런 일이 불가능하다는 사실을 명심해야 한다. 이보다는 구분된 상용 라이센스 요구조건 없이 mysql(클라이언트)를 사용하는 편이 더 현실적이다.
- 일반적으로 실용적인 라이센싱 리소스인 http://www.softwarefreedom.org/resources/2008/compliance-guide.html에서 4.1.2절을 참고한다.
MPL 문제
GNU에 따르면 MPL은 GLP 호환이 불가한데 세부적인 내용은 설명하기가 힘들다 (사실 필자도 이해 못하긴 매한가지다). 그리고 이의 사실 여부는 중요하지 않다. 단, 최소한 한 군데의 라이센스 관리 위원회에서 이를 명확하게 설명하고 입장을 확고히 할 때까지는 이러한 불확실성으로 인해 MPL-GPL 조합은 거슬릴 수 밖에 없다.
Jedi와 그에 따라다니는 CD에 대한 Borland의 선택으로 인해 델파이 세계의 오픈 소스 컴포넌트 대다수는 MPL인 반면 FPC 프로젝트는 GPL에 해당하는 endbinary를 여러 개 사용하기 때문에 큰 문제가 된다. FPC 측면에 대한 라이센스 재취득이 힘든 것은 프로젝트가 만들어진지 이미 14년 이상이 되어 수많은 기여자들이 있기 때문이다. 다행히 일부 사례에선 라이센스 재취득을 모면할 방법이 있는데, 바로 MPL이 LGPL-MPL의 이중 라이센스를 위한 조항을 효과적인 라이센스 문서에 명시적으로 언급하여 제공하는 방법이다 (광범위하게 라이센싱을 변경하기보단 GNU를 충족시키기 위한 절차상 문제에 가깝지만).
라이센스 텍스트와 웹에서 수집한 결과, MPL-LGPL 차이는 그 내용보다는 관점과 단어 선택, 즉 오픈 소스 사상(GNU)과 기업 관련 법률 용어(MPL)의 차이였다. 하지만 어떠한 라이센싱이든 아무리 세부 조항이라 하더라도 사용자는 모든 주요 기여자들로부터 승인을 받아야 한다.
자신의 MPL 프로젝트와 모든 기여자들 사이에 아직 연락을 하고 있다면 MPL 이중 라이센스에 따라 그들에게 라이센스 갱신 허락을 요청할 수 있다. 과거에는 Jedi APILib와 Jedi SDL이 해당 작업을 맡았으며 (현재 FPC 배포의 일부) Jedi Math 프로젝트는 현재 그 작업을 완료하였다 (JediMath는 이후에 FPC 배포판에 포함될 것이다). Jedi JCL는 그에 관한 토론을 가졌고, 기여자들 간 결속력이 좋아 선택권이 있었지만 최종 결과가 어찌되었는지는 기억할 수가 없다. 아마도 대규모로 된 외부 기부를 자주 받으면서 더 복잡해졌을 것이다.
간략한 내용은 다음 링크를 참조한다: http://www.tomhull.com/ocston/docs/mozgpl.html
라자루스와 관련된 MPL 문제
라자루스의 라이센싱은 FPC 자체와 꽤 동일하다. 라이브러리는 modified LGPL으로, 환경 자체가 GPL이다. 하지만 설계 시 라이브러리는 라자루스로 연결되어 GPL가 적용되도록 만든다. 라자루스 팀은 GPL의 정당한 사용 권리를 지적하여 이러한 상황을 완화시킨다. 이러한 GPL의 권리는 당신이 결과물을 배포하기 전까지는 시행되지 않는다. 하지만 GPL 라이센스 의미에서 결과물/산물은 라자루스로 생성한 애플리케이션 바이너리가 아니라 플러그인된 컴포넌트가 있는 라자루스 바이너리이다. 애플리케이션 바이너리 자체는 사용자가 실제로 연계하는 컴포넌트에 의해서만 제한되며, FPC/라자루스 프로젝트에서 그것은 모두 LGPL_with_exception(예외가 적용된 LGPL)를 따른다.
따라서 이 라이센싱은 잠재적으로 혼동될 가능성은 있지만 라자루스로 바이너리를 만들 때는 문제가 되지 않으며, 디자인 시 part가 있는 상용 컴포넌트라 하더라도 마찬가지다. 결과물을 배포할 때 소스만 개방하면 되기 때문이다 (사전 설치된 컴포넌트가 있는 iow 라자루스).
하지만 여기에도 한 가지 부작용은 있다. 만일 컴포넌트를 미리 설치하여 라자루스를 배포할 경우 GPL 호환이 되어야 한다. 컴포넌트 판매업자를 예로 들자면, 그들은 컴포넌트가 설치된 라자루스를 제공하거나 MPI-only Jedi 컴포넌트가 사전에 설치된 라자루스 디스트로(distro)를 생성하는 것이 불가능해진다는 점이다.
참고: 여론과 달리 디자인 시점에서 패키지가 패키지 시스템을 이용해 동적으로 로딩될 때에도 위의 상황은 전혀 바뀌지 않는다. 연결된 폼 전체는 여전히 GPL 관점에서 "큰 작업(larger work)"에 속한다.
제3자 상용 플러그인
최근 필자는 위의 라자루스와 관련된 MPL 문제 절의 내용이 제3자 플러그인에도 적용됨을 지적한 바 있다.
FPC와 관련된 MPL 문제
MPL 문제는 보통 프리 파스칼로 생성된 프로그램이 아니라 (생성된 프로그램이 GPL인 경우는 제외) 공식 FPC 발매 배포판에만 영향을 미치는데, 정상 작동을 위해 컴파일러의 GPL 코드로 어떠한 연계도 필요로 하지 않기 때문이다.
우리는 사용자들의 이익을 위해 FPC 배포판 라이센싱을 어느 정도 균일하게 유지하길 바란다. 즉,
- LGPL-modified 라이브러리, 또는 완전히 호환 가능한 것 (예: (modified/modern) BSD license), 그리고
- enduser binaries, GPL, LGPL, BSD 또는 PD용. 일반적으로 GPL 와 호환이 되는 무료로 된 모든 것 (FSF 혹은 일반 방식).
- 빌드 스크립트, Makefiles 과 같은 유형은 대부분 필요 없는 툴로 간주되며, 그 라이센싱은 보통 명시적으로 제재하지 않는다.
해당 정책의 결과는 현재 core FPC 배포판에 엄격한 MPL 라이브러리를 추가하지 못하도록 되어 있다. 몇몇 프로젝트들은 이를 피하기 위해 (Jedi’s Apilib, -Math, -SDL) 그들의 상품을 LGPL-modified로 이중 라이센스를 취득하여 추가되었는데, 이 점을 매우 감사하게 생각한다. 일부 제3자 컴포넌트 배포자들은 (VirtualStringTree와 같은) 묻지도 않고 변경한 것으로 보이는데, 라자루스에서 곧 찾아볼 수 있기를 바랄 뿐이다.
다른 일부 프로젝트들은 (예: destructor.de’s libtar) 일관성을 위해 고유의 디자인에 대한 본래 라이센스를 취소하고 GPL/LGPL 호환 라이센스에 따라 그들의 소스에 대해 다시 라이센스를 취득하였다. 필자들이 급하게 필요로 했던 패키지이기 때문에 그에겐 평생 고마운 마음을 가질 수 밖에 없다.
패키지를 일반 FPC 또는 라자루스 배포판에 포함하는 일은 단순히 패키지를 통제하는 FPC 코어만 의미하는 것은 아님을 명심한다. 이는 (최신 FPC 배포판과 패키지의) 더 명확하고 동시적인 버전화(versioning)와 용이성을 위해 실행될 뿐이다. 또한 FPC 특정적인 빌드 과정의 배포 기술(release engineering)을 FPC로 이동시켜 프로젝트가 델파이 배포 기술에 초점을 두도록 허용한다. 일반적으로 FPC 저장소 내 이러한 디렉터리들은 다중 라이센스로 간주되어, 그에 수락된 모든 수정사항 (fix) 또한 다중 라이센스로 간주된다. (Jedi winapi에 대한 낮은 수준의 기여는 MPLed로 간주할 수 있으므로 패키지의 원 저작자들은 다시 합칠 수 있다)
또한 제3자 그룹은 라이센스들이 서로 호환되는 한 라이센스들의 모음인 커스텀 FPC 배포판을 생성할 수 있다. 공식 배포판의 GPL/LGPL 호환성은 주요 배포판의 라이센스의 일관성을 위해서만 시행된다.
FPC/라자루스 배포판에 포함된 이중 라이센스 패키지
앞서 언급하였듯 SDL과 같은 일부 패키지들은 원 저작자들이 이중 라이센스를 가지고 있으며, 우리는 그 점을 존중하는 바이다. 원 저작자에게 수정사항(fix)을 전달하기 위해서는 비슷하게 이중 라이센스를 취득한 기여(contribution)만 수락할 것이다.
License Faq licnse관련 번역문
라이센싱
라자루스를 이용해 상용 애플리케이션을 만들 수 있는가?
만들 수 있다. LCL는 예외가 적용된 LGPL을 따르며, 애플리케이션의 소스를 발매할 필요 없이 정적으로 연결하도록 허용한다. LCL의 수정 및 개선사항은 소스와 함께 배포되어야 한다. 라자루스 IDE는 GPL에 따른 사용을 허가한다. LCL은 디렉터리에서 "lcl" 이라는 이름의 코드로만 구성되고, 그 외 다른 코드는 해당 문서에서 다루지 않는다.
상업용 애플리케이션에서 일부 컴포넌트의 사용을 제한하는 이유는?
라자루스에는 제3자가 개발한 추가 컴포넌트가 딸려 있다. 그리고 이러한 컴포넌트들은 다양한 라이센스 규정을 따른다. 사용을 원할 경우 해당 패키지의 소스 파일 내 License를 우선 숙지해야 한다. 제3자가 개발한 컴포넌트 대부분은 "components" 디렉터리에 위치한다.
컴포넌트가 LCL의 일부인지 어떻게 확인하나?
모든 LCL 유닛은 "lcl" 디렉터리에 위치한다. LCL에 속한 유닛의 리스트는 http://lazarus-ccr.sourceforge.net/docs/lcl/ 에서 찾을 수 있다. 사용자의 코드에서 만일 페이지에 열거되지 않은 유닛을 사용하는 경우, LCL에 속하지 않은 컴포넌트를 사용했을 가능성이 있다.
라자루스에 상용 플러그인(plug-in)을 만들 수 있는가?
가능하다. IDE의 IDEIntf part는 동일한 예외가 적용된 LGPL을 따르므로 이 part에서 공유된 데이터 구조는 GPL에 따라 플러그인 또는 디자인타임(design-time) 패키지의 사용에 대한 허가를 강요하지 않는다. 어떠한 라이센스의 플러그인이든 사용자가 마음대로 선택할 수 있으며, 사용자의 선택권을 제한하고 싶지 않다. 따라서 GPL과 호환 가능한 플러그인이 아니면 허용되지 않는다. GPL과 호환이 불가능한 플러그인이 정적으로 포함되어 있는 선컴파일된 라자루스는 그 배포를 허용하지 않음을 명심해야 한다. 하지만 라자루스의 재컴파일은 쉽기 때문에 이러한 제한이 엄격하다곤 말할 수 없다.