콤퓨타지식 오픈소스 라이선스란? 공개 코드의 저작권과 MIT·Apache·GPL의 차이

페이지 정보

본문

작성일 2026-09-17

GitHub에는 누구나 볼 수 있는 수많은 소스코드가 공개되어 있다.

그렇다면 인터넷에 공개된 코드는 누구나 복사해서 자신의 서비스에 사용해도 될까?

소스코드를 공개했다는 사실과 다른 사람에게 자유로운 이용을 허락했다는 것은 같은 의미가 아니다.

오픈소스(Open Source)를 이해하기 위해서는 먼저 저작권(Copyright)과 라이선스(License)의 관계를 이해해야 한다.

오픈소스는 일반적으로 저작권을 포기한 코드가 아니다.

따라서 중요한 질문은 단순히

“이 코드를 볼 수 있는가?”

가 아니라

“이 코드를 어떤 조건으로 사용할 수 있는가?”

이다.

오픈소스는 단순히 ‘소스코드가 공개된 소프트웨어’가 아니다

오픈소스라는 표현 때문에 가장 쉽게 생기는 오해가 있다.

소스코드가 인터넷에 공개되어 있으면 모두 오픈소스라고 생각하는 것이다.

하지만 공개적으로 열람할 수 있는 코드(Publicly Available Source Code)와 오픈소스 소프트웨어는 구분할 필요가 있다.

오픈소스 이니셔티브(Open Source Initiative, OSI)의 오픈소스 정의에서도 단순히 소스코드에 접근할 수 있는 것만으로는 오픈소스라고 하지 않는다.

라이선스가 자유로운 재배포를 허용하고 소스코드를 제공하며, 수정과 파생저작물(Derived Works)의 생성을 허용하는 등 일정한 조건을 충족해야 한다.

즉,

코드 공개

와

코드 이용 허락

은 서로 다른 문제다.

GitHub의 공개 저장소에서 코드를 발견했다고 하더라도 어떤 라이선스가 적용되는지 먼저 확인해야 하는 이유가 여기에 있다.

저작권과 라이선스는 무엇이 다른가

소프트웨어도 일정한 요건을 충족하면 저작권의 보호 대상이 될 수 있다.

라이선스(License)는 이러한 권리를 다른 사람이 일정한 조건 아래 이용할 수 있도록 허락하는 구조다.

관계를 단순화하면 다음과 같다.

저작권(Copyright)
↓
저작권자가 권리를 가지고 있음
↓
라이선스(License)
↓
일정한 조건 아래 이용을 허락
↓
사용·복제·수정·배포

따라서 오픈소스 라이선스가 존재한다는 것은 저작권이 없다는 의미가 아니다.

오픈소스 라이선스가 허용하는 것은 무엇인가

라이선스마다 구체적인 조건은 다르지만 오픈소스 라이선스는 일반적으로 소프트웨어의 사용, 복제, 수정, 재배포 등을 일정한 조건 아래 허용한다.

여기서 중요한 것은 Permission과 Condition을 함께 보는 것이다.

예를 들어 어떤 라이선스가 상업적 이용을 허용한다고 해서 아무 조건 없이 사용할 수 있다는 의미는 아니다.

상업적 이용을 허용하면서도 기존 저작권 표시를 유지하도록 요구할 수 있다.

라이선스 전문을 함께 제공해야 할 수도 있다.

수정한 사실을 표시해야 할 수도 있다.

특정한 방식으로 프로그램을 배포할 경우 소스코드 제공 의무가 발생할 수도 있다.

따라서 오픈소스 라이선스를 확인할 때는

“무엇을 할 수 있는가?”

와 동시에

“그 대신 무엇을 해야 하는가?”

를 확인해야 한다.

오픈소스 라이선스는 크게 어떻게 나뉠까

수많은 오픈소스 라이선스가 존재하지만 구조를 이해하기 위해서는 크게 허용적 라이선스(Permissive License)와 카피레프트 라이선스(Copyleft License)의 차이를 먼저 이해하는 것이 유용하다.

MIT License와 Apache License 2.0은 대표적인 허용적 라이선스에 속한다.

이러한 라이선스는 비교적 넓은 사용·수정·재배포 권한을 허용하면서 일정한 고지 의무 등을 요구한다.

반면 GNU General Public License(GPL)는 대표적인 카피레프트 라이선스다.

GPL은 소프트웨어를 자유롭게 사용하고 수정할 수 있도록 허용하면서, GPL이 적용되는 프로그램이나 그에 기반한 저작물을 일정한 방식으로 전달할 때 그 자유가 후속 이용자에게도 이어지도록 하는 조건을 둔다.

이 차이 때문에 어떤 오픈소스 라이선스를 사용하는지는 상용 소프트웨어 개발에서도 중요한 문제가 된다.

MIT License — 단순하고 넓은 이용을 허용하는 라이선스

MIT License는 대표적인 허용적 라이선스다.

소프트웨어의 사용, 복제, 수정, 병합, 게시, 배포, 재라이선스, 판매 등을 폭넓게 허용하는 매우 간결한 구조를 가지고 있다.

하지만 조건이 전혀 없는 것은 아니다.

MIT License의 핵심적인 조건은 기존의 저작권 고지(Copyright Notice)와 라이선스 고지(Permission Notice)를 소프트웨어의 복제물이나 중요한 부분에 포함하는 것이다.

따라서 MIT 라이선스가 붙은 코드를 상업적인 프로그램에서 사용하는 것 자체는 일반적으로 허용되지만, 그렇다고 원래의 저작권·라이선스 표시까지 자유롭게 제거할 수 있다는 의미는 아니다.

MIT가 비교적 사용하기 쉬운 라이선스로 평가되는 이유는 이러한 조건을 충족하면 수정된 코드를 반드시 같은 MIT 라이선스로 공개하도록 요구하지 않기 때문이다.

즉 MIT 라이선스 코드를 포함한 더 큰 프로그램이 항상 오픈소스가 되어야 하는 것은 아니다.

Apache License 2.0 — 저작권뿐 아니라 특허까지 명시한다

Apache License 2.0 역시 대표적인 허용적 라이선스다.

하지만 MIT보다 라이선스 구조가 더 구체적이다.

여기에 중요한 차이가 하나 더 있다.

특허 라이선스(Patent License)다.

Apache License 2.0에서는 각 기여자가 자신의 기여분 때문에 필연적으로 침해되는 일정한 특허 청구항에 대해 이용자에게 특허 라이선스를 부여하는 구조를 명시하고 있다.

또한 재배포할 경우 Apache License 사본을 제공해야 하고, 수정한 파일에는 변경 사실을 알 수 있는 표시를 해야 하며, 기존 저작권·특허·상표·출처 관련 고지를 일정 범위에서 유지해야 한다.

원본에 NOTICE 파일이 포함되어 있고 그 내용이 적용 대상이라면 파생저작물을 배포할 때 해당 NOTICE의 관련 귀속 정보를 포함해야 하는 조건도 존재한다.

따라서 Apache 2.0은 단순히

“무료로 사용할 수 있는 라이선스”

라기보다

“폭넓은 이용 권한을 허용하면서 저작권·특허·고지에 관한 조건을 구체적으로 정의한 라이선스”

로 이해하는 것이 더 정확하다.

GPL — 자유롭게 사용할 수 있지만 자유를 이어가도록 요구한다

GNU General Public License(GPL)는 MIT나 Apache와 구조가 다르다.

GPL은 카피레프트(Copyleft)라는 원칙을 대표하는 라이선스다.

카피레프트의 핵심 목적은 소프트웨어를 사용할 자유뿐 아니라 수정하고 공유할 자유가 후속 이용자에게도 이어지도록 하는 것이다.

GPLv3는 프로그램을 사용하고 수정하는 것을 허용한다.

하지만 GPL이 적용되는 프로그램을 수정한 저작물 등 라이선스가 규정하는 covered work를 다른 사람에게 전달(convey)할 경우에는 추가적인 조건이 적용된다.

예를 들어 수정된 저작물에는 수정 사실과 관련 날짜를 알리는 고지를 포함해야 하며, 일정한 조건에 해당하는 저작물 전체를 GPLv3에 따라 라이선스해야 한다.

또한 객체코드(Object Code)를 전달하는 경우에는 GPL이 정하는 방식에 따라 해당 프로그램의 대응 소스코드(Corresponding Source)를 함께 제공하거나 이를 받을 수 있는 방법을 제공해야 하는 경우가 있다.

그래서 GPL을 단순히

“상업적으로 사용할 수 없는 라이선스”

라고 이해하면 잘못이다.

GPL은 상업적 이용 자체를 금지하는 라이선스가 아니다.

중요한 것은 GPL이 적용되는 프로그램을 어떤 형태로 수정하고 결합했는지, 그리고 그것을 다른 사람에게 어떻게 전달하는지에 따라 GPL이 요구하는 조건을 검토해야 한다는 점이다.

MIT·Apache 2.0·GPL은 무엇이 다른가

세 라이선스를 가장 단순하게 비교하면 다음과 같다.

구분	MIT	Apache 2.0	GPLv3
라이선스 유형	허용적	허용적	카피레프트
상업적 이용	가능	가능	가능
수정	가능	가능	가능
재배포	가능	가능	가능
저작권·라이선스 고지	필요	필요	필요
수정 사실 표시	일반적으로 별도 요구 없음	재배포하는 수정 파일에 요구	수정된 파일에 요구
명시적 특허 라이선스	없음	있음	있음
동일 라이선스 적용 의무	일반적으로 없음	일반적으로 없음	적용 조건 충족 시 있음
소스코드 제공 의무	일반적으로 없음	일반적으로 없음	특정 전달 형태에서 발생

이 표는 세 라이선스의 구조를 이해하기 위한 요약이다.

실제 적용 여부는 사용하는 코드, 수정 방식, 다른 코드와의 결합 관계, 배포 방식, 적용되는 라이선스 버전 등에 따라 달라질 수 있기 때문에 구체적인 프로젝트에서는 해당 라이선스 전문을 확인해야 한다.

‘사용’과 ‘배포’는 왜 구분해야 할까

오픈소스 라이선스를 이해할 때 특히 중요한 개념이 배포(Distribution) 또는 GPL에서 사용하는 전달(Convey)이다.

소프트웨어를 조직 내부에서 사용하는 것과 다른 사람에게 프로그램을 전달하는 것은 라이선스상 같은 행위가 아닐 수 있다.

특히 GPL 계열에서는 프로그램을 다른 사람에게 전달하는 시점에 소스코드 제공이나 라이선스 적용 등 중요한 의무가 발생할 수 있다.

따라서 오픈소스를 사용했다는 사실만으로 곧바로

“전체 소스코드를 공개해야 한다”

고 결론 내리는 것도 정확하지 않다.

어떤 라이선스가 적용되는지와 함께 어떻게 사용했고 어떻게 배포했는지를 확인해야 한다.

오픈소스 코드를 수정하면 모두 파생저작물이 될까

오픈소스 라이선스를 설명할 때 자주 등장하는 또 하나의 개념이 파생저작물(Derivative Work)이다.

Apache License 2.0은 Derivative Works를 라이선스 안에서 별도로 정의하고 있으며, GPL 역시 수정된 버전이나 기존 프로그램을 기반으로 한 저작물에 관한 규정을 두고 있다.

하지만 실제 소프트웨어에서 어느 범위까지 하나의 저작물로 볼 것인지, 라이브러리를 연결한 프로그램이 어떤 관계를 형성하는지 등의 문제는 단순한 파일 포함 여부만으로 항상 결정되는 것은 아니다.

그래서

“GPL 라이브러리를 한 번 사용하면 프로젝트 전체가 무조건 GPL이 된다”

와 같은 문장은 지나치게 단순화된 설명이다.

라이선스 종류뿐 아니라 프로그램의 결합 방식과 실제 배포 형태까지 함께 검토해야 한다.

라이선스가 없는 공개 코드는 어떻게 봐야 할까

GitHub 등에 소스코드가 공개되어 있지만 별도의 라이선스가 표시되어 있지 않은 경우도 있다.

이때

“라이선스가 없으니 아무 조건 없이 사용할 수 있다”

고 해석해서는 안 된다.

따라서 공개 저장소를 사용할 때는 단순히 저장소가 Public인지 확인하는 것보다 LICENSE 파일이나 프로젝트가 명시한 이용조건을 확인하는 것이 중요하다.

AI가 코드를 생성하면 오픈소스 라이선스 문제는 사라질까

생성형 AI의 등장으로 새로운 상황이 생겼다.

개발자가 특정 오픈소스 저장소에서 직접 코드를 복사하지 않았더라도 AI 코딩 도구가 생성한 결과가 기존 공개 코드와 동일하거나 유사할 수 있기 때문이다.

하지만 AI가 코드를 생성했다는 사실만으로 기존 코드의 저작권이나 라이선스 문제가 자동으로 사라지는 것은 아니다.

반대로 AI가 생성한 모든 코드에 특정 오픈소스 라이선스가 적용된다고 단정할 수도 없다.

AI 출력 코드와 기존 코드 사이의 관계, 기존 표현의 재현 여부, 해당 코드에 적용되는 라이선스, 실제 이용·배포 방식 등은 서로 구분해서 검토해야 할 문제다.

따라서 AI 시대에도 오픈소스 라이선스의 기본 질문은 달라지지 않는다.

코드의 출처는 무엇인가?

어떤 라이선스가 적용되는가?

그 라이선스는 무엇을 허용하는가?

어떤 조건을 요구하는가?

우리는 그 코드를 어떻게 사용하고 배포하는가?

AI는 코드가 만들어지는 방법을 변화시키고 있지만, 소프트웨어를 사용할 수 있는 권리와 조건을 정의하는 라이선스의 기본 구조까지 없애는 것은 아니다.

오픈소스의 핵심은 ‘무료’가 아니라 ‘이용 조건’이다

오픈소스 소프트웨어를 이해할 때 가장 중요한 것은 가격이 아니다.

MIT, Apache 2.0, GPL 모두 폭넓은 소프트웨어 이용을 허용하지만 허용하는 방식과 요구하는 조건은 서로 다르다.

따라서 오픈소스를 사용할 때는 단순히

“무료인가?”

또는

“GitHub에 공개되어 있는가?”

를 확인하는 것만으로 충분하지 않다.

더 중요한 질문은

“누가 어떤 권리를 가지고 있으며, 어떤 라이선스를 통해 무엇을 허용했고, 그 허락을 받기 위해 어떤 조건을 지켜야 하는가?”

이다.

오픈소스 라이선스는 소프트웨어를 자유롭게 사용할 수 있게 만드는 동시에, 그 자유를 어떤 조건으로 행사할 수 있는지를 정의하는 법적·기술적 규칙이다.

용어 정리

오픈소스(Open Source)
소스코드를 단순히 공개하는 것을 넘어 사용·수정·재배포 등에 관한 일정한 권리를 오픈소스 라이선스를 통해 허용하는 소프트웨어 개발·배포 방식.

라이선스(License)
권리자가 자신이 가진 권리의 일부를 다른 사람이 정해진 조건에 따라 이용할 수 있도록 허락하는 법적 조건.

허용적 라이선스(Permissive License)
사용·수정·재배포를 폭넓게 허용하면서 비교적 제한적인 의무를 부과하는 오픈소스 라이선스 유형. MIT와 Apache 2.0 등이 대표적이다.

카피레프트(Copyleft)
소프트웨어를 자유롭게 사용·수정·공유할 권리를 허용하면서, 일정한 조건 아래 수정·재배포된 저작물에도 동일하거나 호환되는 자유를 유지하도록 요구하는 라이선스 방식.

파생저작물(Derivative Work)
기존 저작물을 바탕으로 수정·변형 등을 통해 만들어진 저작물. 구체적인 범위는 적용되는 법률과 라이선스의 정의 및 사실관계에 따라 달라질 수 있다.

특허 라이선스(Patent License)
특허권자가 특정 특허 기술을 일정한 조건 아래 이용할 수 있도록 허락하는 것. Apache License 2.0과 GPLv3에는 명시적인 특허 관련 조항이 존재한다.

배포(Distribution)
소프트웨어나 그 복제물을 다른 사람에게 제공하는 행위. 구체적인 법적 의미와 의무는 라이선스에 따라 달라질 수 있다.

전달(Convey)
GPLv3에서 사용되는 용어로, 제3자가 복제물을 만들거나 받을 수 있도록 하는 종류의 전파 행위를 의미한다. 단순한 실행이나 개인적 수정과 구별된다.

대응 소스코드(Corresponding Source)
GPLv3에서 객체코드를 생성·설치·실행·수정하는 데 필요한 소스코드와 관련 자료를 의미하는 개념.

출처

Open Source Initiative — The Open Source Definition

오픈소스는 단순한 소스코드 접근을 의미하지 않으며, 자유로운 재배포, 소스코드 제공, 수정과 파생저작물 허용 등 오픈소스 라이선스가 충족해야 하는 기준을 정의한다.

https://opensource.org/osd

Open Source Initiative — The MIT License

https://opensource.org/license/mit

Apache Software Foundation — Apache License, Version 2.0

https://www.apache.org/licenses/LICENSE-2.0

Apache Software Foundation — Applying the Apache License, Version 2.0

Apache License 2.0을 실제 소프트웨어에 적용할 때 LICENSE 및 NOTICE 파일과 귀속 정보를 어떻게 관리하는지 설명하는 공식 자료.

https://www.apache.org/legal/apply-license

Free Software Foundation — GNU General Public License Version 3

GPLv3 공식 라이선스 원문. 수정된 프로그램, covered work, convey, Corresponding Source 및 GPL 적용 조건 등을 확인할 수 있다.

https://www.gnu.org/licenses/gpl-3.0.html

Free Software Foundation — A Quick Guide to GPLv3

GPLv3의 카피레프트 구조와 소프트웨어 사용·수정·공유의 자유를 설명하는 공식 해설 자료.

https://www.gnu.org/licenses/quick-guide-gplv3.html

이전글2026년 9월부터 적용된 EU 소프트웨어 취약점 보고 의무, CRA 핵심 내용 정리 26.09.18
다음글GitHub Copilot의 오픈소스 코드 소송, 미국 항소법원은 무엇을 기각했나 26.09.17

탐구

서비스

탐구

서비스

포트폴리오

콤퓨타이야기

최신소식

고객센터