오픈소스 라이선스 확인법, MIT·GPL·Apache 차이 정리

# 오픈소스 라이선스 확인법, MIT·GPL·Apache 차이 정리

개발자라면 배포 전 반드시 확인해야 할 라이선스 실무 가이드

---

오픈소스 라이선스를 제대로 확인하지 않고 코드를 가져다 쓰면 나중에 큰 문제가 될 수 있습니다. 2026년 9월 현재, 대부분의 서비스와 제품이 크고 작은 오픈소스 코드를 품고 있는 시대입니다. 프론트엔드 프레임워크부터 백엔드 라이브러리, 서버 인프라 도구까지 오픈소스 없이 개발하는 경우를 찾기가 오히려 어려울 정도입니다. 그런데 정작 "이 라이브러리 써도 되나요?", "라이선스 고지는 어떻게 하나요?", "회사 서비스에 GPL 코드 넣어도 되나요?" 같은 질문에 명확히 답할 수 있는 사람은 생각보다 많지 않습니다.

이 글에서는 개발자, 기획자, 서비스 운영자 누구나 실무에서 바로 써먹을 수 있도록 MIT, GPL, Apache 2.0, AGPL 네 가지 대표 라이선스의 실제 조문 내용과 차이를 정리합니다. 단순히 "카피레프트냐 아니냐"를 외우는 수준이 아니라, 실제로 배포할 때 어떤 의무가 생기는지, 서로 다른 라이선스를 섞어 쓸 때 어떤 조합이 가능한지, 실제 소송까지 갔던 사례는 무엇인지까지 구체적으로 다룹니다. 글을 끝까지 읽고 나면 프로젝트에 새로운 라이브러리를 추가하기 전에 라이선스 파일을 열어 스스로 판단할 수 있는 기준이 생길 것입니다. 😊

---

준비물·전제조건

오픈소스 라이선스를 확인하려면 특별한 도구보다 정확한 개념 이해가 먼저 필요합니다. 법률 전문가가 아니어도 라이선스 원문을 읽고 핵심 조건을 파악하는 정도는 개발자 스스로 충분히 할 수 있는 영역입니다. 다만 아래 세 가지는 미리 준비해두는 것이 좋습니다.

먼저, 라이선스 원문을 확인할 수 있는 공식 출처를 알아두어야 합니다. OSI(Open Source Initiative) 홈페이지, GNU.org의 라이선스 목록, Apache.org의 라이선스 페이지가 대표적입니다. 개인 블로그나 요약 정리 글은 참고용으로만 보고, 최종 판단은 반드시 원문 대조로 마무리하는 습관을 들이는 것이 중요합니다.

다음으로, 프로젝트에서 사용 중인 오픈소스 목록을 정리하는 습관이 필요합니다. package.json, requirements.txt, go.mod 같은 의존성 파일을 열어보면 사용 중인 라이브러리 목록이 나옵니다. 각 라이브러리 저장소의 LICENSE 파일을 하나씩 확인하는 작업이 번거롭게 느껴질 수 있지만, 서비스 출시 전 단 한 번만 꼼꼼히 해두면 이후에는 신규 추가분만 확인하면 됩니다.

마지막으로, 자사 서비스의 배포 형태를 먼저 정의해두어야 합니다. 코드를 그대로 배포하는지, 컴파일된 바이너리만 배포하는지, 아니면 서버에서만 실행하고 사용자에게는 웹 화면만 보여주는 SaaS 형태인지에 따라 같은 라이선스라도 적용되는 의무가 완전히 달라집니다. 특히 AGPL은 이 구분이 핵심이므로 미리 정리해두면 이후 단계가 훨씬 수월해집니다.

---

Step 1: MIT 라이선스 원문 구조와 상업적 이용 조건 이해하기

MIT 라이선스는 오픈소스 라이선스 중 가장 단순하고 자유로운 허용형(permissive) 라이선스로, 조건이 사실상 하나뿐입니다. MIT 라이선스 원문은 "소프트웨어를 제한 없이 다룰(use, copy, modify, merge, publish, distribute, sublicense, sell) 권리를 무상으로 허락한다"고 명시하고 있습니다. 여기서 눈여겨봐야 할 단어가 sell, 즉 판매까지 포함된다는 점입니다. MIT 라이선스가 적용된 코드는 상업적 이용 오픈소스의 대표 사례로 꼽히는 이유가 바로 여기에 있습니다.

그런데 이 자유에는 딱 하나의 조건이 붙습니다. 바로 "위 저작권 표시와 이 허가 표시(라이선스 전문)를 모든 복제물 또는 중요 부분에 포함"해야 한다는 것입니다. 여기서 실무자들이 자주 놓치는 부분이 있습니다. 단순히 "이 코드는 MIT 라이선스입니다"라는 한 줄만 적어두는 것으로는 부족하다는 점입니다. 원문 조건은 저작권 표시(copyright notice)와 라이선스 허가 전문(permission notice) 둘 다를 포함하라고 규정하고 있습니다. 즉 원저작자 이름과 연도가 담긴 저작권 문구, 그리고 MIT 라이선스 전체 텍스트를 함께 배포물에 넣어야 조건을 충족한 것으로 볼 수 있습니다.

이 조건만 지키면 MIT 라이선스가 적용된 오픈소스 코드를 가져다 독점 소프트웨어에 넣어 유료로 판매하는 것도 가능합니다. 이 때문에 스타트업이나 상용 제품을 개발하는 팀에서 MIT 라이선스 라이브러리를 선호하는 경향이 있습니다. 다만 주의할 점은, "라이선스 고지 의무가 가볍다"는 것이지 "의무가 없다"는 뜻은 아니라는 점입니다. 실제로 많은 앱이나 서비스의 설정 화면 하단에 있는 "오픈소스 라이선스" 메뉴를 눌러보면 수십, 수백 개의 라이브러리 저작권 문구가 나열되어 있는데, 이것이 바로 MIT 계열 라이선스의 고지 의무를 이행한 결과물입니다.

실무에서 확인하는 방법은 간단합니다. 라이브러리 저장소에서 LICENSE 또는 LICENSE.md 파일을 열어 첫 줄에 "MIT License"라는 문구와 Copyright 표기가 있는지 확인하면 됩니다. 이후 자신의 프로젝트를 배포할 때는 사용한 모든 MIT 라이브러리의 저작권 문구와 라이선스 전문을 모아 NOTICE 파일이나 별도 고지 페이지로 정리해두는 것이 안전합니다.

---

Step 2: Apache 2.0 라이선스의 특허 조항 확인하기

Apache 2.0 라이선스가 MIT 라이선스와 실무에서 가장 크게 갈리는 지점은 특허 조항의 유무입니다. 겉보기에 두 라이선스는 모두 허용형(permissive) 라이선스로 분류되고, 소스 공개 의무 없이 상업적 이용이 가능하다는 점에서 비슷해 보입니다. 하지만 특허와 관련된 부분에서는 구조가 완전히 다릅니다.

Apache 2.0 라이선스는 제정 목표 자체에 "기여자 자신의 특허를 필연적으로 침해하는 기여에 대해 특허 라이선스를 요구"하는 내용이 포함되어 있습니다. 쉽게 풀어 설명하면, 어떤 개발자가 자신이 특허를 보유한 기술을 Apache 2.0 프로젝트에 기여했다면, 그 기여자는 해당 코드를 사용하는 모든 사람에게 관련 특허에 대한 라이선스도 함께 부여한 것으로 간주됩니다. 즉 코드만 받는 게 아니라 그 코드에 얽힌 특허 사용권까지 명문화되어 함께 따라온다는 뜻입니다.

반면 MIT 라이선스 원문에는 특허 관련 문구가 전혀 등장하지 않습니다. 이는 MIT 라이선스가 나쁘다는 의미가 아니라, 특허 이슈에 대한 명시적 보호 장치가 없다는 뜻입니다. 대형 프로젝트, 특히 여러 기업이 공동으로 기여하는 프로젝트일수록 특허 분쟁 리스크가 커질 수 있는데, 이런 환경에서 Apache 2.0의 특허 조항이 실질적인 안전장치 역할을 하게 됩니다. "특허 소송 위험이 큰 대형 프로젝트가 Apache 2.0을 택하는 경향이 있다"는 설명은 공식 규정으로 못박힌 내용은 아니지만, 실제로 특허 보호를 이유로 MIT에서 Apache 2.0으로 라이선스를 전환한 프로젝트 사례들이 확인되는 만큼 업계에서 통용되는 실무 관행으로 볼 수 있습니다.

실무 확인 팁을 드리면, 라이브러리의 LICENSE 파일을 열었을 때 "Apache License, Version 2.0"이라는 문구와 함께 "Grant of Patent License"라는 조항 번호가 보인다면 특허 조항이 포함된 버전입니다. 여러 기업이 협업하는 대형 오픈소스 프로젝트를 시작하거나, 특허 리스크가 존재할 수 있는 기술 영역(예: 알고리즘, 하드웨어 연동)에서 라이브러리를 선택해야 한다면 MIT보다 Apache 2.0 계열을 우선 검토해보는 것도 방법입니다. 다만 두 라이선스 모두 저작권 고지 의무가 있다는 공통점은 잊지 말아야 합니다. Apache 2.0은 저작권 표시 외에도 NOTICE 파일이 존재하는 경우 이를 함께 배포하도록 요구하므로, 배포 시 NOTICE 파일 유무를 반드시 확인해야 합니다.

---

Step 3: GPL과 AGPL의 카피레프트 조건, SaaS라면 특히 주의하기

GPL은 카피레프트(Copyleft) 라이선스로, 파생 저작물도 원칙적으로 동일한 조건으로 공개해야 한다는 점이 MIT·Apache 2.0과의 결정적 차이입니다. 공식 라이선스 목록에서도 GPL은 Copyleft: Yes로 명확히 표기되어 있습니다. GPL 코드를 가져다 수정하거나 다른 코드와 결합해 배포하는 경우, 결과물 전체를 동일한 GPL 조건으로 소스코드까지 공개해야 하는 것이 원칙입니다.

여기서 실무자들이 가장 궁금해하는 부분이 "사내에서만 쓰고 외부에 배포하지 않으면 공개 의무가 없는 것 아니냐"는 질문입니다. 이 설명은 널리 통용되고 있지만, 본 글에서는 GPL 원문과 GNU 공식 FAQ 원문을 직접 대조하지 못한 부분이므로 단정적으로 "의무 없음"이라고 결론 내리지 않겠습니다. 실무에 적용하기 전에는 반드시 gnu.org의 GPL FAQ 원문을 직접 확인하고 판단하시길 권합니다.

다만 확실하게 확인된 부분은 AGPLv3, 즉 GNU Affero General Public License입니다. AGPL은 GPL과 같은 강한 카피레프트 범주에 속하면서도, GPL에는 없는 조건을 하나 더 추가한 라이선스입니다. AGPLv3 제13조는 GPLv2·GPLv3에는 없는 추가 조건으로, 프로그램을 수정한 경우 네트워크를 통해 원격으로 상호작용하는 모든 사용자에게 해당 버전의 대응 소스코드를 무료로 받을 기회를 제공해야 한다고 규정하고 있습니다. 이 조항은 오늘날의 SaaS(Software as a Service) 배포 형태를 겨냥해 만들어진 조항이라는 점이 중요합니다.

과거 GPL이 만들어질 당시에는 소프트웨어를 "배포"한다는 것이 곧 실행 파일이나 소스코드를 상대방 컴퓨터에 전달하는 행위를 의미했습니다. 그런데 웹 서비스나 SaaS 형태에서는 서버에서만 소프트웨어를 실행하고 사용자는 브라우저로 결과만 받아보기 때문에, 전통적 GPL의 "배포" 개념에는 해당하지 않아 소스 공개 의무를 피해갈 수 있다는 이른바 "ASP 루프홀(ASP loophole)"이 지적됐습니다. AGPL 제13조는 바로 이 허점을 메우기 위해 만들어진 조항입니다.

여기서 반드시 기억해야 할 단서가 하나 있습니다. 의무가 발생하는 조건은 "수정한(modified) 버전"을 호스팅할 때입니다. 즉 AGPL 소프트웨어를 아무런 코드 수정 없이 그대로 가져다 서버에서 실행만 하는 경우와, 코드를 수정해서 서비스에 반영한 경우는 의무 발생 여부가 다르게 취급됩니다. 참고로 AGPLv3 원문에서는 사적으로 수정판을 만들거나 개인적으로 실행하는 것 자체는 배포 조건 준수 없이 무조건 허용된다는 점도 확인됩니다. 즉 AGPL 조항이 발동되는 시점은 "타인이 네트워크를 통해 상호작용할 수 있는 형태로 수정판을 서비스할 때"라고 이해하면 됩니다.

SaaS 형태로 서비스를 운영하거나 준비 중이라면 의존성 목록에 AGPL 라이선스가 있는지부터 반드시 확인해야 합니다. 데이터베이스, 검색엔진, 문서 편집 라이브러리 등 일부 인기 오픈소스 도구가 AGPL을 채택하고 있는 경우가 있으므로, 해당 도구를 수정 없이 그대로 쓰는지, 커스터마이징해서 서비스에 녹여 넣었는지를 명확히 구분해두는 작업이 필요합니다.

---

Step 4: 라이선스 호환성 확인하고 안전하게 조합하기

서로 다른 라이선스가 적용된 코드를 한 프로젝트에 섞어 쓸 때는 반드시 호환성부터 확인해야 하며, 임의로 조합하면 라이선스 위반이 될 수 있습니다. 라이선스 호환성이란 서로 다른 라이선스가 적용된 코드를 결합해 하나의 배포물로 만들 수 있는지를 따지는 개념입니다. 이 부분은 개발자들이 가장 헷갈려하는 영역이기도 합니다.

먼저 Apache 2.0과 GPL의 관계를 짚어보겠습니다. FSF(Free Software Foundation)는 Apache 2.0의 특허 종료(patent retaliation) 및 면책 조항을 GPLv2에는 없는 제한으로 지적하며, Apache 라이선스를 GPL 버전 2와 호환된다고 본 적이 없다고 명시하고 있습니다. 즉 Apache 2.0 코드와 GPLv2 코드를 결합해서 배포하는 것은 FSF 관점에서 호환되지 않는 조합입니다. 반면 Apache 2.0은 GPLv3에 대해서만 호환된다고 공식적으로 표기되어 있습니다. GPLv3를 제정할 당시 Apache 2.0과의 호환성 문제를 의식해 조항을 일부 조정했기 때문에 생긴 차이입니다.

주의할 점은, Apache 2.0과 LGPL 3(Lesser GPL 버전 3)의 호환 여부는 이번 확인 과정에서 gnu.org 원문으로 직접 대조하지 못했다는 사실입니다. 이 조합을 실제로 검토해야 하는 상황이라면 반드시 FSF 공식 라이선스 목록 페이지에서 최신 원문을 직접 확인하시길 권합니다. 라이선스 호환성 표는 시기에 따라 갱신될 수 있는 영역이므로 개인 블로그나 요약 글보다 원문 대조가 훨씬 안전합니다.

MIT 코드가 GPLv2·GPLv3에 통합 가능하다는 설명도 업계에서 널리 알려져 있지만, 이 역시 FSF 라이선스 목록 원문으로 이번에 직접 확인하지는 못한 부분입니다. 다만 MIT 라이선스가 조건이 매우 적은 허용형 라이선스라는 특성상, 더 엄격한 조건을 가진 GPL 프로젝트에 편입되는 방향의 결합은 일반적으로 문제가 적다고 알려져 있습니다. 반대로 GPL 코드를 MIT 프로젝트에 가져오는 방향은 GPL의 카피레프트 조건이 우선 적용되어 전체 프로젝트가 GPL 조건을 따라야 하는 상황이 생길 수 있으므로 방향성을 반드시 구분해서 판단해야 합니다.

실무에서는 다음 순서로 확인하는 것을 권합니다.

① 프로젝트에 사용할 모든 라이브러리의 라이선스 종류를 먼저 나열합니다
② 그중 카피레프트 계열(GPL, AGPL, LGPL)이 있는지 확인합니다
③ 카피레프트 라이브러리가 있다면 결합 방식(정적 링크, 동적 링크, 별도 프로세스 통신)에 따라 의무 범위가 달라질 수 있으므로 GNU 공식 FAQ에서 해당 케이스를 찾아봅니다
④ 최종 판단이 어려운 경우 사내 법무 검토 또는 외부 법률 자문을 병행합니다

라이선스 호환성 판단은 개발자 혼자 완벽하게 처리하기 어려운 영역일 수 있으므로, 확신이 서지 않는 조합은 반드시 공식 자료로 재확인하는 습관이 결국 가장 안전한 방법입니다.

---

자주 발생하는 오류

라이선스 관련 오류는 대부분 "고지 의무를 형식적으로만 이행했다"는 착각에서 시작됩니다. 실무에서 자주 마주치는 문제 상황을 정리하면 다음과 같습니다.

첫째, MIT 라이선스 코드를 사용하면서 저작권 문구만 적고 라이선스 전문은 생략하는 경우입니다. 앞서 설명한 대로 MIT 조건은 저작권 표시와 라이선스 전문을 함께 포함하는 것이므로, 둘 중 하나만 이행하면 조건 미충족 상태가 됩니다.

둘째, Apache 2.0 라이브러리를 사용하면서 원본 저장소에 존재하는 NOTICE 파일을 누락하는 경우입니다. Apache 2.0은 NOTICE 파일이 존재할 경우 이를 함께 배포하도록 요구하는데, 이 부분을 간과하고 라이선스 텍스트만 복사해두는 사례가 많습니다.

셋째, GPL 코드를 SaaS 형태로 서비스하면서 "배포한 게 아니니 괜찮다"고 판단하는 경우입니다. GPL과 AGPL은 배포 개념 자체가 다르게 설계되어 있으므로, 실제로 사용 중인 라이선스가 GPL인지 AGPL인지부터 정확히 구분해야 합니다. 특히 AGPL 코드를 수정해서 서버에 올린 뒤 사용자에게 서비스한다면 제13조에 따른 소스 제공 의무가 발생할 수 있습니다.

넷째, 실제 소송으로 이어진 사례도 참고할 필요가 있습니다. FSF v. Cisco Systems 사건은 2008년 12월 11일 뉴욕 남부연방지방법원에 FSF가 제기한 소송(사건번호 08-CV-10764)으로, 소장은 FSF를 대리한 Software Freedom Law Center(SFLC)가 제출했습니다. 쟁점은 Linksys 브랜드 제품이 GCC, GNU Binutils, GNU C Library 등 FSF가 저작권을 보유한 프로그램들의 GPL·LGPL 조건을 위반해, 요구되는 완전한 대응 소스코드를 제공하지 않고 배포했다는 점이었습니다. 여기서 오해하기 쉬운 부분이 있는데, 소송의 대상은 펌웨어 자체가 아니라 그 안에 포함된 개별 GNU 툴체인과 라이브러리였다는 점입니다. 이 사건은 Cisco가 Linksys 제품의 라이선스 준수를 담당할 책임자를 지정하고 FSF에 비공개 금액을 기부하는 것으로 합의 종결됐습니다. 이 사례는 하드웨어 제조사도 내부에 포함된 GPL 도구 하나하나까지 준수 여부를 관리해야 한다는 점을 잘 보여줍니다.

---

활용 팁 & 베스트 프랙티스

라이선스 관리를 습관화하려면 프로젝트 시작 시점부터 자동화 도구와 문서화 루틴을 함께 세팅하는 것이 가장 효율적입니다. 몇 가지 실무 팁을 정리하면 다음과 같습니다.

먼저, 의존성 추가 시점마다 라이선스를 확인하는 습관을 들이는 것이 좋습니다. 새 라이브러리를 npm install이나 pip install로 추가할 때마다 해당 패키지의 LICENSE 파일을 한 번씩 열어보는 것만으로도 나중에 몰아서 확인해야 하는 부담이 크게 줄어듭니다.

다음으로, NOTICE 파일 또는 오픈소스 고지 페이지를 프로젝트 초기부터 만들어두는 방법을 추천합니다. 서비스 설정 화면이나 앱의 "오픈소스 라이선스" 메뉴에 들어가는 콘텐츠를 프로젝트 막바지에 몰아서 작성하려고 하면 어떤 라이브러리를 언제 추가했는지 추적하기 어려워집니다. 처음부터 사용 라이브러리, 라이선스 종류, 저작권 문구를 표로 정리해두는 것이 훨씬 안전합니다.

그리고, 카피레프트 계열 라이선스(GPL, AGPL, LGPL)는 별도로 표시해 관리하는 방법도 효과적입니다. 허용형 라이선스와 카피레프트 라이선스를 같은 목록에 섞어두면 나중에 배포 형태를 바꿀 때(예: 온프레미스에서 SaaS로 전환) 놓치기 쉽습니다. 카피레프트 라이선스만 별도 시트나 태그로 분리해 관리하면 서비스 구조가 바뀔 때마다 우선적으로 재검토할 수 있습니다.

마지막으로, 라이선스 판단이 애매한 경우 GNU 공식 FAQ와 OSI 공식 승인 라이선스 목록을 항상 1차 출처로 삼는 습관을 들이시길 권합니다. 검색 결과 상위에 노출되는 블로그 글이나 요약 정리 콘텐츠는 이해를 돕는 참고자료로는 유용하지만, 실제 의사결정의 근거로 삼기에는 부정확할 위험이 있습니다. 특히 라이선스 조항은 버전이 바뀌면서 세부 내용이 달라질 수 있으므로, 사용 중인 라이브러리가 어떤 버전의 라이선스를 채택했는지(GPLv2인지 GPLv3인지, AGPLv1인지 AGPLv3인지)까지 정확히 확인하는 꼼꼼함이 필요합니다.

---

응용·확장

라이선스 확인 습관은 개인 프로젝트뿐 아니라 팀 단위, 조직 단위로 확장할 때 더 큰 효과를 발휘합니다. 개발팀이 여러 명 이상으로 커지면 각자 서로 다른 라이브러리를 자유롭게 추가하게 되는데, 이때 라이선스 정책이 없으면 어느 순간 카피레프트 라이선스가 섞여 들어와도 아무도 인지하지 못하는 상황이 생길 수 있습니다.

이를 방지하기 위해 조직 차원에서는 허용 라이선스 목록(allowlist)과 금지 라이선스 목록(denylist)을 사전에 정의해두는 방법을 고려해볼 수 있습니다. 예를 들어 "MIT, Apache 2.0, BSD 계열은 자유롭게 사용, GPL·AGPL 계열은 사용 전 반드시 검토 요청"과 같은 내부 가이드라인을 문서화해두면, 신규 입사자나 외주 협업자가 참여하더라도 동일한 기준으로 판단할 수 있습니다.

또한 오픈소스를 단순히 "가져다 쓰는 대상"으로만 보지 않고, 직접 만든 사내 도구나 라이브러리를 오픈소스로 공개할 때도 이 글의 개념이 그대로 적용됩니다. 자체 개발한 도구를 외부에 공개하려는 경우, 어떤 라이선스를 선택할지는 그 도구가 상업적으로 활용되길 원하는지, 파생 프로젝트도 동일 조건으로 공개되길 원하는지에 따라 달라집니다. 자유로운 확산과 상업적 활용을 우선한다면 MIT나 Apache 2.0 계열을, 파생물도 계속 공개되는 생태계를 만들고 싶다면 GPL 계열을, SaaS 형태로 우회해 소스를 감추는 것까지 막고 싶다면 AGPL을 검토하는 식으로 목적에 맞춰 선택할 수 있습니다.

---

점검 체크리스트

프로젝트를 배포하기 전, 아래 항목을 다시 한번 확인해보세요.

① 사용 중인 모든 오픈소스 라이브러리의 LICENSE 파일을 확인했는가
② MIT·Apache 2.0 라이브러리의 저작권 문구와 라이선스 전문을 고지 페이지에 모두 포함했는가
③ Apache 2.0 라이브러리의 NOTICE 파일 존재 여부를 확인하고 함께 배포했는가
④ GPL·AGPL 계열 라이브러리가 있는지, 있다면 배포 형태(패키지 배포 vs SaaS)를 명확히 구분했는가
⑤ AGPL 라이브러리를 수정해서 서비스에 반영했는지 여부를 확인했는가
⑥ 서로 다른 라이선스를 결합할 때 호환성을 GNU 공식 FAQ로 재확인했는가
⑦ 라이선스 관련 애매한 판단은 공식 원문 대조 또는 법률 자문으로 마무리했는가

---

자주 묻는 질문 FAQ

Q1. MIT 라이선스 코드를 수정해서 팔아도 저작자에게 따로 허락을 받아야 하나요?
아니요. MIT 라이선스 원문에 따르면 저작권 표시와 라이선스 전문을 포함하는 조건만 지키면 별도 허락 없이 수정, 병합, 재배포, 판매가 모두 가능합니다.

Q2. Apache 2.0과 MIT 중 뭐가 더 안전한가요?
"더 안전하다"보다는 목적이 다릅니다. 저작권 고지 절차가 단순한 것을 원한다면 MIT가 간편하고, 특허 관련 리스크를 명문화된 조항으로 관리하고 싶다면 Apache 2.0이 유리합니다.

Q3. 회사 내부 서버에서만 GPL 코드를 쓰고 외부에 배포하지 않으면 괜찮나요?
이 설명은 널리 통용되지만 본 글에서는 GPL 원문과 GNU 공식 FAQ를 직접 대조하지 못했으므로 단정할 수 없습니다. 반드시 gnu.org의 GPL FAQ 원문을 직접 확인한 뒤 판단하시길 권합니다.

Q4. SaaS로 서비스하면 AGPL 소스코드를 무조건 공개해야 하나요?
아닙니다. AGPLv3 제13조의 의무는 "수정한 버전"을 네트워크로 서비스할 때 발생합니다. 수정 없이 그대로 사용하는 경우와 사적으로만 실행하는 경우는 조건이 다르게 적용될 수 있으므로 수정 여부부터 확인해야 합니다.

Q5. GPLv2와 Apache 2.0을 같이 써도 되나요?
FSF는 Apache 2.0을 GPLv2와 호환된다고 본 적이 없다고 명시하고 있어 이 조합은 권장되지 않습니다. Apache 2.0은 GPLv3에 대해서만 호환된다고 공식적으로 표기되어 있으니 GPLv3 기준으로 검토하시길 권합니다.

---

라이선스 확인은 한 번 습관을 잡아두면 이후 프로젝트마다 반복되는 절차라 크게 부담스럽지 않습니다. 오늘 소개한 개념을 기준으로 지금 진행 중인 프로젝트의 의존성 목록부터 한 번 훑어보시길 권합니다. 공식 원문은 OSI(opensource.org), GNU 라이선스 목록(gnu.org/licenses), Apache 공식 페이지(apache.org/licenses)에서 확인할 수 있습니다.