소프트웨어 시스템의 프로토 타입을 개발 중이며 적어도 시작 시점에 비공개 소스가 될 것입니다.

시간을 절약하기 위해 GPLv3 에 따라 라이센스가 부여 된 라이브러리를 사용 (정적으로 링크)하려고 하므로 디자인을 빠르게 테스트 할 수 있습니다. 이 단계에서 소프트웨어를 배포 한 경우 소스 코드도 함께 배포해야합니다.

그렇지 않은 경우 시스템이 작동한다는 사실을 스스로 만족시키고 배포하기 전에 GPL 라이브러리를 내 코드로 바꾸면 어떻게됩니까? 결과가 GPL에 의해 "오염"됩니까?

내 Git 기록 에 GPL 라이브러리를 유지하면 차이가 생길 수 있다고 생각합니다.

GPL 은 다음과 같이 씁니다 .

귀하는 다음 조건을 모두 충족하는 경우, 섹션 4의 조항에 따라 소스 코드 형식으로 프로그램을 기반으로하는 저작물 또는 프로그램에서 프로그램을 생성하기 위해 수정 한 내용을 전달할 수 있습니다.

따라서이 조건은 작업이 라이브러리를 "기반으로"하는 경우에만 적용되며 라이센스는 다음과 같이 정의됩니다.

저작물을 "수정"한다는 것은 정확한 사본을 만드는 것 외에 저작권의 허가가 필요한 방식으로 저작물의 전부 또는 일부를 복사하거나 수정하는 것을 의미합니다. 결과 저작물을 이전 저작물의 "수정 된 버전"또는 이전 저작물을 "기반으로하는"저작물이라고합니다.

즉, 귀하의 프로그램은 저작권법에 따라 파생물 인 경우에만 라이브러리를 "기반으로"합니다 . 해당 용어의 법적 정의는 관할 지역마다 다소 다르며 일반적으로 소프트웨어를 직접 다루지는 않습니다. 예를 들어 미국 저작권법은 다음과 같이 씁니다.

"파생 작품"은 번역, 음악 배열, 드라마, 허구, 영화 버전, 녹음, 예술 재생, 요약, 응축 또는 작품의 다른 형태와 같은 하나 이상의 기존 작품을 기반으로 한 작품입니다. 리 캐스트, 변형 또는 개조 될 수 있습니다. 전체적으로 저작의 원래 저작물을 나타내는 편집 개정, 주석, 설명 또는 기타 수정으로 구성된 저작물은 "파생 저작물"입니다.

소프트웨어에서 이것이 의미하는 바는 이전의 유사한 판결에 근거하여 법원에서 해석해야합니다. 법원이 귀하의 사건을 어떻게 결정할지 확실하게 말할 수 있도록 귀하의 관할권의 관련 판례법을 충분히 알고 있지 않습니다. "자신의 코드로 GPL 라이브러리를 바꾸는 것"은 특히 코드가 GPL 구현에서 영감을 얻은 경우 번역 행위라고 주장 할 수 있습니다. GPL 라이브러리의 API를 재사용하더라도 뜨거운 물에 빠질 수 있습니다 ( Oracle vs. Google 참조 ).

대답이 당신에게 중요하다면, 인터넷에서 낯선 사람에게 물어 보지 말고 유능한 법적 조언을 구하는 것이 좋습니다.

GPL 라이브러리에 링크하는 동안 다른 사람에게 소프트웨어를 공개하지 않는 한 안전합니다. GPL의 바이러스 성 측면은 소프트웨어를 배포 할 때만 시작됩니다.

물론 LGPL, APL2 또는 MIT와 같이보다 허용적인 라이센스를 가진 라이브러리를 찾을 수 있다면 더 좋습니다.

나는 당신의 질문이 실제로 GPL에 관한 것이라고 생각하지 않습니다. 프로토 타입 및 향후 제공 가능한 소프트웨어 시스템의 기초로 사용 될지 여부에 관한 것입니다.

버림받은 프로토 타입을 제작할 때 제공 가능한 시스템에서 코드를 재사용하지 않으려면 GPL 라이브러리를 사용하십시오.

취할 수있는 세 가지 접근법

그러나 프로토 타입을 발전 시키려면 (많은 관리자가 요구하는) 세 가지 접근 방식이 있습니다.

1. 비 핵심 부품을 JSON, REST API 또는 기타 프로세스 간 통신 언어 / 라이브러리를 통해 코어와 통신하는 별도의 애플리케이션으로 이동하십시오. 따라서 비 핵심 부품도 GPL이 될 수 있으며 GPL 라이브러리를 사용할 수 있습니다.
2. 라이브러리를 교체 할 수 있도록 코드를 설계하십시오. 이것은 구현 세부 사항을 숨기는 정면 을 만드는 것을 의미 합니다. 독점 라이브러리 또는 MIT / BSD 라이브러리로 전환 할 준비가되면.
3. GPL 코드를 전혀 사용하지 마십시오.

첫 번째 접근 방식을 사용하는 것이 좋습니다. 향후 전문가 포트폴리오의 일부로 사용할 수있는 오픈 소스 작업이 있기 때문입니다.

두 번째 방법은 어떻게이기 때문에도 좋다 해야 정확한 기능을 작성, 어쨌든 당신이 필요 / 클래스 시스템을 설계하고 그들을 스텁 할 라이브러리 또는 사용자 지정 코드가있을 때까지 해당 기능 채 웁니다.

귀하의 접근 방식으로 고려해야 할 두 가지 측면을 생각할 수 있습니다. 첫 번째는 GPL 로 배포되는 코드를 사용하는 동안 프로젝트를 배포하지 않거나 (또는 GPLv3 이므로 공용으로 사용할 수 있도록) 간단합니다. 코드 배포 방법이 무엇인지 알기가 어렵습니다 재배포 조건에 따라 GPL 라이센스에 따라.

두 번째 측면은 아마도 당신에게 더 중요 할 것입니다. GPL 라이브러리를 대체하기 위해 자체 구현을 작성할 때 파생 작업을 작성하지 않도록주의해야합니다. 소스 코드를 직접 복사하지 않는 것이 좋은 의도라고 확신하지만 라이브러리 API의 상당 부분을 복사하지 않을 가능성이 높습니다.

이 제품이 상용 제품인 경우 GPLv3 라이센스를주의 깊게 읽고 의심되는 경우 전문적인 법적 의견을 요청하여이 위험을 고려하고 평가해야합니다.

GPL 코드를 대체하기 위해 자체 코드를 작성하려는 경우 클린 룸 환경에서 코드를 작성하지 않기 때문에 잠재적 인 문제가 있습니다. GPL 코드를 보지 않은 사람이 대체 라이브러리를 작성하도록 정말로 원할 것입니다. 반면에 다른 라이센스하에있는 이미 게시 된 라이브러리의 GPL 라이브러리를 간단히 바꾸려면 문제가되지 않습니다. 다른 라이브러리는 이미 클린 룸 환경에서 작성된 것 같습니다.

GPL 코드를 사용하여 개정에 대한 액세스를 제공하면 완전히 GPL이됩니다. 그러나 폐쇄 소스가 아니기 때문에 원하지 않습니다 ...

더 이상 GPL 코드를 더 이상 사용하지 않는 상태의 경우, 이전에 GPL 코드를 사용했던 것은 단순히 관련이 없습니다.

GPL은 배포시 에만 트리거됩니다 ... 수정 된 버전이나 파생 작업을 릴리스하지 않으면 원하는 모든 작업을 수행 할 수 있습니다.

내 Git 기록에 GPL 라이브러리를 유지하면 차이가 생길 수 있다고 생각합니다.

GitHub 와 같은 공개 저장소에 소스를 게시 하려는 경우 문제가있을 수 있습니다. git을 사용 하는 것은 개인 정보와 관련이 없습니다.