오픈 소스, 저작권 및 사소한 버그 수정

개발자가 폐쇄 소스 상용 응용 프로그램을위한 라이브러리를 개발했다고 가정 해보십시오. 그들은 오픈 소스 커뮤니티에 환원하기를 원하기 때문에이 라이브러리를 GPL로 게시하지만 자신의 응용 프로그램에서 계속 사용합니다. 그들은 저작권을 보유하고 있기 때문에 괜찮습니다.

이제 GPL 버전의 사용자는 버그를 찾아 수정하고 원래 개발자에게 패치를 제출합니다. 내가 알고 있듯이,이 버그 수정을 폐쇄 소스 응용 프로그램에서 사용하려면 개발자가 제출자의 허가를 받아야합니다. 제출자가 거부하면 개발자는 비공개 소스 버전에서 버그를 수정하는 다른 방법을 찾아야합니다.

그러나 버그 수정 자체가 실제로 사소한 경우 어떻게해야합니까? 변수를 올바르게 초기화하거나 널 포인터를 확인하는 것과 같이? 반 유능한 프로그래머가 오류 설명으로 몇 분 만에 찾아서 고칠 수있는 것? 이 패치는 여전히 저작권으로 보호됩니까? 아니면 원래 개발자가 제출자의 동의없이 폐쇄 소스 애플리케이션에서 동일한 수정 사항을 구현할 수 있습니까?

참고 : 이것은 실제로 가상 시나리오이며 "나의 '친구'에게이 문제가 있습니다"라는 질문 중 하나가 아닙니다.

주의 사항 : 저는 변호사가 아닙니다!

업데이트 : 사소한 버그 수정은 저작권의 보호를받지 않습니다. 자세한 내용은 원래 언급 한 것보다 정확하다고 생각되는 Michael Shaw의 답변을 참조하십시오.

그러나 이러한 상황은 이상적이지 않습니다.

• 이것은 중요한 기능을 추가하는 것이 아니라 사소한 변경 사항을 제기하는 고안된 예에서 상당히 분명 할 수 있습니다. 그러나 실제로는 그것이 언제인지에 대한 판단 요청이 될 것입니다. 저작권 회색 영역에 남아 있습니다.
• 이상적으로는 업데이트 된 파일을 프로그램에 통합하려고합니다. 사소한 경우에도 자신의 코드를 추가하고 싶지 않습니다. 불필요하게 작업을 복제합니다.
• 이제 두 가지 버전의 파일이 있습니다 : 사용자 버전과 오픈 소스 버전. 나중에 업데이트 된 코드 버전을 커뮤니티에 릴리스하려는 경우 문제가 발생합니다.

결론 : Gnu Public License는 특히 폐쇄 소스 프로그램에서 코드 사용을 제한합니다. 따라서 GPL 하에서 코드를 공개하면 원래 프로그램으로 다시 통합 할 수없는 코드를 의도적으로 생성 할 수 있습니다. 이것은 말이되지 않습니다.

BSD 라이센스 중 하나 또는 Artistic License 와 같이보다 허가 된 라이센스 하에서 코드를 공개하면 더 나은 서비스를 얻을 수 있습니다 . 이러한 라이센스를 통해 추가 권한없이 코드를 폐쇄 소스 소프트웨어에 포함시킬 수 있습니다. 일반적으로 커뮤니티의 추가 개발은 사용하는 것과 동일한 라이센스에 따라 이루어 지므로 소프트웨어에 대한 변경 사항 (사소 하거나 중요)을 통합 할 수 있습니다.

기술적으로 누군가가 코드를 업데이트 한 다음 GPL로 배포하기로 결정할 수는 있지만 적극적으로 선택해야합니다. 기본 위치가 아닙니다. 그리고 그렇게함으로써, 그들은 당신이하는 어떤 업데이트로부터 그들의 릴리스를 차단할 것입니다. 그래서 그것은 그들에게 유리하지 않을 것입니다.

버그 수정이 실제로 사소한 경우, 특히 코드를 작성할 수있는 다른 방법이없는 경우에는 저작권이 전혀 없습니다. 사랑의시나 비디오 게임을 작성하는 방법은 수억 가지가 있지만 실제로 글을 쓰는 방법은 한두 가지가 넘지 않습니다 if (*p == NULL). 저작권은 아이디어의 표현에 있으므로 아이디어를 표현하는 방법에 대한 선택이 없다면 저작권이있을 수 없습니다.

그러나 버그 수정이 여전히 사소한 경우, 수십 가지 방법으로 표현할 수 있으므로 저작권이있을 수 있습니다. 그리고 아주 사소한 것이 저작권이없는 것인지, 저작권이없는 것인지를 말하기는 쉽지 않습니다.

저작권이있을 수 있지만, 사용하는 것은 공정한 사용입니다. 공정 사용은 몇 가지 요소의 무게에 의존하기 때문에 약간 복잡하며, 공정 사용의 적용 여부는 법원에서 결정하기 때문에 도움이되지 않을 수 있습니다. 이상적으로는 법원 사건이 전혀 필요하지 않습니다. 그러나 귀하의 사례는 강력 할 수 있습니다. 공정 사용의 요소 중 하나는 사용 된 작업의 일부 (이것은 모든 것을 취 했으므로 귀하에 대한 것임)이고 다른 하나는 작업의 상업적 잠재력입니다 (이는 상업적 가치이므로 사소한 버그 수정 자체는 0입니다.) 따라서 법원이 어떤 방식으로 규칙을 정할 것인지를 추측하는 것은 오류가 발생하기 쉽습니다.

아마도이 문제를 해결하는 가장 좋은 방법은 패치를 보지 못한 개발자에게 버그에 대한 정확한 설명과 정확한 위치를 전달하는 것입니다. 그런 다음 버그를 독립적으로 수정할 수 있습니다 (이 버그는 사소한 작업이므로 시간이 거의 걸리지 않습니다). 저작권이있을 경우 저작권을 소유하고 있기 때문에 잠재적 인 모든 저작권 문제가 사라집니다. 개발자는 본질적으로 패치를 작성하는 한 가지 방법 만 있기 때문에 패치와 거의 동일한 코드로 끝날 수 있지만이 경우 저작권이 없습니다.

http://www.ifosslr.org/ifosslr/article/view/30/64 를 읽은 후 저의 전문가 의견 은 다음과 같습니다.

원본 저작물은 단독 저작권을 보유하고 있으며 그 사람은 저작권을 소유하며 원하는 방식으로 저작물을 라이센스 할 수 있습니다.

이제 개발자는 버그를 발견하고 수정 사항을 제공합니다. 이것은 저작권이없는 것으로 간주 될 수 있지만 (너무 작은 기여) 상당한 기여라고 말합니다. 원저자는 두 사람 모두 합병에 동의했기 때문에 기여를 받아 들여 저작물을 집단적 저작물로 만듭니다.

공동 저작에서 각 저자는 각자의 부분을 소유하지만 전체 저작물에 대한 분할되지 않은 관심사를 소유하므로 원하는 모든 조건에서 전체 저작물을 공개 할 수 있습니다.

이것이 합리적인 해석이라면, 논란의 여지가 원래의 저자가 상용 릴리스에서 버그 수정을 사용할 수 있는지 아닌지에 대한 논쟁이 아닙니다. 잠재적 인 충돌은 버그 픽스 너가 자신의 작업에 대한 나름의 소유권이 있다고 생각하는지 여부입니다. 이 경우, 원저자가 저작물에 대한 소유권을 인정하지 않음을 분명히 나타내는 버그 수정 프로그램으로부터 릴리스를 얻는 것이 좋습니다.