소프트웨어를 선택할 라이센스에 대한 권장 사항 및 경험


26

소프트웨어 개발자는 작업 목표에 따라 적절한 라이센스를 선택할 수 있습니다.

누구든지 소프트웨어를 선택할 라이센스에 대한 몇 가지 권장 사항 / 경험을 제공 할 수 있습니까?

모든 코딩 된 작업을 오픈 소스 코드로 "제공"하는 장단점은 무엇입니까?

리서치 코드의 혜택을 받고자하는 산업용 플레이어를 다루는 방법은 무엇입니까?


좋은 질문입니다. 나는 그것에 대해서도 궁금했습니다.
milancurcic

이 사이트와 관련이 없습니다. Stack Overflow와 같은 게시물에 게시하는 것이 좋습니다.
aterrel

GPL / LGPL 라이센스 소프트웨어를 상업적으로 사용할 수 없다는 Matt의 진술을 수정하고 싶습니다. 그것도 가능합니다! GPL 라이센스 소프트웨어는 상업용 기업이 원하는 모든 용도 로 사용될 수 있으며 파생 소프트웨어 제품을 만들어이를 폐쇄 소스로 판매 (배포) 할 수는 없습니다 (상업적 기업이 소프트웨어 회사가 아닌 경우 충분해야 함). LGPL은보다 관대하며 원본 라이브러리에 연결된 폐쇄 소프트웨어 제품을 판매 할 수 있습니다. 나는 업계가 GPL 소프트웨어를 다루는 것을 두려워하지만 Matt은 GPL에 대한 오해에 기초하고 있다는 것에 동의합니다. 우리는 원래
Anders Logg를

1
동의하지 않습니다. 많은 사람들이 계산 과학의 문제를 해결하기 위해 새로운 코드 기반을 개발하는 데 많은 시간과 노력을 투자합니다. 이러한 노력의 일환으로 다른 사람들과 작업을 공유하기위한 전략을 세우는 것이 유용 할 수 있습니다.
Allan P. Engsig-Karup

2
그렇습니다. 많은 계산 사람들이 요리에 시간을 소비하지만 요리는 여기서 다루지 않습니다. 기본 소프트웨어 문제에 대한 다른 스택 교환이 있습니다.
aterrel

답변:


18

누구든지 소프트웨어를 선택할 라이센스에 대한 몇 가지 권장 사항 / 경험을 제공 할 수 있습니까?

어떤 라이센스를 선택했는지는 코드를 얼마나 자유롭게 원하는지에 따라 다르지만 무료는 다른 사람들에게 다른 것을 의미합니다.

  • 허가 라이센스 를지지 하는 사람들에게 , 무료 란 사람들이 미래의 파생이 얼마나 자유로운 지 걱정하지 않고 지금 사람들이 원하는대로 소프트웨어를 사용할 수있게하는 것을 의미 합니다.
  • 카피 레프트 라이센스 를지지하는 사람들에게 , 무료 란 소프트웨어와 소프트웨어의 파생물 이 무료로 유지 되도록 보장하고,이를 보장하기 위해 즉각적인 자유 를 희생 할 준비를 하는 것을 의미합니다.

라이센스가 더 관대할수록 더 많은 사람들이 라이센스를 사용할 수 있지만 더 적은 제어권을 갖습니다. 그러나 더 제한적 일수록 사람들이 소프트웨어를 처음 사용하는 것을 막을 가능성이 높습니다.

GPL <= 2, GPL 3 , LGPL , BSD , Eclipse 등을 포함한 수많은 무료 및 오픈 소스 라이센스가 있습니다 . 각각의 장단점이 있으므로 코드에서 어떤 제한 사항을 적용하고 누가 코드를 사용할 수 있는지 결정하십시오. 경고 누군가가 불평을 선택하든, - 이것은 이다 거룩한 전쟁 영토.

전반적으로 미묘한 밸런싱 행위이며 소프트웨어의 대상 고객에 따라 크게 달라집니다.

  • 어떤 라이센스가 귀하에게 적합한 라이센스인지 결정하기위한 훌륭한 리소스 는 Oxford Universities OSS Watch 와 매우 포괄적 인 대화식 라이센스 차별화 요소 입니다.

제 생각에, 허가카피 레프트 라이센스는 과학 코드에 적합합니다. 중요한 것은 코드가 먼저 오픈 소스라는 것입니다. 나는 과학이 개방적이어야한다고 믿으며, 과학을 뒷받침하기 위해 사용 된 코드도 마찬가지입니다.

모든 코딩 된 작업을 오픈 소스 코드로 "제공"하는 장단점은 무엇입니까?

귀하의 소프트웨어를 제공한다는 아이디어는 다른 사람들이 유용하다고 생각하면 사용하게 될 것입니다.

그들이 그것을 사용한다면 그들은 버그를 찾고,보고하고, 자주 고칠 것이며, 그렇게하는 노력을 절약 할 수 있습니다.

그들이 그것을 좋아하고 당신의 소프트웨어가 원하는 것을 거의 수행 한다면, 그들은 당신의 소프트웨어를 향상시키고 그러한 향상에 기여할 것입니다.

즉 많은입니다 IFS 하지만.

리서치 코드의 혜택을 받고자하는 산업용 플레이어를 다루는 방법은 무엇입니까?

첫째, 코드의 상업적 사용을 금지하려면 상업적 재사용 조항이없는 라이센스를 선택할 수 있습니다.

둘째, 누군가가 코드를 실제로 다른 사람에게 배포하지 않고 누군가가 소프트웨어를 사용하여 서비스를 작동시킬 수 있다고 생각한다면, 특정 카피 레프트 허점을 막는 Affero GPL 을 고려할 수 있습니다.

셋째, 당신은 위의 작업을 수행 할 수 있습니다 듀얼 라이센스 옵션을 제공합니다. 공개 다운로드 용 GPL 또는 AGPL 라이센스와 유료 유료 라이센스를 제공하면 두 가지 이점을 모두 누릴 수 있으며 소프트웨어의 상업적 판매에서 약간의 수익을 창출하여 과학 활동을 지원할 수 있습니다.

이 작업을 수행하려는 경우 처음부터 제공하십시오. 나중에 상용 라이센스를 제공하기 시작하는 것보다 오픈 소스 제공 업체의 마찰이 덜 발생할 수 있습니다. 지역 사회가 대중화되면 나중에 상업적인 착취 가능성에 대해 명확하지 않은 사람들이 귀하를 매각한다고 비난하는 것을 원하지 않습니다. 코드베이스에 대한 제 3 자 제공을 수락하기 전에 적합한 CLA (Contributor License Agreement)를 설정하는 것이 이상적 입니다.

이 질문에 대한 이 답변 은이 옵션에 대한 좋은 정보도 제공합니다.


12

PETSc는 덜 제한적인 형태의 BSD 인라이센스를 사용합니다 . 와의 중요한 차이점GPL소프트웨어를 상업적으로 사용할 수 있다는 것입니다. 많은 사람들이 폐쇄 소프트웨어에 대해 원칙적으로 반대하지만, 내 경험상 GPL 라이센스가 있으면 코드 근처에 비즈니스가 없습니다. 또한 PETSc의 산업 사용자는 엄청나게 가치가 있습니다. 그들은 상당히 복잡한 문제를 겪는 경향이 있으며, 대부분의 학자들은 출판물에 대해 보증하는 것보다 더 어려울 것입니다. 또한 많은 코드를 PETSc에 제공하여 정상적인 지원 체인에 들어갈 수있게했습니다. 상업적 사용 가능성이없는 라이센스에 대해 조언하고 실제로 가능한 최소 제한 라이센스를 옹호합니다 (PETSc를 CD로 구워서 쓸 수없는 사람에게 팔려고 시도 할 수 있습니다).


PETSc의 개발 자금은 어떻게 지원 되었습니까? 그리고 오늘날 (자금을 통해) 어떻게 지원됩니까? PETSc의 코드베이스를 유지 관리하는 방법은 무엇입니까?
Allan P. Engsig-Karup

2
여기 자금이 있습니다. 우리는이 열려있는 저장소에 많은 기여를.
Matt Knepley

GPL 코드에 대한 설명 : OpenFOAM은 GPL이며 업계에서 널리 사용됩니다. 소프트웨어를 배포 할 경우에만 GPL 코드를 공개해야하기 때문입니다. 광범위한 청중에게 코드를 판매하려는 비즈니스 만 GPL 라이센스의 영향을받습니다.
akid

3
@akid 웹 사이트에서 OpenFOAM 사용자에 대한 정보를 찾을 수 없지만 "일반적으로 사용되는"특성에 회의적입니다. 나는 대기업 (Shell, Boeing, MS)의 사람들이 연구 코드에 대한 회사 정책이 절대 GPL을 건드리지 말아야한다고 언급했다. 소기업은 더 여유가 있지만 대기업은 부적절한 것처럼 보이는 것조차 피하고 싶어합니다 (GPL 코드를보고 다른 것을 코딩하는 것).
Matt Knepley

2
@Tshepang GNOME 및 Linux는 사무용품과 같이 사용되며 과학 코드에는 절대 적용되지 않습니다. 코드를 비즈니스와 직접 관련된 목적으로 사용하는 것을 의미합니다.
Matt Knepley

5

저는 원래 오픈 소스 운동에 대한 정서 때문에 GPL을 사용합니다 (따라서 확산에 도움이되기를 바랍니다). 또한 이것은 역설적으로 부도덕 한 자본가로부터 가능한 수입을 보호하는 가장 좋은 방법입니다. 저자는 항상 다른 라이센스에 코드를 병렬로 배포하여 화이트 라벨 비즈니스 용 독점 버전을 유지할 수 있습니다.
그러나 이는 또한 사기 일 수 있습니다. 자금 출처는 모든 작업이이 라이센스를 넘어서는 퍼블릭 도메인이되어야한다는 면책 조항을 만들 수 있습니다.

어쨌든, 그 주제에서 가장 중요한 것은 라이센스가 어느 것보다 낫다는 것입니다. 불행히도 과학 개발 세계에서는 상당히 흔합니다. 그가 공개 된 적이없는 존 스미스의 프로그램에서 / * 도난을 * / 또는 CI는 1995 년 Jane Smith의 일부 그룹에 대한 게시물에서 이것을 보았을 것입니다.


1
코드에 라이센스가없는 경우 ( 베른 협약에 서명 한) 대부분의 국가에서이 코드 는 여전히 저작권의 보호 를 받으 므로 재배포는 물론 저작권 소유자 이외의 사람도 법적으로 사용할 수 없습니다.
Mark Booth

@MarkBooth 내 요점입니다.
mbq

5

첫째, 오픈 소스로 갈 때의 장단점 :

장점 : 더 많은 사람들이 귀하의 코드를 사용하고 피드백, 수정, 개선 등을 제공 할 것입니다. 더 나은 코드와 더 많은 사람들이이를 신뢰하게됩니다.

단점 : 코드를 기반으로 비즈니스를 운영하려는 경우 옵션이 더 적습니다 (그러나 컨설팅 서비스 판매와 같은 몇 가지 방법이 여전히 있습니다)

라이센스를 선택하는 방법은 다음과 같습니다.

  1. 고용주 / 보증 기관이 무엇인가를 부과합니까? 그러면 선택의 여지가 없습니다. 코드의 모든 기고자를 위해 이것을 확인하십시오.
  2. 선택을 제한하는 특정 라이센스가있는 코드를 재사용합니까? 그러면 선택도 제한됩니다. 실제로, GPL 라이센스 코드를 통합하는 것이 이러한 제한의 가장 빈번한 소스입니다.
  3. GPL과 그와 유사한 라이센스에 대한 모든 코드, 개방형 철학, 또는 BSD 라이센스에 대한 가장 폭 넓은 사용을 장려하는 철학에 대한 가치를 결정하십시오.
  4. 두 개의 큰 오픈 소스 라이센스 제품군 각각에서 커뮤니티에서 가장 일반적으로 / 허용되는 사항에 따라 선택하십시오.

5

내 연구의 대부분은 공공 자금으로 자금을 조달하므로 가능한 한 가장 제한적인 라이센스를 사용해야 할 의무가 있다고 생각합니다. 우리나라의 다른 사람들이이 연구에 대한 비용을 지불하는 것을 도와주고 있다면, 제 코드를 비공개 소스 및 / 또는 상용 소프트웨어 배포판에 통합 할 수 없다고 말할 권리가 있습니까? 내 코드를 사용하는 대부분의 사람들은 학술 과학자가 될 것으로 기대하지만 소프트웨어를 다른 (아마도 상용) 소프트웨어와 통합하고 GUI를 사용하여 제품을 제공함으로써 소프트웨어를 개선하는 비즈니스에는 철학적 문제가 없습니다. 그들이 이익을 얻는 데 도움이됩니다.

즉, 적절한 속성이 필요한 라이센스를 사용하려고합니다. 예를 들어, 회사 내 코드를 더 큰 상용 제품으로 접는 경우 내 코드를 자유롭게 얻을 수 있도록하기를 원합니다. 그러나 그 외에는 가능한 한 코드 사용자에게 적은 요구 사항을 적용하고 싶습니다.

납세자 자금으로 자금을 지원하지 않는 소프트웨어 개발의 경우 다른 라이센스가 더 적합 할 수 있음을 이해합니다.


5

아무도 이것을 명확하게 설명하지 않았으므로 말할 가치가 있다고 생각합니다.

일부 오픈 소스 라이센스 (특히 GPL)는 코드가 새 프로젝트에서 사용될 때마다 새 프로젝트에 동일한 방식으로 라이센스를 부여해야한다는 의미에서 "바이러스 성" 입니다. 또한 코드는 다른 방식으로 라이센스가 부여 된 코드에 (특정 방식으로) 링크 될 수 없습니다.

한 가지 실질적인 결과는 다음과 같습니다.

  • C로 새로운 수치 방법을 구현하면 MATLAB 또는 Mathematica와 같은 일반적인 소프트웨어에서 라이센스를 호출 할 수 없습니다

  • 새로운 이미지 처리 알고리즘을 구현하면 라이센스에서 Photoshop 플러그인을 만들 수 없습니다.

  • 등등 ...

이렇게하면 상업적 재사용을 막을뿐만 아니라 다른 학계 (폐쇄 된 소프트웨어를 사용하는 경우)에 의한 편리한 재사용이 가능하며, 누군가가 귀하의 코드를 기반으로하는 경우 " -무엇을 할 것인가? "

라이센스 작성을 마치기 전에 고려해야 할 사항입니다.

나는 이것을 알지 못 하거나이 각도에서 그것을 고려하지 않은 사람들 (오픈 소스 라이센스에 익숙하지 않은 사람들)을 만났기 때문에 이것을 이렇게했습니다.


(이것은 단지 개인적인 견해이지만, (공공 자금으로 지원되는) 학계에서 오는 일에 그러한 제한을 적용하는 것은 적절하지 않다고 생각합니다.


4

어떤 라이센스를 선택하든 관계없이 모든 라이센스 계약을주의 깊게 확인하여 소프트웨어 라이센스에 관한 방법을 지시하거나 제한하는 조항이 없는지 확인하십시오.

내 경우에는 내 프로젝트의 많은 자금을 여러 층으로 쌓아 알고, 여기에 조금 조금이 비트, 내가있어 어떻게 추적 유지 허용 에 빛을 유지하는 사람들이 내 물건을 라이센스 및 작동하는 기계는 상당히 복잡합니다.


4

많은 코드를 사용하려면 다른 답변에 설명 된 라이센스 중 하나 인 LGPL을 선택하십시오. 그러나 일반적으로 소프트웨어에 권장되지않지만 업계 동료에게 보낼 수있는 작은 자체 포함 스크립트의 경우 종종 Creative Commons 라이센스를 선택합니다. 코드를 보내는 사람에게 더 명확 해지기 때문에 오해의 잠재적 인 문제가 발생하지 않기 때문입니다. 이것은 과거에 나에게 잘 작동했습니다.


4

여기에 응답하는 대부분의 사람들 (학술 및 / 또는 공공 기관에서 일하는 사람)과 달리 저는 상업 분야에서 일하고 있습니다.

내 제품의 경우 코드가 닫히고이 작업을 수행하면 비즈니스 이점이 계속 있습니다. 그러나 물론 다른 방법도 있습니다 (예를 들어 MySQL에서 다른 사람들과 같이). 라이브러리에 대한 LGPL + 상용 라이센스 접근 방식을 자주 봅니다. 상용 시스템에서 이러한 라이브러리를 아직 사용하지는 않았지만 배제하지는 않았습니다 (지금까지는 R & D 수준에서 이러한 라이브러리 (예 : ALGLIB) 만 사용했습니다). 이것은 내부적으로 사용할 수 있지만 주로 바이러스 성으로 인해 제품에 사용하지 않는 GPL 제품과 대조됩니다.

소스 코드 (사용 방법 샘플, 무료 프로그램 등)를 릴리스 할 때는 일반적으로 Berkeley 라이센스를 사용합니다. 이것은 "자유로운"코드의 정신에 있지만 GPL 문자열과 정치가없는 속성이있는 것 같습니다. 아마도 이것이 MIT 라이센스와 같은 유사한 라이센스가 대학 및 공공 기관에 인기가있는 이유 일 것입니다. 소스 코드는 '무료'라는 진정한 의미로 제공되지만 (여기서 코드를 사용하여 원하는 것을 수행하십시오) 저자는 여전히 신용 / 속성을받습니다.


나는 이것을 투표로 뽑은 사람이 아니며, 실제로 BSD 라이센스를 선호하는 이유와 흥미로운 이유에 대해 더 자세히 투표하고 싶습니다. 그러나 문제가 있습니다. 사용 된 언어는 도발적입니다. 정확히 같은 정보를 담즙없이 전달할 수 있으며, 더 많은 사람들에게 메시지를 전달할 수 있습니다.
qubyte

@ MarkS.Everitt : 정치에 대한 의견 외에, 정확히 여기에 무엇이 도발적인가?
aeismail

예, 담즙이 의도되지 않았습니다. GPL 정치에 대한 나의 의견은 개인적인 의견 일뿐 아니라 관찰입니다.-투표율이 저를 끄는 일종의 정치라고 가정했습니다 (GPL을 비판하고 폐쇄 된 코드를 작성하는 방법은
무엇입니까

첫 문장을 예로 들어 보겠습니다. 이것은 바로 당신 대 저 입니다. 이것은 "무엇과 반대로 ..."문장에서 계속됩니다. 중요하지 않지만 불행히도 중요합니다. 또한 인수를 생성하기에 미끄러운 경사이며 어린 SE에게는 필요하지 않습니다.
qubyte

첫 번째 문장은 내 대답의 맥락을 설정합니다. 상황이 중요하다-그리고 나는 그것이 나에게 특히 그렇다고 생각했다. 다음 단락을 편집하려고 시도하지만 모든 것을 포기하고 삭제할 수 있습니다. 내가 ... 내가 말할 유용한 무언가를 줄 알았는데
winwaed

0

이것은 오래된 질문이지만 모질라 퍼블릭 라이센스 는 허가 라이센스 (BSD, MIT)와 강력한 카피 레프트 라이센스 (GPL) 사이의 중간 근거로 언급 할 가치가 . MPL 코드를 사용하고 재배포 할 수 있지만 MPL 코드와 해당 코드에 대한 수정 사항이 있어야합니다. 예를 들어, 회사는 MPL 코드를 가져 와서 자체적으로 개선 한 후 수정 된 원본 MPL 코드 버전을 사용할 수있는 경우 독점 폐쇄 소스 소프트웨어 패키지로 배포 할 수 있습니다. GPL과 마찬가지로 자체 소스 코드를 모두 공개 할 의무는 없습니다.

BSD 라이센스를 사용하면 회사가 개선 한 내용이 경쟁 우위를 부여한다는 이론적 근거로 기업이 사용자 또는 커뮤니티에 크게 기여하지 않고 코드를 가져 와서 개선 할 수 있다는 두려움이 있습니다. (Matt Knepley의 답변에 따르면 모든 사람이 이런 식으로 행동하는 것은 아닙니다). 반면에 많은 사람들은 GPL 코드를 완전히 피할 수 있습니다. MPL은 최소한 원칙적으로이 두 가지 잠재적 함정을 피합니다.

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