웹 기반 소스 코드 호스팅 서비스 에서 클래스 기반 객체 지향 프로그래밍 언어 (Java) 로 작성된 소프트웨어 라이브러리를 릴리스하고 싶습니다.이 라이브러리 를 사용하면 프로젝트 포크를 메인 프로젝트 (GitHub를 통해 풀을 통해 병합 할 수 있음) 요청). 웹에서 조사한 결과 소프트웨어 라이센스 방법에 대해 많은 생각을했습니다. ( IANAL 관점에서) 다음 가정에서 맞 습니까?

• LGPL과 MPL 은 다른 소프트웨어 프로젝트에서 사용중인 LGPL / MPL 라이센스 소프트웨어에 대한 수정 공유를 장려 합니다. 수정 된 라이브러리의 사용자가 별도 의 라이브러리 포크 를 호스팅 하도록 요구하는 대신 원래 라이브러리 에 대한 기여를 촉진 할 수 있습니다 (예 : 풀 요청을 통해).

• 주요 차이점은 MPL / LGPL 라이센스 코드를 프로젝트에 연결하는 방법입니다. MPL 소스 코드 파일을 직접 독점 소프트웨어 프로젝트 ( 정적 연결 )에 직접 복사 할 수있는 반면, LGPL 라이센스 코드는 동적 소프트웨어 링크 (유일한 독점 소프트웨어 프로젝트에 거의 연결되지 않아 최종 사용자가 라이센스가 부여 된 소프트웨어를 전환 할 수 있음) 라이센스가 부여 된 소프트웨어 라이브러리의 다른 버전에 대한 라이브러리).

• 동적 링크 및 LGPL 은 정적 링크 (MPL)보다 오픈 소스 소프트웨어 라이브러리에 더 많은 기여를하지 않으면 서 독점 소프트웨어 제품 을 패키징 하는 데 추가적인 장애물을 부과 합니다. 정적 링크를 허용 하는 수정 된 LGPL 이 있습니다.

• IANAL 관점 에서 다른 관련 차이점 은 없습니다 .

• 이전의 라이센스 버전은 최신의 것들 좋은으로 내 요구에 적합하지 않습니다.

보시다시피 독점 요구 사항은 독점적 인 제품에서 소프트웨어 라이브러리 사용에 대한 제한을 부과하지 않고 일반 공개 소스에 유용 할 수있는 소프트웨어 라이브러리의 수정 입니다. 관련 용어 의 범위 가 임의로 작거나 클 수 있으므로 GPL로 끝나지 않기 때문에 원본 저작물과 관련된 소프트웨어 라이브러리의 확장 을
요구하는 라이센스 는 없습니다. 독점 제품에 사용됩니다 (전체 소스를 공개하지 않고).

수정 된 LPGL 을 사용하고 싶지만 다른 한편으로는 인기가 없습니다. 위의 점을 바탕으로 MPL을 선호합니다.
질문 : 위의 진술이 정확합니까? 요구 사항을 고려할 때 어떤 라이센스를 선택해야합니까?

솔루션 : 승인 된 답변에 대한 논의를 통해 MPL은 인기 , 연결의 자유 및 수정되지 않은 공식 라이센스 이기 때문에 MPL을 고수 하기로 결정했습니다 .

모질라 퍼블릭 라이센스 와 GNU 레서 일반 퍼블릭 라이센스 의 차이점을 정확하게 언급했으며 귀하의 요구에 잘 맞을 수도 있지만 두 라이센스의 가장 중요한 차이점을 건너 뛰고 있습니다.

누가 새 버전을 만들 수 있습니까?

MPL (섹션 10)과 LGPL (섹션 14)은 모두 현재 버전을 후자 버전으로 대체 할 수있는 권한을 라이센스 부여에 포함하며, 해당 라이센스로 들어갈 수있는 것에 대한 실제 제한은 없습니다. 모질라 재단이나 자유 소프트웨어 재단이 "이 소프트웨어에 대한 모든 기여가 우리의 재산이된다"는 조항을 제정하는 것만 큼 미친 짓을 할 가능성은 거의 없지만, 조직은 마음에 들지 않는 새 라이센스 버전을 출시합니다.

"Modified LGPL"을 사용하는 것에 대한 또 다른 요점이 뜹니다.

수정 된 라이센스는 동일한 라이센스가 아닙니다!

자체 라이센스 조건을 지정할 수있는 상당히 놀라운 능력을 보유하고 있지만 본질적으로 "GPL에 따라이를 배포 할 수 있지만 크레딧에 내 이름을 입력하고 생성 한 수익의 1 %를 지불해야합니다" 라고 말할 수 있습니다 . 그렇게 할 때마다 다른 사람의 작업을 기반으로 새 라이센스를 작성하게됩니다. 즉, MPL 또는 LGPL을 사용하지 않고 새로운 "mucaho 라이센스"를 사용하고 있습니다.

즉, 법정 내부에서 라이센스에 대한 해석을 방어해야 할 경우 원래 라이센스 작성자의 도움을받지 못할 수 있으며 THEIR 버전을 적용해야한다고 주장 할 수 있습니다. 당신이 아닙니다.

물론 두 가지 모두 사소한 점입니다. 코드가 대규모 프로젝트에 직접 통합 될 것으로 예상하지 않는 한 "라이센스 인기"도 중요하지 않습니다.

개인적으로 MPL이 독점 호환성을 원하거나 실제 MPL과 다른 라이센스 사이에서 선택하는 경우 LGPL을 기반으로 수동으로 편집해야하는 것이 더 나은 선택이라고 생각합니다. MPL을 사용하지 않을 이유가 없다면, 재단의 도움을받지 않고 법정에 맡길 수있는 재단 대신 재단의 지원을 받으십시오.

DougM과 AER의 대답은 공정한 지적입니다. 정적 예외가있는 MPLv2 및 LGPLv3은 카피 레프트를 트리거하는 이벤트와 관련하여 동일합니다. 그러나 LGPL과 MPL의 또 다른 중요한 차이점이 누락되었다고 생각합니다. 카피 레프트가 트리거되면 카피 레프트는 다음에 적용됩니다.

• MPL의 경우 : 원본 라이브러리와 정확히 동일한 파일
• LGPL의 경우 : "라이브러리를 사용하는 작업"과 반대로 "라이브러리 기반 작업" 따라서 LGPL은 자신의 카피 레프트를 새로운 파일로 확장 할 수 있습니다.

Edge-case : MPL을 사용하면 사용자가 개선 사항을 공유 할 수 없습니다

MPL은 파일 수준의 카피 레프트 라이센스입니다. 누군가가 더 큰 프로젝트에 (정적으로 또는 동적으로) 파일을 포함시키고 파일을 변경하면이 특정 파일에 대한 변경 사항 만 해제하면됩니다.

코드베이스의 무결성을 열어 두어야 할 경우 MPL의 이러한 카피 레프트 효과로 충분하지 않은 경우가 있습니다.

예를 들어, 누군가 프로젝트의 기본 파일 중 하나를 가져 와서 "import my_private_new_file" 을 추가 한 후 "my_private_new_file.newAwesomeFeature.run ()" 을 추가하여 기본 메소드를 수정할 수 있습니다 .

이 방법으로 그는 수정 된 기본 파일을 해제하고 새 기능의 실제 논리를 "my_private_new_file" 에 닫은 상태로 유지하면서 프로젝트에 새 기능을 추가 할 수있었습니다 .

메인 파일을 커뮤니티에 다시 가져 오면 "새로운 기능을 추가했습니다"라는 정보를 제공하지만이 새로운 기능을 공개적으로 통합 할 수는 없습니다 ... 새로운 기능이 밀접한 경우 성 가실 수 있습니다 -도서관에서 해결하려는 문제와 관련이 있습니다.

분명히, 그것은 엣지 케이스이며 누군가가 그렇게하고 싶지는 않지만 MPLv2를 사용할 때 알아야 할 위험이 있습니다.

LGPL은 그러한 행동을 금지하도록 작성되었습니다. 만나다:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• LGPL에서이 작업을 수행 할 수 있습니까?

원래 LGPL 라이센스를 인용합니다.

"라이브러리 기반의 작업"과 "라이브러리를 사용하는 작업"의 차이점에주의를 기울이십시오. 전자는 라이브러리에서 파생 된 코드를 포함하고, 후자는 실행하기 위해 라이브러리와 결합되어야합니다.

카피 레프트는 "라이브러리 기반 작업"에만 적용됩니다. 이제 "라이브러리 기반 작업"이란 무엇입니까? 해석의 여지가 남아 있습니다. 라이센스 준수가 더 복잡 해져서 무섭다는 것은 좋은 일이 아닙니다. 일부 사람들은 단순히 라이브러리를 사용하지 않을 수도 있습니다.

이런 의미에서 LGPL은 MPL보다 더 제한적이지만 프로젝트의 무결성을 더 보호합니다.

MPL을 사용하면 독점적 인 세계 사용자가 라이브러리를 수정하고 사용하는 것이 더 쉬우면서도 수정 사항을 공유해야합니다.

MPL의 장점은 사용자가 라이브러리에서 버그를 발견하면 모든 코드를 제공하지 않고 수정 만 제공 할 필요없이 파일에서 직접 수정할 수 있다는 것입니다. 실제로, 그는 자신의 작업을 고객에게 배포 할 때 수정 사항이 포함 된 프로젝트 포크에 대한 링크 만 제공 할 수 있습니다.

LGPL을 사용하면 상황이 더 복잡해집니다. 누군가가 프로젝트를 포크하고 버그를 수정하여 자신의 독점 소프트웨어에 정적으로 포함시키는 경우 LGPL에 따라 "라이브러리 기반의 작업"을 사용자에게 배포해야합니다. 특히 라이브러리가 정적으로 포함 된 경우 다소 모호한 개념입니다. 이와 관련하여 원래 LGPL에 "정적"예외와 같은 것이없는 이유가 원래의 이유라고 생각합니다. "라이브러리 기반의 작업"을 간단하게 식별 할 수 있습니다. 독점 소프트웨어에서 호출하는 동적 라이브러리입니다.

결과적으로 MPL을 사용하면 독점 공급 업체가 LGPL보다 라이브러리를 사용하고 수정하기가 훨씬 쉽습니다.

동시에 대부분의 독점 공급 업체는 복잡한 라이브러리에 들어가는 데 필요한 리소스 나 시간이 없으며 스스로 해결하지는 않습니다. 차라리 GitHub 리포지토리에서 문제를 열거 나 메일 링리스트에 이메일을 보내고 수정을 기다립니다.

이와 관련하여 LGPL은 이러한 종류의 행동을 더욱 강화합니다. 그러나 시행이 정말로 필요한가?

결론

LGPL과 MPL 중에서 선택하는 것은 까다로운 문제이며 소프트웨어 라이센스와 마찬가지로 목표에 따라 다릅니다. 두 라이센스는 매우 유사하지만 동시에 매우 다릅니다. 그들은 매우 다른 목표와 철학을 위해 설계되었습니다.

LGPL은 자유 소프트웨어 재단 (Free Software Foundation)에 의해 독점적 세계에서 자유 소프트웨어 라이브러리의 광범위한 사용을 가능하게하기 위해 만들어졌지만 자유 소프트웨어를 홍보하고 독점 소프트웨어와의 싸움이라는 생각을 항상 염두에두고 있습니다. 그것은 모두 그들의 이념을 향한 전략의 일부입니다. 참조 : https://www.gnu.org/licenses/why-not-lgpl.html

MPL은 Mozilla가 원래 라이브러리에 대해 일종의 공유 를 적용하도록 설계된 실제 라이센스 이며, 사람들이 여전히 독점 소프트웨어 (부가 기능 포함)를 Mozilla (Mozilla 자체 포함)에 만들도록 권장합니다. LGPL이지만 여전히 유해한 것으로 간주합니다.

본질적으로 MPLv2는 많은 사람들에게 허용되는 라이센스로 간주되는 반면 정적 예외를 포함한 LGPLv3은 이러한 방식으로 거의 불려지지 않습니다.

편집하다

중요한 것을 언급하는 것을 잊었습니다. LGPLv3 (정적 예외 유무에 관계없이)는 tivoization을 금지 합니다. "세부 사항"이라고 생각할 수도 있지만 목표에 따라 실제로는 그렇지 않습니다. 사용자 자유에 관심이 있습니까? 그런 다음 세부 사항이 아닙니다. Apple 기기에서 라이브러리를 사용할 수 있습니까? VLC는 사용에 대해 더 신경을 쓰므 로 그러한 제한이없는 LGPLv2를 사용하기로 결정했습니다 . 마찬가지로, Linux가 GPLv2를 계속 사용 하는 이유 중 하나입니다 . MPLv2는 또한 FSF 이념이 아니라보다 "실용적인"오픈 소스 철학을 염두에두고 만들어진 라이센스이기 때문에 명백한 제한이 없습니다.

내가 놓친 이와 같은 "사소한"것들이있을 수 있습니다.