전 이적 개발 종속성에 대한 기여도를 부여해야합니까?
종속성 라이선스를 단일 파일로 묶기위한 라이브러리 / cli-tool을 개발 중입니다. 현재 저는 직접 의존성, 전이 의존성 및 직접적인 개발 의존성 에 대한 라이선스를 수집하려고합니다 .
즉, node_modules에 설치된 패키지의 라이선스를 수집하려고합니다. 임시 개발 종속성은 개발 종속성의 특성 때문에 패키지 관리자에 의해 설치되지 않습니다.
이러한 전 이적 종속성의 코드 부분이 설치된 패키지에 어떻게 든 포함될 수 있는지 여부가 걱정됩니다.
예 : 프로젝트 "A"는 패키지 "B"에 종속됩니다. 패키지 "B"에는 개발자 종속성으로 Transpiler "C"가 있습니다. 패키지 "B"의 Transpiler "C"에 의해 생성 된 코드에는 간단한 트랜스 파일 결과뿐만 아니라 이전 브라우저에서는 사용할 수없는 Transpiler "C"의 함수에 대한 일부 폴리 필도 포함됩니다. 하지만 Transpiler "C"는 전 이적 개발 의존성이므로 프로젝트 "A"의 node_modules에 설치되지 않습니다. 따라서 수동으로 설치하지 않으면 Transpiler "C"의 라이선스를 제대로 얻을 수 없습니다. 가능하더라도 Transpiler "C"의 의존성 / 개발 의존성 등을 찾아야합니다.
이 가설에서는 전 이적 개발 종속성이 하나 뿐이지 만 실제 시나리오에서는 수백 개가있을 수 있습니다. 서로 다른 패키지에서 전 이적 개발 종속성으로 정의 된 동일한 패키지의 여러 버전이있을 수 있습니다. 라이선스 정보를 수집하기 위해 전 이적 개발 종속성을 수동으로 설치하면 이러한 전 이적 개발 종속성이 자체 개발 종속성을 가질 수 있으며이 역시 설치해야합니다. 모든 전 이적 개발 종속성의 모든 전 이적 개발 종속성이 설치 될 때까지이 프로세스를 반복해야합니다.
질문 : 전 이적 개발 종속성에 대한 라이선스 정보 수집에 관심을 가져야합니까? 그리고 내가해야한다면 어느 지점까지?
나는 이미 정기적 인 전이 의존성을 신경 쓰지만, 전 이적 개발 의존성이 걱정된다.
답변
이것은 매우 까다로운 시나리오이므로 자동화 된 라이센스 준수 도구가 지금까지만 가능합니다. 귀하의 분석은 일반적으로 올바른 것 같습니다.
실제로 B의 라이선스가 B의 원본 소스 코드뿐만 아니라 B의 트랜스 파일 된 코드 (적어도 B가 트랜스 파일 된 형태로 배포 된 경우)를 포함 할 것으로 예상합니다. 이것은 전 이적 개발 의존성 문제를 깔끔하게 회피 할 것입니다. 그러나 이것은보다 일반적인 문제를 지적합니다. 라이센스 메타 데이터가 정확하지 않을 수 있으며 자동화 도구가 지금까지만 진행되는 또 다른 이유입니다.
범용 도구를 설계하는 경우 패키지 메타 데이터에 언급 된 도구에 대한 메타 데이터를 가져와 (실제로 설치할 필요가 없음) 개발 종속성 및 전 이적 개발 종속성 분석을 트리거 하는 옵션 을 추가하는 것이 유용 할 수 있습니다 . 기본적으로 개발자 종속성이 라이선스 상태에 직접적인 영향을 미치지는 않을 것입니다 (정확히 설명했듯이 특히 폴리 필은이 기대치를 위반할 수 있음).