오픈소스 라이선스: MIT vs Apache vs GPL (개발자가 감옥에 안 가려면)

CODEMAPO

오픈소스 라이선스: MIT vs Apache vs GPL (개발자가 감옥에 안 가려면)

"npm install 하나 잘못 쳤더니 변호사한테 전화가 왔습니다"

개발 3개월 차 때 저는 정말 순진했습니다. 깃허브에 있는 라이브러리는 다 공짜인 줄 알았거든요. "Open Source"라는 말 자체가 "오픈"이니까 막 가져다 써도 된다고 생각했습니다.

그러던 어느 날, 시니어 개발자가 제 PR을 보고 갑자기 심각한 표정으로 물었습니다.

"이 라이브러리 라이선스 확인해봤어요?"

저는 대답했습니다. "네? 그게... 필요한가요?"

그 순간 시니어가 한숨을 쉬며 말했습니다. "이거 GPL이네요. 지금 이거 쓰면 우리 전체 프로젝트 소스코드 공개해야 해요. 법무팀 가기 전에 당장 빼세요."

그날 저는 처음 알았습니다. 오픈소스에도 "법"이 있다는 것을요.

처음엔 이게 대체 뭔 소린지 몰랐습니다

"라이선스"라는 단어 자체가 낯설었습니다. Windows 정품 인증할 때나 보던 단어 아닌가요?

제가 처음 오픈소스 라이선스를 접했을 때 가장 헷갈렸던 것들:

1. "오픈소스 = 공짜 = 마음대로 써도 됨" 이라는 착각

코드가 공개되어 있다는 것과 내가 그 코드를 상업적으로 쓸 수 있다는 것은 완전히 다른 문제였습니다. 깃허브에 올라가 있어도 라이선스가 없으면 저작권법상 사용 금지입니다. 코드 보는 건 괜찮은데, 복사해서 내 프로젝트에 넣는 순간 법적 문제가 생길 수 있습니다.

2. MIT, Apache, GPL... 대체 뭐가 다른 건가요?

처음엔 다 비슷해 보였습니다. "출처 표시만 하면 된다" 같은 말들이 다 비슷하게 들렸거든요. 하지만 알고 보니 천국과 지옥 차이였습니다.

MIT는 "복사하든, 수정하든, 팔든 마음대로 해"지만, GPL은 "내 코드 쓰면 네 코드도 공개해"였습니다.

3. 서버에서만 돌아가는 API 서비스에도 라이선스가 적용되나요?

이게 가장 큰 오해였습니다. GPL은 "배포"할 때만 코드 공개 의무가 있어서, 서버에서만 돌리면 괜찮다고 생각했습니다. 그런데 AGPL이라는 녀석은 "네트워크로 서비스만 해도 공개해야 함"이었습니다.

백엔드 개발자한테 AGPL은 핵폭탄입니다.

"GPL은 전염병이다" 이 한마디에 와닿았습니다

라이선스를 이해하는 데 결정적이었던 비유가 있습니다.

GPL은 전염병처럼 번진다.

일반적인 라이선스는 "이 음식을 먹으면 비용을 내세요" 정도입니다. 하지만 GPL은 "이 음식을 먹으면 당신이 만든 모든 요리 레시피를 공개하세요"입니다.

더 무섭게 말하면:

"GPL 코드 10줄을 내 10만 줄짜리 프로젝트에 넣으면, 그 10만 줄 전체가 GPL이 됩니다."

이게 바로 "Copyleft(카피레프트)"의 핵심입니다. Copyright(저작권)과 반대로, "내 권리를 포기하는 대신 너도 네 권리를 포기해야 해"라는 철학입니다.

저는 이 개념을 "좀비 바이러스 전염"이라고 생각하니까 머릿속에 확 들어왔습니다. GPL 좀비한테 물리면 내 코드도 GPL 좀비가 되는 거죠.

그러니까 회사에서 GPL 코드를 조심스럽게 다루는 이유는 "법적 전염성" 때문이었습니다.

결국 3가지 카테고리로 정리됐습니다

수십 개의 오픈소스 라이선스가 있지만, 결국 개발자가 알아야 할 건 딱 3가지 카테고리였습니다.

1. Permissive (허용적 라이선스) - "냉장고에서 뭐든 꺼내 먹어, 신경 안 써"

가장 관대한 라이선스들입니다. 개발자들이 가장 선호하죠.

MIT 라이선스

내가 이해한 핵심:

MIT 라이선스는 마치 "공짜 뷔페" 같습니다. 원하는 만큼 가져가고, 수정하고, 상업적으로 팔아도 됩니다. 단, 뷔페 입구에 붙어있는 "이 식당은 식중독에 책임지지 않습니다" 문구(라이선스 파일)는 떼지 말아야 합니다.

적용:

// package.json
{
  "name": "my-awesome-project",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "react": "^18.0.0",  // MIT 라이선스
    "lodash": "^4.17.21" // MIT 라이선스
  }
}

React, Vue, Node.js, jQuery 같은 메이저 라이브러리들이 다 MIT입니다. 왜 이렇게 많이 쓰일까요? 기업에서 쓰기 편하니까요.

MIT로 배포된 라이브러리를 쓰면:

소스코드 공개 의무 없음
상업적 사용 제한 없음
수정해서 재배포 가능
단, LICENSE 파일은 포함해야 함 (저작권 고지)

저는 MIT를 "부담 없는 친구"라고 생각합니다. "내가 만든 거 쓰는 건 좋은데, 나한테 문제 생기면 내가 만든 게 아니라고 말할 권리는 있어"라는 느낌입니다.

Apache 2.0 라이선스

내가 이해한 핵심:

Apache는 MIT의 "변호사 버전"입니다. 기본적으로 MIT랑 비슷하게 자유롭지만, 특허 조항이 추가되어 있습니다.

특허 조항이 왜 중요할까요?

제가 실제로 겪은 일입니다. 어떤 라이브러리를 쓰려고 하는데, 그 안에 특허 기술이 포함되어 있었습니다. MIT 라이선스면 "코드는 자유롭게 쓰되, 특허 소송은 따로야"입니다. 그런데 Apache 2.0이면 "특허권도 같이 줄게"라는 약속이 포함됩니다.

예를 들어:
구글이 Android를 Apache 2.0으로 공개하면,
→ 코드도 자유롭게 쓸 수 있고
→ 안드로이드에 들어있는 구글의 특허 기술도 소송 없이 쓸 수 있습니다.

대기업들이 Apache를 선호하는 이유:

대기업은 "특허 소송"을 무척 조심합니다. 어떤 오픈소스를 썼는데 나중에 "그거 우리 특허 침해야" 하고 소송 걸면 끔찍하거든요.

Apache 2.0은 "특허 방어막"을 제공합니다. 라이선스에 "특허권 허락(Patent Grant)"이 명시되어 있어서, 기업 법무팀이 안심하고 승인해줍니다.

Apache 라이선스를 쓰는 유명 프로젝트:

Android
Kafka
Spring Framework
Kubernetes

제가 Apache를 설명할 때 쓰는 비유는 "계약서를 꼼꼼히 쓴 친구"입니다. 친구는 친구인데, 나중에 서로 불편해지지 않게 미리 문서로 정리해두는 타입이죠.

BSD 라이선스 (2-Clause / 3-Clause)

내가 이해한 핵심:

BSD는 MIT의 "사촌"입니다. 거의 비슷한데, 조항 개수가 다릅니다.

BSD 2-Clause: MIT와 거의 동일. "출처 표시만 해"
BSD 3-Clause: 2-Clause + "내 이름으로 홍보하지 마" 조항 추가

예시:
"This product uses OpenSSL (BSD License)"  → OK
"OpenSSL officially endorses this product" → NO (3-Clause 위반)

실제로 BSD와 MIT는 사실상 같은 취급을 받습니다. 둘 다 "상업적 사용 프리패스"입니다.

유명 프로젝트:

nginx (BSD 2-Clause)
Redis (BSD 3-Clause)
FreeBSD 운영체제

2. Weak Copyleft (약한 카피레프트) - "내가 준 건 돌려줘, 네 거는 네가 가져"

Permissive보다는 까다롭지만, GPL보다는 덜 무서운 중간 지대입니다.

MPL (Mozilla Public License)

내가 이해한 핵심:

MPL은 "파일 단위 공개"입니다. GPL처럼 전체 프로젝트를 오픈하라는 게 아니라, "내가 준 파일을 수정했으면 그 파일만 공개해"입니다.

비유하자면:

"내가 레고 블록 10개 줬어. 너는 그 블록으로 성을 만들 수 있어. 근데 내 블록을 고쳤다면 그 블록 설계도는 공개해야 해. 네가 추가한 다른 블록은 비밀로 해도 돼."

실제 적용:

프로젝트 구조:
/src
  /my-code       (내 코드, 비공개 가능)
  /mpl-library   (MPL 라이선스 라이브러리)
    └─ lib.js    (이 파일을 수정했다면 공개해야 함)

MPL은 "상업용 소프트웨어"와 "오픈소스 철학"의 타협점입니다. Firefox 브라우저가 MPL을 쓰는 이유가 여기 있습니다. 브라우저 엔진은 공개하되, 각 회사가 커스터마이징한 UI나 플러그인은 비공개로 둘 수 있습니다.

유명 프로젝트:

Firefox
Thunderbird
LibreOffice (일부 컴포넌트)

LGPL (Lesser GPL)

내가 이해한 핵심:

LGPL은 GPL의 "순한 버전"입니다. "Library GPL"이라고도 불렸는데, 이름을 "Lesser(덜한)"로 바꿨습니다.

GPL이 "내 코드 쓰면 네 전체 프로젝트가 GPL"이라면, LGPL은 "라이브러리로만 쓰면 괜찮아"입니다.

예시:
LGPL 라이브러리를 동적 링크(.dll, .so)로 사용 → OK, 내 코드 비공개 가능
LGPL 라이브러리 코드를 내 소스에 복붙 → NO, 전체 공개해야 함

팁:

제가 LGPL 라이브러리를 써야 할 때는 항상 "동적 링크"로 사용합니다. 정적 링크(Static Link)나 소스코드 병합은 위험합니다.

# 안전한 방식 - 동적 링크
npm install libphonenumber-js  # LGPL 라이브러리
# 내 코드는 이 라이브러리를 '호출'만 함 → 비공개 가능

# 위험한 방식 - 소스 병합
# LGPL 라이브러리 코드를 내 파일에 복사 붙여넣기 → GPL 전염 위험

유명 프로젝트:

Qt (C++ GUI 프레임워크)
GStreamer (멀티미디어 프레임워크)
GNU C Library (glibc)

3. Strong Copyleft (강한 카피레프트) - "좀비 바이러스 주의"

기업 법무팀이 가장 싫어하는 라이선스입니다. "전염성(Viral)"이라고 불립니다.

GPL (v2, v3)

내가 이해한 핵심:

GPL은 리차드 스톨먼(Richard Stallman)이 만든 "자유 소프트웨어 운동"의 상징입니다. 철학은 명확합니다:

"소프트웨어는 자유로워야 한다. 네가 내 코드로 이익을 얻으면, 너도 네 코드를 자유롭게 풀어라."

이게 무섭게 들리지 않을 수도 있는데, 실제로는 법적 핵폭탄입니다.

실제 사례 (공포 스토리):

제가 들은 진짜 이야기입니다. 어떤 스타트업이 임베디드 장비 펌웨어를 개발했는데, 개발자가 모르고 GPL 라이브러리를 사용했습니다. 제품 출시 1년 후, 오픈소스 활동가가 제품을 역공학(Reverse Engineering)해서 GPL 코드를 발견했습니다.

결과는?

"전체 펌웨어 소스코드를 GitHub에 공개하라"는 법적 요구를 받았습니다. 거부하면 소송입니다. 회사는 결국 기술을 모두 공개하거나, 엄청난 비용을 들여 GPL 코드를 완전히 제거하는 리팩토링을 해야 했습니다.

GPL이 전염되는 경로:

1. GPL 라이브러리를 링크 (Static/Dynamic 상관없음)
   → 내 전체 프로젝트가 GPL

2. GPL 코드 일부를 복사해서 사용
   → 내 전체 프로젝트가 GPL

3. GPL 라이브러리를 수정해서 사용
   → 내 프로젝트 + 수정본 모두 GPL

GPL v2 vs v3의 차이:

GPL v2: Linux Kernel이 사용. 비교적 오래됨.
GPL v3: "Tivoization" 방지 추가. 하드웨어에서 GPL 소프트웨어를 실행할 때 사용자가 수정할 수 없게 막는 걸 금지합니다.

예시:
Tivo라는 셋톱박스가 Linux(GPL)를 썼는데, 사용자가 코드를 수정하면
하드웨어가 부팅을 막았습니다. → GPL v3은 이걸 금지합니다.

유명 프로젝트:

Linux Kernel (GPL v2)
Git (GPL v2)
WordPress (GPL v2+)
GCC Compiler (GPL v3)

AGPL (Affero GPL)

내가 이해한 핵심:

AGPL은 GPL의 "클라우드 시대 버전"입니다. GPL의 허점을 막기 위해 만들어졌습니다.

GPL의 허점이 뭐였을까요?

GPL은 소프트웨어를 "배포(Distribute)"할 때만 소스코드 공개 의무가 있었습니다. 그런데 클라우드/SaaS 서비스는 소프트웨어를 배포하지 않습니다. 그냥 서버에서 실행만 하고, 사용자는 웹으로 접속하죠.

예시:
회사가 GPL 라이브러리로 웹 서비스를 만듦
→ 사용자에게 "설치 파일"을 주지 않음 (배포 안 함)
→ GPL 의무 회피 성공!

AGPL은 이 허점을 막았습니다:

"네트워크를 통해 사용자가 접속만 해도, 소스코드를 공개해야 한다."

실제로 AGPL이 무서운 이유:

백엔드 API 서버에 AGPL 라이브러리를 썼다고 상상해보세요. 사용자가 브라우저로 접속하는 순간 "전체 서버 코드 공개" 의무가 생깁니다.

// 위험한 예시
const agplLibrary = require('agpl-database-tool'); // AGPL 라이선스

app.get('/api/users', (req, res) => {
  const users = agplLibrary.query('SELECT * FROM users');
  res.json(users);
});

// ↑ 이 API를 누군가 호출하면, 전체 서버 코드를 공개해야 합니다.

AGPL 사용 사례와 전략:

재밌는 건, 일부 회사가 "전략적으로" AGPL을 씁니다.

MongoDB의 SSPL 전략:

MongoDB는 원래 AGPL이었습니다. AWS 같은 클라우드 회사들이 MongoDB를 서비스로 팔아먹자(Managed MongoDB), MongoDB 회사는 화가 났습니다.

결과: SSPL (Server Side Public License) 개발.

"우리 DB를 클라우드 서비스로 팔려면, 너희 클라우드 전체 인프라 코드를 공개해라."

이게 너무 극단적이라 논란이 많았습니다. 결국 AWS는 MongoDB 대신 DocumentDB라는 호환 DB를 만들었습니다.

Elastic(ElasticSearch)도 비슷한 길을 걸었습니다:

원래: Apache 2.0 (자유로움)
2021년: SSPL로 변경 (AWS 견제)
결과: AWS가 OpenSearch라는 포크(Fork) 버전 개발

유명 프로젝트:

MongoDB (SSPL로 전환)
Grafana (AGPL v3)
Mastodon (소셜 네트워크, AGPL)

실제로 라이선스 관리하는 법

이론은 알겠는데, 실제로 내 프로젝트에 어떤 라이선스가 숨어있는지 어떻게 알까요?

1. 패키지 매니저에서 확인하기

Node.js (npm/yarn):

# 간단 확인
npm list --depth=0

# 라이선스만 추출
npx license-checker --summary

# 상세 정보
npx license-checker --json > licenses.json

실행 결과 예시:

├─ MIT: 1234 packages
├─ Apache-2.0: 45 packages
├─ ISC: 23 packages
├─ BSD-3-Clause: 12 packages
└─ GPL-3.0: 1 package  ⚠️ 위험!

GPL이 하나라도 보이면 즉시 확인해야 합니다.

Python (pip):

# pip-licenses 설치
pip install pip-licenses

# 라이선스 확인
pip-licenses --summary

2. GitHub에서 라이선스 확인하기

라이브러리를 추가하기 전에 항상 확인하는 습관:

1. 깃허브 저장소 들어가기
2. 우측 상단 "About" 섹션 확인
   → "License: MIT" 같은 뱃지가 있음
3. 루트 디렉토리에 LICENSE 또는 COPYING 파일 확인

만약 라이선스 파일이 없다면?

3. package.json에 라이선스 명시하기

내가 라이브러리를 만들 때는 반드시 라이선스를 명시해야 합니다:

{
  "name": "my-library",
  "version": "1.0.0",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "https://github.com/username/my-library"
  }
}

LICENSE 파일도 추가:

# MIT 라이선스 생성
npx license mit > LICENSE

# Apache 2.0 생성
npx license apache > LICENSE

4. 회사 프로젝트에서 금지 라이선스 차단하기

회사에서는 CI/CD 파이프라인에 라이선스 검증을 추가합니다:

# .github/workflows/license-check.yml
name: License Check

on: [push, pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Check licenses
        run: |
          npx license-checker --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC"

금지 라이선스가 발견되면 빌드가 실패하도록 설정합니다.

5. Dual Licensing (듀얼 라이선스) 전략

일부 프로젝트는 2개의 라이선스를 동시에 제공합니다.

MySQL의 예시:

Option 1: GPL v2 (무료)
→ 오픈소스 프로젝트에서 사용
→ 내 프로젝트도 GPL로 공개해야 함

Option 2: Commercial License (유료)
→ 돈 내고 상업적 사용 권한 구매
→ 소스코드 공개 의무 없음

Qt Framework도 마찬가지:

Option 1: LGPL v3 (무료)
→ 동적 링크로만 사용 가능

Option 2: Commercial License (유료)
→ 정적 링크, 소스 병합 가능
→ 비공개 상용 소프트웨어에 사용 가능

이건 "오픈소스 비즈니스 모델"의 대표적인 전략입니다. 개인/오픈소스에는 무료로 주고, 기업에는 돈을 받는 거죠.

라이선스 선택 가이드 - 내가 오픈소스를 만든다면?

반대로, 내가 라이브러리를 만들어서 공개할 때 어떤 라이선스를 선택해야 할까요?

의사결정 트리:

graph TD
    A[오픈소스 라이선스 선택] --> B{상업적 사용을 허용할까?}
    B -->|Yes| C{특허 조항이 필요할까?}
    B -->|No| D[All Rights Reserved<br/>또는 Custom License]

    C -->|No| E[MIT / BSD]
    C -->|Yes| F[Apache 2.0]

    A --> G{수정본도 오픈소스여야 할까?}
    G -->|Yes, 파일 단위만| H[MPL / LGPL]
    G -->|Yes, 전체 프로젝트| I{클라우드도 포함?}

    I -->|No| J[GPL v3]
    I -->|Yes| K[AGPL]

실제 선택 사례:

"많은 사람이 쓰면 좋겠다" → MIT

예: React, Vue, Express.js
기업들이 부담 없이 쓸 수 있음

"대기업들도 안심하고 쓰길 원한다" → Apache 2.0

예: Kubernetes, Kafka, TensorFlow
특허 소송 걱정 없음

"내 코드를 이용해서 비공개 상용 제품 만들면 안 돼" → GPL

예: Linux, WordPress
오픈소스 생태계 강제

"클라우드 회사들이 내 코드로 돈 벌면 안 돼" → AGPL/SSPL

예: MongoDB, Grafana
비즈니스 방어 전략

실수하면 진짜 큰일 나는 시나리오

시나리오 1 - 스타트업의 GPL 악몽

상황:

2년간 개발한 SaaS 제품
투자 유치 직전, 기술 실사(Due Diligence)
투자자 측 변호사가 코드 검토 중 GPL 라이브러리 발견

결과:

Option 1: 전체 소스코드 공개 (회사 가치 폭락)
Option 2: GPL 라이브러리 완전 제거 (개발 3개월 지연, 투자 무산)
Option 3: GPL 코드 저작권자와 별도 협상 (큰 비용)

실제로 일어난 일입니다.

시나리오 2 - AGPL 백엔드의 공포

상황:

회사 내부 관리 도구에 AGPL 라이브러리 사용
"내부용이니까 괜찮겠지" 생각
나중에 고객에게 서비스로 확장

문제:

AGPL은 "배포" 여부가 아니라 "네트워크 접근" 여부를 봅니다.
→ 내부용이든 외부용이든, 누군가 접속하면 공개 의무 발생

시나리오 3 - 라이선스 파일 삭제

상황:

MIT 라이브러리를 사용하면서 LICENSE 파일 삭제
"우리 코드인 것처럼 보이게 하려고"

문제:

MIT의 유일한 의무:
→ 저작권 고지 (Copyright Notice) 유지

LICENSE 파일 삭제 = 라이선스 위반
→ 소송 가능성

결국 핵심은 이 3가지였습니다

2년간 오픈소스 생태계를 경험하면서 깨달은 것들:

1. "무료 ≠ 자유"

오픈소스는 "공짜"가 아니라 "조건부 공유"입니다.

코드를 볼 수 있다는 것과 내 프로젝트에 넣을 수 있다는 건 다른 문제입니다. 라이선스는 "어떤 조건으로 공유하는가"를 정의합니다.

2. "Copyleft는 바이러스다"

GPL/AGPL은 정말 전염됩니다.

이건 버그가 아니라 의도된 설계입니다. 리차드 스톨먼의 철학은 "소프트웨어의 자유를 강제하기"였습니다. 네가 내 코드로 이익을 보면, 너도 자유를 나눠야 한다는 거죠.

기업 입장에서는 악몽이지만, 오픈소스 생태계 입장에서는 "기여 강제 장치"입니다.

3. "변호사 없으면 MIT/Apache 쓰자"

개인 프로젝트나 스타트업은 MIT나 Apache가 답입니다.

GPL을 선택하는 건 "전략적 선택"이어야 합니다. 명확한 이유 없이 GPL을 쓰면:

기업들이 기여를 꺼림
사용자가 줄어듦
상업화 기회 차단

반면 MIT/Apache는:

채택률 증가
기업 기여 활발
나중에 비즈니스 전환 가능 (Dual License)

체크리스트 - 라이선스 실수 방지

새 라이브러리 추가 전:

GitHub에서 LICENSE 파일 확인
GPL/AGPL이 아닌지 확인
상업적 사용이 허용되는지 확인

프로젝트 출시 전:

npx license-checker 실행
금지 라이선스(GPL/AGPL) 검색
LICENSE 파일들이 포함되어 있는지 확인

라이브러리를 만들 때:

package.json에 license 필드 추가
루트에 LICENSE 파일 생성
README에 라이선스 명시

회사 프로젝트에서:

법무팀에 라이선스 정책 확인
CI/CD에 라이선스 검증 추가
GPL 사용 시 반드시 승인 받기

한 줄 요약

"깃허브에 있다고 공짜가 아니다. 라이선스는 코드의 법적 사용설명서다."

오픈소스 라이선스는 법입니다. 모르면 나중에 회사가, 또는 내가 만든 제품이 큰일 납니다. MIT/Apache는 안전하고, GPL/AGPL은 전염성이 있고, 듀얼 라이선스는 비즈니스 전략입니다.

개발 실력도 중요하지만, 법적 위험을 이해하는 것도 시니어 개발자의 덕목입니다.

Open Source Licenses: The Day a Lawyer Called Because I Ran `npm install`

When I was three months into learning to code, I was incredibly naive. I thought everything on GitHub was free to use. The term "Open Source" literally has "open" in it, so I figured I could just grab whatever I wanted.

Then one day, a senior developer looked at my pull request and got serious.

"Did you check the license on this library?"

I replied, "Huh? Is that... necessary?"

The senior sighed. "This is GPL. If we use this, we'll have to open-source our entire codebase. Remove it before legal finds out."

That's when I learned: open source has laws too.

At first, I had no idea what any of this meant

The word "license" itself felt foreign. Wasn't that something you only saw when activating Windows?

Here's what confused me most when I first encountered open source licenses:

1. The assumption: "Open Source = Free = Use However You Want"

Code being publicly available is completely different from being able to use it commercially. Even if it's on GitHub, without a license, it's illegal to use under copyright law. You can look at the code, but the moment you copy it into your project, you might be breaking the law.

2. MIT, Apache, GPL... What's the difference?

At first, they all sounded the same. Phrases like "just attribute the source" seemed identical. But I learned they're as different as heaven and hell.

MIT says "copy, modify, sell—do whatever you want," while GPL says "if you use my code, you must open-source yours too."

3. Do licenses apply to API services running only on servers?

This was my biggest misconception. GPL only requires code disclosure upon "distribution," so I thought running it on a server was fine. But then there's AGPL, which says "even if you just provide a service over the network, you must disclose the code."

For backend developers, AGPL is a nuclear bomb.

"GPL is like a virus"—that one line made it click

One analogy really helped me understand licenses:

GPL spreads like an infectious disease.

Most licenses are like "pay for this food if you eat it." But GPL is "if you eat this food, you must share the recipes of everything you cook."

More dramatically:

"If you include 10 lines of GPL code in your 100,000-line project, the entire 100,000 lines become GPL."

This is the core of "Copyleft"—the opposite of copyright. Instead of "I keep my rights," it's "I give up my rights, but you must give up yours too."

I understood it by thinking of "zombie virus infection". Get bitten by a GPL zombie, and your code becomes a GPL zombie too.

That's why companies handle GPL code so carefully—it has "legal contagion."

It all boils down to 3 categories

There are dozens of open source licenses, but developers really only need to know 3 categories.

1. Permissive Licenses: "Take whatever from the fridge, I don't care"

The most generous licenses. Developers love these.

MIT License

My understanding:

MIT is like an "all-you-can-eat buffet." Take as much as you want, modify it, sell it commercially. Just don't remove the "this restaurant is not liable for food poisoning" sign (the LICENSE file) at the entrance.

Real-world application:

// package.json
{
  "name": "my-awesome-project",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "react": "^18.0.0",  // MIT license
    "lodash": "^4.17.21" // MIT license
  }
}

Major libraries like React, Vue, Node.js, and jQuery all use MIT. Why? Because companies love using them.

Using an MIT-licensed library means:

No obligation to disclose source code
No commercial use restrictions
Can modify and redistribute
But you must include the LICENSE file (copyright notice)

I think of MIT as "a chill friend"—"Use what I made, but if something breaks, I have the right to say it wasn't me."

Apache 2.0 License

My understanding:

Apache is the "lawyer version" of MIT. It's similarly permissive but adds a patent clause.

Why are patent clauses important?

I actually experienced this. I wanted to use a library that contained patented technology. With MIT, "use the code freely, but patent lawsuits are separate." With Apache 2.0, it includes a "I grant you patent rights too" promise.

For example:
If Google releases Android under Apache 2.0,
→ You can freely use the code
→ AND you can use Google's patented tech in Android without getting sued.

Why big companies prefer Apache:

Corporations are extremely cautious about "patent lawsuits." If you use some open source and later get sued for "that's our patent infringement," it's a nightmare.

Apache 2.0 provides a "patent shield." It explicitly grants patent rights, so corporate legal teams approve it with confidence.

Famous Apache projects:

Android
Kafka
Spring Framework
Kubernetes

My analogy for Apache: "the friend who writes detailed contracts." Still a friend, but documents everything upfront to avoid awkwardness later.

BSD License (2-Clause / 3-Clause)

My understanding:

BSD is MIT's "cousin." Nearly identical, just with different numbers of clauses.

BSD 2-Clause: Almost the same as MIT. "Just attribute the source"
BSD 3-Clause: 2-Clause + "Don't use my name for endorsement"

Example:
"This product uses OpenSSL (BSD License)"  → OK
"OpenSSL officially endorses this product" → NO (violates 3-Clause)

In practice, BSD and MIT are treated identically. Both give "free pass for commercial use."

Famous projects:

nginx (BSD 2-Clause)
Redis (BSD 3-Clause)
FreeBSD OS

2. Weak Copyleft: "Give back what I gave you, keep your stuff"

More restrictive than Permissive, but less scary than GPL—the middle ground.

MPL (Mozilla Public License)

My understanding:

MPL is "file-level disclosure." It's not like GPL where the entire project must be opened. It's "if you modified the files I gave you, disclose those files. Your other files can stay private."

An analogy:

"I gave you 10 LEGO blocks. You can build a castle with them. But if you modified my blocks, share those block designs. Your additional blocks can remain secret."

Real application:

Project structure:
/src
  /my-code       (my code, can be private)
  /mpl-library   (MPL-licensed library)
    └─ lib.js    (if you modified this file, must disclose)

MPL is a compromise between "commercial software" and "open source philosophy." That's why Firefox uses MPL—the browser engine is open, but each company's customized UI or plugins can stay closed.

Famous projects:

Firefox
Thunderbird
LibreOffice (some components)

LGPL (Lesser GPL)

My understanding:

LGPL is the "mild version" of GPL. It used to be called "Library GPL," then renamed to "Lesser" (less strict).

If GPL says "use my code and your entire project becomes GPL," LGPL says "if you just use it as a library, you're fine."

Example:
Using an LGPL library via dynamic linking (.dll, .so) → OK, your code can stay closed
Copy-pasting LGPL code into your source → NO, must disclose everything

Practical tip:

When I must use an LGPL library, I always use "dynamic linking." Static linking or source merging is risky.

# Safe approach: dynamic link
npm install libphonenumber-js  # LGPL library
# My code just 'calls' this library → can stay private

# Risky approach: source merge
# Copy-paste LGPL code into my file → GPL contagion risk

Famous projects:

Qt (C++ GUI framework)
GStreamer (multimedia framework)
GNU C Library (glibc)

3. Strong Copyleft: "Beware the Zombie Virus"

The licenses corporate legal teams hate most. Also called "Viral" licenses.

GPL (v2, v3)

My understanding:

GPL is Richard Stallman's "Free Software Movement" manifesto. The philosophy is clear:

"Software should be free. If you profit from my code, you must free your code too."

This might not sound scary, but in reality, it's a legal nuclear bomb.

Real case (horror story):

I heard a true story. A startup developed embedded device firmware, and a developer unknowingly used a GPL library. One year after product launch, an open source activist reverse-engineered the product and found GPL code.

The result?

They received a legal demand to "publish the entire firmware source code on GitHub." Refusing meant a lawsuit. The company had to either disclose their core technology or spend enormous resources refactoring to completely remove the GPL code.

How GPL spreads:

1. Link a GPL library (static/dynamic doesn't matter)
   → Your entire project becomes GPL

2. Copy-paste any GPL code
   → Your entire project becomes GPL

3. Modify and use a GPL library
   → Your project + modifications both become GPL

GPL v2 vs v3 differences:

GPL v2: Used by Linux Kernel. Relatively older.
GPL v3: Adds "Tivoization" prevention. Prevents hardware from blocking users from running modified GPL software.

Example:
Tivo set-top box used Linux (GPL), but prevented booting if users modified the code.
→ GPL v3 prohibits this.

Famous projects:

Linux Kernel (GPL v2)
Git (GPL v2)
WordPress (GPL v2+)
GCC Compiler (GPL v3)

AGPL (Affero GPL)

My understanding:

AGPL is the "cloud era version" of GPL. Created to close a GPL loophole.

What was the GPL loophole?

GPL only required source disclosure upon "distribution." But cloud/SaaS services don't distribute software—they just run it on servers, and users access it via web.

Example:
Company builds web service with GPL library
→ Doesn't give users "installation files" (no distribution)
→ Successfully avoids GPL obligations!

AGPL closed this loophole:

"Even if users just access over the network, you must disclose source code."

Why AGPL is scary in practice:

Imagine using an AGPL library in your backend API server. The moment a user accesses via browser, you're obligated to disclose the entire server code.

// Risky example
const agplLibrary = require('agpl-database-tool'); // AGPL license

app.get('/api/users', (req, res) => {
  const users = agplLibrary.query('SELECT * FROM users');
  res.json(users);
});

// ↑ If anyone calls this API, you must disclose the entire server code.

AGPL use cases and strategies:

Interestingly, some companies use AGPL "strategically."

MongoDB's SSPL strategy:

MongoDB was originally AGPL. When cloud companies like AWS started selling MongoDB as a service (Managed MongoDB), MongoDB Inc. got angry.

Result: Developed SSPL (Server Side Public License).

"If you sell our DB as a cloud service, disclose your entire cloud infrastructure code."

This was so extreme it became controversial. Eventually, AWS created DocumentDB, a compatible alternative.

Elastic (ElasticSearch) took a similar path:

Originally: Apache 2.0 (permissive)
2021: Changed to SSPL (to counter AWS)
Result: AWS developed OpenSearch, a fork

Famous projects:

MongoDB (switched to SSPL)
Grafana (AGPL v3)
Mastodon (social network, AGPL)

How to manage licenses in practice

Theory is clear, but how do you actually detect what licenses are hiding in your project?

1. Check via package manager

Node.js (npm/yarn):

# Simple check
npm list --depth=0

# Extract licenses only
npx license-checker --summary

# Detailed info
npx license-checker --json > licenses.json

Example output:

├─ MIT: 1234 packages
├─ Apache-2.0: 45 packages
├─ ISC: 23 packages
├─ BSD-3-Clause: 12 packages
└─ GPL-3.0: 1 package  ⚠️ Danger!

If you see even one GPL, investigate immediately.

Python (pip):

# Install pip-licenses
pip install pip-licenses

# Check licenses
pip-licenses --summary

2. Check licenses on GitHub

Always verify before adding a library:

1. Visit the GitHub repository
2. Check the "About" section (top right)
   → Look for badges like "License: MIT"
3. Check for LICENSE or COPYING file in root directory

What if there's no license file?

3. Specify license in package.json

When creating your own library, always specify the license:

{
  "name": "my-library",
  "version": "1.0.0",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "https://github.com/username/my-library"
  }
}

Also add a LICENSE file:

# Generate MIT license
npx license mit > LICENSE

# Generate Apache 2.0
npx license apache > LICENSE

4. Block prohibited licenses in company projects

In corporate settings, add license validation to CI/CD pipelines:

# .github/workflows/license-check.yml
name: License Check

on: [push, pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Check licenses
        run: |
          npx license-checker --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC"

Configure builds to fail if prohibited licenses are detected.

5. Dual Licensing strategy

Some projects offer 2 licenses simultaneously.

MySQL example:

Option 1: GPL v2 (free)
→ For open source projects
→ Your project must also be GPL

Option 2: Commercial License (paid)
→ Buy commercial usage rights
→ No source disclosure obligation

Qt Framework is similar:

Option 1: LGPL v3 (free)
→ Only for dynamic linking

Option 2: Commercial License (paid)
→ Static linking, source merging allowed
→ Use in proprietary commercial software

This is a classic "open source business model" strategy—free for individuals/open source, paid for enterprises.

License selection guide: If I create open source

Conversely, when I create and publish a library, which license should I choose?

Decision tree:

graph TD
    A[Choose Open Source License] --> B{Allow commercial use?}
    B -->|Yes| C{Need patent clause?}
    B -->|No| D[All Rights Reserved<br/>or Custom License]

    C -->|No| E[MIT / BSD]
    C -->|Yes| F[Apache 2.0]

    A --> G{Must modifications be open source?}
    G -->|Yes, file-level only| H[MPL / LGPL]
    G -->|Yes, entire project| I{Include cloud?}

    I -->|No| J[GPL v3]
    I -->|Yes| K[AGPL]

Real selection cases:

"I want many people to use it" → MIT

Examples: React, Vue, Express.js
Companies can use without hesitation

"I want enterprises to use it confidently" → Apache 2.0

Examples: Kubernetes, Kafka, TensorFlow
No patent lawsuit concerns

"No proprietary products using my code" → GPL

Examples: Linux, WordPress
Enforces open source ecosystem

"Cloud companies can't profit from my code" → AGPL/SSPL

Examples: MongoDB, Grafana
Business defense strategy

Scenarios where mistakes really hurt

Scenario 1: Startup's GPL nightmare

Situation:

2 years developing a SaaS product
Pre-investment, technical due diligence
Investor's lawyer reviewing code, discovers GPL library

Outcomes:

Option 1: Disclose entire source code (company value crashes)
Option 2: Completely remove GPL library (3 months dev delay, investment falls through)
Option 3: Negotiate separately with GPL copyright holder (expensive)

This actually happened.

Scenario 2: AGPL backend horror

Situation:

Used AGPL library in internal company management tool
Thought "it's internal, should be fine"
Later expanded to customer-facing service

Problem:

AGPL cares about "network access," not "distribution"
→ Internal or external, if someone accesses it, disclosure obligation triggered

Scenario 3: Deleting license files

Situation:

Used MIT library but deleted LICENSE file
"To make it look like our code"

Problem:

MIT's only obligation:
→ Maintain copyright notice

Deleting LICENSE file = license violation
→ Lawsuit possible

If the copyright holder sues, you face damages + injunction.

Ultimately, these 3 things were key

What I learned after 2 years in the open source ecosystem:

1. "Free ≠ Freedom"

Open source is not "free," it's "conditional sharing."

Being able to see code is different from being able to put it in your project. Licenses define "under what conditions is it shared."

2. "Copyleft is a virus"

GPL/AGPL really do spread.

This isn't a bug—it's intentional design. Richard Stallman's philosophy was "to enforce software freedom." If you profit from my code, you must share freedom too.

For corporations, it's a nightmare. For the open source ecosystem, it's a "contribution enforcement mechanism."

3. "Without lawyers, use MIT/Apache"

For personal projects or startups, MIT or Apache is the answer.

Choosing GPL should be a "strategic choice." Using GPL without clear reasons means:

Corporations hesitate to contribute
User base shrinks
Blocks commercialization opportunities

Meanwhile, MIT/Apache:

Increases adoption rate
Active corporate contributions
Allows business pivot later (Dual License)

Checklist: Preventing license mistakes

Before adding a new library:

Check LICENSE file on GitHub
Verify it's not GPL/AGPL
Confirm commercial use is permitted

Before project launch:

Run npx license-checker
Search for prohibited licenses (GPL/AGPL)
Verify LICENSE files are included

When creating a library:

Add license field to package.json
Create LICENSE file in root
Specify license in README

In corporate projects:

Check legal team's license policy
Add license validation to CI/CD
Always get approval for GPL usage

오픈소스 라이선스: MIT vs Apache vs GPL (개발자가 감옥에 안 가려면)

관련 포스트

메모리 관리: 연속 할당과 분산 할당

BFS와 DFS: 그래프 탐색의 두 축

퀵 정렬(Quick Sort): 분할 정복의 대표

Keep-Alive: 전화 끊지 말고 기다려

"npm install 하나 잘못 쳤더니 변호사한테 전화가 왔습니다"

처음엔 이게 대체 뭔 소린지 몰랐습니다

"GPL은 전염병이다" 이 한마디에 와닿았습니다

결국 3가지 카테고리로 정리됐습니다

1. Permissive (허용적 라이선스) - "냉장고에서 뭐든 꺼내 먹어, 신경 안 써"

MIT 라이선스

Apache 2.0 라이선스

BSD 라이선스 (2-Clause / 3-Clause)

2. Weak Copyleft (약한 카피레프트) - "내가 준 건 돌려줘, 네 거는 네가 가져"

MPL (Mozilla Public License)

LGPL (Lesser GPL)

3. Strong Copyleft (강한 카피레프트) - "좀비 바이러스 주의"

GPL (v2, v3)

AGPL (Affero GPL)

실제로 라이선스 관리하는 법

1. 패키지 매니저에서 확인하기

2. GitHub에서 라이선스 확인하기

3. package.json에 라이선스 명시하기

4. 회사 프로젝트에서 금지 라이선스 차단하기

5. Dual Licensing (듀얼 라이선스) 전략

라이선스 선택 가이드 - 내가 오픈소스를 만든다면?

의사결정 트리:

실제 선택 사례:

실수하면 진짜 큰일 나는 시나리오

시나리오 1 - 스타트업의 GPL 악몽

시나리오 2 - AGPL 백엔드의 공포

시나리오 3 - 라이선스 파일 삭제

결국 핵심은 이 3가지였습니다

1. "무료 ≠ 자유"

2. "Copyleft는 바이러스다"

3. "변호사 없으면 MIT/Apache 쓰자"

체크리스트 - 라이선스 실수 방지

한 줄 요약

Open Source Licenses: The Day a Lawyer Called Because I Ran npm install

At first, I had no idea what any of this meant

"GPL is like a virus"—that one line made it click

It all boils down to 3 categories

1. Permissive Licenses: "Take whatever from the fridge, I don't care"

MIT License

Apache 2.0 License

BSD License (2-Clause / 3-Clause)

2. Weak Copyleft: "Give back what I gave you, keep your stuff"

MPL (Mozilla Public License)

LGPL (Lesser GPL)

3. Strong Copyleft: "Beware the Zombie Virus"

GPL (v2, v3)

AGPL (Affero GPL)

How to manage licenses in practice

1. Check via package manager

2. Check licenses on GitHub

3. Specify license in package.json

4. Block prohibited licenses in company projects

5. Dual Licensing strategy

License selection guide: If I create open source

Decision tree:

Real selection cases:

Scenarios where mistakes really hurt

Scenario 1: Startup's GPL nightmare

Scenario 2: AGPL backend horror

Scenario 3: Deleting license files

Ultimately, these 3 things were key

1. "Free ≠ Freedom"

2. "Copyleft is a virus"

3. "Without lawyers, use MIT/Apache"

Checklist: Preventing license mistakes

Open Source Licenses: The Day a Lawyer Called Because I Ran `npm install`