누구나 자유롭게 코드를 보고 수정할 수 있는 오픈소스는 현대 소프트웨어 개발의 근간입니다. 하지만 '무료'라고 해서 '내 마음대로' 써도 된다는 뜻은 결코 아닙니다. 오픈소스에는 저작권자가 명시한 엄격한 '라이선스(License)'가 존재하며, 이를 어길 경우 법적 소송이나 프로젝트 전체 코드 공개라는 치명적인 결과를 초래할 수 있습니다.
개발자와 기업 모두에게 오픈소스 라이선스 이해는 필수적인 생존 지식입니다. 복잡하고 딱딱한 법률 용어 대신, 실무에서 반드시 알아야 할 핵심 라이선스들의 특징과 주의사항을 알기 쉽게 정리해 드립니다. 이 가이드만 숙지해도 저작권 위반이라는 위험한 함정을 안전하게 피할 수 있습니다.
오픈소스 라이선스란 무엇인가? 라이선스는 저작권자가 사용자에게 해당 소프트웨어를 사용, 수정, 배포할 수 있는 권한을 부여하면서 지켜야 할 조건을 명시한 계약서입니다. 저작권 고지 의무, 소스 코드 공개 여부, 특허권 행사 제한 등 다양한 조항들이 포함되어 있습니다.
가장 너그러운 허용형: MIT 라이선스 가장 널리 사용되는 라이선스 중 하나로, 조건이 매우 단순합니다. 저작권 표시와 라이선스 문구만 포함한다면 상업적 이용, 수정, 배포가 자유로우며 2차 저작물의 소스 코드를 공개할 의무도 없습니다. 스타트업이나 개인 프로젝트에서 가장 선호되는 방식입니다.
강력한 카피레프트의 대명사: GPL GNU 일반 공중 라이선스(GPL)는 매우 엄격합니다. GPL 코드를 조금이라도 사용하거나 연결(Link)하여 만든 프로그램은 무조건 GPL로 배포해야 하며, 소스 코드를 대중에게 공개해야 합니다. 기업의 핵심 영업 비밀이 담긴 소프트웨어에 GPL 라이선스를 사용할 때는 극도로 주의해야 합니다.
Apache 라이선스 2.0의 특징 MIT와 유사하게 자유도가 높지만, 특허권에 대한 조항이 명확하게 명시되어 있습니다. 이 라이선스가 적용된 소프트웨어를 사용하다가 나중에 저작권자에게 특허 침해 소송을 당하는 일을 방지해주는 '보호막' 역할이 있어, 대기업이나 대규모 프로젝트에서 선호합니다.
약한 카피레프트: LGPL GPL의 엄격함을 다소 완화한 라이선스입니다. 주로 라이브러리에 적용되며, 해당 라이브러리를 단순히 연결하여 사용하기만 한다면 전체 소스 코드를 공개할 의무는 없습니다. 다만 라이브러리 자체를 수정했을 경우에는 수정한 부분에 한해 코드를 공개해야 합니다.
BSD 라이선스의 심플함 MIT와 거의 흡사한 구조를 가졌으며, 저작권 표시만 잘 지키면 제약이 거의 없습니다. 구버전 BSD에는 광고 시 저작권자를 명시해야 하는 독소 조항이 있었으나, 최근 쓰이는 3-Clause BSD 등은 매우 자유로운 배포를 보장합니다.
배포(Distribution)의 의미를 정확히 파악하라 대부분의 라이선스 의무는 소프트웨어를 외부에 '배포'할 때 발생합니다. 사내에서 내부망으로만 사용하거나 개인적인 연구 목적으로 쓰는 경우에는 라이선스 조항에서 비교적 자유롭습니다. 하지만 고객에게 납품하거나 클라우드 서비스를 제공할 때는 이야기가 달라집니다.
AGPL: 클라우드 시대의 새로운 복병 GPL의 빈틈을 노린 라이선스입니다. 전통적인 의미의 배포(파일 전달)가 없더라도 네트워크를 통해 서비스를 제공하는 것만으로도 소스 코드 공개 의무가 발생합니다. SaaS 기반 서비스를 개발 중이라면 사용하려는 라이브러리에 AGPL이 포함되어 있는지 반드시 확인해야 합니다.
라이선스 충돌 문제 주의하기 한 프로젝트 내에 서로 다른 라이선스를 가진 오픈소스들을 섞어 쓸 때 발생합니다. 예를 들어 GPL 코드와 상충하는 특정 라이선스를 함께 사용하면 법적으로 배포 자체가 불가능해질 수 있습니다. 의존성 관리 도구를 활용해 라이선스 현황을 정기적으로 점검해야 합니다.
오픈소스 고지문(Open Source Notice) 작성법 사용한 모든 오픈소스의 목록과 각각의 라이선스 전문을 문서화하여 제품의 '설정'이나 '정보' 란에 포함시켜야 합니다. 이는 가장 기본적이면서도 중요한 의무 사항으로, 자동화 도구를 사용하면 수많은 오픈소스의 라이선스 정보를 누락 없이 관리할 수 있습니다.
오픈소스는 공유의 정신을 바탕으로 하지만, 그 권리는 법적으로 보호받습니다. 라이선스를 단순히 '지켜야 할 규제'로 보기보다 오픈소스 생태계를 건강하게 유지하는 '약속'으로 받아들여야 합니다. 개발 시작 단계부터 라이선스 체크리스트를 만들어 준수한다면, 기술적 완성도만큼이나 법적으로도 안전한 최고의 소프트웨어를 만들 수 있을 것입니다.
0 댓글