[Final] PEP 541 - Package Index Name Retention

원문 링크: PEP 541 - Package Index Name Retention

상태: Final 유형: Process 작성일: 12-Jan-2017

PEP 541 – Package Index 이름 유지 (Package Index Name Retention)

  • 작성자: Łukasz Langa
  • BDFL-Delegate: Mark Mangoba
  • 상태: 최종 (Final)
  • 유형: 프로세스 (Process)
  • 생성일: 2017년 1월 12일

초록 (Abstract)

이 PEP는 Package Index (PyPI)의 이용 약관(Terms of Use) 확장을 제안하며, 특히 패키지 이름 분쟁 해결과 관련하여 패키지 소유자의 기대치를 명확히 합니다. CPAN, NPM, GitHub와 같은 기존 패키지 저장소의 사례를 참고하여 이 분야의 선행 연구로 활용했습니다.

배경 (Rationale)

PyPI의 패키지 이름은 단일하고 평면적인(flat) 네임스페이스를 공유하기 때문에, 고유한 이름은 한정된 자원입니다. PyPI의 역사가 길어짐에 따라, 기존 이름 사용과 동일한 이름의 다른 사용 제안 사이에 충돌 상황이 지속적으로 증가하고 있습니다. 이 문서는 이러한 충돌의 가장 일반적인 경우를 해결하기 위한 일반적인 지침을 제공하는 것을 목표로 합니다.

승인 절차 (Approval Process)

이 정책의 적용은 Python Software Foundation (PSF)에 잠재적인 법적 영향을 미칠 수 있으므로, 대부분의 PEP보다 더 공식적인 승인 절차를 사용합니다. PEP를 직접 수락하는 대신, 지정된 BDFL-Delegate가 PSF의 Packaging Working Group에 수락을 권고합니다. PSF의 법률 고문(General Counsel)과 협의 후, 정책 채택은 워킹 그룹 내에서 공식 투표를 거쳐야 합니다. 이 공식 승인 절차는 정책의 초기 채택과 향후 모든 수정 사항의 채택에 사용됩니다.

사양 (Specification)

이 문서의 핵심 아이디어는 Package Index가 커뮤니티를 위한 서비스라는 것입니다. 모든 사용자는 자신의 책임 하에 이용 약관에 따라 PyPI에 콘텐츠를 업로드할 수 있습니다. PyPI는 백업 서비스는 아니지만, 관리자들은 게시된 형태로 콘텐츠를 무기한 접근 가능하게 유지하기 위해 최선을 다합니다. 그러나 특정 예외적인 경우, 더 큰 커뮤니티의 요구가 개인이 패키지 이름 소유권에 대해 기대하는 것보다 우선할 수 있습니다.

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

  • 방치된 프로젝트 (Abandoned projects):
    • 다른 사용자 그룹에 의한 지속적인 유지보수.
    • 다른 프로젝트에서 사용하기 위해 PyPI에서 제거.
  • 활성 프로젝트 (Active projects):
    • 이름에 대한 분쟁 해결.
  • 유효하지 않은 프로젝트 (Invalid projects):
    • 지적 재산권 침해 주장의 대상이 되는 프로젝트.

이용 약관에 대한 제안된 확장은 Implementation 섹션에 명시된 대로 PyPI의 별도 문서로 게시되며, 첫 페이지 하단의 기존 이용 약관 옆에 링크될 것입니다.

구현 (Implementation)

연락 가능성 (Reachability)

PyPI 사용자는 자신이 소유한 프로젝트와 관련된 문제에 대해 PyPI 관리자와 연락이 가능하도록 할 책임이 전적으로 있습니다. 관리자는 사용자에게 연락이 필요한 모든 경우 다음 방법을 사용하여 최소 3회 시도합니다.

  • PyPI 사용자 프로필에 등록된 이메일 주소
  • PyPI에 업로드된 특정 프로젝트의 Author 필드에 기재된 이메일 주소
  • PyPI 또는 명시된 홈페이지에 있는 해당 프로젝트 문서에서 찾을 수 있는 모든 이메일 주소

관리자는 6주 후에도 사용자에게 연락을 시도하는 것을 중단합니다.

방치된 프로젝트 (Abandoned projects)

다음 모든 조건이 충족되면 프로젝트는 방치된 것으로 간주됩니다.

  • 소유자에게 연락 불가능 (위의 Reachability 참조).
  • 지난 12개월 동안 릴리스 없음.
  • 프로젝트의 홈페이지에 소유자의 활동 없음 (또는 홈페이지가 명시되지 않음).

이 외의 모든 프로젝트는 활성 프로젝트로 간주됩니다.

방치된 프로젝트의 지속적인 유지보수 (Continued maintenance of an abandoned project)

후보자가 방치된 프로젝트의 유지보수를 계속할 의사가 있고 다음 모든 조건이 충족되면 이름 소유권이 이전됩니다.

  • 프로젝트가 위에 설명된 규칙에 따라 방치된 것으로 결정됨.
  • 후보자가 기존 소유자에게 연락하려는 자신의 시도가 실패했음을 입증할 수 있음.
  • 후보자가 프로젝트의 자체 포크(fork)에서 개선 사항을 만들었음을 입증할 수 있음.
  • 후보자가 다른 이름의 포크가 허용 가능한 해결책이 아닌 이유를 입증할 수 있음.
  • PyPI 관리자에게 추가적인 이의가 없음.

연락 가능한 소유자의 의사에 반하여 이름이 재할당되는 경우는 절대 없습니다.

방치된 프로젝트의 제거 (Removal of an abandoned project)

프로젝트는 방치되었다는 이유만으로 PyPI에서 제거되지 않습니다. PyPI에 업로드된 아티팩트(artifacts)는 고유한 역사적 가치를 지닙니다.

방치된 프로젝트는 다음 모든 조건이 충족될 때 이름을 재사용하기 위한 목적으로 새 소유자에게 이전될 수 있습니다.

  • 프로젝트가 위에 설명된 규칙에 따라 방치된 것으로 결정됨.
  • 후보자가 기존 소유자에게 연락하려는 자신의 시도가 실패했음을 입증할 수 있음.
  • 후보자가 이름을 재사용하려는 제안된 프로젝트가 이미 존재하며 주목할 만한(notability) 요구 사항을 충족함을 입증할 수 있음.
  • 후보자가 다른 이름의 포크가 허용 가능한 해결책이 아닌 이유를 입증할 수 있음.
  • 기존 패키지에 대한 PyPI의 다운로드 통계가 프로젝트가 사용되지 않음을 나타냄.
  • PyPI 관리자에게 추가적인 이의가 없음.

활성 프로젝트의 이름 충돌 해결 (Name conflict resolution for active projects)

PyPI 관리자는 활성 프로젝트와 관련된 분쟁의 중재자가 아닙니다. 많은 시나리오가 있을 수 있으며, 실제 사례를 설명하는 비독점적인 목록은 다음과 같습니다. 다음 중 어떤 경우도 패키지 이름 소유권 이전 자격이 없습니다.

  • 사용자 A와 사용자 B가 프로젝트 X를 공유합니다. 시간이 지나면서 헤어지고 각자 프로젝트 X를 이름 X로 계속하고 싶어 합니다.
  • 사용자 A는 PyPI 외부에 프로젝트 X를 소유하고 있습니다. 사용자 B는 PyPI에 이름 X로 패키지를 만듭니다. 시간이 지난 후, 사용자 A는 프로젝트 X를 PyPI에 게시하고 싶지만 이름이 이미 사용 중임을 알게 됩니다. 이는 사용자 A의 프로젝트 X가 주목할 만한(notability) 주목도를 얻고 사용자 B의 프로젝트 X가 주목할 만하지 않더라도 마찬가지입니다.
  • 사용자 A가 프로젝트 X를 PyPI에 게시합니다. 시간이 지난 후 사용자 B가 프로젝트에 버그 수정 사항을 제안하지만 사용자 A는 새 릴리스를 게시하지 않습니다. 이는 사용자 A가 새 버전을 게시하는 데 동의했다가 나중에 게시하지 않더라도, 사용자 B의 변경 사항이 프로젝트 X의 소스 코드 저장소에 병합되더라도 마찬가지입니다.

위 목록은 비독점적입니다. PyPI 관리자는 사용자들이 서로 연락하여 존중하는 커뮤니케이션(PSF 행동 강령 참조)을 통해 문제를 해결하도록 권고합니다.

유효하지 않은 프로젝트 (Invalid projects)

다음 어떤 조건이라도 충족하는 PyPI에 게시된 프로젝트는 유효하지 않은 것으로 간주되며 PyPI에서 제거됩니다.

  • 프로젝트가 이용 약관을 준수하지 않음.
  • 프로젝트가 멀웨어(malware)임 (시스템이나 사용자를 직접적으로 악용하거나 해를 끼치기 위해, Command-and-Control 공격을 용이하게 하기 위해, 또는 데이터 유출을 수행하기 위해 설계됨).
  • 프로젝트가 스팸(spam)임 (상품이나 서비스를 광고하거나 권유하기 위해 설계됨).
  • 프로젝트에 불법 콘텐츠가 포함됨.
  • 프로젝트가 저작권, 상표권, 특허권 또는 라이선스를 침해함.
  • 프로젝트가 이름 스쿼팅(name squatting)임 (패키지에 기능이 없거나 비어 있음).
  • 프로젝트 이름, 설명 또는 콘텐츠가 행동 강령(Code of Conduct)을 위반함.
  • 프로젝트가 기능을 숨기거나 가리기 위해 난독화(obfuscation)를 사용함.
  • 프로젝트가 의도되지 않은 목적으로 Package Index를 남용함.

PyPI 관리자는 보안상의 이유로 특정 패키지 이름을 선제적으로 사용할 수 없도록 선언합니다.

지적 재산권 정책 (Intellectual property policy)

PSF 및 PyPI 관리자는 제3자의 지적 재산권 침해 주장에 대해 적절하게 대응하는 정책을 가지고 있습니다. PSF 또는 PyPI 관리자는 업로드된 패키지에 대해 어떤 유형의 지적 재산권 침해 여부를 사전 심사하지 않습니다.

잠재적으로 침해하는 패키지는 legal@python.org로 신고해야 하며, PSF 법률 고문이 적절한 대응을 결정할 것입니다. 침해 주장을 해결하기 위해 PSF의 전적인 재량으로 패키지를 제거하거나 새 소유자에게 이전할 수 있습니다.

다음 어떤 조건이라도 충족하는 PyPI에 게시된 프로젝트는 침해하는 것으로 간주되어 PyPI에서 제거되거나 새 소유자에게 이전될 수 있습니다.

  • 프로젝트에 제3자의 비라이선스 저작권 자료가 포함되어 있고, DMCA(Digital Millennium Copyright Act)에 따라 적절하게 제기된 주장의 대상이 됨.
  • 프로젝트가 명목 사용(nominal use) 또는 공정 사용(fair use) 지침에 포함되지 않는 방식으로 제3자의 상표를 사용함.
  • 프로젝트가 특허 시스템 또는 프로세스와 명확하게 관련되어 있고, 불만 제기의 대상이 됨.
  • 프로젝트가 진행 중인 소송의 대상이 됨.

지적 재산권 침해에 대한 불만 제기 시, 불만 사본이 패키지 소유자에게 발송됩니다. 경우에 따라 소유자가 응답하기 전에 PyPI 관리자가 조치를 취할 수 있습니다.

Python Software Foundation의 역할 (The role of the Python Software Foundation)

PSF는 PyPI를 커뮤니티 서비스로 제공하는 비영리 법인입니다. PyPI 관리자는 문제가 명확하지 않은 경우 이 문서에서 다루는 문제를 Packaging Working Group으로 에스컬레이션하여 해결할 수 있습니다. 일부 결정은 특히 행동 강령 위반 또는 법적 주장의 경우 이사회(Board)의 추가적인 판단이 필요합니다. 이사회에서 내린 권고는 검토를 위해 Packaging Working Group으로 전달됩니다. Packaging Working Group은 이 문서에서 다루는 모든 분쟁에 대한 최종 결정권을 가지며, 여기에 나열된 모든 요구 사항이 충족되지 않더라도 신중한 고려 후 PyPI에서 프로젝트를 재할당하거나 제거하기로 결정할 수 있습니다.

이름 이전 요청 방법 (How to request a name transfer)

PyPI에서 기존 프로젝트 이름을 인수하려면 다음 단계를 따르세요.

  1. 현재 소유자에게 직접 연락을 시도합니다: 이메일을 보내고 관련 저장소(repository)를 찾을 수 있다면 이슈(issue)를 엽니다. 여기에 설명된 프로세스는 소유자에게 연락할 수 없을 때 최후의 수단으로 사용됩니다.
  2. 이전이 허용되는 시기를 확인하기 위해 위의 기준을 확인합니다. 특히, 다른 프로젝트에 이름을 재사용하는 기준은 동일한 프로젝트의 유지보수를 계속하는 것보다 더 엄격합니다. (두 경우 모두 이름을 이전받는 것이 쉽지는 않습니다.)
  3. 다른 사람이 이미 동일한 이름을 요청하고 있는지 PyPI 지원 이슈를 검색합니다.
  4. 이름 소유권 이전을 위한 모든 기준이 충족되면, 새 이슈를 열어 요청하고 각 관련 기준이 충족된다고 생각하는 이유를 자세히 설명합니다.

선행 사례 (Prior art)

  • NPM: NPM은 프론트 페이지에서 링크된 별도의 “Package Name Disputes” 섹션을 포함하고 있습니다. 이는 “살아있는 문서(living document)”로 설명되며, 2017년 1월 기준으로 그 내용은 다음과 같이 요약될 수 있습니다.
    • 패키지 이름 스쿼팅은 금지됩니다.
    • 프로젝트 이름을 재사용하려는 사용자는 기존 작성자에게 연락해야 하며, support@npmjs.com을 참조(cc)로 포함해야 합니다.
    • 모든 연락은 NPM 행동 강령을 준수해야 합니다.
    • 몇 주 후에도 해결되지 않으면 npm inc.가 해당 문제에 대한 최종 결정권을 가집니다.
  • CPAN: CPAN은 모든 사용자가 동일한 이름으로 모듈을 업로드할 수 있도록 합니다. 관련 인덱스인 PAUSE는 기본 관리자 또는 공동 관리자가 업로드한 모듈만 나열합니다. CPAN 문서는 다른 분쟁을 다루지 않습니다.
  • GitHub: GitHub의 서비스 약관은 일반적인 사용 조건을 충족하지 않는 행동에 대한 ис포함적인 목록을 포함합니다. 명문화되지는 않았지만, GitHub는 사용자가 방치된 계정 이름을 아카이빙하고 다른 사용자나 조직이 계정 이름을 변경할 수 있도록 하여 방치된 계정 이름을 되찾을 수 있도록 동의합니다. 이는 사례별로(case-by-case basis) 처리됩니다.

거부된 제안 (Rejected Proposals)

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

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments