이 시나리오는 합법적이거나 불법적 인 형태로 발생할 수 있습니다.
회사가 코드와 관련된 저작권을 소유하거나 액세스 할 수있는 경우 이는 합법적으로 발생할 수 있습니다. 예를 들어 소규모 독립 개발 팀은 자신의 저작권을 대기업에 판매하거나 라이센스를 부여 할 수 있습니다. 마찬가지로, 코드의 대부분의 저작권을 취득 할 수있는 경우, "얻을 수없는"부분은 단순히 던져지고 다시 쓰여질 수 있습니다.
동전의 반대편에서 코드는 단순히 불법으로 간주 될 수 있습니다. New Corp, Inc.는 법적 영향이 무엇인지 신경 쓰지 않을 수 있습니다. 프로젝트가 너무 오래되었거나 포기되었거나 New Corp은 소송에서 이길 것이라고 생각합니다. 또는 이러한 종류의 "획득"이 단순히 불법으로 정의되지 않은 영역에 New Corp이 등록되어있을 수 있습니다. 모든 OSS 라이센스를 적용 할 수있는 것은 아니며, 특히 법률 전문가가 아닌 사람이 함께 만든 라이센스는 아닙니다. 모든 프로젝트 소유자가 자신의 저작권 주장을 시행 할 수있는 것은 아니며 FSF와 같은 대규모 조직은 해당 주장에 대해 해당 관할권에 서 있지 않을 수도 있습니다. TL; DR-이 영역은 흐릿하고 추악 할 수 있습니다.
전환 및 예방
전환은 어떻게 이루어지며 차등 라이센스 선택을 넘어서는 것을 방지하기 위해 무엇을 할 수 있습니까?
New Corp, Inc.가 코드베이스를 획득하고 해당 사본을 해당 제어하에 배치하면 전환이 발생합니다. 그런 다음 New Corp의 개발자 는 회사의 대주주가 필요하다고 판단한 변경 사항을 적용 하기 위해 자신 의 코드 기반 버전 작업을 시작 합니다. 이 포크의 실제 메커니즘은 저장소에 따라 다릅니다. 그리고 철학적으로 큰 일이지만 실제로는 실제로 매우 압도적입니다. get allOpenRepos checkin에서 PrivateRepos로.
소스를 배포하지 않는 것을 방지하기 위해 무엇을 할 수 있습니까? 아무것도. 죄송합니다.
GPL (GNU 공개 라이센스)을 예로 들어 봅시다. GPL은 합법적 인 프로젝트 사본을받는 모든 사람이 소스를 사용할 수 있어야합니다. 소스 소지자가 GPL 출원 사본의 정당한 보유자에게 소스의 전달을 거부 할 수있는 조항 은 없습니다 . 그것은 자유 소프트웨어의 결정에 위배되므로 GPL 카피 레프트가 제자리에있는 이유입니다.
잠재적으로, 당신은 추구 할 사후의 법적 조치 과정을 가지고 있습니다. 그러나 그것들은 모두 소스가 탈출 한 후 이전이 아니라 포크 된 후에 발생합니다. 그리고 일부 관할 지역에서는 법적 상환이 없습니다. 그리고이 모든 것은 포크가 발생했다는 것을 알고 있다고 가정합니다 . 당신은 결코 찾을 수 없습니다.
윤리학
회사의 (윤리적 또는 사회적) 책임은 무엇입니까? (예 : 오픈 소스 프로젝트에 돌려주는 것이 윤리적으로해야 할 일)
윤리는 문화에 국한됩니다. 따라서이 섹션을 그 소금 알갱이로 강화하십시오. 윤리에 대한 문화적 고려에 대한 전체 토론은이 답변의 범위를 벗어 났으며 프로그래머에게는 주제가 아닙니다.
나는 프로그래밍 공동체가 적대적인 포크에 부정적으로 반응하는 경향이 있음을 알아 차렸다. 도대체 어떤 경우에는 같은 공동체가 여전히 친근하고 합법적 인 포크에 부정적으로 반응합니다. 꽤 복잡한 커뮤니티입니다.
FOSS 관점에서, 뉴 코퍼레이션 (New Corp)은 지역 사회에 기여한 공헌에 대해 커뮤니티를 "상환"할 것으로 기대하고 있습니다. 상환 조건, 기간 및 기간은 존재하는 OSS 프로젝트의 수만큼 다양합니다. 커뮤니티의 일부 (리차드 스톨만)는 열린 프로젝트가 끝나는 것에 만족하지 않습니다. 다른 사람들은 지역 사회에 제공되는 혜택을 전체적으로 찾고이를 기반으로 판단 할 것입니다. 그리고 다른 사람들은 원산지 프로젝트에 대해 전혀 알지 못 했으므로 걱정하지 않을 것입니다.
소스 가용성
공개 소스 버전과 비공개 소스 버전을 모두 사용할 수있는 경우 경쟁이 두 제품에 어떤 영향을 미칩니 까?
그것은 기능, 성능 및 안정성과 관련하여 두 코드 기반이 얼마나 비슷한 지에 달려 있습니다.
코드 기반이 유사하게 유지되고 New Corp이 OSS 커뮤니티에 친숙한 경우 업데이트를 기본 프로젝트에 다시 제공 할 수 있습니다. 이 경우 모든 사람이 혜택을받습니다. 이 경우에는 "경쟁"이 아니라 상호 이익이되는 공동 작업에 더 가깝습니다.
코드 기반이 심하게 갈라지고 New Corp이 OSS 커뮤니티에 친숙하지 않다면 여전히 경쟁이 없습니다. 더 많은 기능이 풍부한 제품이 살아남을수록 더 적은 제품이 죽는 경향이 있습니다. 오픈 소스 버전이 지속적으로 혁신을 이루거나 커뮤니티의 요구를 더 잘 충족 시키면 폐쇄 버전이 사라질 수 있습니다.
현실은 스펙트럼의 두 끝 사이에있을 것입니다.
예
Red Hat에는 Enterprise Linux와 Fedora의 두 가지 주요 배포판이 있습니다. EL은 "폐쇄 된"라이센스 버전이고 Fedora는 커뮤니티 버전입니다. GPL로 인해 EL 판의 전부는 아니지만 대부분이 소스 형식으로 릴리스됩니다. CentOS라는 Red Hat과 관련이없는 다른 프로젝트는 EL의 변경 사항을 선택하고 약간의 브랜드 변경 후에 해당 프로젝트를 배포합니다.
Red Hat이 두 개의 개별 버전으로 갈 때 약간의 불만이 있었지만 전반적으로 꽤 합의 된 계약이었습니다. Fedora 커뮤니티는 Red Hat의 엔터프라이즈 고객이 선호하는 것보다 빠른 속도로 배포에 포함 된 기능을 원했습니다. 코드베이스의 향상은 양방향으로 흐릅니다.