GPL 피해가기

http://kldp.org/node/42009 와 연관된 글입니다.

GPL인 라이브러리를 GPL이 아닌 프로그램에 링크하는 것은 (LGPL과는 달리) 허용되지 않지만, 예를 들어 파이프나 소켓을 통해 통신이 이루어진다면 이것이 "derived work"인가 하는 문제는 훨씬 애매해집니다. 일반적으로 파이프를 통해 오고가는 텍스트의 포맷이나 소켓의 프로토콜이 "단지 GPL을 피해가기 위해" 고안된 것이라면 무효이고, 일반적이고 다른 프로그램도 사용할 수 있는 것이라면 두 프로그램을 분리된 것으로 볼 수 있다고 해석되는 것 같습니다.

이 사실을 SGI 사가 교묘하게 이용한 것이 Open64 컴파일러입니다. Open64 컴파일러는 GCC 프론트엔드를 사용합니다. 왜냐하면 C++ 파서를 짜는 것은 결코 쉬운 일이 아니고, 리눅스 커널을 비롯한 여러 오픈 소스 프로젝트가 GCC 확장을 사용하기 때문입니다. (이러한 이유 때문에 인텔의 ICC 컴파일러도 GCC 확장을 지원합니다.)

그렇지만 Open64 컴파일러 전체는 GPL이 아닙니다. SGI는 이를 위해 WHIRL이라는 일종의 "중간 언어"를 고안해서 스펙을 공개적으로 출판합니다. 일종의 어셈블리 언어인 이 언어는 또다른 컴파일러를 통해 해당 아키텍처에 적합한 기계어로 최적화 될 수 있습니다. WHIRL은 상당히 잘 디자인된 언어였기 때문에 몇몇 연구에서 이 언어가 실제로 사용됩니다.

그리고 SGI는 GCC 프론트엔드에 WHIRL을 생성하는 백엔드를 붙이고는, WHIRL을 64비트 기계어로 번역하는 최적화 컴파일러를 만들고, WHIRL 백엔드만 GPL로 공개하고 최적화 컴파일러는 공개하지 않았습니다. GCC 개발자들은 이를 싫어했지만 이를 GPL 위반이라고 볼 수는 없다고 결론을 내린 것 같습니다.

어떤 이야기에 따르면, GCC의 프론트엔드와 백엔드가 뚜렷하게 구분되지 않은 이유가 기술적인 이유라기보다는 이러한 "GPL 피해가기"를 막기 위한 고의적인 철학적 이유 때문이라고 합니다. GCC 코드를 쓰지 않고는 GCC의 중간 언어인 RTL에 접근하기 어려운 것도 마찬가지 이유라는 소문이 있습니다.

미겔은 닷넷을 위한 MC++ (Managed C++) 컴파일러 이야기를 하면서, C++ 파서가 짜기 어려우니 GCC에 편승하는 것이 좋은데 GCC는 GPL이라 곤란하다는 이야기를 하면서 WHIRL을 닷넷의 IL로 바꿀 수 있지 않겠느냐는 이야기를 얼마 전에 블로그에 쓰기도 했습니다. 미겔은 이런 방식의 "GPL 피해가기"가 바람직하다고 생각하는 걸까요?

--feanor