여러 오픈 소스 프로토콜(Apache, MIT, BSD, MPL, GPL, LGPL) 간의 차이점

 소프트웨어 개발자로서 오픈 소스 소프트웨어에 자주 노출되어야 하는데 이러한 오픈 소스 소프트웨어에서 사용되는 오픈 소스 라이선스 계약을 실제로 이해하고 있습니까?

        오픈소스가 완전히 무료라고 생각하지 않으시나요? 그럼 이 글을 통해 그 답을 찾아보도록 하겠습니다.


1. 오픈소스 라이선스 계약에 대한 간략한 설명


        오픈소스 라이선스 계약은 저작자와 기여자의 법적 권리를 보호하고 소프트웨어가 일부 상업 조직이나 개인에 의해 도난당하지 않고 소프트웨어 개발에 영향을 미치지 않도록 오픈소스 커뮤니티가 개발한 계약을 의미합니다. 중국어 이름: 오픈 소스 라이센스 계약, 외국 이름: 오픈 소스 라이센스.

2. 오픈소스 라이선스 계약의 차이점과 연관성

        ​ 위 그림을 통해 주로 몇 가지 핵심 문제에 초점을 맞춘 6가지 일반적인 오픈소스 라이선스 계약 간의 차이점과 연관성을 명확하게 이해할 수 있습니다.

  • 소스코드 수정 후 비공개 소스는 허용되나요?
  • 수정된 모든 파일에 저작권 표시를 해야 합니까?
  • 수정된 각 파일에 대해 문서를 제공해야 합니까?
  • 새 코드에도 동일한 라이센스가 필요합니까?
  • 파생 소프트웨어 광고에서 귀하의 이름을 사용하여 이를 홍보할 수 있습니까?​ 

 3. 몇 가지 일반적인 오픈소스 라이선스 계약의 주요 내용


        다양한 오픈 소스 라이센스 계약에 관해 이야기하면 GNU를 언급해야 합니다. GNU의 전체 이름은 "GNU's Not Unix!"(GNU는 Unix가 아닙니다!)의 재귀적 약어입니다.

        1985년에 Richard Stallman은 GNU 프로젝트에 기술적, 법적, 재정적 지원을 제공하기 위해 자유 소프트웨어 재단(Free Software Foundation)을 설립했습니다. GNU 프로젝트는 대부분 개인의 자발적인 무급 기여로 구성되어 있지만 FSF는 때때로 작성을 돕기 위해 프로그래머를 고용합니다. GNU 프로젝트가 성공하기 시작하자 일부 상업 회사들이 개발 및 기술 지원에 개입하기 시작했습니다. 그 중 가장 유명한 것은 나중에 Red Hat에 합병된 Cygnus Solutions입니다.

        리눅스가 점차 발전하고 성장할 수 있었던 것은 바로 GNU 프로젝트의 활발한 추진 덕분이며, 현재 30주년을 맞이한 서버 분야에서는 독보적이라고 할 수 있습니다. Linux의 왕성한 발전 덕분에 점점 더 많은 오픈 소스 소프트웨어가 대중의 관심을 끌게 되었고, 전체 소프트웨어 산업이 개발의 빠른 길로 나아갔습니다. Linux는 계속해서 번영하고 발전할 것입니다. 앞으로도 용기내서. 인기 있는 각 오픈소스 라이선스 계약의 핵심 내용에 집중해 보겠습니다.

1. Apache 오픈 소스 라이센스 계약


         Apache(Apache License): Apache 라이센스 계약, 일반적으로 사용되는 버전 2.0입니다. Apache 2.0 라이센스는 ASF(Apache Software Foundation, Apache Software Foundation)가 2004년에 "오픈 소스 소프트웨어를 통해 개발하고 협력하여"라는 목표를 달성하도록 돕기 위해 출시되었습니다. 안정적이고 오래 지속되는 소프트웨어 제품을 제공합니다.” ASF가 제작한 소프트웨어는 일반적으로 Apache 2.0 라이센스를 채택합니다. 물론 ASF가 아닌 프로젝트에서도 사용할 수 있으며, Apache 라이선스는 모든 사람이 사용할 수 있도록 설계되었습니다.

그 핵심 내용은 다음과 같습니다.

  • 저작권이나 특허로 인한 문제 없이 마음대로 사용하실 수 있습니다!
  • 내 상표를 사용할 수 없습니다!
  • 이 저작물이나 파생 저작물을 배포할 때 더 이상 소스 코드를 제공할 필요가 없습니다!
  • 배포할 때 다음을 수행해야 합니다.

        ​ ​ 1) 이 면허증을 지참하세요!

        ​ 2) 이 소프트웨어에 대한 모든 저작권, 특허 및 기타 지침을 보유하십시오!

        ​ ​ 3) 변경한 파일은 무엇을 변경했는지 말씀해주셔야 합니다!

        ​ ​ 4) NOTICE 파일의 정보는 반드시 보관되어야 합니다!

        5) 본 라이센스 조건에 따라 재라이센스를 부여할 수 있습니다!

        ​ ​ 6) 이 작품은 어떠한 책임도 지지 않습니다! 원한다면 책임을 질 수 있지만, 나를 연루시키지 마세요!

2. MIT 오픈소스 라이선스 계약


        MIT(Massachusetts Institute of Technology): MIT 라이센스의 이름은 Massachusetts Institute of Technology에서 유래되었으며 "X 라이센스" 또는 "X11 라이센스"라고도 알려져 있습니다.

        MIT의 내용은 BSD 라이선스의 3개 조항과 매우 유사하지만 소프트웨어 라이선스 사용자에게 더 큰 권리와 더 적은 제한을 부여합니다.

핵심 내용은 다음과 같습니다.

  • 승인된 사람은 소프트웨어 및 소프트웨어 사본을 사용, 복사, 수정, 병합, 게시, 배포, 재라이센스 부여 및 판매할 수 있는 권리를 갖습니다.
  • 라이센스 사용자는 프로그램의 필요에 따라 라이센스 조건을 적절한 내용으로 수정할 수 있습니다.
  • 저작권 고지 및 허가 고지는 소프트웨어 및 소프트웨어의 모든 사본에 포함되어야 합니다.

        본 라이선스는 카피레프트 자유 소프트웨어 라이선스가 아니며, 무료/오픈 소스 소프트웨어 또는 비자유 소프트웨어(독점 소프트웨어)에서 사용이 허용됩니다. 이는 MIT와 BSD(BSD 라이센스, 3절 BSD 라이센스)의 본질적인 차이점이기도 합니다.

        ​ ​ MIT 약관은 다른 라이선스 약관과 공존할 수 있습니다. 또한 MIT 용어는 자유 소프트웨어 재단(FSF)이 인정한 자유 소프트웨어 라이선스 용어이기도 하며 GPL과 호환됩니다.

        ​​ ​​BSD 오픈소스 라이선스 계약에 비해 MIT 오픈소스 라이선스 계약은 현재 인기 있는 오픈소스 라이선스 계약 중 [가장 완화된] 라이선스 계약이다.

3.BSD 오픈 소스 라이센스 계약 

        BSD는 원래 University of California, Berkeley(BSD는 Berkly Software Distribution의 약어)에서 출시된 각 4.4BSD/4.4BSD-Lite 버전에 사용되었으며 이후 점차적으로 사용되었습니다. 1979년 캘리포니아대학교 버클리캠퍼스는 오픈소스의 선구자로 알려진 BSD 유닉스(BSD Unix)를 출시했는데, 이는 BSD 유닉스를 기반으로 개발된 BSD 라이선스이다. BSD 라이센스Apache 운영 체제 및 기타 오픈 소스 소프트웨어가 채택되었습니다.

        GPL 라이선스와 MPL 라이선스의 엄격함에 비해BSD 라이선스 a> 는 훨씬 더 완화되어 라이센스 원문만 첨부하면 되지만, 더 흥미로운 점은 이후의 모든 개발자가 저작권이 있는 자료를 여기에 올려야 한다는 것입니다. BSD 라이센스를 취득해야 합니다. 라이센스에 따라 출시된 소프트웨어에는 작은 문제가 발생할 수 있습니다. 즉, 이러한 저작권 자료에 대한 라이센스가 프로그램보다 더 많은 공간을 차지합니다.

핵심 내용은 다음과 같습니다.

  • 재배포되는 제품에 소스 코드가 포함되어 있는 경우 원본 코드의 BSD 라이선스가 소스 코드에 포함되어야 합니다.
  • 바이너리 클래스 라이브러리/소프트웨어만 재배포하는 경우 원본 코드의 BSD 라이센스가 클래스 라이브러리/소프트웨어의 문서 및 저작권 설명에 포함되어야 합니다.
  • 오픈소스 코드의 작성자/단체 이름이나 원본 제품 이름을 마케팅 목적으로 사용하지 마십시오.
  • BSD 오픈소스 라이선스 계약은 현재 인기 있는 오픈소스 라이선스 계약 중 [비교적 ​​느슨한] 라이선스 계약이라고 할 수 있다.

4. MPL 오픈 소스 라이선스 계약 


        MPL(Mozilla Public License): Mozilla Public License. MPL은 Mozilla Public License의 약어로, 1998년 초 Netscape의 Mozilla 팀이 오픈 소스 소프트웨어 프로젝트를 위해 설계한 소프트웨어 라이센스입니다. MPL 라이센스가 등장한 가장 중요한 이유는 Netscape가 GPL 라이센스가 소스 코드에 대한 개발자의 요구와 소스 코드를 사용하여 얻는 이점의 균형을 제대로 맞추지 못한다고 믿기 때문입니다. 유명한 GPL 라이센스, BSD 라이센스에 비해 MPL은 많은 권리와 의무가 동일합니다(모두 OSIA 인증을 준수하는 오픈 소스 소프트웨어 라이센스이기 때문입니다)

핵심 내용은 다음과 같습니다.

  •  MPL에서는 MPL 라이선스에 따라 출시된 소스 코드에 대한 수정 사항을 다른 사람이 MPL 조건에 따라 공유할 수 있도록 MPL 라이선스에 따라 2차 라이선스를 부여해야 합니다.소스 코드< /span>. 그러나 MPL 라이선스에서 "릴리스"의 정의는 "소스 코드 형태로 릴리스된 파일"입니다. 이는 MPL을 통해 기업이 소스 코드의 소스 코드를 제외하고 기존 소스 코드 라이브러리에 인터페이스를 추가할 수 있음을 의미합니다. 인터페이스 프로그램 코드는 MPL 라이선스에 따라 라이선스가 부여되지만, 소스 코드 라이브러리의 소스 코드는 MPL 라이선스 없이 강제 라이선스를 받을 수 있습니다. 이는 사람들이 다른 사람의 소스 코드에서 배우고 이를 자신의 상용 소프트웨어 개발에 사용할 수 있는 방법을 제공합니다.
  • MPL 라이선스 3조 7항은 라이선스 사용자가 MPL 라이선스를 통해 얻은 소스 코드를 다른 유형의 자체 코드와 혼합하여 자체 소프트웨어 프로그램을 얻을 수 있도록 허용합니다.
  •  소프트웨어 특허에 대한 태도GPL 라이센스에는 소프트웨어 특허에 반대한다고 명시되어 있지만 소스 코드 제공자는 이미 특허로 보호되는 소스 코드를 제공할 수 없음을 분명히 요구합니다(그 자신이 특허권자이고 이러한 소스 코드를 대중에게 무료로 라이센스한 경우는 제외). 작성), 또한 이러한 소스 코드를 오픈 소스 코드 라이선스 형태로 사용할 수 없습니다. 라이선스를 부여한 후 해당 소스 코드와 관련된 특허를 신청하세요.
  • 소스 코드 정의: MPL(버전 1.1) 라이선스에서 소스 코드 정의는 다음과 같습니다. "소스 코드는 다음을 포함하여 저작물을 수정하기 위해 가장 선호되는 형식을 의미합니다. 모든 모듈에 대한 모든 소스 프로그램과 관련 인터페이스, 실행 가능한 작업의 설치 및 컴파일을 제어하는 ​​'스크립트', 원본 소스 코드와 크게 다르거나 공개 도메인에서 사용 가능한 프로그램 코드의 소스 코드 기여자가 선택한 소스 코드. "

  • MPL 라이센스 3조에는 소스 코드 수정 설명과 관련된 특별 조항이 있습니다. 즉, 모든 재배포자는 소스 코드 프로그램 수정 시간과 방법을 설명하는 특수 파일을 보유해야 합니다.

5. GPL 오픈소스 라이센스 계약 


        GPL(GNU 일반 공중 사용 허가서): GNU 일반 공중 사용 허가서. GNU General Public License는 널리 사용되는 무료 소프트웨어 라이센스 계약으로, GPL은 모든 개발자의 권리를 보장하고 사용자에게 복사, 배포, 수정할 수 있는 충분한 권한을 제공합니다.

핵심 내용은 다음과 같습니다.

  • 자유롭게 복사 가능: 소프트웨어를 귀하의 컴퓨터, 고객의 컴퓨터 또는 어느 곳에나 복사할 수 있습니다. 사본 수에는 제한이 없습니다.
  • 자유롭게 배포할 수 있습니다. 다른 사람들이 귀하의 웹사이트에서 다운로드할 수 있도록 하고, USB 플래시 드라이브에 복사하여 다른 사람들에게 나눠주세요.
  • 영리 목적으로 사용 가능:소프트웨어를 배포할 때 비용을 청구할 수 있지만 비용을 청구하기 전에 고객에게 소프트웨어의 GNU GPL 라이센스 계약을 제공하여 다음 사항을 알려야 합니다. 다른 소스에서 이 소프트웨어를 무료로 얻을 수 있으며 비용을 청구하는 이유.
  • 수정 자유: 특정 기능을 추가하거나 삭제하려는 경우 문제 없습니다. 코드의 일부를 다른 프로젝트에서 사용하려는 경우에도 문제 없습니다. 유일한 요구 사항은 이 코드를 사용하는 프로젝트도 GPL 라이센스를 사용해야 한다는 것입니다. ...

        배포 시 소스코드와 바이너리 파일을 명확히 제공해야 하며, 또한 특정 프로그램에 사용되는 특정 프로토콜에는 몇 가지 문제와 제한 사항이 있으므로 GPL 프로토콜을 사용하려면 소스 코드에 해당 정보를 포함해야 합니다. .그리고 계약 자체.

6. LGPL 오픈소스 라이선스 계약


        LGPL(GNU 약소 일반 공중 라이선스): GNU 약소 일반 공중 라이선스. GNU에는 GPL보다 제품에 대한 권한이 적은 LGPL(Lesser General Public Licence)이라는 또 다른 계약이 있습니다. 일반적으로 LGPL은 GPL이 아니거나 오픈 소스가 아닌 제품에 사용되는 오픈 소스 라이브러리나 프레임워크에 적합합니다. GPL 요구 사항으로 인해 GPL 코드를 사용하는 제품은 GPL 프로토콜도 사용해야 하며 개발자는 상용 제품에 GPL 코드를 사용할 수 없습니다. LGPL은 이러한 제한을 우회합니다.

LGPL은 상용 소프트웨어 개발자로부터 더 많은 지원을 얻기 위해 GNU가 제안한 GPL의 변형입니다. GPL과의 가장 큰 차이점은 다음과 같은 핵심 내용을 가지고 있다는 것입니다.

  • LGPL에 따라 라이센스가 부여된 무료 소프트웨어는 개인적으로 사용할 수 있습니다.
  • 개발된 새로운 소프트웨어는 무료 소프트웨어가 아니더라도 독점 소프트웨어일 수 있습니다.
  • 무료 소프트웨어를 사용하는 모든 회사는 해당 소프트웨어가 LGPL 또는 GPL의 다른 변형에 따라 라이센스가 부여되었는지 확인해야 합니다.

4. 엔딩


        위 내용을 통해 오픈소스가 무료라는 생각을 깨셨겠죠? 그리고 위의 6가지 일반적인 오픈 소스 라이센스 계약을 느슨한 것부터 엄격한 것까지 간단하게 정렬할 수 있습니다: MIT > BSD > Apache > LGPL > Mozalla(MPL) > GPL 

        또한 향후 일부 오픈소스 소프트웨어/프레임워크를 사용/학습할 때 어떤 오픈소스 라이선스 계약이 사용되는지 이해해야 하며, 해당 오픈소스 소프트웨어/프레임워크를 기반으로 비즈니스 활동을 수행하려면 다음 사항을 반드시 확인하시기 바랍니다. 오픈소스 라이선스 계약 내용을 명확하게 이해하여 버전 문제와 관련하여 향후 법적 제재를 받지 않도록 하세요.

Guess you like

Origin blog.csdn.net/weixin_35804181/article/details/133579844