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

번역·라이선스 안내

이 비공식 한국어 번역은 원문 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 프로젝트에서 라이선스를 문서화하는 방법에 대한 사양을 정의합니다.

이를 달성하기 위해 다음을 수행합니다:

Python 프로젝트의 라이선스를 표현하는 수단으로 SPDX license expression syntax을 채택합니다.
프로젝트, 소스 배포판 및 빌드된 배포판에 라이선스 파일을 포함하는 방법을 정의합니다.
필요한 변경 사항과 이에 대응하는 Core Metadata 및 Pyproject Metadata keys을 지정합니다.
source distribution (sdist), built distribution (wheel) 및 installed project 표준에 필요한 변경 사항을 설명합니다.

이를 통해 패키지 작성자가 라이선스를 더 간단하고 모호하지 않게 선언하고, 최종 사용자가 이해하며, 도구가 프로그래밍 방식으로 처리할 수 있게 됩니다.

이러한 변경 사항은 Core Metadata specification을 버전 2.4로 갱신합니다.

목표

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

SPDX license expression을 지정하는 수단입니다.
관련 배포 패키지s 및 설치된 프로젝트s에 라이선스 텍스트를 포함하는 방법입니다.

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

목표가 아닌 사항

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

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

또한 이 PEP는 개별 파일의 라이선스 문서화에 관한 것이 아닙니다. 부록에서 이는 surveyed topic이지만, source distribution과 binary distribution 패키지에 동일한 라이선스가 없는 경우를 다루려는 것도 아닙니다.

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

이로 인해 outdated and ambiguous PyPI classifiers에 대한 논의와 이슈, license interoperability with other ecosystems에 대한 논의와 이슈, too many confusing license metadata options에 대한 논의와 이슈, limited support for license files in the Wheel project에 대한 논의와 이슈, 그리고 the lack of precise license metadata에 대한 논의와 이슈를 비롯한 여러 라이선스 관련 논의와 이슈가 촉발되었습니다.

그 결과 Python 패키지는 평균적으로 다른 일반적인 생태계보다 더 모호하고 누락된 라이선스 정보를 갖는 경향이 있습니다. 이는 PyPI, Maven, npm 및 Rubygems의 모든 패키지를 대상으로 다른 FOSS 프로젝트의 라이선스 명확성을 개선하려는 Open Source Initiative의 활동인 ClearlyDefined project의 statistics page에서 뒷받침됩니다.

현재 라이선스 분류자는 모호한 분류자(예: License :: OSI Approved :: BSD License)를 더 이상 사용하지 않도록 하면서 SPDX 식별자의 전체 범위를 포함하도록 확장할 수 있습니다.

그러나 이러한 접근 방식에 반대하는 주장은 여러 가지가 있습니다.

SPDX 라이선스 목록을 복제하고 동기화된 상태로 유지하려면 많은 노력이 필요합니다.
이는 하위 호환성을 완전히 깨뜨리는 변경으로, PyPI가 기존 분류자의 사용을 중단하면 패키지 작성자가 즉시 새로운 분류자로 업데이트해야 합니다.
이는 단일 라이선스가 적용되는 패키지만 다룹니다. 종속성을 함께 제공하는 프로젝트(예: Setuptools), 여러 라이선스 중 하나를 선택할 수 있도록 하는 프로젝트(예: Packaging), 라이선스를 변경한 프로젝트, 다른 프로젝트의 코드를 적용한 프로젝트 또는 다른 라이선스가 적용되는 글꼴, 이미지, 예제, 바이너리 및 기타 자산을 포함하는 프로젝트는 다루지 않습니다.
작성자와 도구 모두 PyPI별 분류자 시스템을 이해하고 구현해야 합니다.
패키지가 새 시스템을 채택했음을 나타내는 지표로는 그다지 명확하지 않으므로, 이에 맞게 처리해야 합니다.

근거

기존 라이선스 메타데이터 정의를 파악하기 위해 Python ecosystem 및 variety of other packaging systems, Linux distributions, language ecosystems and applications에 대한 조사를 수행했습니다.

이 조사에서 도출된 시사점은 이 PEP의 권고 사항을 수립하는 데 지침이 되었습니다.

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

따라서 이 PEP는 두 개의 새로운 Core Metadata 필드를 도입합니다.

License-Expression은 SPDX 라이선스 표현을 사용하여 패키지의 라이선스를 모호하지 않게 표현하는 방법을 제공합니다.
License-File은 패키지를 배포할 때 라이선스 전문을 패키지에 포함하는 표준화된 방법을 제공하며, Core Metadata를 사용하는 다른 도구가 distribution archive의 라이선스 파일을 찾을 수 있도록 합니다.

또한 이 명세는 Setuptools 및 Wheel 프로젝트의 기존 관행을 기반으로 합니다. 이 PEP의 현재 초안 최신 버전은 Hatch 패키징 도구에 implemented되어 있으며, license files portion의 이전 초안은 implemented in Setuptools되어 있습니다.

용어

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

라이선스 용어

라이선스 관련 용어는 특히 license identifier 및 license expression을 비롯하여 SPDX Project에서 많은 부분을 차용했습니다.

라이선스 분류자: License ::로 시작하는 PyPI Trove classifier입니다( described Core Metadata 명세에 설명되어 있습니다).
라이선스 표현: 하나 이상의 SPDX license identifier(s)를 포함하며, Project의 라이선스(s)와 라이선스 간의 관계를 설명하는 유효한 SPDX license expression syntax의 문자열입니다. 예: GPL-3.0-or-later, MIT AND (Apache-2.0 OR BSD-2-clause)
라이선스 식별자: 이 PEP의 License-Expression 필드 추가 절에 설명된 유효한 SPDX short-form license identifier입니다. 여기에는 유효한 모든 SPDX 식별자와 SPDX specification, clause 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를 구현하는 데 필요한 변경 사항은 다음을 포함합니다.

specification에 정의된 Core Metadata의 추가 사항입니다.
specification에 정의된 저자 제공 project source metadata의 추가 사항입니다.
additions은 소스 배포판(sdist), 빌드 배포판(wheel) 및 설치된 프로젝트 명세에 대한 추가 사항입니다.
결과가 일관되고 정확하도록 레거시 라이선스 메타데이터를 라이선스 표현식으로 처리하고 변환하는 도구를 위한 guide for tools입니다.

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

SPDX 라이선스 표현식 구문

이 PEP는 SPDX specification에 문서화된 SPDX 라이선스 표현식 구문을 채택하며, 버전 2.2 또는 이후의 호환 가능한 버전을 사용합니다.

라이선스 표현식에는 다음과 같은 license identifiers를 사용할 수 있습니다.

버전 3.17 또는 이후의 호환 가능한 버전인 SPDX License List에 게시된 모든 SPDX 등재 라이선스 약식 식별자입니다. SPDX 작업 그룹은 라이선스 식별자를 절대 제거하지 않으며, 대신 식별자를 “deprecated”로 표시할 수 있음에 유의하십시오.
SPDX 라이선스 목록에 포함되지 않은 라이선스를 식별하기 위한 사용자 지정 LicenseRef-[idstring] 문자열로, 여기서 [idstring]은 문자, 숫자, . 및/또는 -를 포함하는 고유한 문자열입니다. 사용자 지정 식별자는 해당 사양 버전의 SPDX specification, clause 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

Core Metadata

이 섹션의 오류 및 경고 지침은 빌드 및 게시 도구에 적용됩니다. 최종 사용자 대상 설치 도구는 이 사양을 준수하지 않는 잘못된 메타데이터를 발견할 때 여기에서 언급한 것보다 덜 엄격할 수 있습니다.

새 필드를 추가하므로 이 PEP는 Core Metadata 버전을 2.4로 업데이트합니다.

`License-Expression` 필드 추가

License-Expression 선택적 Core Metadata field는 defined above에 정의된 유효한 SPDX license expression인 텍스트 문자열을 포함하도록 지정됩니다.

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

License-Expression 필드를 포함하는 새로 업로드된 모든 distribution archives에 대해 Python Package Index (PyPI)는 해당 파일에 유효한 식별자를 포함하는 유효하고 대소문자가 정규화된 라이선스 표현식이 있는지 검증해야 하며( defined above에 정의됨), 그렇지 않은 업로드는 거부해야 합니다. SPDX 사양을 준수하는 사용자 지정 라이선스 식별자는 유효한 것으로 간주됩니다. 위에서 언급한 SPDX License List 버전 기준으로 deprecated된 라이선스 식별자를 사용한 경우 PyPI는 업로드를 거부할 수 있습니다.

`License-File` 필드 추가

License-File은 선택적 Core Metadata field입니다. 각 인스턴스에는 라이선스 관련 파일 경로의 문자열 표현이 포함됩니다. 경로는 project source tree 내에 있으며 project root directory를 기준으로 합니다. 이 필드는 여러 번 사용할 수 있으며 0회 이상 나타날 수 있고, 각 인스턴스에는 해당 파일 하나의 경로가 나열됩니다. 이 필드에 지정된 파일에는 패키지와 함께 배포해야 하는 라이선스 텍스트, 저자/귀속 정보 또는 기타 법적 고지가 포함될 수 있습니다.

이 PEP에서 specified by this PEP로 지정한 대로, 그 값은 installed projects및 표준화된 Distribution Package 유형 모두에서 해당 파일의 root license directory 기준 경로이기도 합니다.

License-File이 Source Distribution 또는 Built Distribution의 Core Metadata에 나열된 경우:

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

빌드 도구는 빌드된 배포판의 메타데이터에 License-File 항목이 없을 경우 설명적인 경고를 출력할 수 있으며, 게시 도구는 출력해야 합니다. 게시 도구는 오류를 발생시킬 수 있지만, 빌드 도구는 오류를 발생시켜서는 안 됩니다.

하나 이상의 License-File 필드를 Core Metadata에 포함하고 Metadata-Version을 2.4 이상으로 선언하는 새로 업로드된 모든 distribution archives에 대해 PyPI는 지정된 모든 파일이 해당 distribution archives에 존재하는지 검증해야 하며, 검증에 실패하는 업로드는 반드시 거부해야 합니다.

`License` 필드 사용 중단

레거시 비구조화 텍스트 License Core Metadata field는 더 이상 사용되지 않으며 새로운 License-Expression 필드로 대체됩니다. 이 필드들은 상호 배타적입니다. Core Metadata를 생성하는 도구는 이 두 필드를 모두 생성해서는 안 됩니다. Core Metadata를 읽는 도구는 두 필드가 동시에 존재하는 경우 License-Expression의 값을 읽고 License 필드의 값은 반드시 무시해야 합니다.

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

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

향후 PEP에서 새로운 버전의 사양이 제정될 때 License 필드가 제거될 수 있습니다.

라이선스 분류자 사용 중단

Classifier Core Metadata field에서 license classifiers를 사용하는 것은 더 이상 사용되지 않으며, 더 정확한 License-Expression 필드로 대체됩니다(described in the Core Metadata specification).

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

그렇지 않고 이 필드에 라이선스 분류자가 포함되어 있으면, 도구는 사용자에게 그러한 분류자가 더 이상 사용되지 않음을 알리고 대신 License-Expression을 사용할 것을 권고하는 경고를 출력할 수 있습니다. 기존 게시 및 설치 프로세스와의 호환성을 위해, License-Expression도 함께 제공되지 않는 한 라이선스 분류자가 존재하더라도 오류가 발생해서는 안 됩니다.

새 라이선스 분류자는 added to PyPI해서는 안 되며, 이를 필요로 하는 사용자는 대신 License-Expression 필드를 사용해야 합니다. 향후 PEP에서 새로운 버전의 사양이 제정될 때 라이선스 분류자가 제거될 수 있습니다.

프로젝트 소스 메타데이터

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

`license` 키에 문자열 값 추가

[project] 테이블의 license 키는 최상위 문자열 값을 포함하도록 정의됩니다. 이는 defined in this 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` 키 추가

패키지와 함께 배포할 라이선스 및 기타 법적 고지를 포함하는 파일의 경로를 pyproject.toml을 기준으로 프로젝트 소스 트리 내에서 지정할 수 있도록 [project] 테이블에 새로운 license-files 키가 추가됩니다. 이는 Core Metadata의 License-File 필드에 대응합니다.

해당 값은 아래에 명시된 대로 유효한 glob 패턴을 반드시 포함해야 하는 문자열 배열입니다:

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

이 사양에서 다루지 않는 모든 문자 또는 문자 시퀀스는 유효하지 않습니다. 프로젝트는 그러한 값을 사용해서는 안 됩니다. 이 필드를 사용하는 도구는 오류와 함께 유효하지 않은 값을 거부해야 합니다.

도구는 라이선스 파일 콘텐츠가 유효한 UTF-8 인코딩 텍스트라고 가정해야 하며, 이를 검증하고 그렇지 않으면 오류를 발생시켜야 합니다.

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

빌드 도구:

각 값을 glob 패턴으로 취급해야 하며, 패턴에 유효하지 않은 glob 구문이 포함되어 있으면 오류를 발생시켜야 합니다.
나열된 패턴과 일치하는 모든 파일을 모든 배포 아카이브에 포함해야 합니다.
일치하는 각 파일 경로를 Core Metadata의 License-File 필드에 나열해야 합니다.
사용자가 지정한 개별 패턴이 하나 이상의 파일과 일치하지 않으면 오류를 발생시켜야 합니다.

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에서 사양의 새 버전으로 제거될 수 있습니다.

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

기존 사양에 몇 가지 추가 사항이 적용됩니다.

프로젝트 소스 트리s: 해당 프로젝트 소스 메타데이터 섹션에 따르면, Declaring Project Metadata specification은 라이선스 파일 경로가 프로젝트 루트 디렉터리에 상대적이어야 한다는 점을 반영하도록 업데이트됩니다. 즉, pyproject.toml을 포함하는 디렉터리이며, 동등하게 setup.py, setup.cfg 등과 같은 기존 프로젝트 구성 파일을 포함하는 디렉터리입니다.
소스 배포판(sdist): Metadata-Version이 2.4 이상인 경우 sdist가 License-File 필드에 지정된 모든 라이선스 파일을 PKG-INFO에 포함하고, 해당 파일을 sdist의 을 기준으로 한 각 경로에 배치해야 함을 반영하도록 sdist 사양이 업데이트됩니다(pyproject.toml 및 PKG-INFO 핵심 메타데이터를 포함함).
빌드 배포판s (wheels): Metadata-Version이 2.4 이상이고 하나 이상의 License-File 필드가 지정된 경우, .dist-info 디렉터리에 licenses 하위 디렉터리가 있어야 하며, 이 하위 디렉터리에 METADATA 파일의 License-File 필드에 나열된 파일을 licenses 디렉터리에 상대적인 각 경로에 포함해야 함을 반영하도록 Wheel 사양이 업데이트됩니다.
설치된 프로젝트s: Metadata-Version이 2.4 이상이고 하나 이상의 License-File 필드가 지정된 경우, .dist-info 디렉터리에 licenses 하위 디렉터리가 있어야 하며, 이 하위 디렉터리에 METADATA 파일의 License-File 필드에 나열된 파일을 licenses 디렉터리에 상대적인 각 경로에 포함해야 하고, 이 디렉터리의 모든 파일을 설치 도구가 wheel에서 복사해야 함을 반영하도록 설치된 프로젝트 기록 사양이 업데이트됩니다.

레거시 메타데이터 변환

도구는 사용자에게 알리고, 진행하기 전에 원하는 라이선스 표현식 값을 선택하고 확인하도록 모호하지 않은 긍정적 사용자 작업을 요구하지 않는 한, license.text [project]키(또는 이에 상응하는 도구별 형식)의 내용, 라이선스 분류자 또는 핵심 메타데이터 License 필드의 값을 사용하여 license키의 최상위 문자열 값이나 핵심 메타데이터 License-Expression 필드의 값을 채워서는 안 됩니다.

라이선스 분류자를 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를 따르는 wheel의 라이선스가 이전의 설치 도구별 동작으로 생성된 라이선스와 비교하여 서로 다른 위치에 배치되도록 보장합니다. 이는 새로운 메타데이터 버전을 통해 추가로 뒷받침됩니다.

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

소스 배포판(sdist), 빌드 배포판(wheel) 및 설치된 프로젝트 사양에 추가 사항이 적용됩니다. 이러한 추가 사항은 현재 사양에서 허용되는 동작을 문서화하고, 새로운 메타데이터 버전이 적용되는 경우에만 해당 동작을 허용합니다.

이 PEP는 새로운 License-Expression 및 License-File 필드의 유효성 검사를 PyPI가 구현할 것을 제안하며, 새 필드 사용을 명시적으로 선택하고 사양을 올바르게 따르지 않는 경우를 제외하면 업로드된 신규 및 기존 패키지에 영향을 주지 않습니다. 따라서 이는 하위 호환성에 영향을 주지 않으며, 새 필드와 함께 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는 특정 라이브러리의 사용을 의무화하지 않으며, 도구 작성자가 각 프로젝트에 가장 적합한 구현을 선택하도록 맡깁니다.

Alyssa Coghlan
Kevin P. Fleming
Pradyun Gedam
Oleg Grenrus
더스틴 잉그램
크리스 제도넥
시릴 로엘란트
루이스 빌라
세스 M. 라슨
오펙 레브

Copyright

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

Python 개선 제안 한국어 번역