오픈 소스 프로젝트에 대한 라이센스 선택

저는 오픈 소스 프로젝트를 수행했으며 앞으로 더 많은 것을 할 계획입니다. 지금까지 GPL에 따라 모든 코드를 공개했지만 GPL이 회사 환경에서 사용하기에 너무 제한적이라고 주장하는 기사를 읽었습니다. 이것은 아마도 기여를 줄입니다.

내가 성취하고 싶은 것은 다음과 같습니다.

의 경우 전체 응용 프로그램 :

• 응용 프로그램에 대한 지원 판매를 제외하고는 상업적 용도로 사용하지 않습니다 (예 : 응용 프로그램 을 판매 할 수는 없지만 주변의 모든 것이 가능합니다)

대한 라이브러리 (구성 요소, 플러그인, ...)

• 수정없이 상업 프로젝트에 포함될 수 있습니다
• 라이브러리 / 컴포넌트의 수정은 오픈 소스 여야합니다 (기여)-상업적이든 아니든 프로젝트의 나머지 부분은 영향을받지 않습니다.

응용 프로그램의 경우 GPL은 여전히 ​​논리적 선택입니다. 라이브러리의 경우 라이센스에 대한 기본 지식을 이해하면 LGPL이 적합하다고 생각하지만 확실하지 않습니다. MIT 라이센스를 살펴 봤는데 너무 허용적인 것 같습니다.

대부분의 경우, 개선 사항이 반영되는 한 사람들이 원하는 곳에서 코드를 사용하기를 원합니다.

LGPL이 오픈 소스 라이브러리, 구성 요소, 플러그인 등에 대한 논리적 선택입니까? 더 나은 대안이 있습니까? 내 응용 프로그램에 GPL이 좋은 선택입니까, 아니면 더 좋은 것이 있습니까?

최신 정보:

최종 결정에 관심이있는 사람들을 위해 다중 라이센스 체계 인 MPL, LGPL 및 GPL로 라이브러리를 릴리스하기로 결정했습니다. 따라서 MPL에 따라 코드를 수정하지 않으면 사실상 모든 사람 이 의무없이 내 코드를 사용할 수 있습니다.이 경우 코드를 다시 제공해야합니다.

이것은 코드가 FSF와 독점 소프트웨어 둘 다에 의해 사용될 수 있지만 "나쁜"상업적 이용은 막을 수 있다는 것을 의미합니다.

GPL과 LGPL이 프로젝트에 원하는 것 같습니다.

• 응용 프로그램에 대한 지원 판매를 제외하고는 상업적 용도로 사용하지 않습니다 (예 : 응용 프로그램 을 판매 할 수는 없지만 주변의 모든 것이 가능합니다)

GPL은 애플리케이션 판매를 금지하지 않으며 Huperniketes가 관찰 한 바와 같이이를 금지하면 실제로 라이센스가 자유롭지 않게됩니다. 는 GPL을 보장하는 유일한 방법은 소프트웨어를 판매하는 회사는 것입니다 또한 무료로 코드 기반을 제공해야합니다. 그러나 소프트웨어 패키지는 무료로 제공하지 않아도됩니다 . 소프트웨어의 소스 코드는 쉽게 사용할 수있는 제품이 아니기 때문에 큰 차이가 있습니다.

소프트웨어의 상업적 사용을 막고 싶다면 GPL은이를 자르지 않을 것입니다. GPL은 수정 된 소스를 재배포해야하기 때문에 상용 제품이 판매 하는 제품에서 피하는 경향이 있지만 내부적으로 GPL 소프트웨어를 자유롭게 사용할 수 있습니다. 즉, 기업이 GPL 소프트웨어를 판매하거나 GPL 소프트웨어 (예 : LinkSys)를 중심으로 하드웨어를 구축하도록 설정되어 있지는 않지만 대부분의 기업은 경쟁 업체와 제품을 공유하지 않는 것이 좋습니다.

Creative Commons Attribution Non-Commercial No Derivatives 라이센스가 원하는 것인지 모르지만 (유일한 제한은 상업적 용도 임), 그렇지 않은 경우, 변호사가 준비한 라이센스가 있어야합니다. 라이센스 보유자가 가질 수있는 언어 부여 권한.

이 같은 제한을 포함하는 시작하면 또한, 비상업적 인 용도 및 비 수정 가능성을 , 당신은 더 이상의 기준에 부합하지 않을 수 오픈 소스 로 라이선스 정의 에 의해 오픈 소스 이니셔티브를 . 이 사이트에는 승인 된 다른 OSS 라이센스 도 나와 있습니다. 아마도 당신의 목표와 일치하는 것이 이미있을 것입니다.

또한 소프트웨어 사용자에게 부여 된 권리와 제한을 선택하기 전에 목표 를 적절하게 정의하는 것이 중요합니다. 수정 가능성, 배포 또는 사용보다 인기가 더 중요합니까? 처음에 코드를 릴리스하는 목표를 생각해 보시고, 어떤 방식으로 코드를 작성 하든지 또는 액세스 권한을 부여하는 용어에 반대의 영향을 줄 수 있습니다.

당신이 신경 쓰는 것이 코드를 무료로 유지하고, 개선을 얻고, 누군가가 그것을 사용할 수 있는지 확인하는 것이라면 MPL 이 당신에게 적합한 라이센스입니다. LGPL이 부과하는 것과 같이 이상하고 신비한 연결 제한없이 상용 소프트웨어를 포함한 모든 제품에서 무료로 사용할 수 있습니다. 코드를 사용하고 수정하는 사람은 MPL 하에서 변경 사항을 해제해야하지만 프로젝트의 나머지 코드는 건드 리거나 제한하지 않습니다.

모든 코드를 작성한 경우 (즉, 코드를 소유 한 경우) 이중 라이센스를 부여 할 수 있습니다. 예를 들어 GPLv3에 코드를 게시 하고 덜 제한적으로 사용하려는 사용자에게 다른 라이센스와 함께 판매하도록 제안하십시오.

(GPL이있는 라이브러리는 GPL 소프트웨어에서만 사용할 수 있기 때문에 이는 특히 라이브러리와 관련이 있습니다).

코드에 포함 된 외부 기여 또는 패치 (소유하지 않기 때문에)에주의하십시오.

실제로 MPL을 신청할 수 있는지 아니면 GPL 만 신청할 수 있는지 여부는 한 가지 중요한 차이점에 달려 있습니다.

"이하의 권리"에는 MPL "Covered Code"를 MPL 이외의 비공개 코드와 연결하여 "큰 작업"(MPL 3.7 큰 작업)을 형성 할 수있는 권한이 수신자에게 부여됩니다. GPL은 수신자에게 그러한 권리를 부여하지 않습니다. 따라서 수신자는 MPL 대신 GPL을 적용하기 위해 라이센스 조건을 변경할 수 없습니다.

참조 이 .

이것이 당신에게 의미하는 바는 GPL이 포함 된 컴포넌트를 사용하는 경우 MPL 하에서 코드를 릴리스 할 수 없다는 것입니다. MPL은 잘못된 MPL 하에서 GPL 코드를 재배포하도록 잘못 시도합니다. 종속성이 MIT 또는 Apache 라이센스 순서 인 경우에는 문제가 없습니다.

일반적으로, 경우 없는 이미 MPL 물건을 사용하지 않는 MPL을 통해 GPL만을 선택하여 더 좋은 일을. GPL은 또한 기부금이 다시 게시되도록합니다.

MPL이 제공하는 중요한 변화는 무의식적으로 유발 된 특허 침해에 대한 보호입니다. 라이센스에 따르면 :

누군가 자신이 특허를 보유한 수정을 작성하고, 라이센스에 따라 필요에 따라 수정을 무료로 제공 한 다음, 돌아와서 모든 사람에게 특허권을 청구하려고 시도하는 것은 괜찮습니다.

MPL과 GPL은 호환되지 않습니다.

이중 라이센스의 의미에 대한 논의는 MIT vs. BSD vs. 이중 라이센스 를 참조하십시오 .

아무도 그들에 대해 이야기하는 것 같지 않지만 Creative Commons 라이센스를 고려할 수 있습니다. 그들은 다양한 라이센스를 가지고 있습니다 (또는 당신이 당신의 요구에 맞게 다른 것을 보았습니다).