GitHub가 Git과 상호 작용하고 Git이 GPLv2에 따라 라이센스가 부여 된 경우 GitHub가 공개 소스가 아니어야합니까?


58

Git은 GPLv2에 따라 라이센스가 부여되고 GitHub가 Git과 상호 작용하므로 GitHub 코드베이스 전체가 GPL 호환 라이센스로 공개 소스로 제공되지 않아야합니까?


59
상호 작용에 대해 이야기하는 GPL의 특정 단락을 가리킬 수 있습니까? 힌트 : 없습니다.
Jörg W Mittag

14
@ JörgWMittag : 네트워크 액세스가 '릴리즈'인지 전파되는지에 대해 주제에 정통하지 않은 사람에게 혼란을주는 것은 합리적이지 않습니다.
whatsisname

1
간단합니다 : github은 다른 사람의 라이센스가 부여 된 작업을 전달하지 않으며, 어느 정도까지는 라이센스 조건을 따릅니다. GPL에 따라 다른 사람으로부터 라이센스를받은 작업이 포함 된 "유형 매체에 고정 된"작업을 지적 할 수 있습니까?
jthill

3
@TobiasKienzler "git"은 두 가지 분리되어 있지만 관련된 것입니다. 첫째는 소스 코드 버전 관리의 특정 방법을 정의하는 표준이고, 둘째는 해당 표준의 참조 구현입니다. 두 가지 이름은 git입니다. 이러한 것들 중 하나만 GPL, AGPL 등으로 라이센스를받을 수 있습니다. 표준에서 자체 구현을 생성하는 경우 원하는 방식으로 라이센스를 부여 할 수 있으며 표준 또는 참조 구현 작성자는 아무런 관련이 없습니다. 당신의 코드에.
Moo

6
@TobiasKienzler는 Java 사양에 대한 최근 Oracle-Google 법원 소송에서 기본적으로 표준 의 재 구현 을 방지하는 데 사용할 수있는 라이센스가 없음을 의미 합니다.
Moo

답변:


111

3 가지 이유 :

  1. GPL의 용어에 따르면 웹을 통해 GitHub에 액세스하는 사람들은 릴리스 또는 GPLv3 용어로 전파되는 것으로 간주되지 않으므로 GitHub은 소스 코드를 공유 할 필요가 없습니다. GitHub가 소프트웨어를 전송하고 자체 네트워크에서 내부적으로 GitHub 인스턴스를 실행하는 버전의 서비스를 판매하려는 경우 (내가 신경 쓰지 않았을 수도 있음) 다음을 제외하고 소스 코드를 제공하십시오.

  2. GitHub는 명령 행 호출을 통해 Git 클라이언트에 매우 잘 액세스 할 수 있습니다.이 경우 "arms length"로 통신 하는 것으로 간주 되므로 GitHub를 파생 작업으로 만들지 않으므로 GPL의 요구 사항이 적용되지 않습니다.

  3. 또한 GitHub는 Git 소프트웨어를 사용하지 않을 수도 있으며 자체 핵심 "git 구현"을 작성했으며 호환성을 유지하기 위해 인터페이스를 다시 구현했습니다.이 경우 GPL의 요구 사항이 다시 적용되지 않습니다.


47
실제로 AFAIK, GitHub는 자체 Git 구현을 가지고 있으므로 Linus Torvald의 Git 구현 라이센스는 아무 관련이 없습니다.
Jörg W Mittag

18
Github은 소프트웨어를 출시합니다. enterprise.github.com
Bryan Chen

8
"3) 또한 GitHub는 Git 소프트웨어를 사용하지 않을 수도 있고 자체 핵심"git 구현 "을 작성했으며 호환성을 유지하기 위해 인터페이스를 다시 구현했습니다.이 경우 GPL의 요구 사항이 다시 적용되지 않습니다. " Github이 libgit2를 사용하기 때문에 @whatsisname이 옳았다 고 생각합니다. 링크 : libgit2.github.com , 출처 : github.com/libgit2/libgit2
andytime

8
LibGit2는 링크 예외와 함께 GPL2 따라 라이센스가 부여됩니다 .
RubberDuck

8
@RubberDuck : libGit2는 github이 소유하고 있으므로이를 사용하기 위해 라이센스가 필요하지 않으므로 라이센스가있는 모든 것을 준수 할 필요가 없습니다. libgit2의 소유자로서 자신이 논쟁을하더라도 사용자 정의 라이센스로 라이센스를 부여 할 수 있습니다.
slebetman

6

다른 답변 외에도, 두 협력 프로그램이 단일 작업을 구성 할 때 FSF의 견해는 매우 모호하다고 덧붙입니다.

또한 이러한 견해는 독일을 제외하고 법정에서 테스트 된 적이 없습니다.

현재 진행중인 사건이지만 판사는 두 프로그램이 하나의 저작물을 구성하는지, 즉 동일한 주소 공간을 공유하는지 여부를 결정하기 위해 FSF가 명시한 주요 고려 사항 중 하나가 (독일) 저작권법과 관련이 없다고 동의했습니다. FSF는 소송에 관여하지 않았지만 소송 당사자는 집계 / 파생에 대한 FSF의 견해를지지 해 왔다는 점에 유의해야합니다.

따라서 다음 Github을 작성하는 사람들은 FSF가 귀하에게 있다고 말할 때 (그리고 그 반대의 경우도) 법의 반대편에 있다고 가정하지 마십시오.


법정에서 빈번하지 않다고 가정해야 할 것입니다. Stallman은 디스크에 기술 회사 DRM의 소프트웨어를 언급했으며 소프트웨어는 디스크의 무료 사본 구성 요소로 빌드되었다고 Stallman의 이야기를 기억합니다. Stallman은 프레젠테이션에서 벤더가 이에 대해 법적 조치를 한 적이 없다고 언급했습니다.
Lan

1
@Lan 글쎄, DRM은 이전 GPLv2가 아닌 최신 GPLv3에서만 발생하는 별도의 문제입니다. GPLv2를 해석하면 벤더는 독점 하드웨어에서 수정을 실행할 수있는 실질적인 방법을 제공하지 않고 GPLv2 카피 레프트 컴포넌트의 소스를 제공 할 권리가 있습니다.
DepressionedDaniel

@ 란 가정하지 마십시오. 법 집행 기록을 살펴보면 적어도 그럴듯한 견해 법적인 행동에 직면 한 위반자가 일반적으로 준수한다는 것입니다. 그것은이든 할 수 있습니다 시행 할 누군가가 그렇게 할 수있는 시간이 걸립니다 여부와 동일하지 않고, 비지 박스는 비 호환 제품에 포함 될 가능성이 높다 그리고 저자는 도전까지있는 흥미로운 장소입니다.
chrylis

@chrylis BusyBox의 저자가 무엇인지 잘 모르겠습니다. 롭 Landley는 소송을 시작했지만 그는 결과에 혐오감, 결국 (완전히 BSD 라이센스 됨으로써 GPL을 피할 수) ToyBox에 작업 비지 박스를 방치 : brownrudnick.com/blog/emerging-technologies/...를 . 기본적으로 BusyBox에 대한 수정을 공개하지 않고 (아무도 없었 음) 상황은 미래의 소송 자금을 조달하고 법적 이론에 의해 BusyBox와 완전히 관련이없는 독점적 인 구성 요소를 개설하기 위해 돈을 요구하기 위해 남용되었습니다. 슬퍼. 슬프다.
DepressionedDaniel

또한, "링크"가 의미하는 바에 대한 FSF의 설명은 기술적 인 의미가 없습니다. 예를 들어, Java를 사용하는 사람은 "모듈이 공유 주소 공간에서 서로 연결된 상태로 실행되도록 설계되어 있다면이를 하나의 프로그램으로 결합하는 것입니다."라는 문장을 알고 있습니다. 말도 안됩니다.
Michael Kay

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.