Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

부록: 거부된 아이디어

초록

이 문서는 PEP 639에서 제안된 아이디어의 대안 목록과 해당 대안이 거부된 이유에 대한 자세한 설명을 담고 있습니다.

핵심 메타데이터 필드

다음은 PEP 639에서 지정한 Core Metadata 필드의 구조, 내용 및 사용 중단에 대한 잠재적 대안입니다.

License 필드 재사용

초기 논의에 따라, PEP 639의 초기 버전에서는 기존 License 필드를 재사용하여 도구가 해당 필드를 SPDX 라이선스 표현식으로 구문 분석하고, 실패할 경우 자유 텍스트로 대체하도록 제안했습니다. 처음에는 이로 인해 경고가 발생하고, 결국 오류로 처리될 예정이었습니다.

이는 하위 호환성이 더 높고, 커뮤니티에서 SPDX 라이선스 표현식을 원활하게 도입할 수 있게 하며, 라이선스 관련 필드를 또 하나 추가하지 않아도 된다는 장점이 있었습니다.

결국 전용 License-Expression 필드를 사용하는 것이 더 나은 접근 방식이라는 합의에 도달했습니다. 이 필드의 존재는 복잡한 휴리스틱 없이도 SPDX 식별자 지원을 명확하게 나타내며, 도구가 유효하지 않은 콘텐츠를 쉽게 감지할 수 있게 합니다.

또한 기존 License 필드와 라이선스 분류자를 모두 쉽게 사용 중단할 수 있고, 도구가 패키지가 PEP 639를 준수하는지 여부를 구분하여 그에 맞게 동작을 조정할 수 있게 합니다.

마지막으로 기존 메타데이터 필드의 동작을 변경하지 않아도 되며, 도구가 단순히 필드의 존재 여부가 아니라 해당 값에 따라 Metadata-Version 및 필드 동작을 추측해야 하는 상황도 방지합니다.

License 필드에 이미 유효한 SPDX 라이선스 표현식을 포함한 배포 패키지는 자동으로 그러한 패키지로 인식되지 않습니다. 그러나 마이그레이션은 간단하며, PEP 639에서는 도구를 통해 이를 자동으로 수행하는 방법을 안내합니다.

값 접두사를 사용하여 License 필드 재사용

앞선 대안으로, License 필드를 재사용할 때의 모호성을 줄이기 위해 SPDX 라이선스 표현식 앞에 예를 들어 spdx:를 붙이자는 제안이 있었습니다. 그러나 이는 사실상 필드 안에 필드를 만드는 것과 같으며, License 필드를 유지할 때의 단점을 해결하지 못합니다. 즉, 여전히 기존 메타데이터 필드의 동작을 변경하고, 도구가 콘텐츠를 어떻게 처리할지 결정하기 위해 해당 값을 구문 분석해야 하며, 명세 및 사용 중단 절차를 더 복잡하고 덜 깔끔하게 만듭니다.

현재 License 필드에서 유효한 SPDX 식별자를 사용하는 프로젝트는 자동으로 인식되지 않으며, 새 필드를 도입하는 경우와 거의 같은 노력을 들여 수정해야 합니다. 즉, 프로젝트의 원본 메타데이터에서 한 줄을 변경해야 합니다. 따라서 새 필드를 선호하여 이 대안은 거부되었습니다.

License-Expression을 상호 배타적으로 만들지 않기

하위 호환성을 위해 새 License-Expression 필드와 함께 License 필드 및/또는 라이선스 분류자를 계속 허용하고, 아마도 경고를 표시할 수도 있었습니다. 그러나 이는 서로 일관되지 않는 라이선스 메타데이터가 무려 세 개의 서로 다른 필드에 존재하는 상황으로 쉽게 이어질 수 있으며, 이는 라이선스 관련 사항을 명확하게 만드는 PEP 639의 목표에 어긋납니다. 따라서 커뮤니티의 합의에 따라 이 아이디어는 거부되었습니다.

기존 License 필드 및 분류자의 사용을 중단하지 않기

일부 커뮤니티 구성원은 기존 License 필드 및 분류자의 사용을 중단하면 패키지 작성자에게 상당한 변경 부담이 발생하고 신규 작성자의 진입 장벽이 높아질 것이라고 우려했습니다. 특히 법적 세부 사항을 지나치게 신경 쓰지 않고 개인 프로젝트를 패키징하려는 개발자에게 그러했습니다. 실제로 모든 사용 중단은 장기적인 순편익을 고려하여 신중하게 검토해야 합니다. 최소한 이 변경으로 인해 Python 개발자가 원하는 라이선스에 따라 자신의 작업물을 공유하기가 더 어려워져서는 안 되며, 이상적으로는 상황이 개선되어야 합니다.

여러 차례의 논의를 거친 후, 일반적인 합의는 라이선스를 지정하는 기존 방식을 사용 중단하고 “이를 수행하는 하나의 명확한 방법”을 선호하는 쪽으로 기울었습니다. 그렇게 하지 않으면 패키지의 라이선스를 지정하는, 사용 중단되지 않은 서로 다른 세 가지 방법이 남게 되며, 그중 두 가지는 모호하고 문서화가 일관되지 않으며 시대에 뒤처진 상태가 됩니다. 이는 도구가 무기한 지원하기에 더 복잡하며, 무시할 수 없는 유지 관리 비용을 초래합니다.

마지막으로, 유지 관리되지 않는 패키지, 이전 메타데이터 버전을 지원하는 도구를 사용하는 패키지 또는 라이선스 메타데이터를 제공하지 않기로 선택한 패키지의 경우에는 해당 지원 중단과 관계없이 변경할 필요가 없습니다.

PyPI에서 새 필드의 유효성 검사를 의무화하지 않기

이전에 PEP 639는 PyPI(또는 다른 패키지 색인)가 License-Expression 또는 License-File 필드를 검증해야 하는지와 검증한다면 어떻게 해야 하는지에 대한 구체적인 지침을 제공하지 않았으며, 더 이상 사용되지 않는 License 필드 또는 라이선스 분류자와 함께 이 필드들을 사용하는 경우 어떻게 처리해야 하는지도 제시하지 않았습니다. 이렇게 하면 사양이 단순해지고 PyPI에서의 구현을 이후 PEP로 미루어 패키지 작성자의 혼란을 최소화할 수 있습니다.

이는 License-Expression을 License 필드와 분리하지 않았던 PEP 639의 초기 초안에 적용되어 있었습니다. 유효성 검사는 어려웠을 뿐 아니라 하위 호환성을 깨뜨려 기존 패키지를 손상했을 것입니다. 현재 제안에서는 새 필드를 처음부터 검증해야 한다는 명확한 합의가 있었습니다. 이에 따라 Core Metadata 버전 2.4 이상을 선언하고 License-Expression 필드를 포함하여 PyPI에 업로드된 모든 배포 패키지가 유효한 표현식을 갖도록 보장되며, PyPI와 해당 패키지 및 메타데이터의 소비자는 이 문서의 사양을 따를 수 있습니다.

이는 새 License-File 필드에도 동일하게 적용하여 해당 필드가 유효하고 법적으로 요구되는 라이선스 파일이 존재하도록 보장할 수 있습니다. 명확히 하자면, 업로드되는 모든 배포 패키지가 이러한 메타데이터를 갖도록 요구하는 것은 아니며, PEP 639의 사양에 따라 이를 선언하기로 선택한 경우에만 유효함이 보장됩니다.

소스 메타데이터 license 키

pyproject.toml 프로젝트 소스 메타데이터의 license 키와 관련하여 고려한 대안입니다.

테이블에 새 하위 키 추가

테이블에 다양한 하위 키를 추가하자는 제안이 있었습니다. 서로 다른 처리가 필요한 여러 유형의 메타데이터를 결합하고, 하위 키의 상호 배타성에 관한 새로운 지침과 그중 일부를 동적으로 정의할 가능성을 추가하면 전환이 더 어려워지고 사용자에게 명확성보다 더 큰 혼란을 초래할 수 있습니다. 이 접근 방식은 더 평면적인 pyproject.toml 설계, pyproject.toml 키와 Core Metadata 필드 간의 명확한 매핑, 그리고 개별 키의 향상된 가독성을 위해 거부되었습니다.

거부된 제안:

  • 테이블에 expression 및 files 하위 키 추가
  • 문자열 값 대신 expression 하위 키 추가
  • text를 표현식으로 처리하도록 type 키 추가

새로운 최상위 license-expression 키 정의

PEP 639의 이전 버전에서는 license 키의 문자열 값을 사용하는 대신 [project] 테이블 아래에 새로운 최상위 license-expression을 정의했습니다. 이는 PEP 639의 목표에 부합하며 독자와 작성자에게 더 명확한 것으로 여겨졌습니다.

기존 도구 형식(및 Core Metadata 필드 이름)과의 차이는 PEP 621에 선례가 있지만, 기존 키의 의미를 다른 것으로 바꾸고(다른 Core Metadata 필드에 매핑하며) 서로 다르고 호환되지 않는 구문을 사용하도록 하는 데에는 선례가 없습니다. 이는 독자와 작성자에게 모호성을 초래할 수 있습니다.

또한 project source metadata spec에 따라, [project] 키에서 License 및 License-Expression 메타데이터 필드에 대응하는 항목을 각각 dynamic으로 표시할 수 있으므로, PEP 639가 현재 허용하는 것처럼 License-Expression 필드에서 License 필드를 보완할 때 발생할 수 있는 우려를 피할 수 있습니다. 단, 이를 license가 동적으로 설정된 경우로 하지 않으면 이러한 방식은 불가능합니다(두 필드가 모두 동일한 최상위 키에 매핑되기 때문입니다).

그러나 커뮤니티의 합의는 기존 license 키의 최상위 문자열 값을 사용하는 쪽을 선호했으며, 이는 PEP 621에서 이 목적을 위해 예약됨에 따른 것입니다.

라이선스 키에 사용할 실용적인 문자열 값은 향후 PEP에서 SPDX 표현식 지원을 지정할 수 있도록 의도적으로 제외되었습니다(파일 또는 텍스트가 나타내는 라이선스를 지정하는 모든 종류의 “type” 필드에도 동일한 논리가 적용됩니다).

이는 사용자가 기억하고 입력하기 더 쉽고, 기존 키를 활용하면서 새 최상위 키를 추가하지 않아도 되며, 사용자가 기본값으로 라이선스 표현식을 사용하도록 유도하고, 원래 PEP 621에서 구상한 방식도 따릅니다.

또한 키 자체는 지원 중단하지 않고 테이블 값을 깔끔하게 지원 중단할 수 있으며, 사용자가 이를 기억하거나 도구가 이를 적용할 필요 없이 서로 배타적으로 만들 수 있습니다.

마지막으로, 다른 도구 형식 및 기본 Core Metadata와의 일관성은 기존 키를 사용하는 이점을 무시할 만큼 충분히 중요한 우선순위가 아니었습니다. 또한 빌드 시 레거시 라이선스에서 라이선스 표현식으로 변환하도록 지정하지 않고, dynamic이 아닌 경우 License 필드를 명시적으로 보완하도록 지정했으며, 두 필드가 서로 배타적이라는 사실로 dynamic 관련 우려가 대부분 완화되었습니다. 따라서 어느 필드가 동적인지 구별할 실질적인 필요성은 거의 없습니다.

따라서 PEP 639에서는 이전 작업 초안에서 일시적으로 지정했던 것처럼 license의 최상위 문자열 값을 채택했습니다.

소스 메타데이터 license-files 키

pyproject.toml의 [project] 테이블에 있는 license-files 키에 대해 고려한 대안이며, 주로 경로/글로브 유형 처리와 관련되어 있습니다.

license-files에 상호 배타적인 paths 및 globs 하위 키를 정의합니다.

PEP의 이전 초안에서는 license-files[project] 테이블 키에 상호 배타적인 paths 및 globs 하위 키를 지정했습니다. 이는 사용자와 도구 모두에게 정의된 값의 명확성을 극대화하기 위해 제안되었습니다. 라이선스 파일을 리터럴 경로로 지정하도록 허용하면 글롭 문자를 포함하는 경우(또는 PEP 672에서 설명한 것처럼 글롭 문자와 혼동하기 쉬운 경우)와 같은 예외적인 상황을 피할 수 있습니다.

그러나 이 접근 방식은 PEP 639가 license키에서 제거한 것과 동일한 방식으로 중첩 수준을 한 단계 추가합니다. 이로 인해 프로젝트 작성자는 라이선스 파일 위치를 지정할 때 어느 접근 방식을 선택할지 구분해야 하므로 부담이 커집니다. 경로도 글롭을 지원한다고 잘못 추정하기가 매우 쉽다는 지적이 있었습니다.

따라서 명세와 구현을 단순화하고 기존 도구의 구성 형식과 더욱 밀접하게 일치하는 평면 배열 값을 채택하는 대신 이 접근 방식은 배제하기로 결정했습니다. PEP에서는 글롭 패턴을 해석할 때 혼동이 발생하지 않도록 파일 이름에 영숫자 기호와 점(.) 이외의 기호를 사용하지 않을 것을 권장합니다.

리터럴 경로만 허용합니다.

pyproject.toml의 license-files키 값으로 글롭을 허용하지 않고 리터럴 경로만 허용할 수 있습니다. 이렇게 하면 모든 라이선스 파일이 명시적으로 지정되고, 발견되어 포함되며, 도구가 포함될 라이선스 파일과 License-File값이 정확히 무엇인지 판단하기 위해 프로젝트 소스 파일의 나머지 부분을 검사하지 않아도 소스 메타데이터가 가장 엄격한 의미에서 완전히 정적 상태가 됩니다. 또한 이는 명세와 도구 구현을 단순화합니다.

그러나 여기서는 실용성이 순수성보다 중요합니다. 글롭은 이미 많은 기존 도구에서 지원되며, 모든 라이선스 파일의 전체 경로를 명시적으로 지정하는 것은 벤더링된 의존성이 있는 복잡한 프로젝트에서 불필요하게 번거롭습니다. 더 중요하게는, 이렇게 하면 법적으로 필요한 파일을 실수로 누락하기가 훨씬 쉬워져 패키지를 배포할 수 없게 될 수 있습니다.

도구는 패키지를 설치하거나, 코드를 실행하거나, 파일을 검사하지 않고도 사용자가 지정한 글롭 패턴과 패키지의 파일 이름만을 바탕으로 포함할 파일을 여전히 판단할 수 있습니다. 물론 sdists, wheels 및 기타 배포물에는 배포 메타데이터에 지정된 파일의 완전한 정적 목록이 포함됩니다.

지정되지 않은 경우 license-files에 기본값을 사용합니다.

PEP의 이전 초안에서는 사용자가 라이선스 파일을 선언하지 않았고 키를 dynamic으로 표시하지 않은 경우 라이선스 파일을 감지하기 위한 기본값을 제안했습니다. 해당 값은 다음 글롭 배열로 정의되었습니다: ["LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"]

그러나 기존 메타데이터에서 예외가 발생하는데, 다른 키에는 암시적 기본값이 정의되어 있지 않기 때문입니다. pyproject.toml 키의 암시적 값은 dynamic필드에 위임되며, 이는 계산되는 것으로 지정됩니다. 또한 해당 값은 왜 표준이 되어야 하는지에 대한 강력한 근거 없이 임의로 선택되었습니다.

기본값을 사용하려면 dynamic으로 표시해야 합니다.

관련 PEP 621의 dynamic 목록에 대한 설명을 제한적으로 해석하면, 기본 글롭 패턴이 사용되도록 하거나 또는 라이선스 파일이 조금이라도 매칭되어 포함되도록 하려면 license-files 키를 dynamic으로 표시하도록 요구하는 것이 합리적으로 보일 수 있습니다.

그러나 이는 사용자가 직접 지정할 수 있는 다른 글롭 패턴 집합과 마찬가지로 모든 준수 도구에서 정확히 사용해야 하는, 정적이고 엄격하게 지정된 기본값을 선언하는 것에 불과합니다. 그 결과 생성되는 License-File핵심 메타데이터 값은 코드를 실행하거나 파일 내용을 검사하지 않고 소스의 파일 목록을 검사하여 판단할 수 있습니다.

더욱이 그렇지 않다고 하더라도, 이러한 해석은 기존 형식과 하위 호환되지 않으며 기존 도구의 동작과도 일관되지 않습니다. 또한 이로 인해 많은 프로젝트가 법적으로 필수인 라이선스 파일을 더 이상 포함하지 않게 되는 사실을 모른 채 배포될 심각한 위험이 발생하므로, 이는 타당한 기본값이 아닙니다.

마지막으로, 기본값을 dynamic으로 정의하지 않으면 작성자가 빌드/패키징 도구가 라이선스 파일의 포함을 직접 처리할 시점을 모호하지 않게 나타낼 수 있습니다. 그렇지 않으면 dynamic목록의 목적이 훼손됩니다.

라이선스 파일 경로

소스 및 빌드 배포판에서 라이선스 파일의 경로와 위치와 관련된 대안입니다.

하위 디렉터리의 라이선스 파일 평탄화

이전 PEP 639 초안에서는 하위 디렉터리의 라이선스 파일을 처리하는 방법을 지정하지 않았습니다. 현재 Wheel및 Setuptools프로젝트는 소스 하위 디렉터리 계층을 보존하지 않고 모든 라이선스 파일을 .dist-info 디렉터리로 평탄화합니다.

이 방식은 기존의 임의적 관행과 일치하지만, 이름 충돌과 라이선스 파일 간 덮어쓰기를 초래할 수 있으며, 이를 해결하는 방법에 대한 정의된 동작이 없고, 지정된 라이선스 파일이 포함되지 않았다는 명확한 표시도 없이 패키지를 법적으로 배포할 수 없게 만들 수 있습니다.

또한 이는 소스, sdist 및 wheel 사이에서 루트가 아닌 라이선스 파일의 상대 파일 경로를 일관되지 않게 만들며, “static” [project] 테이블 메타데이터에 지정된 경로가 진정으로 정적이지 않게 합니다. 마지막으로 소스 디렉터리 구조에는 라이선스가 무엇에 적용되는지에 관한 귀중한 정보가 포함되는 경우가 많지만, 이를 평탄화하면 그 정보가 사라지고 복원하기도 결코 간단하지 않습니다.

이를 해결하기 위해 이제 PEP에서는 원래 라이선스 파일의 소스 디렉터리 구조를 .dist-info 디렉터리 내부에 재현할 것을 제안합니다. 이 방식의 유일한 단점은 더 중첩된 .dist-info 디렉터리를 갖게 된다는 점입니다. 다음 제안은 라이선스 파일의 루트를 licenses 하위 디렉터리 아래에 두어 이름 충돌과 복잡성 문제를 모두 완전히 제거합니다.

이름 충돌을 다르게 해결하기

.dist-info 디렉터리 내부에서 라이선스 파일의 소스 디렉터리 구조를 보존하는 대신, 과도하게 중첩된 디렉터리를 피하기 위해 이름이 고유해질 때까지 트리를 거슬러 올라가면서 상위 디렉터리 이름을 라이선스 파일 이름 앞이나 뒤에 붙이는 등 충돌 해결을 위한 다른 메커니즘을 지정할 수도 있습니다.

그러나 이렇게 해도 경로 일관성 문제는 해결되지 않으며, 훨씬 더 많은 논의가 필요하고 사양을 더욱 복잡하게 만들 것입니다. 따라서 많은 이해관계자가 주장해 온 것처럼 소스 하위 디렉터리 배치를 그대로 보존하는 더 명확한 해결책을 채택하여 이를 거부했습니다.

.dist-info에 직접 저장하기

이전에는 포함된 라이선스 파일이 빌드된 wheel과 설치된 프로젝트의 최상위 .dist-info 디렉터리에 직접 저장되었습니다.

그러나 이는 라이선스를 자체 네임스페이스로 분리하는 것에 비해 .dist-info 디렉터리를 더 복잡하게 만듭니다. 또한 .dist-info 디렉터리의 사용자 지정 라이선스 파일 이름(예: RECORD, METADATA)과 충돌할 위험이 여전히 있으며, 이 경우 사용할 수 있는 파일 이름을 제한해야 합니다. 마지막으로, 라이선스를 지정된 자체 하위 디렉터리에 넣으면 사람과 도구가 Core Metadata에서 각 경로를 참조하지 않고도 모든 라이선스를 한 번에 올바르게 처리할 수 있습니다(예: 배포판 패키징, 법적 검사 등).

따라서 Wheel 및 Setuptools 구현 이슈에서 여러 사람이 제안한 것처럼, 가장 간단하고 명확한 해결책은 라이선스 파일의 루트를 .dist-info의 licenses 하위 디렉터리를 기준으로 지정하는 것입니다. 이는 구현이 간단하고 다른 더 복잡한 선택지에 비해 큰 단점 없이 여기에서 언급한 모든 문제를 해결합니다.

사양은 다소 복잡해지지만 구현은 똑같이 간단하게 유지되어야 합니다. 이는 이 변경 사항을 적용하여 생성된 wheel의 라이선스 위치가 이전과 달라진다는 의미이지만, 하위 디렉터리에 있던 라이선스도 이미 그러했으며 PEP 639 이전에는 이러한 파일에 프로그래밍 방식으로 접근할 방법이 없었으므로 실제로 큰 문제를 일으키지는 않을 것입니다.

wheel에 새로운 licenses 카테고리 추가

wheel에서 Core Metadata 디렉터리(.dist-info) 내부에 루트 라이선스 디렉터리(licenses)를 정의하는 대신, 라이선스 파일 전용으로 .data 아래에 현재 포함된 다른 카테고리와 유사한 새로운 카테고리(그리고 아마도 이에 대응하는 설치 체계)를 정의하고, 이를 (예를 들어) licenses라고 부를 수도 있습니다. 이는 wheel 제작자가 언급한 내용이며, 사이트 경로의 .dist-info 디렉터리에만 설치하는 것보다 플랫폼에 더 적합하고 유연한 위치에 라이선스를 설치할 수 있게 합니다.

그러나 현재 PEP 639에서는 이 아이디어를 구현하지 않으며, 향후 PEP로 미룹니다. 이 PEP는 주로 기존 관행을 표준화하고 Core Metadata 사양을 업데이트하는 데 중점을 두므로, 이 아이디어를 도입하면 PEP 639에 상당한 복잡성과 마찰이 추가될 것입니다. 또한 그렇게 하려면 Wheel, Installer 및 기타 도구와 함께 sysconfig 및 그 안에 지정된 설치 체계를 수정해야 할 수 있으며, 이는 간단하지 않은 작업입니다. 재패키징 담당자에게는 다소 더 복잡할 수 있지만, 현재 제안은 여전히 모든 라이선스 파일이 하나의 전용 디렉터리에 포함되도록 보장하므로 이 점에서 현재 상태를 크게 개선할 것입니다.

또한 이 방식은 완전한 하위 호환성을 갖지 않으며(단순히 wheel을 추출하는 도구에는 투명하지 않기 때문입니다), 기존 관행에서 더 크게 벗어나고 서로 다른 버전의 wheel에서 라이선스 설치 위치를 더욱 일관되지 않게 만들 것입니다. 마지막으로 이는 라이선스가 관련 코드에 최대한 가까운 위치에 설치되지 않고, 플랫폼 간 및 빌드 배포판과 설치된 프로젝트 간에 라이선스 루트 경로의 변동성이 커지며, 설치된 라이선스에 프로그래밍 방식으로 접근하기가 더 어려워지고, 이름 충돌을 방지할 수 있는 적절한 설치 위치와 방법을 새로 만들어야 한다는 의미입니다.

따라서 PEP 639를 범위에 유지하기 위해 현재 접근 방식을 유지합니다.

하위 디렉터리 이름을 license_files로 지정합니다.

휠과 설치된 프로젝트의 .dist-info 내부 루트 라이선스 디렉터리에 사용할 수 있는 이름으로 licenses와 license_files가 모두 제안되었습니다. PEP의 초기 초안에서는 전자가 약간 더 명확하고 Core Metadata 필드 이름(License-File) 및 [project] 테이블 키(license-files)와 일관된다는 이유로 전자를 지정했습니다. 그러나 PEP의 현재 버전에서는 커뮤니티가 더 짧고 구분 문자가 없는 이름을 전반적으로 선호하기 때문에 licenses라는 이름을 채택합니다.

기타 아이디어

최종적으로 채택되지 않은 기타 제안, 가능성 및 논의 사항입니다.

식별자를 라이선스 파일에 매핑합니다.

이를 위해서는 매핑을 사용해야 하며, 라이선스 문서화 방식이 더 복잡해지고 중첩 수준이 하나 추가됩니다.

모든 표현식(키)에 하나의 라이선스 파일만 연결된다고 보장할 수 없고(예를 들어 예외가 포함된 GPL은 하나의 파일에 있을 수 있음), 어떤 표현식에도 둘 이상의 라이선스 파일이 연결되지 않는다고 보장할 수 없으므로 매핑이 필요합니다. (예를 들어 Apache 라이선스의 LICENSE와 해당 NOTICE 파일은 서로 다른 두 파일입니다.) 대부분의 일반적인 경우에는 하나의 라이선스 표현식과 하나 이상의 라이선스 파일이면 충분합니다. 여러 라이선스가 관련된 더 드물고 복잡한 경우에도 작성자는 여기에 지정된 필드를 안전하게 사용할 수 있습니다. 다만 어떤 텍스트 파일이 어떤 라이선스 식별자에 매핑되는지 지정하지 않음으로써 명확성이 약간 떨어질 수 있습니다(각 라이선스 식별자에는 SPDX에 등록된 해당 전체 라이선스 텍스트가 있음). 동시에 이를 필요로 하거나 원하지 않는 대다수 사용자에게 더 복잡한 매핑을 강제하지 않을 수 있습니다.

물론 여러 가능한 값 유형을 갖는 데이터 필드를 사용할 수도 있지만, 이는 혼란의 원인이 될 수 있습니다. 예를 들어 npm에서는 역사적으로, Rubygems에서는 현재까지 이러한 방식이 사용되어 왔습니다. 그 결과 도구는 코드에서 메타데이터 필드를 사용하기 전에 해당 필드의 유형을 검사해야 하며, 사용자는 목록을 사용할지 문자열을 사용할지 혼란을 겪습니다. 따라서 이 접근 방식은 거부됩니다.

식별자를 소스 파일에 매핑합니다.

앞서 논의했듯이 파일 수준의 고지는 PEP 639의 범위에 포함되지 않으며, 추가적인 사양 없이도 필요한 경우 기존 SPDX-License-Identifier 관례를 이미 사용할 수 있습니다.

특정 SPDX 버전과의 호환성을 고정하지 않습니다.

PEP 639에서는 특정 SPDX 사양 버전이나 유효한 라이선스 식별자 목록의 특정 버전을 지정하지 않을 수 있으며, 이렇게 하면 사양이 발전함에 따라 더 유연하게 업데이트할 수 있습니다.

그러나 향후 SPDX 업데이트로 기존 표현식 및 식별자와의 호환성이 깨져 현재 패키지가 PEP 639의 정의에 따라 유효하지 않은 메타데이터를 갖게 될 수 있다는 심각한 우려가 제기되었습니다. 여기에서 이러한 사양의 특정 버전과의 호환성을 요구하고 PEP 또는 이와 유사한 절차를 통해 이를 업데이트하면 이러한 상황을 방지할 수 있으며, 다른 패키징 생태계의 관행도 따르게 됩니다.

따라서 최소 버전을 지정하고 도구가 해당 버전과 호환되도록 요구하되 하위 호환성을 깨지 않는 한 업데이트를 허용하도록 결정했습니다. 이를 통해 유연성과 호환성의 균형을 유지하면서 도구가 개선 사항을 즉시 활용하고 새 라이선스를 받아들일 수 있습니다. 이를 통해 도구는 개선 사항을 즉시 활용하고 새 라이선스를 받아들이면서 유연성과 호환성의 균형을 유지할 수 있습니다.

사용자 지정 라이선스 식별자를 허용하지 않습니다.

이 PEP의 이전 초안에서는 프로젝트에 라이선스가 있지만 인식된 SPDX 라이선스 식별자가 없는 경우를 처리하기 위해 두 개의 사용자 지정 식별자, 즉 LicenseRef-Public-Domain과 LicenseRef-Proprietary만 사용할 수 있도록 하는 방안을 지정했습니다. 사용자 지정 식별자는 올바른지 검사할 수 없으며, 사용자는 식별자 앞에 항상 LicenseRef를 붙여야 한다고 생각할 수 있습니다. 이로 인해 도구가 유효하지 않은 메타데이터를 생성하게 됩니다.

그러나 Python 패키지는 다양한 개방적이고 폐쇄적인 환경에서 생성되므로, 허용된 사용자 지정 식별자의 작은 하위 집합만으로는 라이선스를 선언할 수 없거나 여러 이유로 라이선스를 SPDX 라이선스 목록에 추가할 수 없는 경우가 있을 수 있습니다.

사용자 지정 라이선스 식별자는 공식 SPDX 사양에서 명시적으로 허용되고 설명되어 있으며, 대소문자가 정규화되지는 않지만 구문 검증이 가능합니다.

따라서 사용자 지정 식별자를 완전히 검증할 수 없고 오류가 포함될 수 있음을 인정하면서도 공식 SPDX 사양에 따라 이를 허용하기로 결정했습니다.

소스 배포와 바이너리 배포에 서로 다른 라이선스를 적용합니다.

추가적인 사용 사례로서, 프로젝트 자체와는 다른 라이선스로 바이너리를 컴파일하여 번들링하는 비순수 파이썬(non-pure-Python) 패키지의 경우처럼, 바이너리 배포판(wheel)의 라이선스 표현식이 소스 배포판(sdist)의 라이선스 표현식과 다른 경우를 처리하는 것이 PEP 639의 범위에 포함되는지에 대한 질문이 제기되었습니다. 예로 언급된 것은 PyTorch였으며, 이는 자유롭게 배포 가능하지만 오픈 소스는 아닌 Nvidia의 CUDA를 포함하고 있습니다.

그러나 이 문제에 내재된 복잡성과 이를 처리할 명확한 메커니즘의 부재, 각 wheel이 자체적인 라이선스 정보를 필요로 한다는 점, PyPI가 배포판 아카이브 단위로 라이선스 정보를 노출하는 것을 지원하지 않는다는 점, 그리고 상대적으로 특수한(niche) 사용 사례라는 점을 고려하여, 이는 PEP 639의 범위를 벗어나는 것으로 결정되었으며, 충분한 필요성과 관심이 존재하고 적절한 메커니즘을 찾을 수 있다면 향후 PEP에서 해결하도록 남겨두었습니다.