오픈 소스 소프트웨어 라이선스는 크게 두 가지 범주로 나뉩니다. 일부 라이선스는 카피레프트 라이선스 범주에 속하고, 다른 라이선스는 퍼미시브 오픈 소스 라이선스입니다.
이 글에서는 오픈 소스 소프트웨어 라이선스의 개념과 종류에 대해 설명합니다.
소개
오픈 소스 라이선스는 사용자가 소프트웨어의 소스 코드를 자유롭게 열람, 수정 및 공유할 수 있도록 허용하는 라이선스입니다. 이를 통해 사용자는 code 소스를 빈번하게 업데이트하고 기존 제품을 기반으로 발전시켜 나갈 수 있습니다.
선택한 오픈 소스 라이선스 유형에 따라 사용자는 code를 판매하거나 상업적으로 사용하는 등 특정 활동을 할 수 있을 수도 있고, 없을 수도 있습니다. 또한 오픈 소스 라이선스는 매우 다양하며, 소스 코드를 어떻게 활용하느냐에 따라 각기 다른 조건과 약관을 제공합니다.
따라서 라이선스의 혜택을 누리기 전에 해당 오픈 소스 라이선스 유형을 완전히 이해하는 것이 중요합니다. 결정을 내리기 전에 아래 내용을 충분히 읽어보시기 바랍니다.
오픈 소스 라이선스의 유형
허용적 라이선스 (Permissive Licenses)
비카피레프트(non-copyleft) 라이선스라고도 불리는 Permissive 라이선스는 사용자에게 소스 code를 사용, 수정 및 공유할 수 있는 권한을 부여합니다. 또한 사용자는 파생 저작물을 포함하여 재배포 시 일부 약관을 변경할 수 있는 옵션도 가집니다. 소프트웨어 문맥에서 파생 저작물이란 기존 프로그램을 기반으로 만든 소프트웨어를 의미합니다. 원본이 Permissive 라이선스로 출시되었다면, 제작자는 원본 라이선스의 요구 사항과 다른 조건으로 자신의 파생 저작물을 공유할 수 있습니다.
카피레프트(Copyleft) 라이선스
오픈 소스의 Copyleft 라이선스는 사용자에게 소프트웨어를 수정, 사용 및 재배포할 수 있는 저자의 자유를 제공합니다. 다만, 사용자에게 원래 부여되었던 것과 동일한 권리를 하위 사용자에게도 부여함으로써 특정 권리를 전달해야 한다는 조건이 붙습니다.
Copyleft 라이선스는 code의 재배포와 변경이 허용되는 방식을 정의하며, 이를 독점화하거나 비공개로 전환하려는 시도를 금지합니다. 덕분에 소프트웨어를 수정하는 개발자는 소스 code에 접근해 업데이트하거나 자신의 변경 사항을 통합할 수 있습니다. 물론 다른 사람도 오픈 소스 혜택을 누릴 수 있도록 모든 수정 사항을 공개해야 합니다. 학술·연구 용도에서는 문제가 되지 않지만, 상용 소프트웨어를 만들 때는 종종 발목을 잡는 조건이 됩니다.
오픈 소스 소프트웨어 라이선스를 포함해야 하는 이유
소프트웨어를 오픈 소스로 공개하거나 다른 사람과 공유할 때 오픈 소스 소프트웨어 라이선스를 포함하는 것은 매우 중요합니다. 라이선스는 다음과 같은 중요한 역할을 합니다:
- 협업과 혁신 촉진
오픈 소스 라이선스는 누구나 소프트웨어의 소스 code를 확인, 수정 및 배포할 수 있도록 허용합니다. 이는 다른 개발자들이 프로젝트에 기여하고, 버그를 수정하며, 새로운 기능을 추가하도록 장려합니다. 결과적으로 더욱 견고하고 혁신적인 소프트웨어 제품을 만들 수 있습니다.
- 사용자에게 더 많은 제어권과 유연성 제공
오픈 소스 라이선스는 일반적으로 사용자가 상업적 용도를 포함하여 어떤 목적으로든 소프트웨어를 사용, 수정 및 배포할 수 있도록 허용합니다. 이를 통해 사용자는 소프트웨어 경험에 대해 더 큰 제어권을 갖게 되며, 독점 소프트웨어 벤더에 대한 의존도를 낮출 수 있습니다.
- 소프트웨어를 중심으로 커뮤니티 구축
오픈 소스 라이선스는 여러분의 소프트웨어에 열정을 가진 사용자와 개발자 커뮤니티를 구축하는 데 도움이 됩니다. 이 커뮤니티는 프로젝트에 지원, 피드백, 새로운 아이디어를 제공할 수 있습니다.
- 소프트웨어의 접근성과 포용성을 높이기 위해.
오픈 소스 소프트웨어는 일반적으로 무료로 다운로드해 사용할 수 있고, 다양한 언어로 제공되는 경우가 많습니다. 덕분에 소득이나 배경에 관계없이 전 세계 사람들이 더 쉽게 접근할 수 있습니다.
이러한 이점 외에도 오픈 소스 라이선스는 다음과 같은 도움을 줍니다:
- 저작권 침해 방지.
라이선스 없이 소프트웨어를 배포하면 저작권 침해 소송의 위험에 처할 수 있습니다. 오픈 소스 라이선스는 사용자에게 소프트웨어 사용, 수정, 배포 권한을 명시적으로 부여해 법적 책임으로부터 여러분을 보호합니다.
- 우수한 인재 유치 및 유지.
많은 실력 있는 개발자가 오픈 소스 프로젝트에 매력을 느낍니다. 오픈 소스 라이선스로 소프트웨어를 공개하면 잠재적 직원에게 더 매력적인 회사가 될 수 있습니다.
- 브랜드 평판 강화.
오픈 소스 소프트웨어는 기술 커뮤니티에서 널리 존중받습니다. 오픈 소스 라이선스로 소프트웨어를 공개하면 협업과 혁신에 대한 의지를 보여줄 수 있습니다.
인기 있는 허용적(Permissive) 소프트웨어 라이선스
허용적(Permissive) 소프트웨어 라이선스는 가장 대중적인 라이선스 중 하나입니다. 본질적으로 이 라이선스는 사용자가 최소한의 제한만으로 소프트웨어를 원하는 대로 수정하고 재배포할 수 있도록 허용합니다. 가장 인기 있는 허용적 라이선스 세 가지는 다음과 같습니다:
MIT 라이선스
이 MIT 라이선스 가장 대중적이고 허용 범위가 넓은 오픈 소스 소프트웨어 라이선스입니다. 라이선스에 명시된 모든 조건을 준수한다면, 사용자는 해당 결과물을 자유롭게 공유, 수정, 사용 및 상업화할 수 있는 상당한 자유를 가집니다.
Apache License 2.0
Apache License 2.0은 사용자가 소프트웨어를 자유롭게 수정하고 재배포할 수 있게 하면서도, 결과물에 포함된 저작권 문구와 고지 사항이 원래 형태로 유지되도록 보장하는 인기 있는 허용적 라이선스입니다. 이 오픈 소스 라이선스는 독점적 수정 및 재배포를 허용하며, 명확한 라이선스 약관을 제공하여 누구나 소프트웨어 사용 시 자신의 권리를 쉽게 이해할 수 있습니다.
BSD (Berkeley Software Distribution) 라이선스
GitHub에서는 두 가지 BSD 라이선스 중 하나를 선택할 수 있습니다. 하나는 BSD 2-Clause “Simplified” License, 때때로 “FreeBSD” 라이선스라고도 하며, 다른 하나는 BSD 3-Clause “New” 또는 “Revised” 라이선스. 두 라이선스의 주요 차이점은 3번째 조항에 있습니다. 이 조항은 소프트웨어 사용자가 저자, 저자들 또는 기여자의 이름을 제품이나 서비스 홍보 목적으로 사용하는 것을 제한합니다.
Boost Software License
Boost Software License는C++의 Boost Libraries에서 유래되었으며 2008년 OSI의 승인을 받았습니다. 이 라이선스는 MIT 및 BSD 라이선스와 유사하지만, 바이너리 형태로 재배포할 때 저작권 고지(attribution)를 요구하지 않는다는 점이 다릅니다.
Copyleft 오픈소스 소프트웨어 라이선스
Copyleft 라이선스는 소프트웨어 사용자에게 소스 code를 사용, 수정 및 공유할 수 있는 권한을 부여하는 동시에, 특정 제한 및 약관을 통해 라이선스가 변경되는 것을 방지합니다. 이는 사용자의 작업물이 라이선스에 명시된 원본 권리를 준수하도록 요구하는 이 라이선스의 상호 호혜적 특성을 나타냅니다.
GNU 라이선스 Copyleft 소프트웨어 라이선스 중에서도 GPL (General Public License) 가장 대중적이고 널리 사용됩니다. 이 오픈소스 라이선스는 저작권 고지, 보증 면책 조항 또는 수정되지 않은 프로그램에 추가된 기타 라이선스와 같은 특정 조건을 유지하는 한, 사용자가 프로그램의 복제본과 수정 버전을 자유롭게 배포할 수 있도록 허용합니다.
이 라이선스 유형으로 소프트웨어를 공개하면, 개발자는 다른 사람들이 소스 code에 접근할 수 있도록 보장하여 커뮤니티에 도움이 되는 개선 및 수정을 가능하게 합니다. 또한, 이러한 “copyleft” 개념은 누구나 자유 소프트웨어를 다룰 때 동일한 자유를 협력적으로 공유할 수 있도록 보장합니다.
Mozilla Public License
이 Mozilla Public License, 또는 MPL은 Mozilla Foundation 에서 제공하며, 약한(weak) copyleft 라이선스로 간주됩니다. 이 라이선스는 (Eclipse Public License와 비교했을 때) 파일 단위의 copyleft를 적용한다는 점이 특징이며, 이는 code를 오픈 소스 또는 독점 code와 결합할 수 있음을 의미합니다.
Eclipse Public License
이 Eclipse Public License는 Eclipse Foundation에서 제공하며 약한 copyleft 라이선스로 간주됩니다. 약한 copyleft 라이선스는 사용자가 code에 가한 모든 변경 사항을 공유하도록 요구합니다. 이 라이선스는 사용자가 GNU General Public License에서 겪었던 엄격한 요구 사항을 완화하기 위해 더 약한 형태의 copyleft를 채택했습니다.
프로젝트에 맞는 올바른 라이선스를 선택하는 방법은?
-
프로젝트를 오픈 소스 라이선스로 공개하려면, 사용 중인 다른 프로젝트와 호환되는 라이선스를 선택해야 합니다.
-
다른 사람들이 프로젝트를 상업적 목적으로 사용하는 것을 허용하려면, 이를 허용하는 라이선스를 선택하세요.
-
다른 사람들이 프로젝트를 수정하고 배포할 수 있도록 하려면, 이를 허용하는 라이선스를 선택하세요.
-
프로젝트가 계속해서 자유로운 오픈 소스로 유지되길 원한다면, copyleft 라이선스를 선택하세요.
-
어떤 라이선스를 선택해야 할지 모르겠다면, Open Source Initiative에서 제공하는 인기 라이선스 목록을 비교해 보세요.
오픈 소스 프로젝트에 적합한 라이선스를 선택하는 것은 매우 중요한 결정입니다. 요구 사항과 목표를 신중히 고려하면 원하는 결과를 얻는 데 도움이 되는 라이선스를 선택할 수 있습니다.
Capgo 새로운 라이선스
이 모든 걸 어떻게 이룰 수 있을까요? 바로 라이선스를 바꾸는 겁니다.
Capgo의 라이선스가 MIT에서 GNU Affero General Public License V3 (AGPLv3) 또는 그 이후 버전으로 변경되었습니다. Capgo 버전은 여기에서 확인할 수 있습니다.
Capacitor-updater(플러그인)의 라이선스가 LGPLv3에서 Mozilla Public License Version 2.0 (MPLv2) 또는 그 이후 버전으로 변경되었습니다. Capacitor-updater 버전은 여기에서 확인할 수 있습니다.
Capgo Cloud를 구독하거나 Capgo을 직접 호스팅하는 분들에게는 이번 변경 사항이 아무런 영향을 미치지 않습니다. 다만, 기여 없이 제 소프트웨어를 이용해 저와 직접 경쟁하려 했던 일부 기업들에게는 불편한 소식이 될 수 있겠네요.
AGPL은 Google이 꺼려하는 라이선스입니다. 그들은 자신들의 클로즈드 소스인 code을 공개할 준비가 되어 있지 않기 때문입니다. Google은 AGPL에 반대하며 밝힙니다: “GNU Affero General Public License(AGPL)에 따라 라이선스된 Code은 Google에서 사용해서는 안 된다.”
AGPL의 목표는 사용자의 자유를 극대화하고 기업들이 오픈소스에 기여하도록 장려하는 것입니다. 저는 사용자 대상 독립형 애플리케이션이며, 라이브러리나 더 큰 프로젝트의 일부가 아닙니다. Google의 기부를 바라는 것도 아니기에, AGPL 라이선스를 채택하게 되어 기쁩니다. 이것이 Capgo에 가장 적합한 라이선스입니다.
마치며
오픈소스 소프트웨어 라이선스를 선택할 때는 고려해야 할 요소가 많습니다. 하지만 개발자 커뮤니티에서 흔히 쓰이는 선택지들은 분명히 존재합니다. 대표적인 허용적(permissive) 라이선스로는 MIT, Apache, BSD 라이선스가 있으며, 대표적인 카피레프트(copyleft) 라이선스로는 GNU General Public License와 Mozilla Public License가 있습니다.
오픈소스 소프트웨어 라이선스 이해하기에서 계속 읽기
사용 중이라면 오픈 소스 소프트웨어 라이선스 이해하기 live update 배포를 계획하려면, 다음과 연결하세요 Capgo Live Updates Capgo Live Updates의 제품 워크플로우를 보려면, 개요 Overview의 구현 상세를 보려면, 기능 Features의 구현 상세를 보려면, 업데이트 동작 Update Behavior의 구현 세부 사항은 다음과 같고, 업데이트 유형 Update Types의 구현 세부 사항은 다음과 같습니다.