GPL이 목표 달성에 얼마나 성공 했습니까? [닫은]

코드의 상업적 사용과 관련하여 광범위하게 두 가지 유형의 FOSS 라이센스가 있습니다. GPL 유형과 BSD 유형이라고합시다. 첫 번째는 라이센스 하에서 코드의 상업적 사용 (사용으로 인해 수정 및 재배포, 파생 된 저작물 생성 등을 의미 함)에 대해 광범위하게 제한적이며, 두 번째는 훨씬 더 허용 적입니다.

알다시피, GPL 유형 라이센스의 기본 개념은 사람들이 독점 소프트웨어 모델을 포기하고 대신 FOSS 코드로 변환하도록 장려하는 것이며 라이센스는 그들이 그렇게하도록 유도하는 도구입니다. ,하지만 당신이 우리 캠프에 와서 우리 규칙에 따라 플레이하기로 동의 한 경우에만 "

내가 묻고 싶은 것은-지금까지이 전략이 성공적 이었습니까? 즉, GPL로 인해 폐쇄 형에서 개방형으로 진행되거나 GPL로 인해 개방형으로 개발 된 일부 소프트웨어 형태의 주요 성과가 있습니까? 예를 들어, 모든 사람이 BSD 유형의 라이센스를 가지고 있거나 공개 도메인에서 모든 오픈 소스 코드를 공개하는 세계와 비교할 때이 전략의 영향은 얼마나 큰가?

FOSS 모델이 성공적인지 묻지 않습니다. 이것은 의심의 여지가 없습니다. 내가 묻는 것은 사람들이 GPL 유형에 의해 사용되고 BSD 유형 라이센스에 의해 사용되지 않는 독점에서 FOSS로 변환하도록 유혹하는 구체적인 방법이 성공했는지입니다. 또한 라이센스로서 GPL 자체의 장점에 대해 묻지 않고 그 효과의 사실에 대해서만 묻습니다.

첫째, 질문에는 본질적인 주관성이 있습니다. 확실히 알 방법이 없으며, 역사는 어느 쪽이든 해석 될 수 있습니다. 이것은 오래된 토론이며 토론 오픈 소스 대 자유 소프트웨어의 핵심 문제 중 하나입니다. 또한 목표에 도달하여 의미를 정의해야합니다. GPL과 FSF가 지난 2-3 년간 오픈 소스를 중요한 운동으로 만들지 않았다고 주장하기는 어렵다. 그러나 자유 코드 인 모든 코드의 목표에 도달하지 못했습니다.

GPL 소프트웨어의 모범은 물론 리눅스이며 FSF (gcc 등)에서 오는 모든 것입니다. 흥미롭게도 리눅스의 경우 GPL은 정치적 입장으로 선정 된 것이 아니라 리누스 토 발드 (Linus Torvald)가 여러 차례 언급 한 것처럼 상호주의라는 아이디어 때문에 선택되었습니다. 나는 당신에게 내 코드를 주지만, 당신이 내 코드를 사용한다면 나에게 당신의 코드를 대가로 주어야합니다.

리눅스 자체가 진행되는 한 GPL은 매우 귀중하다고 생각합니다. 최근 예는 Oracle 내부에서 개발 된 새로운 fs 인 BTRFS입니다. BTRFS의 주요 작가는 오라클이 GPL을 사용하기로 처음 동의 한 유일한 이유는 선택의 여지가 없기 때문이라고 밝혔다. 더 큰 문제는 리눅스 자체가 GPL로 인해 성공했는지 아니면 그래도 성공했는지 여부입니다. Linus의 놀라운 리더십, 그 당시 * BSD 프로젝트의 저작권 문제 등과 같은 여러 가지 요인으로 인해 가설을 증명하거나 반증 할 수 없습니다.

gcc의 경우 Stallman 은 GPL이 왜 프로젝트를 "사전 화"에 반대하여 저장했는지 여러 번 썼다 .

BSD, MIT 및 Apache 라이센스와 같은 무제한 라이센스는 GPL보다 FOSS를 증진시키기 위해 훨씬 더 많은 일을했다고 말합니다.

예 :

• 성 프로젝트,
• jQuery,
• SQLite,
• 아파치,
• 최대 절전 모드 및 최대 절전 모드
• ASP.NET MVC,
• JSON.ORG,

그리고 많은 다른 사람들.

비즈니스 자체가 실제로 GPL / 부가가치 서비스 모델 하에서 작동하지 않는 한, 대부분의 비즈니스는 개발 노력의 어느 곳에서나 GPL 코드를 허용하기 위해 GPL을 너무 조심합니다.

GNU GPL은 FLOSS 시행에도 불구하고 성공했지만 성공했습니다. 회사는 대부분 GPL에 따라 자발적으로 코드에 기여하고 배포합니다. 상용 알고리즘이 적용되는 중요한 알고리즘과 라이브러리는 없으므로 상용 개발자가 독점을 해제해야합니다.

애플은 좋은 모범을 보인다. 그들은 KHTML을 채택하여 WebKit으로 발전 시켰습니다. 그리고 코드를 다시 공개 소스 커뮤니티에 공개했습니다. 이것이 LGPL에 의해 강제 되었기 때문에 이것이 가능하다고 생각할 수는 있지만, 가능성이 낮습니다. 다윈과 BSD 사용자에게는 코드를 자발적으로 게시합니다. 그리고 LLVM을 사용하여 새로운 FLOSS 프로젝트를 시작했습니다. 그러나 애플은 여전히 ​​독점 소프트웨어 벤더로 남아있다.

안드로이드도 비슷합니다. 물론 하드웨어 지원은 여기서 중요한 역할을하지만 Google은 BSD 코드베이스를 채택하여 독점적으로 사용할 수있었습니다. 그러나 그들은 리눅스를 선택했습니다. 따라서 GPL이 아닌 대안이 없었기 때문에 기꺼이 기꺼이 기여합니다.

Openoffice는 한 시점에서 실제로 독점적이기 때문에 더 흥미로운 이야기입니다. 그러나 다시 한 번, LGPL 변환은 자발적이며 필요하지 않았습니다. 그러나이 경우 * GPL 유형 라이센스가 가능해졌습니다. 다른 사람이 코드를 소유했을 수 있기 때문에 Sun이 Openoffice를 릴리스하기에는 학술 BSD 유형 라이센스로는 충분하지 않았을 것입니다. 이와 관련하여 GNU * GPL은 성공적이었습니다.

상호 / 바이러스 조항은 더 많은 오픈 소스 코드로 직접 연결되지 않습니다. 그러나 소프트웨어 공급 업체는 원하는 때에이를 활용하여 FLOSS 풀에 기여합니다. 그러나 대부분의 공급 업체는이를 무의식적으로 만듭니다. 더 많은 코드 기여를 장려한다는 점에서 BSD 스타일과 GPL 스타일 라이센스의 차이점은 거의 없습니다.
결론적으로 GNU GPL은 성공적 이었지만보다 적합한 BSD / MIT 스타일 라이센스를 추진했습니다. 그러나 "코드의 양"에서의 성공을 측정 할 수도 있습니다. 실제 FSF 메트릭이라고 생각합니다.

GNU 선언문을 보면 설득력있는 회사가 FOSS 소프트웨어를 출시하도록하는 것이 목표 중 하나라는 것이 확실하지 않습니다. 인용문은 다음과 같습니다.

불명예없이 컴퓨터를 계속 사용할 수 있도록, 나는 자유롭지 않은 소프트웨어 없이도 잘 지낼 수 있도록 충분한 자유 소프트웨어를 모으기로 결정했습니다.

우리가 그 목표를 보면 GNU 프로젝트가 크게 성공한 것입니다. 우리는 자유롭게 수정하고 재배포 할 수있는 GPL OS, 오피스 스위트, 데이터베이스 및 기타 여러 응용 프로그램을 보유하고 있습니다.

FOSS 세계에서 둘 다 (GPL 및 BSD 유형 라이센스) 모두 중요하다고 생각합니다. 두 그룹에서 GPL 사용을 봅니다. 하나는 매우 참여도가 높은 오픈 소스 지지자 그룹입니다. 그들은 오픈 소스를 독점적 인 작업으로 다시 전환 할 수있는 가능성이 OSS 세계를 손상시킬 것이라고 믿는다. 개인적으로 생각하는 것은 큰 문제가 아닙니다. PC-BSD (독점 BSD- 변형)는 BSD- 커뮤니티를 손상시키지 않습니다. GPL을 채택한 두 번째 그룹은 대기업입니다. 그들은 라이센스를 사용하여 제품에 대한 통제력을 강화합니다 (예 : 비즈니스 모델을 지원하기 위해). 경쟁사에는 다른 GPL 라이센스 소프트웨어 제품으로 돈을 벌기 위해 문제가있을 것입니다. 따라서 회사는 경쟁 우위를 유지하면서 제품을 오픈 소싱하기에 좋은 업장을 얻습니다.

내 개인적인 관점은 개인 개발자 중 하나이며, 장애로 인해 한동안 고용되지 않았으며, 내가 가진 유일한 소중한 기술로 다시 살 수 있기를 바라고 있습니다.

GPL은 항상 상업 프로젝트에 사용됩니다. 문제는 때때로 "바이러스 적"성질이라고하는 것입니다. 즉, 프로젝트에서 일부 GPL 코드를 사용하는 경우 해당 프로젝트의 모든 코드 를 GPL해야 할 수도 있습니다 . 일부는 동적 연결에 대한 제외를 주장합니다. GPL은 FAQ는 플러그인으로 인해 동적 링크 공유 데이터 구조에 금지 주장 - http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins. 모든 Windows 응용 프로그램이 Windows 구성 요소에 동적으로 링크되고 Windows와 데이터 구조를 공유하기 때문에 (응용 프로그램은 여러 가지 방법으로 운영 체제 플러그인 임), GPL Windows 응용 프로그램이 GNU에 의해 많이 출시 된 것을 포함하여 이상하게 보입니다. 어쩌면 이것은 포인터로 핸들을 위장하고 함수를 통해 대부분의 액세스를 수행하는 것은 데이터 구조를 공유하는 것으로 계산되지 않습니다. 이는 특별히 설계된 플러그인 API 또는 동적으로 연결된 라이브러리가 아마도 악용 할 수있는 허점이 될 수 있지만 분명히 개별 개발자는 안전하게 사용해야합니다. 그런 문제에.

어쨌든, GPL의 "바이러스 적"성질에 대한 충분한 이유가 있지만, 생계를 유지해야하는 필사적 인 소규모 개발자의 경우, 이것은 당신의 일을 아무것도 포기하지 않는 것처럼 보입니다. 우리는 다른 문제들 중에서도 관련 기술을 모두 갖추고 있지 않기 때문에 지원을 청구하거나 효과적으로 매뉴얼을 판매하여 돈을 벌 수는 없습니다. 또한 제품에 무료 설명서가 충분하지 않은 경우 실제 설명서는 아마도 스택 오버플로 또는 수퍼 유저 또는 유료 매뉴얼이 아닌 다른 것으로 끝날 것입니다. 그리고 그것은 누군가가 그것을 알아 내려고 귀찮게한다고 가정합니다.

이러한 관점에서 BSD 스타일 라이센스는 매우 매력적입니다. 다른 오픈 소스 작업을 이용하면서 결과 제품을 닫아 두는 것이 위선적임을 인정하지만 다른 문제와 균형을 이루어야합니다.

OTOH, 나는 실제로 열거 나 닫은 것을 공개하지 않았습니다. 적어도 10 년 전에 기본적으로 공개 도메인을 만든 플러그인이 있기 때문에 (그리고 몇 년의 경험이 가르쳐 주었을 때, 그들은 잘 쓰여지지 않았습니다. ). 그래서 적어도 모든 순간은 나에게 학문적입니다.

그래도 GPL 스타일 라이센스가있는 라이브러리를 볼 때마다 나의 생각은 "이것에 의존하면 옵션을 제한하는 것"입니다.

저는 사람들이 GPL을 생각할 때 소프트웨어가 자유로운 생각이어야하는 아이디어에 대해 생각할 수 있다고 생각합니다. 그래서 아이디어가 나올 것이고 대기업은 그것을 허용하지 않기 때문에 나쁜 사람이라고 생각합니다. 문제는 사고 방식이 많은 프로그래머를 사지 않는다는 것입니다. 왜냐하면 그들은 단지 코딩하기를 원하고, 프로그램을 가지고 있고 또한 자신의 삶을 소유하고 있기 때문입니다. 소프트웨어를 포함 할 필요는 없습니다. 리누스는 개발자에게 리차드 스톨만보다 더 인기가 있다는 것과 같은 의미에서 첫 번째는 단지 우리와 마찬가지로 자신의 일을하기를 원하고 다른 하나는 전 세계를 바꾸고 싶어하기 때문입니다. 결국 GPL은 진화를 시작하지만 성공할 운명이 아닌 미하일 고르바초프와 같습니다.