오픈소스SW를 반드시 알아야 할 이유
오픈소스SW(Open Source Software)는 컴퓨터프로그램 개발자라면반드시 알아야하는 핵심개념으로서 해외및 국내공공과 민간에서널리 활용되고있습니다. 자유롭게 사용할 수있지만 반드시지켜야 할조건이 존재합니다. 이를 알지못하고 사용할경우 법적분쟁의 원인이될 수있습니다.
오픈소스는 '레시피가 공개된 요리'와 같습니다.
누구나 따라 만들고 응용할 수 있지만 원작자인 저작권자의 이름을 있는 그대로 보전 및 고지해야 합니다. 즉, 원작자 이름을 지우거나 자신의 이름으로 배포 및 판매할 수는 없습니다.
오픈소스SW 개요
오픈소스SW는소스코드가공개되어누구나자유롭게복제및수정, 사용및재배포할수있는소프트웨어입니다. 그런데, 처음부터 이런 문화가 있었던 건 아닙니다. 지금의 오픈소스가 만들어지기까지 어떤 배경과 변화가 있었는지 간략히 살펴보겠습니다.
오픈소스SW 등장 배경
등장 배경과 발전 과정을 시간 순으로 간략히 정리하면 아래와 같습니다.
| 시기 | 주요사건 |
|---|---|
| 1980년대 | 기업들이 소프트웨어의 소스코드를 공개하지 않고 사용을 제한하기 시작함 |
| 1983년대 | MIT 인공지능 실험실의 해커 리처드 스톨만이 "누구나 자유롭게 SW를 써야 한다"고 주장하며 GNU 프로젝트 시작 |
| 1985년대 | 자유 소프트웨어 재단(Free Software Foundation) 설립 자유SW 운동 본격화 |
| 1989년대 | GPL(GNU General Public License) 발표 수정한 SW도 소스코드 공개 의무 부과 |
| 1998년대 | 철학보다 실용성을 강조한 ‘오픈소스’ 용어 등장 에릭 레이먼드, 브루스 페런스 등이 OSI(Open Source Initiative) 설립 |
| 이후~현재 | 자유 소프트웨어 재단(Free Software Foundation) 설립 자유SW 운동 본격화 기업과 공공기관도 오픈소스 적극 활용 |
자유SW 운동으로부터 오픈소스SW가 시작되었지만, 시간이 흐르며 독자적인 방향으로 발전해왔습니다. 그렇다면 이 둘은 어떤 점에서 다르고, 왜 구분해서 이해해야 할까요?
자유SW와 오픈소스SW의 차이점
많은 사람들은 오픈소스SW와 자유SW이 모두 소스코드가 공개된다는 공통점을 가지고 있어서 같은 개념으로 생각하지만 실제로는 배경, 목적, 철학, 활용방식에 중요한 차이가 있습니다.
| 구분 | 자유SW | 오픈소스SW |
|---|---|---|
| 목표 | 사용·수정·복제·배포의 자유를 통한 기술 독립과 윤리적 사용 | 기업·개인 누구나 소프트웨어를 효율적으로 개발하고 활용 |
| 특징 | 소프트웨어를 자유롭게 사용할 수 있는 사용자의 권리를 강조 | 소스코드 공개를 통해 협업과 품질 개선을 강조 |
| 중심 철학 | "자유(Freedom)" 중심 – 정보 접근의 평등성 | "공개(Open)" 중심 – 개발 프로세스의 효율성 |
| 대표 단체 | 자유소프트웨어재단 (FSF) | 오픈소스이니셔티브 (OSI) |
| 대표 라이선스 | GNU GPL(GNU General Public License)→ 수정된 소스도 공개해야 함 | MIT, Apache, BSD 등→ 공개 의무가 없고 상업적 사용에 유연함 |
| 기업 활용도 | 일부 제약으로 인해 활용도 낮음 | 상업적 활용 용이성으로 인해 높음 |
| 주요 차이점 | 자유 소프트웨어는 "자유로운 이용이 보장된 권리"가 핵심 | 오픈소스 소프트웨어는 "소스코드의 개방"이 핵심 |
그렇다면, 둘 중의 어떤 방식으로든 공개된 소스코드는 정말 누구나 자유롭게 사용하고 변경 및 재 배포해도 괜찮은 걸까요?
사실 오픈소스SW도 저작권 등 다양한 지식재산권의 보호를 받는 창작물입니다. 사용자 입장에서는 이와 관련된 법적 권리를 이해하고 준수하는 것이 중요합니다.
오픈소스SW는 소스코드가 공개되어 있다고 하더라도 여전히 저작권, 특허권, 상표권 등 지식재산권의 보호를 받는 대상입니다.
오픈소스SW에 적용되는 지식재산권
저작권, 특허권, 상표권, 영업비밀은 각기 다른 방식으로 오픈소스 소프트웨어의 사용과 배포에 영향을 줍니다.
| 권리 | 설명 | 예시 |
|---|---|---|
| 저작권 (Copyright) |
인간의 사상이나 감정이 드러난 창작물에 자연적으로 부여되는 권리 | 사람이 만든 소스코드, 문서 등 |
| 특허권 (Patent) |
등록된 기술적 아이디어에 대한 독점적 사용 권리 | 영상 압축 알고리즘, 검색 엔진 구조 등 |
| 상표권 (Trademark) |
소프트웨어의 이름이나 로고 등에 대해 등록된 고유 권리 | “Linux”, “MySQL” 등 제품명과 로고 |
| 영업비밀 (Trade Secret) |
외부에 공개되지 않은 기술 정보, 알고리즘 등에 대한 보호 | 기업 내부의 비공개 알고리즘, 설정값 등 |
그렇다면 실무에서 자주 발생하는 행위에 따라 어떤 권리가 침해되는지 아래 표를 통해 구체적인 예시와 함께 살펴보세요.
| 실무에서 자주 발생하는 행위 | 적용되는 권리 | 침해행위 예시 |
|---|---|---|
| 소스코드를 복제 및 수정 사용하거나 배포 | 저작권 | 오픈소스SW의 소스코드 사용 사실을 고지하지 않거나 소스코드를 공개하지 않고 무단 사용 |
| 등록된 기술 구현 | 특허권 | 특허받은 압축기술을 무단 사용 |
| 이름/로고 사용 | 상표권 | “리눅스” 명칭을 상업용 제품에 무단 사용 |
| 내부 아이디어 유출 | 영업비밀 | 기업의 비공개 SW 알고리즘 유출 |
위와 같은 다양한 지식재산권은 오픈소스 소프트웨어의 사용 범위를 정하는 중요한 기준이 됩니다. 사용자는 관련 권리를 정확히 이해하고, 정해진 조건 내에서 소프트웨어를 활용해야 합니다. 그렇다면, 이러한 사용 조건은 어디에 명시되어 있을까요? 바로 ‘라이선스’라는 문서를 통해 확인할 수 있습니다.
라이선스(License)는 해당 소프트웨어의 권리자가 ‘이 소프트웨어는 이렇게 사용하시면 됩니다’ 라고 알려주는 사용 조건 및 허가서입니다.
오픈소스SW는 소스코드를 자유롭게 사용할 수 있도록 공개되어 있지만, 완전히 제한 없이 사용할 수 있는 것은 아닙니다. 소프트웨어의 저작권자(대체로 개발자)는 사용자가 지켜야 할 조건을 ‘라이선스’라는 문서화된 형태로 명시하며, 사용자는 해당 라이선스 조건을 준수하는 범위 안에서만 오픈소스를 사용할 수 있습니다.
오픈소스 라이선스 분류
오픈소스 라이선스는 소스코드의 공개 여부 및 공개 범위에 따라 크게 3가지 유형으로 분류됩니다. 즉, 사용자(개발자)의 자유로운 이용/협업 관점에서 “공개” 를 강하게 요구하는 “강한 카피레프트”, 상대적으로 공개를 덜 요구하는 “약한 카피레프트”, 소스코드 수정/재배포 자유롭고 소스코드 공개의무도 없는 “퍼미시브”가 있습니다.
| 라이선스 분류 | 특징 | 대표 예시 |
|---|---|---|
| 강한 카피레프트 (Strong Copyleft) |
소프트웨어 소스코드를 수정하거나 재배포할 경우, 연결된 전체 소스코드를 공개 의무사항이 발생하는 라이선스 | GPL (General Public License) |
| 약한 카피레프트 (Weak Copyleft) |
소프트웨어 소스코드를 수정하거나 재배포할 경우, 일부 연결 라이브러리나 모듈 등의 제한된 범위에서의 소스코드 공개 의무사항이 발생하는 라이선스 | LGPL (Lesser GPL) |
| 퍼미시브 (Permissive) |
소프트웨어 소스코드를 수정하거나 재배포 할 경우 소스코드 공개의무 없이 고지 의무사항만 발생하는 라이선스 | MIT, BSD, Apache 등 |
주요 오픈소스 라이선스 의무사항
각 라이선스는 서로 다른 조건을 포함하고 있으므로, 사용자는 반드시 사용 전 의무사항을 확인해야 합니다.
| 라이선스 유형 | 주요 의무사항 |
|---|---|
| GPL | 소스코드 공개 필수, 동일 라이선스로 배포해야 함 (상호주의 조건) |
| LGPL | 링크된 라이브러리 소스코드만 고지 혹은 공개하면 되고, 독립된 소스는 별도 배포 가능 |
| MIT / BSD / Apache | 저작권 표시만 유지하면 사용•수정•배포 자유, 소스 공개는 선택 |
- 라이선스 조건을 위반할 경우, 저작권 침해 또는 계약 위반으로 간주되어 법적 책임이 발생할 수 있습니다.
- 특히 GPL 등 Copyleft 라이선스는 코드를 공개하지 않으면 소송 대상이 될 수 있습니다.
라이선스는 오픈소스SW의 사용 조건을 규정하는 핵심 문서입니다. 하지만 오픈소스 라이선스는 단일한 형태가 아니라 종류마다 조건과 구조가 서로 다르기 때문에 정확한 구분과 이해가 필요합니다.
오픈소스 라이선스는 종류마다 소스코드 공개 여부, 재배포 조건, 상업적 이용 허용 범위 등이 다릅니다. 사용 전 반드시 각 라이선스의 구조와 차이를 이해해야 합니다.
| 라이선스명 | 복제 | 수정 | 재배포 | 상업적 이용 |
소스코드 공개 의무 |
특이사항 |
|---|---|---|---|---|---|---|
| GPL | 허용 | 허용 | 허용 | 허용 | 필수 | 강한 카피레프트, 동일 라이선스로만 재배포 가능 |
| LGPL | 허용 | 허용 | 허용 | 허용 | 조건부 | 라이브러리 수준에서만 공개 의무 |
| MIT | 허용 | 허용 | 허용 | 허용 | 없음 | 퍼미시브 라이선스, 저작권 표시만 유지 |
| BSD | 허용 | 허용 | 허용 | 허용 | 없음 | MIT와 유사, 표준 텍스트 유지 필요 |
| Apache | 허용 | 허용 | 허용 | 허용 | 없음 | 무료 특허 로열티 라이선스 조항 포함 |
그렇다면, 실제로는 어떤 라이선스들이 가장 많이 사용되고 있을까요?
다음은 주요 오픈소스 프로젝트에서 사용되고 있는 라이선스의 분포 현황입니다.
이 통계는 GitHub, GitLab 등 주요 오픈소스 플랫폼에서 어떤 라이선스가 실제로 가장 많이 사용되는지를 기반으로 정리된 자료입니다.
| 순위 | 라이선스명 | 사용 비율(%) |
|---|---|---|
| 1 | MIT | 44.6 |
| 2 | 기타 (unstated 등) | 15.6 |
| 3 | GPL v2 | 12.9 |
| 4 | Apache 2.0 | 11.1 |
| 2 | GPL v3 | 8.8 |
| 2 | BSD 3 Clause | 4.5 |
| 7 | Unlicense | 1.8 |
| 8 | BSD 2 Clause | 1.7 |
| 9 | LGPL v3 | 1.3 |
| 10 | AGPL v3 | 1.0 |
출처: https://github.blog/open-source/open-source-license-usage-on-github-com/?utm_source=chatgpt.com(2025. 7. 10.접속)
편집자주: 프로젝트에 여러 개의 라이선스가 포함된 경우 중복 집계되었을 가능성이 있음)
MIT, Apache 2.0, BSD와 같은 퍼미시브(permissive) 라이선스는 소스코드 공개 의무가 없어 기업이나 개인 개발자 모두에게 부담이 적은 선택지로 널리 채택되고 있습니다.
반면, GPL과 같은 카피레프트(copyleft) 라이선스는 수정한 내용을 다시 공개해야 하는 상호주의 원칙을 기반으로 하며, 자유 소프트웨어 운동의 철학을 따르는 전통적인 프로젝트에서 많이 사용됩니다.
이처럼 라이선스별로 접근 방식과 조건이 다르기 때문에 오픈소스SW의 사용자 입장에서도 꼭 알아야 할 점들이 있습니다.
오픈소스는 자유롭게 쓸 수 있지만, 정해진 규칙(=라이선스 조건) 안에서만 가능하다는 걸 기억해야 합니다. “공짜니까 아무 데나 써도 되는 거 아닐까?”라는 잘못된 판단을 한다면 법적 분쟁으로 이어질 수 있습니다.
사용 전 반드시 확인할 3가지 체크포인트
반드시 라이선스 종류를 확인하고 재배포 조건과 고지의무를 확인하여야 합니다. 예를 들어 Apache 2.0은 저작권 고지를 명시해야 하고, GPL은 소스코드 전체를 함께 공개해야 합니다.
| 항목 | 확인 내용 |
|---|---|
| 라이선스 종류 | MIT? GPL? Apache? 조건이 모두 달라요. |
| 재배포 조건 | 수정했을 때 소스코드 공개 의무가 있는지 확인해야 해요 |
| 고지(Notice) 의무 | README, UI 화면 등 어디에 어떤 방식으로 출처를 밝혀야 하는지 명확히 해야 해요. |
- 라이선스를 위반하면 ‘저작권 침해’로 간주되어 법적 소송이나 배상 책임이 생길 수 있어요.
- 실제로 기업들이 오픈소스 사용 규정을 지키지 않아 수십억 원대 벌금이나 조정 비용을 물었던 사례도 있습니다.
오픈소스 라이선스는 실제로 국내외 법정에서 저작권과 유사한 효력을 인정받고 있으며사용 조건을 위반할 경우 법적 분쟁으로 이어진 사례도 존재합니다. 아래는 시사점을 남긴 대표적인 판례들입니다.
- Eduroam 사건: 비영리 목적의 배포라도 저작권 침해로 판단된 사례
- 국내 A사 v. B사: 국내 최초로 오픈소스 라이선스 위반이 정식 소송으로 이어진 사건
- Jacobsen v. Katzer (미국): 오픈소스 라이선스 위반이 저작권 침해로 인정된 첫 미국 판례
- Welte v. Skype (독일): 고지 의무 불이행에 대해 유통업체 책임을 명확히 한 판례
- FSF v. Bracken: 라이선스 조건을 인지하지 못한 사용자도 책임이 있다는 점을 분명히 한 사례
- Welte v. D-Link (독일): 오픈소스 저작권이 대륙법 체계에서도 인정될 수 있음을 보여줌
- FSF v. Cisco: 오픈소스 사용에 대한 공급망 전체의 책임성을 이슈화한 합의 사례
- SFC v. 14개 기업: 한국 기업이 포함된 최초의 GPL 집단 대응 사례
- 익명 국내 전자업체 – exFAT 라이선스 관련 이슈 (2013, 유럽)
- Versata Software v. Ameriprise (2014, 미국)
- Patrick McHardy v. 다수 유럽 제조업체 (2013, 독일)
- Christoph Hellwig v. VMware (2015, 독일)
- Google v. Oracle (2012~2018, 미국)
- Xiaomi (2015, 중국)
- 익명 한국 기업 v. Artifex (2017, 한국)
- Stockfish v. ChessBase (2021, 독일)
- SFC v. Vizio (2021, 미국)
- VirtualApp v. Dim Sum Desktop (2019, 중국)
- GitHub 개발자들 v. Microsoft/OpenAI (진행 중)
이처럼 오픈소스 라이선스는 단순한 사용 조건이 아니라, 실제로 법적 효력을 가지며 국제적으로도 활발히 다뤄지는 중요한 권리 사항입니다. 사용자는 반드시 라이선스 조건을 숙지하고, 고지 및 의무사항을 준수해야 합니다.
고지(Notice) 의무와 이행 방법
오픈소스를 사용할 때에는 어떤 오픈소스를 어떻게 사용했는지 명확하게 고지하는 것이 필수적인 책임입니다.
| 항목 | 설명 |
|---|---|
| 고지 위치 | 사용자 매뉴얼, 제품 내 UI, 웹사이트 하단, 별도 공지 페이지 등 |
| 고지 내용 | 사용한 오픈소스 이름, 라이선스 종류, 출처(저작권자/링크 등) |
| 방법 예시 |
- NOTICE 파일 첨부 - About 페이지에 명시 - 앱 내 설정 메뉴에 고지 정보 포함 |
