PEP 639 – 더 나은 패키지 메타데이터를 통한 라이선스 명확성 개선

Author:

Philippe Ombredanne <pombredanne at nexb.com>, C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>, Karolina Surma <karolina.surma at gazeta.pl>

PEP-Delegate:

Brett Cannon <brett at python.org>

Discussions-To:

Discourse thread

Status:

Final

Type:

Standards Track

Topic:

Packaging

Created:

15-Aug-2019

Post-History:

15-Aug-2019, 17-Dec-2021, 10-May-2024

Resolution:

Discourse message

---

Table of Contents

• 초록
• 목표
• 목표가 아닌 것
• 동기
• 근거
• 용어
  • 라이선스 용어
• 명세
  • SPDX 라이선스 표현식 문법
  • 코어 메타데이터
    • License-Expression 필드 추가
    • License-File 필드 추가
    • License 필드 폐지
    • 라이선스 분류자 폐지
  • 프로젝트 소스 메타데이터
    • license 키에 문자열 값 추가
    • license-files 키 추가
    • license 키의 테이블 하위 키 폐지
  • 프로젝트 형식의 라이선스 파일
  • 레거시 메타데이터 변환
• 하위 호환성
• 보안 영향
• 교육 방법
• 참조 구현
• 기각된 아이디어
• 부록
• 참고 문헌
• 감사의 글
• Copyright

번역·라이선스 안내

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

Important

This PEP is a historical document. The up-to-date, canonical spec, Core metadata specifications, is maintained on the PyPA specs page.

×

See the PyPA specification update process for how to propose changes.

초록

이 PEP는 Python 프로젝트에서 라이선스를 문서화하는 방법에 대한 명세를 정의합니다.

이를 위해 이 PEP는 다음을 수행합니다:

• Python 프로젝트의 라이선스를 표현하는 수단으로 SPDX 라이선스 표현식 문법을 채택합니다.
• 프로젝트, 소스 배포판, 빌드된 배포판에 라이선스 파일을 포함하는 방법을 정의합니다.
• Core Metadata와 이에 대응하는 Pyproject 메타데이터 키에 필요한 변경 사항을 명시합니다
• 소스 배포판(sdist), 빌드된 배포판(wheel), 설치된 프로젝트 표준에 필요한 변경 사항을 기술합니다.

이를 통해 라이선스 선언은 패키지 작성자가 작성하기에, 최종 사용자가 이해하기에, 도구가 프로그래밍 방식으로 처리하기에 더 간단하고 덜 모호해집니다.

이 변경 사항은 Core Metadata 명세를 버전 2.4로 갱신합니다.

목표

이 PEP의 범위는 배포 패키지의 라이선스를 문서화하기 위한 새로운 메커니즘을 다루는 것으로 한정되며, 구체적으로 다음을 정의합니다:

• SPDX 라이선스 표현식을 지정하는 수단.
• 배포 패키지와 설치된 프로젝트에 라이선스 텍스트를 포함하는 방법.

이 PEP가 요구하는 변경 사항은 영향을 최소화하고 하위 호환성을 최대화하도록 설계되었습니다.

목표가 아닌 것

이 PEP는 특정 패키지 작성자에게 특정 라이선스를 선택하도록 권장하지 않습니다.

프로젝트가 새 필드를 사용하지 않기로 결정하더라도, PyPI에 업로드할 때 이 PEP로 인한 추가 제약은 부과되지 않습니다.

또한 이 PEP는 개별 파일에 대한 라이선스 문서화를 다루지 않으며(부록에서 조사한 주제로 다루기는 합니다), 소스 배포판과 바이너리 배포판 패키지가 동일한 라이선스를 갖지 않는 경우를 다루려는 의도도 없습니다.

동기

소프트웨어는 작성자 이외의 사람이 이를 다운로드하고, 사용하고, 공유하고, 수정할 수 있도록 라이선스가 부여되어야 합니다. 현재 Core Metadata에는 라이선스가 문서화되는 필드가 여러 개 있으며, 각 필드로 표현할 수 있는 내용에는 한계가 있습니다. 이는 종종 패키지 작성자와, 배포판 재패키징 담당자를 포함한 최종 사용자 모두에게 혼란을 초래합니다.

이로 인해 오래되고 모호한 PyPI 분류자, 다른 생태계와의 라이선스 상호 운용성, 지나치게 많고 혼란스러운 라이선스 메타데이터 옵션, Wheel 프로젝트의 제한적인 라이선스 파일 지원, 정확한 라이선스 메타데이터의 부재 등 라이선스와 관련된 여러 논의와 이슈가 제기되었습니다.

그 결과, 평균적으로 Python 패키지는 다른 일반적인 생태계에 비해 라이선스 정보가 더 모호하거나 누락되는 경향이 있습니다. 이는 PyPI, Maven, npm, Rubygems의 모든 패키지를 대상으로 하며 다른 FOSS 프로젝트의 라이선스 명확성 개선을 돕기 위한 Open Source Initiative의 활동인 ClearlyDefined 프로젝트의 통계 페이지에서 확인할 수 있습니다.

모호한 분류자(예: License :: OSI Approved :: BSD License)를 폐기하면서, 현재의 라이선스 분류자를 SPDX 식별자 전체를 포함하도록 확장할 수도 있습니다.

그러나 이러한 접근 방식에 반대하는 인자(논거)가 여러 가지 있습니다.

• SPDX 라이선스 목록을 복제하고 동기화 상태를 유지하는 데 많은 노력이 필요합니다.
• 하위 호환성을 크게 깨뜨리며, PyPI가 기존 분류자를 폐기하면 패키지 작성자가 즉시 새 분류자로 갱신해야 합니다.
• 이 방식은 단일 라이선스를 따르는 패키지만 다룹니다. 의존성을 벤더링하는 프로젝트(예: Setuptools), 여러 라이선스 중 하나를 선택할 수 있게 하는 프로젝트(예: Packaging(패키징)), 라이선스가 변경된 프로젝트, 다른 프로젝트의 코드를 가져와 수정해 쓰는 프로젝트, 다른 라이선스를 따르는 글꼴, 이미지, 예제, 바이너리 또는 기타 자산을 포함하는 프로젝트는 다루지 못합니다.
• 작성자와 도구 모두가 PyPI 전용 분류자 체계를 이해하고 구현해야 합니다.
• 이 방식은 패키지가 새 체계를 채택했음을 그만큼 분명하게 나타내지 않으므로, 그에 맞게 다루어야 합니다.

근거

Python 생태계와 기타 다양한 패키징 시스템, 리눅스 배포판, 언어 생태계 및 애플리케이션에 존재하는 라이선스 메타데이터 정의를 파악하기 위해 조사를 수행했습니다.

이 조사에서 얻은 시사점을 바탕으로 이 PEP의 권고 사항을 정했습니다.

• SPDX 및 SPDX와 유사한 문법은 많은 현대 패키지 시스템에서 가장 널리 쓰이는 license expression입니다.
• 대부분의 자유 및 오픈 소스 소프트웨어 라이선스는 패키지 작성자가 Distribution Package에 라이선스 전문을 포함하도록 요구합니다.

따라서 이 PEP는 두 가지 새로운 코어 메타데이터 필드를 도입합니다.

• SPDX 라이선스 표현식을 사용하여 패키지의 라이선스를 모호함 없이 표현하는 방법을 제공하는 License-Expression입니다.
• 배포 시 패키지와 함께 라이선스 전문을 포함하는 표준화된 방법을 제공하고, Core Metadata를 사용하는 다른 도구가 distribution archive의 라이선스 파일을 찾을 수 있게 하는 License-File입니다.

또한 이 명세는 Setuptools 및 Wheel 프로젝트의 기존 관행을 토대로 합니다. 이 PEP의 현재 초안 최신 버전은 Hatch 패키징 도구에 구현되어 있으며, 라이선스 파일 부분의 이전 초안은 Setuptools에 구현되어 있습니다.

용어

이 문서의 키워드 “MUST”, “MUST NOT”, “REQUIRED”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”은 RFC 2119에 설명된 대로 해석해야 합니다.

라이선스 용어

라이선스 관련 용어, 특히 license identifier와 license expression은 SPDX 프로젝트의 용어를 많이 차용합니다.

라이선스 분류자

(Core Metadata 명세에서 설명하는 것과 같이) License ::로 시작하는 PyPI Trove 분류자입니다.

라이선스 표현식

SPDX 표현식

하나 이상의 SPDX license identifier를 포함하는 유효한 SPDX 라이선스 표현식 구문의 문자열로, Project의 라이선스와 그 라이선스들이 서로 어떻게 관계되는지를 기술합니다. 예: GPL-3.0-or-later, MIT AND (Apache-2.0 OR BSD-2-clause)

라이선스 식별자

SPDX 식별자

이 PEP의 License-Expression 필드 추가 절에서 설명하는 유효한 SPDX 짧은 형식 라이선스 식별자입니다. 여기에는 유효한 모든 SPDX 식별자와 SPDX 명세 10.1절을 따르는 사용자 정의 LicenseRef-[idstring] 문자열이 포함됩니다. 예: MIT, GPL-3.0-only, LicenseRef-My-Custom-License

루트 라이선스 디렉터리

라이선스 디렉터리

project source tree, distribution archive 또는 installed project에서 라이선스 파일이 저장되는 디렉터리입니다. 또한 License-File Core Metadata field에 기록된 라이선스 파일 경로의 기준이 되는 루트 디렉터리이기도 합니다. project source tree 또는 source distribution의 경우 project root directory로 정의되고, Built Distribution 또는 installed project의 경우 built metadata를 담고 있는 디렉터리의 licenses라는 하위 디렉터리, 즉 .dist-info/licenses 디렉터리로 정의됩니다.

명세

이 PEP를 구현하는 데 필요한 변경 사항은 다음과 같습니다.

• 명세에 정의된 Core Metadata에 대한 추가 사항입니다.
• 명세에 정의된, 작성자가 제공하는 프로젝트 소스 메타데이터에 대한 추가 사항입니다.
• 소스 배포판(sdist), 빌드된 배포판(wheel), 설치된 프로젝트 명세에 대한 추가 사항.
• 레거시 라이선스 메타데이터를 처리하여 라이선스 표현식으로 변환하는 도구를 위한 지침. 이 지침은 결과가 일관되고 올바르도록 보장합니다.

오류와 경고에 관한 지침은 도구의 기본 동작에 대한 것임에 유의하십시오. 사용자가 CLI 플래그나 설정 옵션 등으로 명시적으로 설정한 경우 도구는 더 엄격하게 동작할 수 있습니다(MAY).

SPDX 라이선스 표현식 문법

이 PEP는 SPDX 명세 버전 2.2 또는 이후의 호환 버전에 문서화된 SPDX 라이선스 표현식 문법을 채택합니다.

라이선스 표현식에는 다음 라이선스 식별자를 사용할 수 있습니다:

• SPDX 라이선스 목록 버전 3.17 또는 이후의 호환 버전에 게재된, SPDX에 등재된 모든 라이선스 약식 식별자. SPDX 작업 그룹은 라이선스 식별자를 절대 제거하지 않으며, 대신 식별자를 “deprecated”로 표시할 수 있다는 점에 유의하십시오.
• SPDX 라이선스 목록에 포함되지 않은 라이선스를 식별하기 위한 사용자 정의 LicenseRef-[idstring] 문자열. 여기서 [idstring]은 문자, 숫자, ., -로 이루어진 고유한 문자열입니다. 사용자 정의 식별자는 해당 명세 버전의 SPDX 명세 10.1절을 따라야 합니다.

유효한 SPDX 표현식의 예:

MIT
BSD-3-Clause
MIT AND (Apache-2.0 OR BSD-2-Clause)
MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
LicenseRef-Special-License OR CC0-1.0 OR Unlicense
LicenseRef-Proprietary

유효하지 않은 SPDX 표현식의 예:

Use-it-after-midnight
Apache-2.0 OR 2-BSD-Clause
LicenseRef-License with spaces
LicenseRef-License_with_underscores

코어 메타데이터

이 절의 오류 및 경고 지침은 빌드 도구와 배포 도구에 적용됩니다. 최종 사용자용 설치 도구는 이 명세를 따르지 않는 잘못된 형식의 메타데이터를 만났을 때 여기에 언급된 것보다 덜 엄격하게 동작할 수 있습니다(MAY).

이 PEP는 새로운 필드를 추가하므로 코어 메타데이터 버전을 2.4로 올립니다.

License-Expression 필드 추가

선택적 코어 메타데이터 필드인 License-Expression에는 앞서 정의한 대로 유효한 SPDX 라이선스 표현식인 텍스트 문자열이 들어갑니다.

빌드 도구와 배포 도구는 License-Expression 필드에 유효한 SPDX 표현식이 들어 있는지 확인해야 하며(SHOULD), 여기에는 개별 라이선스 식별자의 유효성(앞서 정의한 대로)도 포함됩니다. 유효하지 않은 표현식이 발견되면 도구는 실행을 중단하고 오류를 발생시킬 수 있습니다(MAY). 도구가 SPDX 표현식을 검증하기로 한 경우, 각 SPDX 라이선스 식별자에는 기준 대소문자를, AND, OR, WITH 키워드에는 대문자를 사용하여 대소문자를 정규화한 License-Expression 필드도 저장해야 합니다(SHOULD). 하나 이상의 라이선스 식별자가 SPDX 라이선스 목록에서 deprecated로 표시된 경우, 도구는 경고를 보고해야 하며(SHOULD) 배포 도구는 오류를 발생시킬 수 있습니다(MAY).

License-Expression 필드를 포함하여 새로 업로드되는 모든 배포 아카이브에 대해 Python 패키지 색인(PyPI)는 유효한 식별자(앞서 정의한 대로)로 이루어진, 대소문자가 정규화된 유효한 라이선스 표현식이 들어 있는지 반드시 검증해야 하며(MUST), 그렇지 않은 업로드는 반드시 거부해야 합니다(MUST). SPDX 명세를 따르는 사용자 정의 라이선스 식별자는 유효한 것으로 간주합니다. 라이선스 식별자가 앞서 언급한 SPDX 라이선스 목록 버전 기준으로 deprecated 상태라면, PyPI는 해당 식별자를 사용한 업로드를 거부할 수 있습니다(MAY).

License-File 필드 추가

License-File은 선택적 코어 메타데이터 필드입니다. 각 항목에는 라이선스 관련 파일 경로의 문자열 표현이 들어갑니다. 이 경로는 프로젝트 소스 트리 안에 있으며, 프로젝트 루트 디렉터리를 기준으로 한 상대 경로입니다. 이 필드는 0번 이상 나타날 수 있는 다중 사용 필드이며, 각 항목은 그러한 파일 하나의 경로를 나타냅니다. 이 필드에 지정되는 파일에는 라이선스 텍스트, 저작자/귀속 정보, 또는 패키지와 함께 배포해야 하는 기타 법적 고지가 포함될 수 있습니다.

이 PEP에서 명시한 대로, 이 값은 설치된 프로젝트와 표준화된 배포 패키지 유형 모두에서 라이선스 루트 디렉터리를 기준으로 한 해당 파일의 상대 경로이기도 합니다.

소스 배포 또는 빌드 배포의 코어 메타데이터에 License-File이 나열된 경우:

• 해당 파일은 루트 라이선스 디렉터리를 기준으로 지정된 경로에 위치하도록 distribution archive에 반드시 포함되어야 합니다.
• 해당 파일은 project와 함께 동일한 상대 경로에 반드시 설치되어야 합니다.
• 지정된 상대 경로는 프로젝트 소스 트리, 소스 배포판(sdist), 빌드된 배포판(Wheels), 설치된 프로젝트 사이에서 반드시 일관되어야 합니다.
• 패키징 도구는 루트 라이선스 디렉터리 안에, 원본 라이선스 파일이 프로젝트 루트를 기준으로 위치한 디렉터리 구조를 반드시 그대로 재현해야 합니다.
• 경로 구분자는 반드시 슬래시 문자(/)여야 하며, 상위 디렉터리 표시자(..)를 사용해서는 안 됩니다.
• 라이선스 파일의 내용은 반드시 UTF-8로 인코딩된 텍스트여야 합니다.

빌드된 배포판의 메타데이터에 License-File 항목이 하나도 없으면, 빌드 도구는 유용한 정보를 담은 경고를 출력할 수 있고 게시 도구는 출력하는 것이 좋습니다. 또한 게시 도구는 오류를 발생시킬 수 있지만 빌드 도구는 오류를 발생시켜서는 안 됩니다.

코어 메타데이터에 하나 이상의 License-File 필드를 포함하고 Metadata-Version을 2.4 이상으로 선언하는, 새로 업로드되는 모든 distribution archive에 대해 PyPI는 지정된 모든 파일이 해당 distribution archive에 존재하는지 검증해야 하며(SHOULD), 검증을 통과하지 못한 업로드는 반드시 거부해야 합니다(MUST).

License 필드 폐지

비구조화 텍스트로 된 기존 License Core Metadata field는 폐지되며, 새로운 License-Expression 필드로 대체됩니다. 두 필드는 상호 배타적입니다. 코어 메타데이터를 생성하는 도구는 이 두 필드를 모두 생성해서는 안 됩니다(MUST NOT). 코어 메타데이터를 읽는 도구는 이 두 필드가 동시에 존재하는 경우 반드시 License-Expression의 값을 읽어야 하며(MUST), License 필드의 값은 반드시 무시해야 합니다(MUST).

License 필드만 존재하는 경우, 도구는 해당 필드가 폐지되었음을 사용자에게 알리고 대신 License-Expression을 사용하도록 권장하는 경고를 출력할 수 있습니다.

새로 업로드되는 모든 distribution archives 중 License-Expression 필드를 포함하는 것에 대해, Python Package Index (PyPI)는 License 필드와 License-Expression 필드를 모두 지정한 것을 반드시 거부해야 합니다.

License 필드는 향후 PEP를 통해 명세의 새 버전에서 제거될 수 있습니다.

라이선스 분류자 폐지

Classifier Core Metadata field에서 license classifiers를 사용하는 방식(Core Metadata 명세에 설명됨)은 폐지되며, 더 정확한 License-Expression 필드로 대체됩니다.

License-Expression 필드가 존재하는 경우, 빌드 도구는 Classifier 필드에 라이선스 분류자가 하나 이상 포함되어 있으면 오류를 발생시킬 수 있으며, 그러한 분류자를 스스로 추가해서는 안 됩니다.

그렇지 않은 경우, 이 필드에 라이선스 분류자가 포함되어 있으면 도구는 그러한 분류자가 폐지되었음을 사용자에게 알리고 대신 License-Expression을 사용하도록 권장하는 경고를 출력할 수 있습니다. 기존 게시 및 설치 절차와의 호환성을 위해, License-Expression도 함께 제공된 경우가 아니라면 라이선스 분류자가 있다는 이유로 오류를 발생시키지 않는 것이 좋습니다.

새로운 라이선스 분류자는 PyPI에 추가되어서는 안 되며, 이를 필요로 하는 사용자는 대신 License-Expression 필드를 사용하는 것이 좋습니다. 라이선스 분류자는 향후 PEP를 통해 명세의 새 버전에서 제거될 수 있습니다.

프로젝트 소스 메타데이터

이 PEP는 pyproject.toml 파일의 [project] 테이블 아래에 있는 프로젝트 소스 메타데이터의 변경 사항을 규정합니다.

license 키에 문자열 값 추가

[project] 테이블의 license 키는 최상위 문자열 값을 담도록 정의됩니다. 이 값은 이 PEP에서 정의한 유효한 SPDX 라이선스 표현식입니다. 이 값은 코어 메타데이터의 License-Expression 필드에 대응합니다.

빌드 도구는 License-Expression 필드 추가 절에 설명된 대로 표현식을 검증하고 대소문자 정규화를 수행하며, 규정된 대로 오류나 경고를 출력하는 것이 좋습니다.

예시:

[project]
license = "MIT"

[project]
license = "MIT AND (Apache-2.0 OR BSD-2-clause)"

[project]
license = "MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)"

[project]
license = "LicenseRef-Proprietary"

license-files 키 추가

[project] 테이블에 새로운 license-files 키가 추가됩니다. 이 키는 패키지와 함께 배포될 라이선스 및 기타 법적 고지가 담긴 파일의 경로를 지정하는 데 사용합니다. 경로는 프로젝트 소스 트리 안에서 pyproject.toml 기준 상대 경로로 지정합니다. 이 키는 코어 메타데이터의 License-File 필드에 대응합니다.

값은 문자열 배열이며, 아래에 명시된 대로 유효한 glob 패턴을 반드시 담고 있어야 합니다:

• 영숫자, 밑줄(_), 하이픈(-), 점(.)은 반드시 문자 그대로 일치해야 합니다.
• 특수 glob 문자인 *, ?, **와, 문자 그대로 일치하는 문자만 포함하는 문자 범위 []를 반드시 지원해야 합니다. [...] 안에서 하이픈은 로케일에 무관한 범위를 나타냅니다(예: a-z, 순서는 유니코드 코드 포인트를 기준으로 합니다). 시작이나 끝에 있는 하이픈은 문자 그대로 일치합니다.
• 경로 구분자는 반드시 슬래시 문자(/)여야 합니다. 패턴은 pyproject.toml이 있는 디렉터리를 기준으로 하는 상대 경로이므로, 맨 앞에 슬래시 문자를 사용해서는 안 됩니다.
• 상위 디렉터리 표시(..)를 사용해서는 안 됩니다.

이 명세에서 다루지 않는 문자나 문자 시퀀스는 유효하지 않습니다. 프로젝트는 이러한 값을 사용해서는 안 됩니다. 이 필드를 사용하는 도구는 유효하지 않은 값을 오류로 거부하는 것이 좋습니다.

도구는 라이선스 파일 내용이 유효한 UTF-8 인코딩 텍스트라고 반드시 가정해야 하며, 이를 검증하여 그렇지 않은 경우 오류를 발생시키는 것이 좋습니다.

리터럴 경로(예: LICENSE)도 유효한 glob으로 취급되므로, 리터럴 경로 역시 지정할 수 있습니다.

빌드 도구는 다음을 따릅니다:

• 각 값을 glob 패턴으로 취급해야 하며(MUST), 패턴에 잘못된 glob 문법이 포함되어 있으면 반드시 오류를 발생시켜야 합니다(MUST).
• 나열된 패턴과 일치하는 모든 파일을 반드시 모든 배포 아카이브에 포함해야 합니다.
• 일치하는 각 파일 경로를 코어 메타데이터의 License-File 필드에 반드시 나열해야 합니다(MUST).
• 사용자가 지정한 개별 패턴 중 하나라도 일치하는 파일이 하나도 없으면 반드시 오류를 발생시켜야 합니다.

license-files 키가 있고 그 값이 빈 배열로 설정되어 있으면, 도구는 어떤 라이선스 파일도 포함해서는 안 되며 오류를 발생시켜서도 안 됩니다.

유효한 라이선스 파일 선언의 예:

[project]
license-files = ["LICEN[CS]E*", "AUTHORS*"]

[project]
license-files = ["licenses/LICENSE.MIT", "licenses/LICENSE.CC0"]

[project]
license-files = ["LICENSE.txt", "licenses/*"]

[project]
license-files = []

유효하지 않은 라이선스 파일 선언의 예:

[project]
license-files = ["..\LICENSE.MIT"]

이유: ..을 사용해서는 안 됩니다. \는 유효하지 않은 경로 구분자이며, /를 사용해야 합니다.

[project]
license-files = ["LICEN{CSE*"]

이유: “LICEN{CSE*”는 유효한 glob이 아닙니다.

license 키의 테이블 하위 키 폐지

[project] 테이블의 license 키에 대한 테이블 값은 text 및 file 테이블 하위 키를 포함하여 이제 폐지되었습니다. 새 license-files 키가 있는 경우, license 키가 정의되어 있고 그 값이 단일 최상위 문자열이 아니면 빌드 도구는 반드시 오류를 발생시켜야 합니다.

새 license-files 키가 없고 license 테이블에 text 하위 키가 있으면, 도구는 경고를 표시하는 것이 좋습니다. 이 경고는 사용자에게 이것이 폐지되었음을 알리고, 대신 최상위 문자열 키로 라이선스 표현식을 사용하도록 권장해야 합니다.

마찬가지로, 새 license-files 키가 없고 license 테이블에 file 하위 키가 있으면, 도구는 경고를 표시하는 것이 좋습니다. 이 경고는 사용자에게 이것이 폐지되었음을 알리고, 대신 license-files 키를 사용하도록 권장해야 합니다.

지정된 라이선스 file이 소스 트리에 있으면, 빌드 도구는 이를 사용하여 코어 메타데이터의 License-File 필드를 채우는 것이 좋으며, 지정된 파일을 license-file 필드에 지정된 것처럼 반드시 포함해야 합니다. 지정된 경로에 파일이 존재하지 않으면, 도구는 앞서 명시한 대로 반드시 정보를 제공하는 오류를 발생시켜야 합니다.

license 키의 테이블 값은 향후 PEP에서 새 버전의 명세로부터 제거될 수 있습니다(MAY).

프로젝트 형식의 라이선스 파일

기존 명세에 몇 가지 내용이 추가됩니다.

프로젝트 소스 트리

프로젝트 소스 메타데이터 절에 따라 프로젝트 메타데이터 선언 명세는 라이선스 파일 경로가 반드시(MUST) 프로젝트 루트 디렉터리를 기준으로 한 상대 경로여야 한다는 점을 반영하도록 갱신됩니다. 프로젝트 루트 디렉터리는 pyproject.toml(또는 이에 상응하는 다른 레거시 프로젝트 구성 파일, 예: setup.py, setup.cfg 등)이 들어 있는 디렉터리입니다.

소스 배포판(sdist)

sdist 명세는 Metadata-Version이 2.4 이상이면 PKG-INFO의 License-File 필드에 지정된 모든 라이선스 파일을 sdist가 sdist의 (pyproject.toml과 PKG-INFO 코어 메타데이터가 들어 있는 곳)을 기준으로 한 각각의 경로에 반드시(MUST) 포함해야 한다는 점을 반영하도록 갱신됩니다.

빌드 배포판 (휠)

휠 명세는 Metadata-Version이 2.4 이상이고 License-File 필드가 하나 이상 지정된 경우 .dist-info 디렉터리가 반드시(MUST) licenses 하위 디렉터리를 포함해야 한다는 점을 반영하도록 갱신됩니다. 이 하위 디렉터리는 METADATA 파일의 License-File 필드에 나열된 파일을 licenses 디렉터리를 기준으로 한 각각의 경로에 반드시(MUST) 포함해야 합니다.

설치된 프로젝트

설치된 프로젝트 기록 명세는 두 가지 점을 반영하도록 갱신됩니다. 첫째, Metadata-Version이 2.4 이상이고 License-File 필드가 하나 이상 지정된 경우 .dist-info 디렉터리는 반드시(MUST) licenses 하위 디렉터리를 포함해야 하며, 이 하위 디렉터리는 METADATA 파일의 License-File 필드에 나열된 파일을 licenses 디렉터리를 기준으로 한 각각의 경로에 반드시(MUST) 포함해야 합니다. 둘째, 설치 도구는 이 디렉터리의 모든 파일을 반드시(MUST) 휠에서 복사해야 합니다.

레거시 메타데이터 변환

도구는 license.text [project] 키(또는 이에 상응하는 도구별 형식)의 내용, 라이선스 분류자, 코어 메타데이터 License 필드의 값을 사용하여 license 키의 최상위 문자열 값이나 코어 메타데이터 License-Expression 필드를 채워서는 안 됩니다(MUST NOT). 단, 사용자에게 이를 알리고, 진행하기 전에 사용자가 원하는 라이선스 표현식 값을 선택하고 확인하는 명확하고 적극적인 행동을 요구하는 경우는 예외입니다.

라이선스 분류자를 SPDX 식별자로 자동 변환해야 하는 도구 작성자는 PEP 작성자들이 마련한 권장 사항을 사용할 수 있습니다.

하위 호환성

새로운 License-Expression 코어 메타데이터 필드와 pyproject.toml [project] 테이블의 license 키에 대한 최상위 문자열 값을 추가하는 것은 이 PEP의 명세를 지원한다는 뜻임이 명확합니다. 이를 통해 새로운 도구가 라이선스 표현식을 자유 형식의 라이선스 설명으로 잘못 해석하거나 그 반대로 해석할 위험을 피할 수 있습니다.

폐기 예정인 레거시 코어 메타데이터 License 필드, pyproject.toml [project] 테이블의 license 키 테이블 하위 키(text와 file), 라이선스 분류자는 하위 호환성을 유지합니다. 이들의 제거는 향후 PEP와 새 버전의 코어 메타데이터 명세에 맡깁니다.

새로운 License-File 코어 메타데이터 필드의 명세와 배포판에 파일을 추가하는 방식은 여러 패키징 도구에서 이 필드를 사용해 온 기존 방식과 대체로 하위 호환되도록 설계되었습니다. pyproject.toml의 [project] 테이블에 새로 추가되는 license-files 키는 사용자와 도구가 이를 채택해야만 효과가 있습니다.

이 PEP는 라이선스 파일을 .dist-info 디렉터리의 전용 licenses 하위 디렉터리에 두어야 한다고 규정합니다. 이는 새로운 방식이며, 이 PEP를 따르는 휠의 라이선스가 이전의 설치 프로그램별 동작으로 생성된 휠의 라이선스와 다른 위치에 놓이도록 보장합니다. 새로운 메타데이터 버전이 이를 한층 더 뒷받침합니다.

또한 이는 서로 다른 위치에 있는 라이선스 파일의 이름이 같을 때 파일이 실수로 덮어써져, 알아차리지 못한 채 휠을 배포할 수 없게 되는 현재의 문제도 해결합니다. 또한 같은 디렉터리에 있는 다른 메타데이터 파일과의 충돌도 방지합니다.

소스 배포판(sdist), 빌드 배포판(휠), 설치된 프로젝트 명세에 내용이 추가됩니다. 이러한 추가 내용은 현재 명세에서 허용되는 동작을 문서화하고, 새로운 메타데이터 버전에서만 그 동작이 적용되도록 제한합니다.

이 PEP는 PyPI가 새로운 License-Expression 및 License-File 필드에 대한 유효성 검사를 구현할 것을 제안합니다. 이 검사는 새로 업로드되는 패키지와 기존 패키지가 이 새 필드를 명시적으로 사용하기로 선택하고도 명세를 올바르게 따르지 않은 경우가 아니라면 아무런 영향을 주지 않습니다. 따라서 이는 하위 호환성에 영향을 주지 않으며, 새 필드와 함께 PyPI에 업로드되는 모든 배포판이 명세를 준수하도록 보장함으로써 상위 호환성을 보장합니다.

보안 영향

이 PEP에는 예상되는 보안상의 영향이 없습니다. License-Expression 필드는 일반 문자열이고 License-File 필드는 파일 경로입니다. 둘 중 어느 쪽도 알려진 새로운 보안 우려를 일으키지 않습니다.

교육 방법

대다수의 패키지는 단일 라이선스를 사용하므로 이 경우는 간단합니다. 단일 라이선스 식별자는 그 자체로 유효한 라이선스 표현식입니다.

패키징 도구 사용자는 도구가 유효하지 않은 라이선스 표현식을 감지하거나 폐기 예정인 License 필드 또는 라이선스 분류자가 사용되었을 때 도구가 내보내는 메시지를 통해 자기 패키지의 유효한 라이선스 표현식을 알게 됩니다.

유효하지 않은 License-Expression을 사용하면 사용자는 패키지를 PyPI에 게시할 수 없으며, 오류 메시지를 통해 SPDX 식별자를 사용해야 한다는 점을 이해하게 됩니다. 잘못된 라이선스 메타데이터를 가진 배포본을 생성할 수는 있지만, 이를 PyPI나 License-Expression의 유효성을 강제하는 다른 색인 서버에 게시할 수는 없습니다. 이제 폐기 예정이 된 License 필드나 라이선스 분류자를 사용하는 작성자에게는 패키징 도구가 경고하고, 이를 대체하는 License-Expression을 안내할 수 있습니다.

도구는 변환을 돕고, 여러 일반적인 경우에 라이선스 표현식을 제안할 수도 있습니다.

• 부록 부록: 라이선스 분류자를 SPDX 식별자에 매핑하기에서는 레거시 분류자로부터 만든 라이선스 표현식을 제안하는 방법에 대한 권고를 도구 작성자에게 제공합니다.
• 도구는 프로젝트 소스 메타데이터에 있는 기존 License 값을 갱신하여 라이선스 표현식으로 변환하는 방법을 제안할 수도 있으며, 이는 이 PEP에서도 명시한 바와 같습니다.

참조 구현

도구가 명세의 이 부분을 구현하기로 결정한다면 License-Expression 필드에 있는 라이선스 표현식의 구문 분석과 유효성 검사를 지원해야 합니다. 유효성 검사를 도구 자체에서 구현할지(예: hatch), 사용 가능한 Python 라이브러리 중 하나를 사용할지(예: license-expression)는 도구가 결정할 일입니다. 이 PEP는 특정 라이브러리의 사용을 의무화하지 않으며, 각 프로젝트에 가장 적합한 구현을 선택하는 일은 도구 작성자에게 맡깁니다.

기각된 아이디어

많은 대안 아이디어가 제안되었으나 신중한 검토 끝에 거부되었습니다. 거부 근거를 포함한 전체 목록은 별도 페이지에서 확인할 수 있습니다.

부록

보조 문서 목록은 다음과 같습니다.

• 상세한 라이선스 예제,
• 사용자 시나리오,
• Python 및 기타 프로젝트의 라이선스 문서,
• 라이선스 분류자와 SPDX 식별자 간 매핑,
• 거부된 아이디어 상세 설명.

참고 문헌

감사의 글

• Alyssa Coghlan
• Kevin P. Fleming
• Pradyun Gedam
• Oleg Grenrus
• Dustin Ingram
• Chris Jerdonek
• Cyril Roelandt
• Luis Villa
• Seth M. Larson
• Ofek Lev

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.