당신의 복종이 가지고있는 것에서 덜 제한적인 오픈 소스 라이선스를 사용할 수 있습니까?
일반성을 잃지 않고 Gradle을 빌드 시스템으로 사용하는 오픈 소스 Java 프로젝트가 있고 여기에 MIT 라이선스를 추가하려고한다고 가정합니다. 사례를 고려하십시오.
사례 1. build.gradle 파일 에서 Eclipse Public License-v 2.0에 따라 라이센스가 부여 된 JUnit5 의 종속성을 제거 합니다. 테스트 폴더에서 몇 가지 테스트를 수행하면 src 폴더와 함께 모든 것이 GitHub에 업로드됩니다. 귀하의 프로젝트는 MIT에서 라이센스를받을 수 있습니까? 또한 프로젝트와 함께 패키지를 만들지 만 JUnit5 테스트는 포함되지 않습니다.
사례 2. build.gradle 파일 에서 Apache License 2.0에 따라 라이센스가 부여 된 JetBrains의 Java 주석 에 대한 종속성을 해제합니다 . 귀하의 프로젝트는 MIT에서 라이센스를받을 수 있습니까? 또한 프로젝트와 함께 패키지를 생성하고 종속 된 사람들이 코드의 주석을 보길 원하지만 코드에서 주석을 사용할 수 있는지 여부는 염려하지 않습니다.
요약 : 프로젝트 파일을 복사하여 붙여 넣는 경우 호환 가능한 라이선스로만 다시 라이선스를 부여 할 수 있지만 Maven / Gradle 패키지 및 제작 된 프로젝트 패키지를 통해서만 의존하는 경우에도 동일하게 적용된다는 것을 이해합니다. 포함하지 않습니까?
답변
패키지 X에 대한 종속성을 선언 할 때 두 가지 가능성이 있습니다.
패키지 X에는 GPL 또는 AGPL과 같은 강력한 카피 레프트 라이선스가 있습니다. 이러한 라이선스에는 최종 바이너리 응용 프로그램이 각각 GPL 또는 AGPL 라이선스에 따라 라이선스가 부여되어야한다는 요구 사항이 있습니다. 결과적으로 그들은 자신의 코드에 대해 선택할 수있는 라이선스에 제한을 둡니다.
패키지 X를 포함하는 배포하는 모든 빌드는 패키지 X와 동일한 라이선스로 라이선스를 받아야합니다. 패키지 X가없는 빌드가없는 경우 동일한 라이선스로 소스 코드에 라이선스를 부여하는 것이 가장 좋습니다. 패키지 X가없는 빌드도있는 경우 소스 코드에 대해 호환 가능한 라이선스를 선택할 수 있습니다.
패키지 X에는 다른 라이선스가 있습니다. 이러한 라이선스는 해당 라이선스로 명시 적으로 라이선스가 부여 된 파일을 초과하여 범위를 확장하지 않으므로 사용자가 자신의 코드에 대해 선택할 수있는 라이선스에 제한을 두지 않습니다.
이 경우 덜 제한적인 오픈 소스 라이선스, 더 제한적인 오픈 소스 라이선스 또는 호환되는 비공개 소스 라이선스를 사용할 수 있습니다.
언급 한 두 경우 (JUnit5 및 Java 주석)는 두 번째 범주의 라이선스를 포함하므로 자체 코드에 대한 라이선스 선택에 영향을주지 않습니다.