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의 패키징 작업 그룹에 승인을 권고합니다. PSF의 법률 고문과 협의한 후, 정책 채택 여부는 작업 그룹 내의 공식 투표에 부쳐집니다.

이 공식 승인 절차는 정책의 최초 채택과 향후 개정안의 채택 모두에 사용됩니다.

사양

이 문서의 핵심 취지는 패키지 색인이 커뮤니티를 위해 운영된다는 것입니다. 모든 사용자는 사용 약관에 따라 패키지 색인에 콘텐츠를 업로드하도록 초대되며, 이에 따른 위험은 전적으로 사용자에게 있음을 이해해야 합니다.

패키지 색인은 백업 서비스가 아니지만, 패키지 색인 관리자는 게시된 형태의 콘텐츠에 무기한 접근할 수 있도록 최선을 다합니다. 그러나 특정 예외적인 경우에는 더 큰 커뮤니티의 요구가 패키지 이름에 대한 개인의 소유권 기대보다 우선할 수 있습니다.

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

방치된 프로젝트:
- 다른 사용자 집합에 의한 유지 관리 계속; 또는
- 다른 프로젝트에서 사용하기 위해 색인에서 제거하는 경우.
활성 프로젝트:
- 이름에 관한 분쟁 해결.
유효하지 않은 프로젝트:
- 지식재산권 침해 주장에 해당하는 프로젝트.

구현 섹션에 명시된 사용 약관에 대한 제안된 확장은 패키지 색인에 별도 문서로 게시되며, 첫 페이지 바닥글의 기존 사용 약관 옆에 링크됩니다.

구현

연락 가능성

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

패키지 색인 사용자 프로필에 등록된 이메일 주소;
색인에 업로드된 특정 프로젝트의 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] 참조).

유효하지 않은 프로젝트

다음 항목 중 어느 하나라도 충족하는 패키지 색인 게시 프로젝트는 유효하지 않은 것으로 간주되며 색인에서 삭제됩니다.

프로젝트가 이용 약관을 준수하지 않습니다.
프로젝트가 악성 코드입니다(시스템이나 사용자에게 직접 피해를 주거나 악용하도록 설계되었거나, 명령 및 제어 공격을 용이하게 하거나, 데이터를 유출하도록 설계된 경우).
프로젝트가 스팸입니다(상품이나 서비스를 광고하거나 권유하도록 설계된 경우).
프로젝트에 불법 콘텐츠가 포함되어 있습니다.
프로젝트가 저작권, 상표, 특허 또는 라이선스를 침해합니다.
프로젝트가 이름 선점에 해당합니다(패키지에 기능이 없거나 비어 있습니다).
프로젝트 이름, 설명 또는 콘텐츠가 행동 강령을 위반합니다.
프로젝트가 기능을 숨기거나 가장하기 위해 난독화를 사용합니다. 또는
프로젝트가 패키지 색인을 원래 의도되지 않은 목적으로 악용합니다.

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

지적 재산권 정책

Python Software Foundation과 패키지 색인 관리자는 제3자의 지적 재산권 침해 주장에 적절히 대응하는 것을 정책으로 합니다. Python Software Foundation이나 패키지 색인 관리자는 업로드된 패키지를 어떠한 유형의 지적 재산권 침해에 대해서도 사전 심사하지 않는 것을 정책으로 합니다.

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

다음 항목 중 어느 하나라도 충족하는 패키지 색인 게시 프로젝트는 침해 프로젝트로 간주될 수 있으며, 색인에서 삭제되거나 새 소유자에게 이전될 수 있습니다.

프로젝트가 명목적 사용 또는 공정 사용 지침의 적용 범위를 벗어나는 방식으로 제3자의 상표를 사용합니다.
프로젝트가 특허를 받은 시스템이나 프로세스와 명백히 관련되어 있으며, 이에 대한 이의 제기가 제기되었습니다. 또는
프로젝트는 현재 진행 중인 소송의 대상입니다.

지식재산권 침해에 관한 소장이 제기되는 경우, 소장 사본이 패키지 소유자에게 발송됩니다. 일부 경우에는 소유자가 응답하기 전에 패키지 색인 유지 관리자가 조치를 취할 수 있습니다.

Python Software Foundation의 역할

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

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

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

이름 이전을 요청하는 방법

PyPI에서 기존 프로젝트 이름을 인수하려는 경우 다음 단계를 따르십시오.

현재 소유자에게 직접 연락해 보십시오. 관련 저장소를 찾을 수 있다면 이메일을 보내고 이슈를 여십시오. 여기에 설명된 절차는 소유자에게 연락할 수 없는 경우의 최후의 수단으로 마련된 것입니다.
이전이 허용되는 경우를 확인하려면 위의 기준을 확인하십시오. 특히 reusing a name for a different project 은continuing maintenance of the same project 보다 기준이 더 엄격하지만, 어느 경우든 이름을 이전받기는 쉽지 않습니다.
다른 사람이 이미 같은 이름을 요청하고 있는지 확인하려면 PyPI Support issues 를검색하십시오.
이름의 소유권을 이전하기 위한 모든 기준이 충족되면, 각 관련 기준이 충족된다고 판단하는 이유를 자세히 설명하여 open a new issue 하여 요청하십시오.

선례

NPM에는 첫 페이지에서 연결되는 Package Name Disputes 라는별도 섹션이 있습니다. 이는 “living document”로 설명되며, 2017년 1월 기준으로 그 내용은 다음과 같이 요약할 수 있습니다.

패키지 이름 선점은 금지됩니다.
프로젝트 이름을 재사용하려는 사용자는 기존 작성자에게 연락해야 하며, support@npmjs.com을 참조로 포함해야 합니다.
모든 연락은 NPM 행동 강령을 준수해야 합니다.
몇 주 후에도 해결되지 않는 경우, npm inc.가 해당 사안에 대한 최종 결정을 내릴 권리를 가집니다.

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

GitHub의 서비스 약관에는 일반적인 사용 조건을 충족하지 않는 행위의 전체 목록이 포함되어 있습니다. 어디에도 명문화되어 있지는 않지만, GitHub는 사용자가 버려진 계정을 보관 처리하고 다른 사용자나 조직이 자신의 계정 이름을 변경하도록 함으로써 버려진 계정 이름을 되찾는 것을 허용합니다. 이는 사안별로 처리됩니다.

기존 접근 방식은 문서화된 정책 없이 문제가 발생할 때마다 최선의 결과를 기대하며 해결하는 것이었습니다. 이는 지속 가능하지 않습니다. 패키지 이름 충돌 해결에 관한 일반적으로 이용 가능한 문서화된 지침이 없기 때문에 불필요한 긴장이 발생하고 있습니다. 사용자 관점에서는 문서화된 지침 없이 패키지 색인 유지 관리자가 내린 결정이 자의적으로 보일 수 있습니다. 패키지 색인 유지 관리자 관점에서는 정의된 정책의 부재로 인해 의도하지 않은 피해가 발생할 위험이 있으므로 이름 충돌을 해결하는 일이 스트레스가 큰 작업입니다.