오픈 소스 소프트웨어 라이센스를 루트에 유지해야하는 이유는 무엇입니까?


10

거의 모든 오픈 소스 소프트웨어 라이센스는 사용자가 보호하고있는 프로젝트의 루트에 전체 라이센스를 포함하도록 요구합니다.

내가 말한 한 변호사는 CD 케이스의 전체 라이센스가 보석 케이스에 포함될 필요가 있었을 때 CD 시대의 유산이라고 제안했다.

그러나 오늘날 우리는 클라우드 시대에 살고 있습니다. 예를 들어 웹 사이트에서 정식 라이센스를 호스팅하고 소스 파일 헤더에 해당 라이센스의 제목 + URL을 포함시킬 수없는 이유는 무엇입니까?

보너스 : 일반적으로 기존 라이센스를 루트에 그대로 유지해야한다는 데 동의하는 경우, FSF의 OSI 가 URL로 참조 할 있는 라이센스를 승인하지 않은 이유는 무엇입니까?


4
염두에 두어야 할 한 가지 문제는 URL이 변경되거나 중단 될 수 있다는 것입니다.
Aaron Kurtzhals

6
'인터넷은 어디에서나 사용되지 않습니다'가 가장 명백한 이유입니다 (소프트웨어를 다운로드 할 때 누군가 인터넷에 연결되어 있어도 소프트웨어를 확장 / 수정하려는 경우 사용하지 못할 수 있음).
TZHX

9
전체 라이센스가 루트에 포함되어야하는 이유 또는 전체 라이센스가 루트에 포함되어야하는 이유를 묻고 있습니까?
DougM

우리가 여기서 거짓 이분법을 말하는 것 같습니다. 라이센스가 루트에 있어야하는 이유와 URL에서 온라인으로 라이센스를 사용할 수없는 이유는 무엇입니까? 아무도 언급되지 않은 세 번째 옵션이 있습니다. 라이센스는 소프트웨어와 함께 번들로 제공되지만 "docs"디렉토리 또는 다른 곳에 있으며 코드 파일 헤더의 주석이이를 반영합니다. 라이센스를 소프트웨어와 함께 번들로 제공해야하는 이유에 동의하지만 문서 디렉토리에 들어 가지 않습니다.
James

4
거의 항상 루트에있는 이유는 찾기가 쉽기 때문입니다. 프로젝트를 다운로드 할 때 루트를 탐색하며 가장 먼저 보는 것은 라이센스입니다. 그렇게 간단 함
JohnL

답변:


24

로부터 GPL 자주 묻는 질문 (그러나 조언 모든 라이센스에 적용) :

GPL이 프로그램의 모든 사본에 GPL 사본을 포함해야하는 이유는 무엇입니까?

프로그램에 라이센스 사본을 포함시키는 것은 프로그램의 사본을 얻는 모든 사람이 자신의 권리가 무엇인지 알 수 있도록 필수적입니다.

라이센스 자체 대신 라이센스를 나타내는 URL을 포함 시키려고 할 수 있습니다. 그러나 지금부터 5 년 또는 10 년 후에도 URL이 유효한지 확신 할 수 없습니다. 20 년 후 오늘날 우리가 알고있는 URL은 더 이상 존재하지 않을 수 있습니다.

네트워크에서 발생할 수있는 모든 변경 사항에도 불구하고 프로그램 사본을 보유한 사람들이 라이센스를 계속 볼 수 있도록하는 유일한 방법은 프로그램에 라이센스 사본을 포함시키는 것입니다.

(강조 광산)

라이센스를 호스팅하는 사이트가 다운되거나 URL 경로가 변경되는 순간 소프트웨어 사본을 보유한 사용자는 더 이상 안전하게 행사할 수있는 권한을 확인할 수 없습니다. 정확한 URL이 영원히 온라인 상태가 될 것이라고 보증 할 수 있다고 가정하십시오. 사용자가 소프트웨어 사용이 합법적임을 확인할 수있는 능력은 여전히 ​​해당 특정 URL에 연결하는 능력에 달려 있습니다. 이 요구 사항은 특정 도시 / 국가 / 플래닛에서는 번거롭지 않지만 다른 곳에서는 번거로울 수 있습니다. 특히 전체 라이센스 텍스트를 포함한 해결 방법이 사소한 경우에는이 요구 사항을 강요해서는 안됩니다.

"그래서 어떻습니까? URL이 다운되거나 액세스 할 수없는 경우 'GNU GPL v3'과 같은 명확한 설명이 충분해야합니다. GPL의 전체 텍스트 사본은 풍부합니다. 사용자는 찾을 수 있습니다. 라이센스 자체. " 몇 가지 문제가 즉시 떠 오릅니다.

  1. 덜 명확한 라이센스 식별자로 일반화하지는 않습니다 ( "BSD 라이센스"라는 문구가 떠오름).

  2. 덜 일반적이거나 커스터마이즈 된 라이센스로는 일반화되지 않습니다 ( "링크 예외가있는 GPL"은 어떤 링크 예외입니까?). 사용자가 이름으로 안정적으로 찾을 수 있기 전에 라이센스가 얼마나 일반적이어야합니까?

  3. 이를 위해서는 여전히 사용자가 인터넷에 연결되어 있어야합니다. 소프트웨어를 구입 한 시점에 연결되어 있어도 그렇지 않을 수도 있습니다. (그리고 그들은 소프트웨어를 얻었을 때 인터넷에 접속하지 않았을 수도 있습니다. "CD 시대"는 아직 세계 여러 지역에서 끝나지 않았습니다. 추가 사례로서, 인터넷에 널리 보급되어 있지만 상당 부분을 검열하는 국가 인구를 고려하십시오 .) 자유롭게 재배포 가능한 소프트웨어의 결과로받는 사람이 귀하로부터 직접 또는 원래 예상 한 배포 채널을 통해 소프트웨어 사본을받지 못할 수 있습니다.

라이센스 링크에 대한 하나의 최종 주장은 아래 MichaelT의 의견에 의해 언급됩니다. 라이센스를 동적으로 소급하여 변경할 수 있습니다. 이것은 의도적으로 수행 될 수 있지만 소프트웨어 버전간에 라이센스를 변경했지만 두 버전에 대해 동일한 라이센스 링크를 사용하여 기존 라이센스가 존재하지 않는 경우 실수로 수행 할 수도 있습니다. 이러한 스위치는 현재 버전과 다른 라이센스로 이전 사본을 가지고 있음을 증명해야하는 사람들에게 어려움을 줄 수 있습니다.

그렇다면 왜 프로젝트 루트에 라이센스를 유지해야합니까?

나는 변호사가 아니에요,하지만 난 당신이 그 어떤 강력한 인수 본 적이 않는 프로젝트 루트에서 라이센스를 유지해야합니다. 각 저작물 사본에 라이센스가 포함되어야한다고 명시한 GPL조차도 그 저작물에 대한 라이센스 방법대해서는 침묵 합니다. ( "루트 디렉토리"라는 개념이 의미가없는 비 소프트웨어 컨텍스트에서 GPL을 적용 할 수 있기 때문일 수 있습니다.)

루트 디렉토리에 라이센스를 유지하는 것은 사용자가 라이센스를 볼 가능성을 최대화하여 일부 불분명 한 디렉토리에 라이센스를 숨기려는 사용자에 대한 불만 및 불만 가능성을 최소화하기 때문에 좋은 아이디어 일 것입니다 . 라이센스가 많은 경우 라이센스를 모두 자신의 폴더에 배치하고 각 구성 요소의 라이센스를 찾기위한 파일 경로가 포함 된 프로젝트 README를 포함시키는 것이 더 합리적 일 수 있습니다.

디렉토리 루트에 라이센스를 배치하면 전체적으로 작동하는 것과 다르게 라이센스가 부여 된 모듈의 라이센스를 명확하게 할 수 있기 때문에 유용한 방법입니다. 내 프로젝트 FooProj가 독립형 모듈 BarMod를 사용한다고 가정합니다. FooProj는 GPL 라이센스가있는 반면 독립형 모듈은 MIT 라이센스가있을 수 있습니다. FooProj를 처음 열면 루트에 GPL 사본이 표시되고 전체적으로 GPL 라이센스가 부여 된 작업임을 이해합니다. BarMod 폴더로 내려 가면 새 라이센스 파일이 표시되며이 폴더의 내용이 MIT 라이센스가 있음을 이해합니다. 물론 이것은 도움이 될뿐입니다. README, NOTICE 또는 유사한 파일에 모듈의 라이센스를 명시 적으로 표시해야합니다.

요약하면, 파일 루트를 사용하는 것은 편의성과 명확성의 문제입니다. 법적으로 구속력이있는 오픈 소스 라이센스 텍스트를 보거나 법적으로 요구되는 이유를 알지 못했습니다. 수신자가 쉽게 알아볼 수있는 라이센스 여야합니다. 이 기준을 만족시키기 위해서는 프로젝트 루트에 라이센스를 포함시키는 것으로 충분하지만 반드시 필요한 것은 아닙니다.


3
또한 BSD 라이센스하에있는 site.com/foo/license.txt에 대한 원격 사이트에 링크 할 가능성을 고려한 후 GPL v3 하에서 라이센스가 부여 된 것이므로 site.com/foo/license입니다. txt에 포함되어 있습니다. 그러나 다운로드 한 버전은 다른 권한을 갖습니다.

OSS 라이센싱에 대한 기존의 법적 법적 지식을 제시하는 것처럼이 답변을 올바르게 표시했습니다. ,이 생각은 우리가 살고있는이 백업 된 버전 제어 세계에 대한 약간의 편집증으로 생각 나게합니다. 정식 URL 콘텐츠 변조의 위험이 누군가의 일부를 실수로 삭제하는 위험보다 더 확실하지는 않습니다. 루트 내에 포함 된 라이센스 그리고 위험이 더 커도 코드 주석에 외부 호스팅 라이센스를 인용하는 것과 달리 개발자가 소프트웨어에 전체 라이센스를 포함하도록 강요하는 것에 회의적입니다.
samthebrand

참고로, 아마도 OSS 라이센싱에 대한 징후 일 것입니다 : Creative Commons 4.0은 라이센시가 속성 정보가 포함 된 별도의 페이지에 링크 할 수 있도록합니다.
samthebrand

6

그러나 오늘날 우리는 클라우드 시대에 살고 있습니다. 예를 들어 웹 사이트에서 정식 라이센스를 호스팅하고 소스 파일 헤더에 해당 라이센스의 제목 + URL을 포함시킬 수없는 이유는 무엇입니까?

이를 허용하는 라이센스가 있습니다. 예를 들어 Apache 2.0. Apache 2.0에는 각 소스 파일에 Apache 2.0 라이센스의 표준 URL을 가리키는 작은 헤더가 포함되어 있어야합니다. 소스 트리에서 전체 라이센스를 재현 할 필요가 없습니다.

Apache 2.0 라이센스 자체에서 :

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

부록이 불완전하거나 적어도 라이센스 사본을 이미 포함하고 있다고 가정하여 작동한다고 생각합니다. 로부터 2.0 텍스트 자체 아파치 라이센스 작업을 배포 할 때, :4.(a) You must give any other recipients of the Work or Derivative Works a copy of this License;
apsillers

3

프로젝트의 루트에 있어야한다는 요구 사항은 없습니다. 그것은 가장 일반적인 장소이므로 라이센스를 찾기 위해 사람들이 가장 먼저 찾는 곳입니다. 그 문제는 흔하지 않더라도 사람들이 가장 먼저 보게 될 가능성이 높습니다. 정보에 대한 라이센스가 존재하므로 정보를 숨기는 것은 의미가 없습니다.

URL 뒤에 숨길 경우 해당 URL을 항상 사용할 수 있다는 보장은 없습니다. 파일이 프로젝트 루트에있는 파일 인 경우 정의에 따라 항상 사용할 수 있습니다.

요컨대, 이것은 가장 효과적이고 사용자 친화적 인 장소입니다.


프로젝트 루트는 가장 먼저 보이는 것입니다. 트리의 최상위, 폴더 계층의 루트입니다. readme, license 등 모든 최상위 레벨 문서가 있어야합니다.이 파일을 사용하면 독자가 프로젝트의 다른 곳을 더 깊이 파고들 수 있지만 루트는 내가 찾은 첫 번째 장소입니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.