내가 밤새워 만든 코드가 어느 날 경쟁사 서비스의 핵심 기능으로 버젓이 쓰이고 있다면 기분이 어떨까요? 심지어 그 코드를 내가 ‘오픈소스’로 공개했기 때문에 법적으로 아무 문제 없다고 주장한다면 말이죠. 이런 끔찍한 상황은 오픈소스의 개념을 절반만 이해했을 때 벌어집니다. 오픈소스는 ‘공짜’일지 몰라도 ‘마음대로’ 써도 된다는 뜻은 아니기 때문입니다. 그 규칙을 정하는 것이 바로 ‘라이선스’입니다.
오픈소스, 공짜 뷔페가 아니다?
오픈소스를 흔히 공짜 뷔페에 비유하곤 합니다. 누구나 자유롭게 이용할 수 있다는 점에서 그렇죠. 하지만 아무리 공짜 뷔페라도 지켜야 할 규칙은 있습니다. 음식을 외부로 가져가면 안 된다거나, 사용한 접시는 정해진 곳에 반납해야 하는 것처럼 말입니다. 오픈소스 라이선스는 바로 이 뷔페의 ‘이용 규칙’과 같습니다.
이 규칙을 무시하고 코드를 가져다 쓰면, 단순한 비매너를 넘어 법적 분쟁으로까지 번질 수 있습니다. 특히 스타트업이나 기업 입장에서는 서비스의 존폐를 가를 만큼 치명적인 리스크가 되기도 합니다. 소스 코드를 전부 공개해야 하거나, 거액의 손해배상을 해야 하는 상황에 처할 수 있는 셈이죠. 그래서 개발자든 기획자든, 우리 서비스를 만드는 데 어떤 오픈소스가 들어가는지, 그리고 그 라이선스가 무엇을 의미하는지 반드시 알아야 합니다.
가장 많이 쓰는 라이선스 3대장: MIT, GPL, 아파치
세상에는 수많은 오픈소스 라이선스가 있지만, 실제로는 몇 가지가 시장을 지배하고 있습니다. 그중에서도 가장 대표적인 3인방이 바로 MIT, GPL, 아파치(Apache) 라이선스입니다. 이 세 가지만 제대로 이해해도 웬만한 라이선스 이슈는 피해갈 수 있습니다. 이들의 가장 큰 차이는 ‘자유’에 대한 관점입니다.
- MIT: 내 코드를 가져다 뭘 하든 상관없으니, 출처만 남겨줘. (가장 허용적)
- GPL: 내 코드로 만든 너의 코드도 우리처럼 모두에게 공개해. (강력한 공유 의무)
- 아파치: MIT처럼 자유롭지만, 특허 관련해서는 선을 넘지 마. (실용성과 법적 안정성)
각각의 라이선스가 어떤 특징을 가졌는지 구체적으로 살펴보겠습니다.
MIT 라이선스: 가장 자유로운 ‘허용적’ 라이선스
MIT 라이선스는 가장 단순하고 제약이 적어 많은 개발자들이 선호합니다. React, .NET Core, VS Code 등 우리가 이름만 대면 알 만한 수많은 프로젝트가 이 라이선스를 따릅니다. 핵심은 ‘최소한의 요구사항’입니다.
주요 의무사항:
- 이 소프트웨어를 상업적으로 이용하거나, 수정하고, 복제해서 배포하는 모든 행위가 가능하다.
- 단 하나의 조건: 원본 코드의 저작권 표시와 MIT 라이선스 원문을 최종 결과물에 포함해야 한다.
MIT 라이선스가 적용된 코드는 내 상용 소프트웨어에 넣고 소스 코드를 공개하지 않아도 아무런 문제가 없습니다. 그래서 기업들이 가장 선호하는 라이선스 중 하나입니다. 자유도가 매우 높아 다른 라이선스와의 충돌 문제도 거의 없습니다.
GPL 라이선스: ‘카피레프트’의 대표주자
GPL(GNU General Public License)은 MIT와 정반대 철학을 가집니다. 바로 ‘카피레프트(Copyleft)’라는 강력한 개념 때문입니다. 저작권을 의미하는 ‘카피라이트(Copyright)’를 뒤집은 용어로, 만들어진 저작물이 계속해서 자유롭게 공유되어야 한다는 사상을 담고 있습니다.
주요 의무사항:
- GPL 코드를 사용해 만든 2차 저작물(프로그램)은 반드시 동일한 GPL 라이선스로 소스 코드를 공개해야 한다.
이것이 왜 중요할까요? 만약 회사가 만드는 상용 소프트웨어에 실수로 GPL 코드를 단 한 줄이라도 포함했다면, 그 회사는 전체 소프트웨어의 소스 코드를 GPL에 따라 전부 공개해야 할 의무가 생길 수 있습니다. 리눅스 커널, Git, 워드프레스 등이 대표적인 GPL 기반 프로젝트입니다. 강력한 공유 정신을 지키기 위한 장치이지만, 상용 소프트웨어를 만드는 기업에게는 가장 피해야 할 라이선스로 꼽히는 이유이기도 합니다. (참고로, 라이브러리 형태로 ‘연결’해서 사용하는 경우를 위해 제한을 완화한 LGPL이라는 버전도 있습니다.)
아파치 라이선스 2.0: MIT와 GPL 사이의 균형
아파치 라이선스는 MIT의 자유로움과 GPL의 법적 장치를 절묘하게 결합한 형태입니다. 안드로이드 운영체제, 쿠버네티스, 스위프트(Swift) 등 대규모 프로젝트에서 널리 사용됩니다.
주요 의무사항:
- MIT처럼 상업적 이용, 수정, 배포가 자유롭고 소스 코드 공개 의무가 없다.
- 원본 저작권과 라이선스 정보를 명시해야 한다.
- 결정적 차이점: 명시적인 특허권 관련 조항이 있다. 아파치 라이선스 코드를 제공한 기여자는 자신이 기여한 부분에 대한 특허 사용권을 사용자에게 무료로 부여한다. 반대로, 사용자는 이 코드를 사용하면서 기여자에게 특허 소송을 걸 수 없다.
이 특허 조항은 기업 간의 잠재적인 특허 분쟁을 예방하는 안전장치 역할을 합니다. 그래서 구글이나 애플 같은 대기업이 주도하는 오픈소스 프로젝트에서 아파치 라이선스를 선호하는 경향이 있습니다.
라이선스 위반, ‘몰랐어요’는 통하지 않는다
최근에도 한 스타트업이 고객사의 오픈소스 코드를 라이선스 규정 위반 소지가 있게 가져다 썼다는 의혹이 제기되어 테크 업계 뉴스에 오르내렸습니다. 이런 사건이 터지면 회사는 세 가지 큰 타격을 입습니다.
- 법적 분쟁: 라이선스 원 소유자는 소스 코드 공개를 요구하거나 손해배상 청구 소송을 제기할 수 있습니다. 법정 다툼은 시간과 비용 소모가 막대합니다.
- 기업 평판 추락: ‘남의 코드를 훔치는 회사’라는 낙인은 개발자 커뮤니티와 투자자들에게 치명적입니다. 신뢰를 잃으면 좋은 인재를 영입하기도, 다음 투자를 유치하기도 어려워집니다.
- 프로젝트 중단 또는 폐기: 문제가 된 코드를 식별하고 모두 제거해야 할 수 있습니다. 만약 서비스의 핵심 기능에 깊숙이 얽혀 있다면, 사실상 프로젝트를 처음부터 다시 만들어야 하는 최악의 상황으로 이어질 수도 있습니다.
결국 라이선스 관리는 단순한 개발 실무가 아니라, 회사의 미래를 좌우하는 핵심적인 리스크 관리 활동인 셈입니다.
내 프로젝트에 맞는 라이선스 고르기 (체크리스트)
그렇다면 내가 직접 오픈소스 프로젝트를 공개하거나, 우리 회사 제품에 어떤 라이선스의 코드를 써야 할지 어떻게 결정할 수 있을까요? 아래 질문들에 답해보면 방향을 잡는 데 도움이 됩니다.
1. 내 코드를 다른 사람이 상업적으로 쓰는 걸 허용할 생각인가?
대부분의 경우 ‘Yes’일 것입니다. 이 경우 MIT나 아파치 라이선스가 적합합니다.
2. 내 코드를 사용한 파생 프로젝트도 반드시 소스 코드를 공개하게 만들고 싶은가?
오픈소스 정신의 확산이 중요하다면 ‘Yes’, GPL이 답입니다. 상업적 활용도를 높이고 싶다면 ‘No’, MIT나 아파치를 선택해야 합니다.
3. 특허 문제로부터 프로젝트 참여자와 사용자를 보호하고 싶은가?
프로젝트 규모가 크고 여러 기업이 참여할 가능성이 있다면, 특허 조항이 명시된 아파치 라이선스가 현명한 선택지입니다.
오픈소스는 개발 생태계를 풍요롭게 만드는 엄청난 자산입니다. 하지만 그 이면에 있는 ‘규칙과 책임’을 정확히 이해할 때 비로소 그 가치를 안전하고 제대로 누릴 수 있습니다.
출처: TechCrunch
테크가이드팀
Home-In-One 테크가이드팀은 IT 기기 비교, 소프트웨어 추천, 트러블슈팅 가이드 등 실용적인 기술 콘텐츠를 제작합니다. 초보자도 쉽게 따라할 수 있는 단계별 가이드를 지향합니다.