밤새 짠 코드가 경쟁사 서비스에 버젓이 들어가 있는 걸 발견했다. 그것도 내가 오픈소스로 공개한 코드라서 법적으로 문제없다는 주장까지 따라온다면. 이런 일이 실제로 벌어진다. 오픈소스를 ‘공짜’와 ‘자유’를 동의어로 착각하는 순간, 이런 상황이 생긴다. 그 경계를 정하는 게 라이선스다.
오픈소스는 공짜 뷔페가 아니다
공짜 뷔페라도 접시는 반납해야 하고, 음식을 외부로 싸들고 나가면 안 된다. 오픈소스도 마찬가지다. 누구나 쓸 수 있지만, 조건이 붙는다.
이 조건을 무시하면 단순한 에티켓 문제로 끝나지 않는다. 소스 코드 전체를 강제 공개해야 하거나, 거액의 손해배상 청구를 받는 상황이 온다. 스타트업 입장에서는 서비스 존폐를 건드리는 수준의 리스크다. 개발자든 기획자든, 우리 서비스에 어떤 오픈소스가 들어가 있고 그 라이선스가 뭘 허용하는지 모르면 곤란하다. 법정 다툼은 ‘몰랐다’는 말을 들어주지 않는다.
MIT, GPL, 아파치 — 3대 라이선스
오픈소스 라이선스 종류는 수십 가지지만, 실제로 현장에서 자주 마주치는 건 세 개다. MIT, GPL, 아파치(Apache) 2.0. 이 셋만 제대로 이해해도 웬만한 라이선스 이슈는 걸러낼 수 있다. 차이의 핵심은 딱 하나, ‘자유를 어디까지 허용하느냐’다.
- MIT: 출처만 남겨줘, 나머진 알아서 써. (가장 허용적)
- GPL: 내 코드로 만든 건 너도 똑같이 공개해야 해. (강력한 공유 의무)
- 아파치 2.0: MIT처럼 자유롭되, 특허 건드리는 건 안 돼. (실용성 + 법적 안전망)
각각 뭐가 다른지 뜯어보자.
MIT 라이선스: 조건이 딱 하나
React, VS Code, .NET Core. 이름만 대면 아는 프로젝트들이 MIT 라이선스를 쓴다. 그도 그럴 것이, 조건이 단 하나다. 원본 저작권 표시와 MIT 라이선스 원문을 결과물에 포함할 것. 그게 전부다.
- 상업적 이용, 수정, 복제, 배포 모두 자유.
- 소스 코드를 공개하지 않아도 된다.
- 다른 라이선스와 충돌할 일도 거의 없다.
기업들이 MIT를 제일 좋아하는 이유가 여기 있다. 갖다 쓰고, 수정하고, 상품으로 팔아도 된다. 저작권 고지 하나만 넣으면 그만이다. 자유도가 높은 만큼 다른 라이선스와의 호환성도 넓어서 복잡한 의존성 트리를 관리할 때도 상대적으로 편하다.
GPL 라이선스: 카피레프트의 칼날
GPL(GNU General Public License)은 MIT와 철학이 정반대다. 핵심 개념은 카피레프트(Copyleft). 저작권을 뜻하는 Copyright를 뒤집은 말로, 자유롭게 공유된 코드는 계속해서 자유롭게 공유되어야 한다는 사상이 담겨 있다.
- GPL 코드를 한 줄이라도 포함한 파생 프로그램은 반드시 동일한 GPL 라이선스로 소스 코드 전체를 공개해야 한다.
이게 왜 무섭냐면, 상용 소프트웨어에 GPL 코드가 단 한 줄 섞여 들어갔다가 전체 소스를 공개해야 할 수 있기 때문이다. 리눅스 커널, Git, 워드프레스가 GPL 기반이다. 오픈소스 정신을 가장 강력하게 지키는 장치지만, 기업 코드베이스에서는 가장 조심해야 할 라이선스다. 이건 좀 과하다 싶을 정도로 강제성이 세다. 참고로, 라이브러리 형태로 ‘연결’해서 쓰는 경우를 위해 제한을 완화한 LGPL이라는 버전도 있다. 라이브러리를 동적 링크 방식으로만 쓴다면 LGPL 쪽이 숨통이 트인다.
아파치 라이선스 2.0: 특허까지 건드린다
안드로이드, 쿠버네티스, Swift. 대규모 기업 주도 오픈소스 프로젝트가 아파치 2.0을 선택하는 데는 이유가 있다. MIT처럼 자유롭게 쓸 수 있으면서, 특허 문제를 명시적으로 다루기 때문이다.
- 상업적 이용, 수정, 배포 자유. 소스 코드 공개 의무 없음.
- 원본 저작권 및 라이선스 정보 명시 필요.
- 결정적 차이: 명시적 특허 조항이 들어간다. 기여자는 자신이 기여한 부분의 특허 사용권을 사용자에게 무료로 부여하고, 사용자는 기여자에게 특허 소송을 제기할 수 없다.
이 특허 조항이 구글·애플 같은 대기업이 아파치 2.0을 선호하는 이유다. 잠재적 특허 분쟁을 사전에 차단하는 안전장치 역할을 한다. MIT는 특허 관련 조항이 없어서, 규모가 커지면 법적 불확실성이 남는다. 그 지점에서 아파치 2.0이 더 안정적이다.
라이선스 위반, ‘몰랐다’는 말은 안 통한다
얼마 전 한 스타트업이 고객사 오픈소스 코드를 라이선스 규정에 어긋나게 가져다 썼다는 의혹이 테크 업계 뉴스에 올랐다. 이런 사건이 터지면 세 가지 타격이 동시에 온다.
- 법적 분쟁: 라이선스 소유자는 소스 코드 공개 요구나 손해배상 청구가 가능하다. 법정 싸움은 시간과 비용 모두 소모가 크다.
- 평판 훼손: ‘남의 코드 훔친 회사’ 낙인은 개발자 커뮤니티와 투자자 모두에게 치명적이다. 좋은 인재 영입도, 다음 투자 유치도 어려워진다.
- 프로젝트 중단: 문제 코드를 전부 식별하고 걷어내야 한다. 서비스 핵심 기능에 깊숙이 엮여 있으면 사실상 처음부터 다시 짜는 최악의 시나리오가 펼쳐진다.
결국 라이선스 관리는 개발 실무 중 하나가 아니다. 회사의 생존을 좌우하는 리스크 관리다. 나중에 투자받거나 M&A 협상 테이블에 앉았을 때, 라이선스 감사(audit)가 발목을 잡는 경우가 생각보다 많다.
어떤 라이선스를 골라야 할까
직접 오픈소스를 공개하거나, 제품에 어떤 라이선스의 코드를 써야 할지 모르겠다면 이 세 가지 질문만 던져보면 된다.
1. 다른 사람이 상업적으로 써도 괜찮은가?
대부분 괜찮다면 MIT나 아파치가 맞다. 조건을 최소화해서 사용자 저변을 넓히는 전략이다.
2. 내 코드를 쓴 파생 프로젝트도 반드시 공개하게 만들고 싶은가?
오픈소스 확산이 목표라면 GPL이 답이다. 상업적 활용도를 높이고 싶다면 MIT나 아파치를 선택해야 한다. 솔직히 여기서 갈린다. GPL을 택하는 순간, 기업 고객이 채택하기 어려워진다는 걸 감안해야 한다.
3. 여러 기업이 동시에 참여하는 프로젝트인가?
규모가 크고 특허 리스크가 있다면 아파치 2.0이 현명한 선택이다. 기여자 간의 잠재적 분쟁을 라이선스 텍스트 자체로 예방한다.
오픈소스는 개발 생태계를 키우는 진짜 자산이다. 단, 뒤에 붙은 규칙을 제대로 알고 써야 그 가치를 온전히 누릴 수 있다. 라이선스 하나 허술하게 관리했다가 서비스 전체가 흔들리는 일, 남 얘기가 아닐 수 있다.
출처: TechCrunch
테크가이드팀
Home-In-One 테크가이드팀은 IT 기기 비교, 소프트웨어 추천, 트러블슈팅 가이드 등 실용적인 기술 콘텐츠를 제작합니다. 초보자도 쉽게 따라할 수 있는 단계별 가이드를 지향합니다.