라이선스(LPPL)

LPPL이란, LaTeX 본체와 거의 모든 패키지가 쓰는 라이선스입니다. 얼마나 “거의”일까요. TeX Live 2024 패키지 대장에서 라이선스를 신고한 4,292건 가운데 2,986건(69.6%) 이 LPPL이며, GPL 계열 425건(9.9%)을 크게 앞섭니다. 그리고 이 라이선스에 대해 누구나 기억하는 한 문장——“고쳤으면 파일 이름을 바꿔야 한다”——은 지금 여러분 디스크에 있는 LPPL 1.3c 조문에 한 글자도 들어 있지 않습니다. 이 페이지는 그 규칙이 어디로 갔는지, 왜 사라졌는지, 그리고 남은 조항이 실제로 무엇을 요구하는지를 TeX Live에 동봉된 원문으로 확인해 나갑니다.

“고쳤으면 파일 이름을 바꿔라”는 어느 판의 조문인가

답은 LPPL 1.2의 제3조이며, 현행 1.3c가 아닙니다. TeX Live 2024에 동봉된 texmf-dist/doc/latex/base/lppl-1-2.txt의 74번째 줄을 열면, 수정한 파일을 배포해도 되는 여덟 조건 가운데 세 번째로 “You must not distribute the modified file with the filename of the original file.”(수정한 파일을 원래 파일 이름으로 배포해서는 안 된다)가 적혀 있습니다. 더 오래된 1.0은 한술 더 떠, 변경을 가하기 전에 파일 이름을 바꾸라는 순서까지 지정했습니다. 그런데 같은 디렉터리의 현행 lppl.txt——머리말이 LPPL Version 1.3c 2008-05-04인 본문——을 “renam”과 “filename”으로 검색하면 일치가 0건입니다. 이 규칙은 이제 조문에 존재하지 않습니다.

# TeX Live 2024 ships every version of the licence side by side.
$ cd texmf-dist/doc/latex/base
$ grep -c -iE "renam|filename" lppl-1-2.txt   # LPPL 1.2, 1999-09-03
7
$ grep -c -iE "renam|filename" lppl.txt       # LPPL 1.3c, 2008-05-04
0

그렇다면 애초에 왜 그런 조건을 두었을까요. 그 근거는 같은 디렉터리에 있는 1995년 문서 modguide.tex에 구체적인 예와 함께 지금도 적혀 있습니다. LaTeX의 tools 모음에는 array.sty가 있고, 1994년 말 여기에 새로운 사용자 기능이 추가되었습니다. 그래서 문서 쪽은 \usepackage{array}[1994/10/16]이라고 써서 “이 날짜 이후의 판이 필요하다”고 선언할 수 있습니다. 만약 다른 사람이 개조한 array를 같은 이름으로 배포한다면, 날짜만 새롭고 기능은 없는 파일이 돌아다니게 되어 이 선언은 무의미해집니다——이것이 LaTeX Project의 주장이었습니다. 그리고 이 장치는 30년이 지난 지금도 동작합니다. TeX Live 2024에 존재하지 않는 날짜를 요구하면 LaTeX Warning: You have requested, on input line 3, version ... but only version ... is available.가 나옵니다. TeX에서 파일 이름은 사용자가 마주하는 문법의 일부입니다.

1.3에서 조문이 바뀐 이유 — 2003년 Debian 논쟁

직접적인 계기는 Debian이 2003년에 LaTeX을 본 배포판에서 제외할지 검토한 일이었습니다. 쟁점은 바로 그 파일명 조항이었습니다. “수정판을 원래 이름으로 배포해서는 안 된다”가 Debian 자유 소프트웨어 지침(DFSG)에 비추어 허용될 수 있는지가 debian-legal 메일링 리스트에서 오래 논의되었습니다. 자유 소프트웨어 재단의 견해도 미묘했습니다. FSF는 LPPL 1.2를 자유 라이선스이지만 GPL과는 호환되지 않는다고 보았고, 개명 요구는 겨우 허용 가능한 쪽에 걸친다고 평가했습니다. 허용한 이유가 시사적입니다. TeX에는 파일 이름을 바꿔 읽는 장치가 있다는 것——foo를 요구받으면 bar를 쓰도록 설정할 수 있으므로, 개명은 성가실 뿐 장애물은 아니라는 것입니다. 뒤집어 말해, 그런 장치가 없는 체계에 같은 조건을 옮기면 소프트웨어가 부자유해진다고도 적었습니다. 이 논쟁을 거쳐 1.3이 2003년 12월 1일에 공개되었고, 파일명 조항은 사라졌습니다.

1.3c는 실제로 무엇을 요구하는가 — 제6조의 네 가지 의무

1.3c의 본문은 12개 조항으로 이루어지며, 그중 개변자와 관계있는 것은 사실상 제6조뿐입니다. 구성은 이렇습니다. 제1~3조는 이용과 무개변 배포, 제4조는 “당신이 Current Maintainer라면 자유롭게 고치고 배포해도 된다”, 제5조는 “아니더라도 자기 사본은 고쳐도 된다”, 그리고 제6조가 “Current Maintainer가 아닌 사람이 수정판을 배포할 때의 조건”이며 a부터 d까지 넷이 놓입니다. 핵심은 6a로, 원래 구성 요소가 Base Interpreter(LaTeX 저작물에서는 LaTeX 포맷)와 함께 대화형으로 실행되며 사용자에게 자신을 밝히는 자리에서는, 교체된 구성 요소도 “이것은 수정판”임을 명확하고 모호하지 않게 밝혀야 한다고 정합니다. 즉 요구가 “이름을 바꿔라”에서 “혼동되지 않게 하라”로 바뀐 것입니다.

그렇다면 개명은 이제 필요 없을까요. 실무에서는 여전히 개명이 정석이지만, 그 근거는 라이선스가 아니라 modguide.tex 에 있습니다. 이 문서는 클래스나 패키지를 개선했다면 부디 다른 이름을 붙여 달라고 명시하고, 가장 간단한 해결책으로 \documentclass{article}을 \documentclass{myart}로 바꾸기만 하면 된다고 알려 줍니다. 즉 지금의 상황은 이렇게 정리됩니다. 개명은 의무가 아니라, 6a를 충족하는 가장 확실하고 다툼의 여지가 없는 방법입니다. 포크해서 CTAN에 올릴 생각이라면 망설이지 말고 다른 이름을 붙이십시오. 반대로 사내 클래스를 조금 고쳐 우리끼리만 쓴다면 애초에 배포가 아니므로 제6조는 발동하지 않습니다(다만 1.3c는 “배포”를 넓게 보아, 공유 파일 시스템에 올려 두는 것도 배포에 포함된다는 입장을 적어 두었습니다).

maintainer와 Current Maintainer의 차이 — 방치된 패키지를 이어받는 길

Current Maintainer는 직책 이름이고 maintained는 상태 이름입니다——이 둘을 뒤섞으면 조문을 읽을 수 없게 됩니다. 1.3c의 정의절에 따르면 Current Maintainer는 “저작물 안에서 그 역할로 지명된 사람”이며, 명시적인 지명이 없으면 저작권자가 그 역할을 겸합니다. 이는 직함이고, 제4조에 따라 개변도 재배포도 자유롭게 할 수 있는 유일한 위치입니다. 한편 maintained / author-maintained / unmaintained 는 저작물 자체의 유지보수 상태이며, 저작물 안에 적어 두는 선언입니다. 저작물이 maintained라는 것은 Current Maintainer가 “버그 보고를 받을 의사가 있다”고 밝혔다는 뜻입니다(예를 들어 유효한 메일 주소를 적어 두는 것). 보고에 답할 의무까지 지는 것은 아닙니다. author-maintained는 “저자만 유지보수한다”는 선언이며, 이를 고르면 아래의 인수인계 규정이 작동하지 않습니다.

unmaintained가 된 저작물에는 인수인계 절차가 조문으로 적혀 있습니다. (1) 인터넷 검색 등으로 현 Current Maintainer(그리고 다른 사람이라면 저작권자)를 합리적으로 찾습니다. (2) 찾았다면 아직 유지보수 중인지 묻고, 그렇다면 1개월 안에 연락처를 갱신해 달라고 요청합니다. (3) 찾지 못했거나 아무 반응이 없다면, 관련 커뮤니티에 인수 의사를 표명합니다. (4) 그 표명으로부터 3개월 동안 현 유지보수자도, 저작권자도, 그 밖의 누구도 이의를 제기하지 않으면, 자신을 새 Current Maintainer로 적도록 저작물을 고쳐도 됩니다. (5) 다만 연락이 닿지 않던 이전 유지보수자가 변경 후 3개월 안에 나타나 요구하면, 그 자리는 그에게 돌아갑니다. 실제 사례는 가까이 있습니다. 다국어 패키지 babel의 머리말을 보면 저작권이 1989~2012년 Johannes Braams, 2012~2024년 Javier Bezos와 Braams로 되어 있고, 현재 Current Maintainer는 Javier Bezos라고 명시되어 있습니다.

자신의 패키지에 LPPL을 붙이려면 무엇을 써야 하는가

자신이 만든 .sty나 .cls를 LPPL로 공개하는 데 필요한 것은 각 파일 앞머리에 두는 몇 줄의 고지뿐이고, 결국 네 가지 요소로 정리됩니다. (1) 저작권 표시(자신의 이름과, 쓴 해 또는 마지막으로 크게 손본 해). (2) “1.3 또는 그 이후 판”으로 라이선스한다는 문구. (3) 유지보수 상태(maintained를 고르는 것이 정석)와 Current Maintainer 의 이름. (4) 어떤 파일이 “저작물”을 구성하는지의 열거. 마지막 (4)를 빠뜨리기 쉬운데, 조문은 저작물의 모든 파일을 함께 배포하라고 요구하므로 무엇이 저작물인지 저자가 밝히지 않으면 받는 쪽이 판단할 수 없습니다. 파일 수가 많다면 % This work consists of all files listed in manifest.txt. 한 줄로 넘겨도 됩니다. 그리고 LPPL은 퍼블릭 도메인이 아닙니다. 코드는 자유롭게 쓸 수 있지만 위의 표시 의무와 제6조는 남습니다.

%% mypkg.sty
%% Copyright 2026 M. Y. Name
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3
% of this license or (at your option) any later version.
% The latest version of this license is in
%   https://www.latex-project.org/lppl.txt
% and version 1.3 or later is part of all distributions of LaTeX
% version 2005/12/01 or later.
%
% This work has the LPPL maintenance status 'maintained'.
%
% The Current Maintainer of this work is M. Y. Name.
%
% This work consists of the files mypkg.dtx and mypkg.ins
% and the derived file mypkg.sty.

끝으로 다른 라이선스와의 관계를 정리해 둡니다. LPPL 1.3c는 2009년 11월 11일자로 OSI 승인을 받았고, Debian의 DFSG에도 적합하며 FSF도 자유 라이선스로 인정합니다. 그럼에도 GPL과는 호환되지 않는데, 그 이유는 “수정판임을 밝혀라”가 아니라——이 부분을 잘못 설명하는 글이 많습니다——제6조 d, 즉 “수정판을 배포하려면 무개변 완전 사본이나 그 입수 방법을 첨부하라”는 조건이 GPL이 허용하지 않는 추가 조건이기 때문입니다. 따라서 LPPL 코드를 GPL 프로젝트에 흡수할 수는 없습니다. 반대로 TeX 주변이 전부 LPPL인 것도 아닙니다. 예를 들어 다국어 패키지 중 babel은 LPPL이지만 polyglossia는 MIT 라이선스입니다. 라이선스 항목을 읽는 습관은 패키지를 고를 때도 도움이 됩니다.