PEP 541 – 패키지 색인 이름 보유

Author:: Łukasz Langa <lukasz at python.org>
BDFL-Delegate:: Mark Mangoba <mmangoba at python.org>
Discussions-To:: Distutils-SIG list
Status:: Final
Type:: Process
Topic:: Packaging
Created:: 12-Jan-2017
Post-History:
Resolution:: Distutils-SIG message

Table of Contents

초록
근거
승인 절차
명세
구현
이름 이전을 요청하는 방법
선행 사례
거부된 제안
참고 문헌
Copyright
Acknowledgements

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 패키지 색인 [2]의 이용 약관 [1]에 대한 확장을 제안합니다. 이 확장은 패키지 색인에서 패키지 이름을 소유하는 문제, 특히 분쟁 해결과 관련하여 패키지 소유자가 무엇을 기대할 수 있는지 명확히 합니다.

CPAN [3], NPM [4], GitHub [5] 같은 기존 패키지 저장소를 이 필드의 선행 사례로 조사할 것입니다.

근거

색인의 패키지 이름은 하나의 평면 네임스페이스를 공유하므로 고유한 이름은 유한한 자원입니다. 패키지 색인이 오래될수록 이름의 현재 사용과 같은 이름에 대해 제안된 다른 사용 사이에 충돌이 생기는 상황이 상수처럼 꾸준히 증가합니다.

이 문서는 이러한 분쟁 중 가장 전형적인 경우를 해결하기 위한 일반 지침을 제공하는 것을 목표로 합니다.

승인 절차

이 정책을 적용하면 Python Software Foundation에 법적 영향이 생길 수 있으므로, 대부분의 PEP보다 더 공식적인 승인 절차를 사용합니다.

지정된 BDFL-Delegate는 PEP를 직접 수락하지 않고, 대신 PSF의 패키징 워킹 그룹(Packaging Working Group)에 수락을 권고합니다. 그다음 PSF의 법률 고문(General Counsel)과 협의한 후, 워킹 그룹 내 공식 투표로 정책 채택 여부를 결정합니다.

이 공식 승인 절차는 정책을 처음 채택할 때와 앞으로 개정안을 채택할 때 모두 사용합니다.

명세

이 문서의 핵심 개념은 패키지 색인이 커뮤니티를 위해 존재한다는 것입니다. 모든 사용자는 이용 약관에 따라 패키지 색인에 콘텐츠를 업로드할 수 있습니다. 다만 그에 따르는 위험은 전적으로 사용자 본인이 부담한다는 점을 이해해야 합니다.

패키지 색인은 백업 서비스가 아니지만, 패키지 색인의 유지 관리자는 해당 콘텐츠를 게시된 형태 그대로 무기한 접근 가능하도록 유지하기 위해 최선을 다합니다. 그러나 일부 예외적인 경우에는 더 넓은 커뮤니티의 필요가 패키지 이름을 소유하려는 개인의 기대보다 우선할 수 있습니다.

이 문서가 다루는 사용 사례는 다음과 같습니다:

방치된 프로젝트:
- 다른 사용자들이 유지 관리를 이어받는 경우, 또는
- 다른 프로젝트에서 이름을 쓸 수 있도록 색인에서 제거하는 경우.
활성 프로젝트:
- 이름에 관한 분쟁 해결.
부적합한 프로젝트:
- 지식 재산권 침해 주장의 대상이 된 프로젝트.

구현 섹션에 기술된 이용 약관 확장안은 패키지 색인에 별도 문서로 게시되며, 첫 페이지 하단(footer)에서 기존 이용 약관 옆에 링크됩니다.

구현

연락 가능성

패키지 색인 사용자는 자신이 소유한 프로젝트에 관한 사안에 대해 패키지 색인 유지 관리자가 자신에게 연락할 수 있도록 할 전적인 책임을 집니다. 사용자에게 연락해야 하는 모든 경우에 유지 관리자는 다음 연락 수단을 사용하여 최소 세 번 연락을 시도합니다:

패키지 색인 사용자 프로필에 등록된 이메일 주소;
색인에 업로드된 해당 프로젝트의 Author 필드에 기재된 이메일 주소; 그리고
색인 또는 기재된 홈페이지에 있는 해당 프로젝트의 문서에서 찾을 수 있는 모든 이메일 주소.

유지 관리자는 6주가 지나면 사용자에게 연락하려는 시도를 중단합니다.

방치된 프로젝트

다음 조건을 모두 충족하는 프로젝트는 방치된 것으로 간주합니다:

소유자에게 연락할 수 없음(위의 연락 가능성 항목 참조);
지난 12개월 동안 릴리스가 없음; 그리고
프로젝트 홈페이지에 소유자의 활동이 없음(또는 기재된 홈페이지가 없음).

그 밖의 모든 프로젝트는 활성 상태로 간주합니다.

방치된 프로젝트의 유지보수 지속

후보자가 방치된 프로젝트의 유지보수를 계속할 의사가 있는 것으로 보이면, 다음 조건을 모두 충족할 때 이름의 소유권을 이전합니다:

위에서 설명한 규칙에 따라 해당 프로젝트가 방치된 것으로 판정되었음;
후보자가 기존 소유자에게 직접 연락을 시도했으나 실패했음을 입증할 수 있음;
후보자가 자신의 프로젝트 포크에서 이룬 개선 사항을 입증할 수 있음;
후보자가 다른 이름으로 포크하는 것이 받아들일 수 있는 대안이 아닌 이유를 입증할 수 있음; 그리고
패키지 색인의 유지 관리자에게 추가적인 이의가 없습니다.

연락 가능한 소유자의 의사에 반하여 이름을 재할당하는 일은 어떠한 경우에도 없습니다.

방치된 프로젝트의 제거

프로젝트가 방치되었다는 이유만으로 패키지 색인에서 제거되는 일은 없습니다. 패키지 색인에 업로드된 아티팩트는 그 자체로 역사적 가치를 지닙니다.

다음 조건을 모두 충족하면 이름을 재사용할 목적으로 방치된 프로젝트를 새 소유자에게 이전할 수 있습니다:

위에서 설명한 규칙에 따라 해당 프로젝트가 방치된 것으로 판정되었음;
후보자가 기존 소유자에게 직접 연락을 시도했으나 실패했음을 입증할 수 있음;
후보자가 해당 이름을 재사용하려고 제안한 프로젝트가 이미 존재하며 주목도 요건을 충족함을 입증할 수 있음;
후보자가 다른 이름으로 포크하는 것이 받아들일 수 있는 대안이 아닌 이유를 입증할 수 있음;
패키지 색인에 있는 기존 패키지의 다운로드 통계가 해당 프로젝트가 사용되지 않고 있음을 나타냄; 그리고
패키지 색인의 유지 관리자에게 추가적인 이의가 없습니다.

활성 프로젝트의 이름 충돌 해결

패키지 색인의 유지 관리자는 활성 프로젝트를 둘러싼 분쟁의 중재자가 아닙니다. 이와 관련해서는 여러 가지 상황이 있을 수 있으며, 실제 사례 일부를 담은 목록을 아래에 제시합니다. 이 목록이 모든 경우를 포함하지는 않습니다. 다음 중 어느 경우도 패키지 이름 소유권 이전의 사유가 되지 않습니다:

사용자 A와 사용자 B가 프로젝트 X를 함께 진행합니다. 얼마 후 두 사람은 결별하게 되고, 각자 X라는 이름으로 프로젝트를 계속하기를 원합니다.
사용자 A는 패키지 색인 외부에서 프로젝트 X를 소유하고 있습니다. 사용자 B가 색인에 X라는 이름으로 패키지를 만듭니다. 얼마 후 사용자 A는 프로젝트 X를 색인에 게시하려 하지만 이름이 이미 사용 중임을 알게 됩니다. 이는 사용자 A의 프로젝트 X가 널리 알려지고 사용자 B의 프로젝트 X는 잘 알려지지 않은 경우에도 마찬가지입니다.
사용자 A가 프로젝트 X를 패키지 색인에 게시합니다. 얼마 후 사용자 B가 프로젝트에 버그 수정을 제안하지만, 사용자 A는 새 릴리스를 게시하지 않습니다. 이는 사용자 A가 새 버전을 게시하기로 동의했다가 나중에 게시하지 않는 경우에도, 사용자 B의 변경 사항이 프로젝트 X의 소스 코드 저장소에 병합된 경우에도 마찬가지입니다.

다시 말하지만, 위의 목록이 전부는 아닙니다. 패키지 색인의 유지 관리자는 사용자들이 서로 연락하여 정중한 소통으로 문제를 해결할 것을 권장합니다(PSF 행동 강령 [6] 참조).

유효하지 않은 프로젝트

패키지 색인에 게시된 프로젝트가 다음 중 하나라도 해당하면 유효하지 않은 것으로 간주되어 색인에서 제거됩니다:

프로젝트가 이용 약관을 준수하지 않는 경우;
프로젝트가 악성 소프트웨어인 경우(시스템이나 사용자를 직접 악용하거나 해를 끼치도록, 명령 및 제어(command-and-control) 공격을 용이하게 하도록, 또는 데이터 유출을 수행하도록 설계된 경우);
프로젝트가 스팸인 경우(상품이나 서비스를 광고하거나 권유하도록 설계된 경우);
프로젝트에 불법적인 콘텐츠가 포함된 경우;
프로젝트가 저작권, 상표, 특허 또는 라이선스를 침해하는 경우;
프로젝트가 이름 선점(name squatting)인 경우(패키지에 기능이 없거나 비어 있는 경우);
프로젝트 이름, 설명 또는 콘텐츠가 행동 강령을 위반하는 경우;
프로젝트가 기능을 숨기거나 감추기 위해 난독화를 사용하는 경우; 또는
프로젝트가 패키지 색인을 본래 의도되지 않은 목적으로 남용하는 경우.

패키지 색인 유지 관리자는 보안상의 이유로 특정 패키지 이름을 사용할 수 없는 것으로 사전에 지정합니다.

지적 재산권 정책

서드파티의 지식 재산권 침해 주장에 적절히 대응하는 것은 Python Software Foundation과 패키지 색인 유지 관리자의 정책입니다. 업로드된 패키지에 대해 어떠한 유형의 지식 재산권 침해 여부도 사전 심사하는 것은 Python Software Foundation이나 패키지 색인 유지 관리자의 정책이 아닙니다.

침해 가능성이 있는 패키지는 legal@python.org로 신고해야 하며, Python Software Foundation의 법률 고문이 적절한 대응을 결정합니다. 침해 주장을 처리하기 위해 Python Software Foundation의 단독 재량으로 패키지를 제거하거나 새 소유자에게 이전할 수 있습니다.

패키지 색인에 게시된 프로젝트가 다음 중 하나라도 해당하면 침해로 간주되어 색인에서 제거되거나 새 소유자에게 이전될 수 있습니다:

프로젝트에 서드파티의 저작물이 허가 없이 포함되어 있고, 그에 대해 DMCA에 따라 적법하게 제기된 청구가 있는 경우;
프로젝트가 지명적 사용이나 공정 사용 지침에 해당하지 않는 방식으로 서드파티의 상표를 사용하는 경우;
프로젝트가 특허받은 시스템이나 프로세스와 명백히 관련되어 있고, 이에 대한 신고가 접수된 경우; 또는
프로젝트가 현재 진행 중인 소송의 대상입니다.

지식 재산권 침해에 관한 신고가 접수되면 신고 사본이 패키지 소유자에게 전달됩니다. 경우에 따라서는 소유자가 응답하기 전에 패키지 색인 유지 관리자가 조치를 취할 수 있습니다.

Python Software Foundation의 역할

Python Software Foundation [7]은 커뮤니티 서비스로서 패키지 색인을 제공하는 비영리 법인입니다.

사안이 충분히 명확하지 않은 경우, 패키지 색인 유지 관리자는 이 문서에서 다루는 문제를 패키징 워크그룹(Packaging Workgroup)에 회부하여 해결을 요청할 수 있습니다. 일부 결정, 특히 행동 강령 위반이나 법적 청구와 관련된 경우에는 이사회의 추가 판단이 필요합니다. 이사회가 내린 권고는 검토를 위해 패키징 워크그룹 [8]에 전달됩니다.

패키징 워크그룹은 이 문서에서 다루는 모든 분쟁에 대해 최종 결정권을 가지며, 여기에 나열된 요건이 모두 충족되지 않은 경우에도 신중한 검토를 거쳐 프로젝트를 재배정하거나 패키지 색인에서 제거하기로 결정할 수 있습니다.

이름 이전을 요청하는 방법

PyPI의 기존 프로젝트 이름을 넘겨받으려면 다음 단계를 따르십시오.

현재 소유자에게 직접 연락해 보십시오. 이메일을 보내고, 관련 저장소를 찾을 수 있다면 이슈를 여십시오. 여기에 설명된 절차는 소유자와 연락이 닿지 않을 때 사용하는 최후의 수단입니다.
위의 기준을 확인하여 어떤 경우에 이전이 허용되는지 살펴보십시오. 특히 다른 프로젝트를 위해 이름을 재사용하는 경우의 기준은 같은 프로젝트의 유지 관리를 이어가는 경우보다 더 엄격합니다. 다만 어느 쪽이든 이름을 이전받기는 쉽지 않습니다.
PyPI Support 이슈를 검색하여 다른 사람이 이미 같은 이름을 요청하고 있는지 확인하십시오.
이름의 소유권 이전을 위한 기준을 모두 충족한다면 새 이슈를 열어 이전을 요청하고, 관련된 각 기준이 충족된다고 판단하는 이유를 자세히 기술하십시오.

선행 사례

NPM에는 첫 페이지에서 링크된 패키지 이름 분쟁이라는 별도의 섹션이 있습니다. 이 섹션은 “살아 있는 문서”로 소개되며, 2017년 1월 기준으로 그 내용은 다음과 같이 요약할 수 있습니다.

패키지 이름 선점(squatting)은 금지됩니다.
프로젝트 이름을 재사용하려는 사용자는 참조(cc)에 support@npmjs.com 주소를 넣어 기존 작성자에게 연락해야 합니다.
모든 연락은 NPM 행동 강령을 준수해야 합니다.
몇 주가 지나도 해결되지 않으면 npm inc.가 해당 사안에 대한 최종 결정권을 가집니다.

CPAN은 모든 사용자가 같은 이름의 모듈을 업로드할 수 있도록 허용합니다. 관련 색인인 PAUSE는 주 유지 관리자나 등록된 공동 유지 관리자가 업로드한 모듈만 목록에 올립니다. 그 밖에 CPAN 문서는 분쟁을 다루지 않습니다.

GitHub의 서비스 약관에는 일반 이용 조건을 충족하지 않는 행위의 목록이 빠짐없이 나와 있습니다. 어디에도 명문화되어 있지는 않지만, GitHub는 방치된 계정을 보관 처리하고 다른 사용자나 조직이 자신의 계정 이름을 바꿀 수 있게 하는 방식으로 사용자가 방치된 계정 이름을 되찾는 것을 허용합니다. 이는 사례별로 처리됩니다.

기존 방식은 명문화된 정책 없이 잘 되기를 바라며 문제가 생길 때마다 해결하는 것이었습니다. 이 방식은 지속될 수 없습니다. 패키지 이름 충돌 해결에 관해 누구나 볼 수 있는 명문화된 지침이 없어서 불필요한 갈등이 생기고 있습니다. 사용자의 관점에서는, 서면 지침 없이 패키지 색인 유지 관리자가 내린 결정이 자의적으로 보일 수 있습니다. 패키지 색인 유지 관리자의 관점에서는, 정의된 정책이 없어 의도치 않은 피해를 줄 위험이 있기 때문에 이름 충돌 해결이 스트레스가 많은 작업입니다.