오픈 소스 라이센스 종류?

Q: 오픈 소스 라이센스 종류?

| 구분 | 오픈 소스 라이선스 종류 및 의무사항 | |---|---| | 퍼미시브 | MIT 저작권 고지 및 라이선스 특징 유지 | | 퍼미시브 | Apache 라이선스 상업적 이용 허용 및 특허권 명시 | | 카피레프트 | GPL 소스코드 공개 의무 사항 포함 | | 라이선스 비교 | 각 오픈소스별 저작권 고지 방법 준수 |

2개월 전 0 조회수

구분	오픈 소스 라이선스 종류 및 의무사항
퍼미시브	MIT 저작권 고지 및 라이선스 특징 유지
퍼미시브	Apache 라이선스 상업적 이용 허용 및 특허권 명시
카피레프트	GPL 소스코드 공개 의무 사항 포함
라이선스 비교	각 오픈소스별 저작권 고지 방법 준수

의견 0 좋아요

이런 질문도 있으신가요?더 많이

오픈 소스 라이선스 종류: 퍼미시브 vs 카피레프트 비교

소프트웨어 개발 시 오픈 소스 라이선스 종류를 정확히 파악하는 과정은 법적 분쟁 예방의 핵심 요소입니다. 규정 오해는 공들여 만든 소스코드를 의도치 않게 공개하는 상황이나 저작권 침해 책임을 유발합니다. 개발 시작 전 각 라이선스별 의무사항을 철저히 점검하여 기업의 소중한 지식재산권을 안전하게 보호하는 것이 매우 유익합니다.

오픈 소스 라이선스 종류와 올바른 선택 가이드

오픈 소스 라이선스는 소프트웨어를 누구나 사용하고 수정하며 배포할 수 있는 권리를 부여하지만, 동시에 사용자가 지켜야 할 특정 의무 사항을 명시한 법적 계약입니다. 이는 개발 환경이나 프로젝트의 성격에 따라 해석이 달라질 수 있으며, 한 가지 정답이 있는 것은 아닙니다. 질문하신 라이선스 종류는 크게 MIT나 Apache와 같이 자유로운 사용을 중시하는 퍼미시브(Permissive) 계열과, 소스 코드 공개 의무를 강조하는 GPL 중심의 카피레프트(Copyleft) 계열로 나뉩니다.

현대 상업용 소프트웨어의 약 90-95%가 적어도 하나 이상의 오픈 소스 구성 요소를 포함하고 있습니다. 개발자가 라이선스를 제대로 이해하지 못하고 코드를 복제해 사용할 경우, 나중에 기업의 핵심 기술을 강제로 공개해야 하거나 거액의 소송에 휘말릴 위험이 큽니다. 실제로 조사에 따르면 상용 코드베이스의 약 68%에서 최소 한 개 이상의 라이선스 충돌이 발견되었습니다. 법적^[2] 분쟁은 생각보다 가까이 있습니다. 하지만 너무 겁먹을 필요는 없습니다. 핵심적인 오픈소스 라이센스 차이점만 파악해도 대부분의 위험을 피할 수 있기 때문입니다.

그런데 기업용 앱을 개발할 때 가장 조심해야 할 독소 조항이 하나 있습니다. 이를 모르면 공들여 만든 전체 소스 코드를 경쟁사에 무료로 공개해야 하는 재앙이 닥칠 수 있습니다. 이 치명적인 실수가 무엇인지는 아래 LGPL과 라이브러리 활용 섹션에서 구체적으로 설명하겠습니다. 우선 가장 많이 쓰이는 라이선스들부터 차근차근 살펴보겠습니다.

가장 자유로운 선택: 퍼미시브(Permissive) 라이선스

MIT License: 간결함의 대명사

MIT 라이선스 특징은 현재 GitHub에 공개된 프로젝트 중 약 45%를 차지하며 가장 널리 쓰이고 있습니다. ^[3] 문구 자체가 매우 짧아서 법률 전문가가 아니더라도 1분이면 다 읽을 수 있을 정도입니다. 핵심은 간단합니다. 마음대로 써도 좋지만, 사고가 나도 제작자는 책임지지 않는다는 것입니다.

저도 개인 프로젝트를 진행할 때 복잡한 걸 따지기 싫어서 주로 MIT를 선택하곤 합니다. 특별한 제약이 없기 때문에 스타트업이나 개인 개발자들이 가장 먼저 고려하는 옵션입니다. 하지만 너무 자유롭다 보니 특허권 보호 측면에서는 다소 취약할 수 있다는 점을 기억해야 합니다.

Apache License 2.0: 기업을 위한 안전장치

Apache 2.0 라이선스는 기업 환경에서의 신뢰도가 높아 약 11%의 점유율을 기록하고 있습니다.^[4] MIT와 비슷하게 상업적 이용과 소스 코드 비공개가 가능하지만, 결정적인 차이점은 특허권 관련 조항입니다. 라이선스 공여자가 사용자에게 해당 소프트웨어에 포함된 특허 기술을 무상으로 사용할 수 있도록 허가한다는 내용이 명시되어 있습니다.

대규모 인프라나 복잡한 알고리즘이 포함된 프로젝트라면 Apache 2.0이 훨씬 안전합니다. 나중에 원작자가 특허 침해 소송을 제기할 가능성을 원천 차단해주기 때문입니다. 구글의 안드로이드나 텐서플로우가 이 라이선스를 채택한 이유도 여기에 있습니다. 비즈니스 규모가 커질 계획이라면 처음부터 이 라이선스를 고려하는 것이 현명합니다.

공유의 철학: 카피레프트(Copyleft) 라이선스

카피레프트는 저작권을 뜻하는 카피라이트(Copyright)를 뒤집은 용어입니다. 소프트웨어의 자유를 보존하기 위해, 이 코드를 활용해 만든 파생 저작물도 반드시 오픈 소스로 공개하도록 강제하는 개념입니다. 이는 오픈 소스 생태계를 풍요롭게 만드는 원동력이지만, 기업 입장에서는 매우 까다로운 조건입니다.

GPL (General Public License): 강한 전염성

GPL은 가장 대표적인 강한 카피레프트 라이선스입니다. 만약 여러분의 프로그램에 GPL 코드가 단 한 줄이라도 섞여 있고 이를 외부에 배포한다면, 전체 소스 코드를 GPL로 공개해야 합니다. 이를 두고 흔히 라이선스의 전염성이라고 부릅니다. 이 때문에 기업 내부적으로만 쓰는 도구가 아니라 상용 판매용 제품이라면 GPL 코드 사용에 극도로 주의해야 합니다.

솔직히 말씀드리면 저도 예전에 외주 프로젝트를 하다가 오픈 소스 라이브러리 하나를 무심코 가져다 썼는데, 나중에 알고 보니 GPL이었습니다. 마감 직전에 그 라이브러리를 걷어내느라 이틀 밤을 꼬박 새웠던 기억이 납니다. 눈이 침침해질 정도로 코드를 뒤지며 GPL의 흔적을 지워야 했습니다. 정말 끔찍한 경험이었습니다.

LGPL (Lesser GPL): 라이브러리를 위한 타협점

앞서 언급한 기업용 앱의 독소 조항이 바로 여기서 나옵니다. LGPL은 주로 라이브러리에 적용되는데, 이를 동적 링크(Dynamic Linking) 방식으로 사용하면 메인 프로그램의 소스 코드를 공개하지 않아도 됩니다. 하지만 정적 링크(Static Linking) 방식으로 라이브러리를 컴파일에 포함해버리면 이야기가 달라집니다. 이 경우 전체 소스 코드를 공개해야 하는 GPL과 같은 의무가 발생합니다.

많은 개발자가 이 차이를 간과합니다. 단순히 LGPL이니까 안전하겠지라고 생각했다가, 배포 방식의 실수로 법적 의무를 짊어지게 됩니다. 모바일 앱 환경에서는 라이브러리를 포함하는 방식에 따라 해석이 갈릴 수 있어 더욱 정교한 관리가 필요합니다. 해결책은 간단합니다. 가능하면 공유 라이브러리 형태로 연결해서 쓰십시오. 그것이 비즈니스를 지키는 길입니다.

주요 오픈 소스 라이선스 핵심 비교

프로젝트의 목적에 따라 어떤 라이선스가 유리한지 한눈에 비교해 보세요. 상업적 이용 가능 여부와 소스 공개 의무가 핵심입니다.

MIT License (추천: 개인/스타트업)

명시적 조항 없음 (취약할 수 있음)

없음. 수정 후 비공개 배포 가능

매우 간결하고 제약이 거의 없음

완전히 허용됨

Apache 2.0 (추천: 기업/중대형 프로젝트)

특허 보복 방지 조항 포함 (안전함)

없음. 수정 후 비공개 배포 가능

특허권 행사가 중요한 상용 SW에 최적화

완전히 허용됨

GPL v3 (추천: 커뮤니티/공익 프로젝트)

사용자에게 특허 허가 부여 명시

강력함. 파생 저작물 전체 공개 필수

소프트웨어의 자유를 강제로 유지함

가능하지만 소스 공개가 필수라 제약됨

기업용 소프트웨어를 만든다면 MIT나 Apache 2.0이 가장 실용적입니다. 반면, 오픈 소스 생태계의 성장을 돕고 싶다면 GPL을 선택하여 코드가 영구히 자유롭게 남도록 할 수 있습니다.

서울 IT 스타트업 지민의 라이선스 위기 극복기

서울 서초구에서 에듀테크 스타트업을 운영하는 지민은 유료 강의 플랫폼 배포를 앞두고 큰 고민에 빠졌습니다. 개발 팀장이 영상 스트리밍을 위해 가져다 쓴 라이브러리가 알고 보니 강력한 소스 공개 의무가 있는 GPL v3 계열이었기 때문입니다.

지민은 처음엔 단순히 저작권 고지만 하면 될 줄 알고 무시하려 했습니다. 하지만 법률 자문을 구한 결과, 플랫폼 핵심 보안 알고리즘까지 모두 경쟁사에 노출될 수 있다는 경고를 듣고 등줄기에 식은땀이 흘렀습니다. 당장 배포를 멈추고 라이브러리를 전면 교체해야 했습니다.

교체 과정에서 기존 코드와 호환되지 않는 문제가 발생해 서비스 출시가 3주나 지연되었습니다. 지민은 이 사건을 계기로 팀 내에 오픈 소스 검수 프로세스를 도입했습니다. 모든 외부 코드를 쓰기 전 라이선스를 먼저 확인하는 문화를 만든 것입니다.

결국 지민은 Apache 2.0 라이선스 기반의 다른 라이브러리로 교체해 서비스를 안전하게 런칭했습니다. 출시 후 6개월 만에 가입자 10만 명을 돌파하며 성공 가도에 올랐고, 이제는 라이선스 리스크 없는 견고한 코드베이스가 회사의 가장 큰 자산이 되었습니다.

다른 질문

오픈 소스를 수정하지 않고 그대로 쓰면 소스 공개를 안 해도 되나요?

GPL의 경우 수정을 하지 않더라도 해당 코드를 포함하여 배포한다면 메인 프로그램의 소스 코드를 공개해야 할 의무가 생길 수 있습니다. 반면 MIT나 Apache는 단순 포함 시에도 비공개가 가능합니다. 라이선스마다 결합 방식에 따른 해석이 다르므로 주의가 필요합니다.

기업 내부에서만 쓰는 도구에도 라이선스 의무가 적용되나요?

대부분의 오픈 소스 라이선스 의무는 배포(Distribution) 시점에 발생합니다. 회사 외부로 소프트웨어를 판매하거나 배포하지 않고 내부 서버에서만 사용한다면, GPL이라 하더라도 소스 코드를 외부에 공개할 의무는 없습니다.

라이선스 고지는 어떻게 하는 게 정석인가요?

오픈 소스의 개념이 인공지능 분야에서는 어떻게 적용되는지 궁금하시다면 오픈 소스 AI 뜻?에 대한 내용을 확인해 보세요.

중요한 항목

안전한 비즈니스를 원한다면 MIT나 Apache를 선택하세요

상용 소프트웨어를 판매할 계획이라면 소스 코드 비공개가 보장되는 퍼미시브 라이선스 계열이 법적 리스크가 가장 적습니다.

GPL 사용 시 배포 범위를 반드시 확인하세요

GPL 코드가 포함되면 전체 소스 코드가 전염되어 공개될 수 있으므로, 외부 배포용 제품에는 사용을 지양하거나 철저히 격리해야 합니다.

라이브러리 연결 방식이 의무사항을 바꿉니다

LGPL 라이브러리를 쓸 때는 정적 링크보다는 동적 링크 방식을 사용하여 메인 코드 공개 의무를 피하는 것이 기술적인 정석입니다.

이 아티클에서 제공하는 정보는 교육 및 정보 제공 목적으로 작성되었으며, 실제 법적 효력을 갖는 자문이 아닙니다. 오픈 소스 라이선스 해석은 구체적인 상황과 국가별 법률에 따라 달라질 수 있습니다. 중요한 비즈니스 결정을 내리기 전에는 반드시 지식재산권 전문 변호사나 법률 전문가의 상담을 받으시기 바랍니다.