⚖️
오픈소스 라이선스 핵심 치트시트

오픈소스 소프트웨어 라이선스 완벽 가이드: MIT, Apache 2.0, BSD, GPL, LGPL, AGPL, MPL 비교 분석, 3초 선택 의사결정 트리, 저작권 및 특허권 조항, SPDX 표준 식별자, 언어별 소스코드 헤더 표기법, 서드파티 라이선스 의존성 감사(Audit) 및 기업용 거버넌스 체크리스트
#license#opensource#mit#apache#gpl#spdx#copyright#governance#audit#compliance최종 업데이트: 2026-10-08
오픈소스 라이선스 핵심 치트시트 핵심 명령어 및 실전 가이드

## 1. 필수 사전 요건 & 오픈소스 법적 기초 (Prerequisites)

오픈소스(Open Source) 코드는 **"무료로 누구나 마음대로 쓸 수 있는 공공재"가 아닙니다.** 저작권자(Copyright Holder)가 특정한 이용 허락 조건(License Terms)을 명시하고, 이용자가 그 조건을 준수한다는 전제하에 배포되는 법적 계약입니다.

### ⚖️ 1. 라이선스 미표기 저장소의 법적 의미 (All Rights Reserved)
- GitHub 등 공개 저장소에 소스코드가 올라와 있어도 `LICENSE` 파일이 없으면 **기본적으로 저작권법상 '모든 권리 보유(All Rights Reserved)' 상태**입니다.
- 즉, 타인은 해당 코드를 눈으로 볼 수만 있을 뿐, 복제·수정·배포·상업적 사용이 **원칙적으로 불법**입니다. 자신의 프로젝트를 남들이 자유롭게 쓰게 하려면 반드시 공식 라이선스를 명시해야 합니다.

### 📦 2. 프로젝트 라이선스 적용의 3대 필수 요소
프로젝트에 오픈소스 라이선스를 올바르게 부여하기 위해 다음 3단계를 구성합니다:
1. **저장소 루트에 `LICENSE` (또는 `LICENSE.txt`) 파일 배치**: 라이선스 공식 전문과 저작권 표기(`Copyright (c) YYYY Name`) 포함.
2. **패키지 매니저 메타데이터 명시**: `package.json`, `pom.xml`, `pyproject.toml` 등에 공식 SPDX 식별자 기재.
3. **소스코드 파일 상단 SPDX 헤더 주석 표기**: 파일 복제 및 단독 사용 시에도 라이선스 추적이 가능하도록 간결한 표준 헤더 삽입.

### 🛠️ 3. 라이선스 감사 및 분석 CLI 도구 설치
프로젝트의 자체 라이선스 상태 및 서드파티(npm, pip 등) 의존성 라이선스를 진단하는 유용한 도구들입니다:

```bash
# 1. GitHub 공식 라이선스 감지 CLI (저장소의 LICENSE 판별)
gem install licensee
licensee detect .

# 2. Node.js 의존성 라이선스 검사 도구
npm install -g license-checker
license-checker --summary

# 3. Python 가상환경 의존성 라이선스 추출 도구
pip install pip-licenses
pip-licenses --summary

# 4. Rust Cargo 라이선스 및 보안 감사 도구
cargo install cargo-deny
cargo deny check licenses
```

---

## 2. 직관적인 멘탈 모델 & 의사결정 트리 (Mental Model)

### 🌳 1. 나에게 맞는 라이선스 선택 3초 의사결정 트리

```
[내 프로젝트를 오픈소스로 배포할 때]
                    │
   누군가 내 코드를 수정해서 배포할 때,
   그 사람의 변경된 소스코드도 공개하게 만들고 싶은가?
                    │
         ┌──────────┴──────────┐
      [ 아니오 ]             [ 예 ]
 (최대한 자유롭게 배포)     (카피레프트/소스코드 공개 강제)
         │                     │
  특허권 및 상표권 분쟁을       어떤 범위까지 수정한 코드를
  명시적으로 방지하고 싶은가?     공개하도록 강제할 것인가?
         │                     │
    ┌────┴────┐           ┌────┴───────────────┐
 [아니오]    [예]      [네트워크/웹서비스] [전체 바이너리/링크]  [수정한 파일만]
    │         │       (SaaS 백엔드 포함)   (파생 저작물 전체)    (독립 파일 유지)
    ▼         ▼           │                    │                 │
   MIT     Apache 2.0     ▼                    ▼                 ▼
 (가장 단순  (특허 보호,     AGPL v3              GPL v3            MPL 2.0
  대중적)   기업 친화적)  (클라우드 우회 방지) (강한 카피레프트) (약한 카피레프트)
```

---

### 📊 2. 오픈소스 라이선스 자유도 스펙트럼 (Permissive vs Copyleft)

```
[허용형 (Permissive)] ◀───────────────────────────────▶ [카피레프트 (Copyleft)]
 ─────────────────────────────────────────────────────────────────────────────
  Unlicense / CC0  │  MIT / BSD-2  │  Apache 2.0  │  MPL 2.0  │  LGPL v3  │  GPL v3   │  AGPL v3
 ──────────────────┼───────────────┼──────────────┼───────────┼───────────┼───────────┼──────────
  저작권 완전 포기 │ 단순 고지만   │ 특허권 보호  │ 파일 단위 │ 동적 링크 │ 파생 코드 │ 웹 서비스
  (Public Domain)  │ 요구          │ 상표권 배제  │ 공개 의무 │ 허용      │ 전체 공개 │ 실행도 공개
```

---

### 📑 3. 주요 오픈소스 라이선스 핵심 비교표

| 라이선스 (SPDX) | 구분 | 소스코드 공개 의무 | 상업적 이용 | 특허권 명시 허용 | 2차 저작물 라이선스 변경 | 대표 프로젝트 |
| :--- | :--- | :---: | :---: | :---: | :---: | :--- |
| **MIT** | 허용형 (Permissive) | ❌ 불필요 | ✅ 가능 | ⚠️ 묵시적 | ✅ 자유 변경 가능 | React, Vue, Node.js |
| **Apache-2.0** | 허용형 (Permissive) | ❌ 불필요 | ✅ 가능 | ✅ 명시적 특허 부여 | ✅ 자유 변경 가능 | Kubernetes, Android, Spring |
| **BSD-3-Clause** | 허용형 (Permissive) | ❌ 불필요 | ✅ 가능 | ⚠️ 묵시적 | ✅ 자유 변경 가능 | Go, Redis(초기), Nginx |
| **MPL-2.0** | 약한 카피레프트 | ⚠️ 수정된 파일만 | ✅ 가능 | ✅ 명시적 특허 부여 | ❌ 동일 라이선스(파일) | Firefox, Terraform(구) |
| **LGPL-3.0** | 약한 카피레프트 | ⚠️ 라이브러리만 | ✅ 가능 | ✅ 명시적 특허 부여 | ❌ 동일 라이선스 | FFmpeg, 7-Zip DLL |
| **GPL-3.0** | 강한 카피레프트 | ✅ 전체 소스 공개 | ✅ 가능 | ✅ 명시적 특허 부여 | ❌ 무조건 GPL-3.0 | Linux 커널(v2), Git, Bash |
| **AGPL-3.0** | 네트워크 카피레프트 | ✅ 전체 소스 공개 | ✅ 가능 | ✅ 명시적 특허 부여 | ❌ 무조건 AGPL-3.0 | Grafana(신), Mastodon |

---

## 3. 대표 라이선스별 특징 & 바로 쓰는 LICENSE 템플릿

### 🟢 1. MIT License (가장 널리 쓰이는 표준 허용형)
- **핵심 요약**: "무엇을 하든 자유이지만, 원저작자 저작권 표시 및 면책 조항만 보존하세요."
- **의무 사항**: 라이선스 전문과 저작권 고지(`Copyright (c) YYYY 저작자`)를 복제물에 포함해야 함.
- **상업적 사용**: 비공개 상용 솔루션에 포함하거나 판매 가능.

#### 📄 바로 복사해서 쓰는 `LICENSE` (MIT)
```text
MIT License

Copyright (c) 2026 홍길동 (Hong Gil-dong)

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
```

---

### 🔵 2. Apache License 2.0 (기업 및 엔터프라이즈 권장 허용형)
- **핵심 요약**: MIT의 자유로움에 **특허권 보호(Patent Grant)** 및 **상표권 보호(Trademark Restriction)**가 체계적으로 결합된 기업 표준 라이선스.
- **특허 보복 조항**: 사용자가 기여자에게 특허 침해 소송을 제기하면, 해당 사용자에게 부여된 소프트웨어 특허 라이선스가 즉시 종료됩니다.
- **의무 사항**: 
  - 저작권 고지 보존
  - 원본 코드를 수정한 경우 "수정되었다는 사실(Notice of Modification)"을 소스 파일에 명시
  - 프로젝트에 `NOTICE` 파일이 포함되어 있다면 재배포 시 해당 내용 보존

#### 📄 바로 복사해서 쓰는 `NOTICE` 파일 예시 (Apache 2.0)
```text
My Awesome Project
Copyright 2026 홍길동 (Hong Gil-dong)

This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
```

---

### 🟡 3. BSD 3-Clause License (보증 및 홍보 제한형)
- **핵심 요약**: MIT와 거의 유사하나, **3번째 조항(No Endorsement)**을 통해 원저작자나 기여자의 이름을 동의 없이 제품 홍보나 보증 목적으로 사용할 수 없도록 법적으로 차단합니다.

#### 📄 바로 복사해서 쓰는 `LICENSE` (BSD 3-Clause)
```text
BSD 3-Clause License

Copyright (c) 2026, 홍길동 (Hong Gil-dong)
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived from
   this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
```

---

### 🔴 4. GNU GPL v3 (강한 카피레프트 / General Public License)
- **핵심 요약**: "자유 소프트웨어의 자유를 영구히 보장한다." 코드를 가져다 쓰거나 결합하여 바이너리로 배포하는 순간, **전체 프로젝트의 소스코드를 동일한 GPL v3 라이선스로 공개해야 합니다 (전염성).**
- **티보이제이션(Tivoization) 방지**: 하드웨어 기기에 탑재될 경우, 사용자가 수정된 소프트웨어를 기기에 설치하여 실행할 수 있는 설치 정보(키, 서명)까지 제공해야 합니다.
- **주의점**: 사내 독점 소스코드가 담긴 기업용 클로즈드 솔루션에 GPL 코드를 직접 정적 링크(Static Link)하여 배포하면 사내 전체 소스코드를 공개해야 하는 치명적 리스크가 발생합니다.

---

### 🟣 5. GNU LGPL v3 (약한 카피레프트 / Lesser GPL)
- **핵심 요약**: 주로 공유 라이브러리(C/C++ .so, .dll 등)에 사용됩니다.
- **동적 링크 허용**: 응용 프로그램이 LGPL 라이브러리를 **동적 링크(Dynamic Linking)** 형태로만 호출하여 사용할 경우, 메인 응용 프로그램의 소스코드는 비공개로 유지할 수 있습니다.
- 단, LGPL 라이브러리 자체의 버그를 수정하거나 수정한 라이브러리를 번들링하여 배포한다면 해당 라이브러리의 수정 소스코드는 반드시 공개해야 합니다.

---

### 🌐 6. GNU AGPL v3 (네트워크/SaaS 카피레프트 / Affero GPL)
- **핵심 요약**: GPL의 최대 맹점이었던 **"클라우드 서비스(SaaS) 루프홀"을 차단**한 라이선스입니다.
- GPL은 바이너리를 "배포(Distribute)"할 때만 소스 공개 의무가 발생하여, 코드를 서버에 올려놓고 웹 API로만 서비스(SaaS)하면 소스 공개를 피할 수 있었습니다.
- AGPL은 **네트워크를 통해 해당 소프트웨어와 상호작용하는 원격 사용자에게도 소스코드 전체를 다운로드할 수 있는 수단(링크 등)을 제공할 것을 법적으로 강제**합니다.
- 백엔드 데이터베이스, 모니터링 엔진(Grafana), 분산 시스템에서 악의적인 클라우드 기업(AWS 등)의 무료 호스팅 재판매를 방지하기 위해 적극 도입되고 있습니다.

---

### 🛡️ 7. Mozilla Public License 2.0 (MPL 2.0 - 실무 친화형 파일 단위 카피레프트)
- **핵심 요약**: GPL과 MIT 사이의 완벽한 실무적 균형점입니다.
- **파일 단위(File-level) 카피레프트**: MPL 라이선스가 걸린 원본 소스 파일(`foo.go`)을 수정한 경우 해당 파일만 소스코드를 공개하면 되며, 해당 파일을 임포트하여 만든 별도의 새로운 파일(`my_business_logic.go`)은 비공개 상용 라이선스로 유지할 수 있습니다.

---

## 4. SPDX 표준 식별자 & 소스코드 파일 상단 표기법 (Header Standard)

### 🏷️ 1. SPDX(Software Package Data Exchange)란?
리눅스 재단(Linux Foundation)에서 제정한 소프트웨어 라이선스 표준 식별자 규격입니다. 긴 라이선스 전문 대신 단 한 줄의 `SPDX-License-Identifier` 주석으로 기계 가독성(Machine-readable)을 확보합니다.

| 라이선스 정식 명칭 | 표준 SPDX Identifier |
| :--- | :--- |
| MIT License | `MIT` |
| Apache License 2.0 | `Apache-2.0` |
| BSD 2-Clause "Simplified" | `BSD-2-Clause` |
| BSD 3-Clause "New" or "Revised" | `BSD-3-Clause` |
| GNU General Public License v3.0 only | `GPL-3.0-only` |
| GNU General Public License v3.0 or later | `GPL-3.0-or-later` |
| GNU Lesser General Public License v3.0 | `LGPL-3.0-only` |
| GNU Affero General Public License v3.0 | `AGPL-3.0-only` |
| Mozilla Public License 2.0 | `MPL-2.0` |
| The Unlicense | `Unlicense` |
| Creative Commons Zero v1.0 Universal | `CC0-1.0` |

---

### 💻 2. 언어별 파일 상단 헤더 주석 작성 표준

#### JavaScript / TypeScript (`.js`, `.ts`, `.tsx`, `.vue`)
```typescript
/**
 * Copyright (c) 2026 Hong Gil-dong <gildong@example.com>
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 *
 * SPDX-License-Identifier: MIT
 */

export function calculateTotal(items: number[]): number {
  return items.reduce((acc, cur) => acc + cur, 0);
}
```

#### Python (`.py`)
```python
# Copyright (c) 2026 Hong Gil-dong <gildong@example.com>
# SPDX-License-Identifier: Apache-2.0

import os
import sys

def main() -> None:
    print("Application initialized under Apache 2.0")
```

#### Java / Kotlin (`.java`, `.kt`)
```java
/*
 * Copyright (c) 2026 Hong Gil-dong
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * SPDX-License-Identifier: Apache-2.0
 */

package com.example.service;

public class OrderService {
    // Business logic
}
```

#### Go (`.go`)
```go
// Copyright 2026 The Awesome Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
//
// SPDX-License-Identifier: BSD-3-Clause

package main

import "fmt"
```

#### Shell Script / Dockerfile
```bash
#!/usr/bin/env bash
# Copyright (c) 2026 Hong Gil-dong
# SPDX-License-Identifier: MIT

set -euo pipefail
echo "Deployment automation script"
```

---

### 🔀 3. 복합 라이선스(Dual-license) SPDX 표현식
여러 라이선스 중 선택하거나 결합할 때 논리 연산자(`OR`, `AND`, `WITH`)를 사용합니다:

```text
// 1. MIT 또는 Apache 2.0 중 사용자가 원하는 라이선스 하나를 선택 가능 (듀얼 라이선스)
SPDX-License-Identifier: MIT OR Apache-2.0

// 2. 두 라이선스 조건을 모두 만족해야 함
SPDX-License-Identifier: LGPL-2.1-only AND BSD-2-Clause

// 3. 라이선스 예외 조항 추가 (GPL 코드이지만 런타임 클래스패스 링크 예외 허용)
SPDX-License-Identifier: GPL-2.0-only WITH Classpath-exception-2.0
```

---

## 5. 패키지 매니저별 라이선스 메타데이터 설정 (Package Configs)

### 📦 1. Node.js (`package.json`)
```json
{
  "name": "lucky-awesome-lib",
  "version": "1.0.0",
  "description": "High performance utilities",
  "license": "MIT",
  "author": "Hong Gil-dong <gildong@example.com>",
  "repository": {
    "type": "git",
    "url": "https://github.com/example/lucky-awesome-lib.git"
  }
}
```
> **복합 라이선스 지정 시**: `"license": "(MIT OR Apache-2.0)"`  
> **사내 독점 비공개 패키지 시**: `"license": "UNLICENSED", "private": true`

---

### 🐍 2. Python (`pyproject.toml` - PEP 621 표준)
```toml
[project]
name = "lucky-awesome-tool"
version = "0.1.0"
authors = [
    { name = "Hong Gil-dong", email = "gildong@example.com" }
]
license = { text = "Apache-2.0" }
# 또는 SPDX 식별자 직접 지정:
# license = "Apache-2.0"
classifiers = [
    "License :: OSI Approved :: Apache Software License",
    "Programming Language :: Python :: 3.12",
]
```

---

### ☕ 3. Java Maven (`pom.xml`)
```xml
<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>lucky-core</artifactId>
  <version>1.0.0</version>

  <licenses>
    <license>
      <name>Apache License, Version 2.0</name>
      <url>https://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
      <comments>A business-friendly OSS license</comments>
    </license>
  </licenses>
</project>
```

---

### 🦀 4. Rust (`Cargo.toml`)
```toml
[package]
name = "lucky-fast-engine"
version = "0.1.0"
edition = "2021"
authors = ["Hong Gil-dong <gildong@example.com>"]
license = "MIT OR Apache-2.0"
license-file = "LICENSE-MIT"
description = "Blazing fast computing engine"
```

---

## 6. 의존성 라이선스 자동 감사 & CI/CD 검증 (Automated Compliance)

### 🔍 1. Node.js `license-checker` 실무 활용
기업 사내 정책상 허용된 화이트리스트 라이선스(MIT, Apache, BSD, ISC)만 통과시키고, GPL/AGPL이 섞여 들어오면 빌드를 즉시 실패 처리합니다:

```bash
# 허용 라이선스 외 의존성 발견 시 에러 코드(Exit Code 1) 반환
npx license-checker \
  --production \
  --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD;CC0-1.0" \
  --summary
```

---

### 🐍 2. Python `pip-licenses` 의존성 리포트 생성
```bash
# 프로덕션 설치 패키지의 라이선스 현황 마크다운 테이블 출력
pip-licenses --format=markdown --with-urls --output-file=DEPENDENCY_LICENSES.md
```

---

### 🚀 3. GitHub Actions 라이선스 컴플라이언스 자동 검사 파이프라인
Pull Request가 생성될 때마다 새로 추가된 npm 의존성에 사내 금지 라이선스가 포함되어 있는지 검사하는 완전한 CI 워크플로우입니다:

```yaml
# .github/workflows/license-compliance.yml
name: License Compliance Audit

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  audit-licenses:
    runs-on: ubuntu-latest
    steps:
      - name: 저장소 체크아웃
        uses: actions/checkout@v4

      - name: Node.js 20 설치
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: 의존성 설치 (Production Only)
        run: npm ci --omit=dev

      - name: 라이선스 화이트리스트 정책 검증
        run: |
          echo "=== 서드파티 오픈소스 라이선스 적합성 검사 시작 ==="
          npx license-checker \
            --production \
            --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD;CC0-1.0" \
            --summary
```

---

## 7. 실무 주의사항 & 기업 오픈소스 거버넌스 체크리스트 (Best Practices)

### ⚠️ 1. 개발자가 가장 흔히 저지르는 치명적 실수 TOP 5

1. **상용 솔루션에 GPL 라이브러리 정적 임포트 (Static Linking)**:
   - "인터넷에서 편리한 코드 조각을 가져와 빌드했는데 알고 보니 GPL-3.0 라이브러리였다." ➔ 배포 후 법적 소송 및 사내 전체 핵심 솔루션 코드 공개 요구에 직면할 수 있습니다.
2. **클라우드 SaaS 백엔드에 AGPL 솔루션 탑재**:
   - 내부 데이터 파이프라인이나 서비스 레이어에 AGPL 코드를 직접 통합할 경우, API 사용자에게도 서버 소스코드를 공개해야 하는 위험이 있습니다.
3. **포크(Fork) 및 복제 시 원저작자 Copyright 임의 삭제**:
   - 오픈소스 코드를 가져와 자신의 프로젝트에 넣으면서 파일 상단의 원저작자 저작권 표시를 지우는 것은 **모든 오픈소스 라이선스 공통의 중대한 계약 위반(저작권법 위반)**입니다.
4. **'Source-Available' 비오픈소스와 오픈소스 혼동**:
   - 최근 Redis, MongoDB(SSPL), Elastic(ELv2) 등이 클라우드 벤더(AWS)의 무단 재판매를 막기 위해 OSI 공식 오픈소스가 아닌 독점적 "소스 공개형(Source-Available / BSL)"으로 전환했습니다. 이들 제품을 호스팅 형태로 서드파티에 서비스하는 것은 라이선스 위반이 됩니다.
5. **라이선스가 없는 GitHub 코드 무단 복제**:
   - 오픈소스처럼 보여도 `LICENSE`가 없으면 저작권법상 보호를 받으므로 절대 프로덕션에 직접 복사해 넣으면 안 됩니다. 이슈나 PR을 통해 저작자에게 라이선스 명시를 먼저 요청해야 합니다.

---

### ✅ 2. 기업용 오픈소스 도입 판단 기준표 (Governance Checklist)

```
[안전성 등급]   [라이선스 종류]                 [기업 상용 솔루션 도입 가이드]
─────────────────────────────────────────────────────────────────────────────
🟢 안전 (Green)  MIT, Apache-2.0, BSD, ISC      제약 없이 상용 제품에 탑재 및 재배포 가능
                                                (저작권 고지문 및 LICENSE 파일만 유지)

🟡 주의 (Yellow) MPL-2.0, LGPL-3.0 (동적 링크)  동적 링크 상태 유지 필수.
                                                라이브러리 파일 자체를 수정한 경우에만
                                                해당 수정 코드 공개 준비.

🔴 위험 (Red)    GPL v2/v3, AGPL v3, SSPL        사내 독점 클로즈드 소스 프로젝트에 결합 배포 금지.
                                                독립 프로세스(CLI 실행, 별도 마이크로서비스)로
                                                격리하여 통신하는 아키텍처 필수.
```
💬
오픈소스 라이선스 핵심 치트시트

의견 및 질문

댓글 수정

댓글 삭제
