오픈 소스 라이센스는 무엇을 의미하나요?

오픈 소스 라이선스 의미: MIT 라이선스, 전체 오픈 소스 프로젝트의 44% 차지

오픈 소스 라이선스 의미를 정확히 아는 것은 현대 소프트웨어 개발의 기본이다. 소프트웨어의 97% 이상이 오픈 소스 구성 요소로 이루어질 만큼 중요하며, 라이선스별 조건을 이해하는 것이 상업적 이용과 법적 리스크 관리에 필수적이다. 따라서 개발자와 기업 모두가 라이선스 조건을 숙지해야 한다. 상세 정보를 알아본다.

오픈 소스 라이선스의 본질적 의미와 필요성

오픈 소스 라이선스란 소스 코드가 공개된 소프트웨어를 누구나 자유롭게 사용, 수정, 배포할 수 있도록 허용하는 법적 약속이자 규칙입니다. 흔히 오픈 소스를 누구나 마음대로 가져다 써도 되는 무법지대로 오해하곤 하지만, 실제로는 저작권자가 정해놓은 일정한 조건 하에서만 사용이 허가되는 엄격한 계약의 형태를 띠고 있습니다.

현대 소프트웨어의 97% 이상이 오픈 소스 구성 요소를 포함하고 있습니다.^[1] 이 숫자가 말해주는 오픈 소스 라이선스 의미는 명확합니다. 우리가 사용하는 거의 모든 서비스가 타인의 코드를 기반으로 구축되었다는 뜻이죠. 하지만 많은 개발자가 간과하는 독소 조항이 하나 있습니다. 잘못된 라이선스 선택 하나가 기업 전체의 코드를 강제로 공개하게 만들 수도 있는데, 이에 대해서는 뒤에서 자세히 다루겠습니다.

저도 처음 개발을 시작했을 때는 라이선스가 단순히 형식적인 문서인 줄로만 알았습니다. 소스 코드가 공개되어 있으니 당연히 무료이고, 제약 없이 쓸 수 있다고 믿었죠. 하지만 실제로는 기업의 생존이 걸린 문제였습니다. 솔직히 말씀드리면, 저도 예전에는 라이선스 파일을 읽어보지도 않고 코드를 복사해서 쓴 적이 있습니다. 무지해서 용감했던 시절이죠. 결국 나중에 보안 점검 과정에서 해당 코드를 전부 걷어내느라 며칠 밤을 새운 기억이 납니다.

라이선스가 없으면 어떻게 되나요?

가장 흔한 오해 중 하나는 라이선스 파일이 없는 공개 저장소의 코드는 마음대로 써도 된다는 생각입니다. 이는 아주 위험한 착각입니다. 저작권법에 따르면 명시적인 라이선스가 없는 경우, 해당 코드에 대한 모든 권리는 저작권자에게 귀속되며 제3자는 이를 복제하거나 수정할 권한이 전혀 없습니다.

라이선스가 없는 코드를 가져다 쓰는 행위는 타인의 물건을 허락 없이 빌려가는 것과 같습니다. 법적 분쟁이 발생하면 사용자가 패소할 확률이 매우 높습니다. 실제로 오픈 소스 라이선스 미준수로 인한 법적 합의 비용은 중소 규모 스타트업의 경우 상당한 금액이 될 수 있습니다.^[2] 기업 운영의 큰 리스크가 되는 셈이죠. 따라서 안전하게 코드를 사용하려면 반드시 명시된 라이선스 조건을 확인해야 합니다.

잠깐만요. 오픈 소스 라이선스 종류가 수천 개라면 어떻게 다 공부해야 할까요? 다행히도 우리가 실무에서 마주치는 라이선스는 크게 두 가지 줄기로 나뉩니다. 하나는 허용형이고, 다른 하나는 카피레프트입니다.

허용형 라이선스와 카피레프트의 차이

오픈 소스 라이선스는 권리 부여의 정도에 따라 성격이 완전히 달라집니다. 기업들이 가장 선호하는 방식은 제약이 거의 없는 허용형 라이선스입니다. 반면, 오픈 소스 정신을 극단적으로 계승하려는 쪽은 카피레프트 방식을 사용합니다.

허용형 라이선스 (Permissive License)

허용형 라이선스의 대표 주자는 MIT와 Apache 2.0입니다. 이들은 이름 그대로 사용자의 자유를 최대한 보장합니다. 저작권 표시만 제대로 한다면 해당 코드를 수정해서 상용 소프트웨어를 만들어 팔아도 소스 코드를 공개할 의무가 없습니다. GitHub의 라이선스 적용 프로젝트 중 약 44%가 MIT 라이선스를 선택하고 있을 정도로 압도적인 인기를 누리고 있습니다. ^[3]

카피레프트 라이선스 (Copyleft License)

카피레프트의 정점에는 GPL(General Public License)이 있습니다. 이 라이선스는 강한 전염성을 가지고 있습니다. GPL 코드를 사용해 새로운 프로그램을 만들었다면, 그 결과물 또한 반드시 GPL 라이선스로 공개해야 합니다. 즉, 내 회사의 독자적인 기술력을 담은 소스 코드까지 세상에 무료로 공개해야 할 수도 있다는 뜻입니다. 기업 입장에서는 매우 까다로운 조건입니다.

여기서 핵심은 이겁니다. 내 프로젝트가 상업적인 가치가 크고 소스 코드를 지켜야 한다면 GPL은 피해야 합니다. 하지만 리눅스 커널처럼 전 세계 개발자가 함께 발전시켜야 하는 공공의 자산이라면 GPL은 가장 강력한 보호막이 됩니다.

상업적 이용 시 꼭 확인해야 할 3가지 의무

오픈 소스를 제품에 포함하여 배포할 때, 여러분이 반드시 지켜야 할 의무 사항들이 있습니다. 이를 무시하면 나중에 법적 청구서나 오픈 소스 커뮤니티의 비난을 받게 될 수 있습니다.

첫째, 고지 의무입니다. 어떤 오픈 소스를 썼고 원작자가 누구인지 명시해야 합니다. 보통 Open Source Notice라는 메뉴를 통해 앱이나 웹사이트 하단에 표시합니다. 둘째, 수정 사항 공개 여부입니다. 사용 중인 라이선스가 수정된 코드의 공개를 요구하는지 반드시 확인해야 합니다. 셋째, 특허권 관련 조항입니다. Apache 2.0 같은 라이선스는 사용자가 해당 소프트웨어와 관련된 특허 소송을 제기할 경우 라이선스 권리를 박탈하는 조항을 포함하고 있습니다.

단 한 번도 오픈 소스 라이선스 위반 사례가 없었던 기업은 드뭅니다. 사실 완벽하기가 매우 어렵죠. 하지만 위반 사실을 인지했을 때 얼마나 빠르게 조치하느냐가 실력입니다. 무조건 숨기는 것이 능사는 아닙니다.

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

개발자가 실무에서 가장 자주 마주치는 3대 라이선스의 주요 특징을 한눈에 비교해 보세요.

MIT 라이선스 (가장 추천)

• 제한 없이 가능하며 상용 제품 판매 시 가장 선호됨

• 소프트웨어 내 저작권 표시 및 라이선스 고지만 하면 됨

• 수정하거나 배포해도 소스 코드를 공개할 필요가 없음

Apache 2.0

• 사용자가 특허 소송을 제기할 경우 라이선스가 즉시 종료되는 보호 장치 포함

• 특허 문제가 중요한 대기업 간 프로젝트에서 선호됨

• 소스 코드를 공개할 의무가 없으나 수정 사항에 대한 고지가 필요함

GPL 3.0 (주의 필요)

• 사내에서만 쓰는 경우 괜찮으나 외부 배포 시 모든 의무 발생

• 오픈 소스의 생태계 유지를 위한 강력한 의무 중심 라이선스

• 해당 코드를 사용한 전체 프로그램의 소스 코드를 반드시 공개해야 함

스타트업의 라이선스 실수와 투자 유치 위기

서울 소재의 한 IT 스타트업 개발자 김민수 씨는 마감 기한에 쫓겨 이미지 처리 기능을 구현하던 중, GitHub에서 성능이 뛰어난 오픈 소스 모듈을 발견해 프로젝트에 통합했습니다. 코드는 완벽하게 작동했고 기능은 성공적으로 런칭되었습니다.

문제는 시리즈 A 투자 유치를 위한 실사 과정에서 발생했습니다. 투자사 측 법무 팀이 코드 스캐닝 도구를 돌리자, 김 씨가 사용한 모듈이 GPL 3.0 라이선스라는 사실이 밝혀졌습니다. 이는 회사의 유료 서비스 코드 전체를 공개해야 한다는 뜻이었습니다.

회사는 발칵 뒤집혔고 투자가 무산될 위기에 처했습니다. 김 씨는 며칠 밤을 새우며 GPL 모듈을 제거하고 MIT 라이선스의 다른 대안으로 교체했습니다. 이 과정에서 기존 로직을 상당 부분 재작성해야 하는 고통을 겪었습니다.

결국 보름간의 긴급 작업 끝에 코드를 정화했고 투자를 무사히 마칠 수 있었습니다. 이후 이 회사는 모든 외부 라이브러리 도입 시 라이선스 승인을 거치는 프로세스를 도입했으며, 김 씨는 '무료라고 다 같은 무료가 아니다'라는 뼈아픈 교훈을 얻었습니다.