본문 바로가기
목차
CE

Open Source Licenses

by ds31x 2025. 9. 19.
728x90
반응형

오픈 소스 소프트웨어 개발과 배포에 있어서 핵심적인 역할을 하는 몇 가지 라이선스들이 존재함.

 

이 글에서는 5가지 주요 오픈 소스 라이선스에 대해 간략히 정리함.

https://en.wikipedia.org/wiki/Open-source_license

1. BSD 라이선스 (1980년)

역사:

  • 1980년에 UC Berkeley에서 4.0 Berkeley Software Distribution(4.0BSD) 운영 체제와 함께 4개의 절로 구성된 BSD 라이선스(4-clause BSD license)가 함께 자리잡기 시작함 (일종의 초안).
  • 1999년 7월 22일, UC Berkeley의 기술 라이선싱 사무소(Office of Technology Licensing) 책임자 William Hoskins에 의해 광고 조항(advertising clause, 3절)이 공식적으로 제거(removed)되어 3개의 절로 구성된 BSD 라이선스가 됨.

 


특징:

  • 허용적 라이선스(permissive license): MIT와 유사하게 자유로운 사용 조건
  • 광고 조항(advertising clause)의 문제:
    • 초기 4절 BSD 라이선스는 실제 마케팅 광고 자료(브로셔, 웹사이트, 제품 광고 등)에서 UC Berkeley를 반드시 언급해야 했음
    • 예를 들어:
      • 소프트웨어 제품 광고: "This product includes software developed by UC Berkeley"
      • 회사 웹사이트, 제품 브로셔, 신문 광고 등에 이런 문구 필수 삽입
    • 문제점:
      • 다른 개발자들도 유사한 조항을 추가하면서, 광고 한 페이지가 크레딧으로 가득 차게 되는 상황 발생
  • 현재 널리 사용되는 3절 BSD 라이선스(Modified BSD License 또는 New BSD License)는 이 광고 조항이 제거된 버전임.
  • 3절 BSD 라이선스는 MIT 라이선스와 유사하지만 추천/후원 금지 조항(non-endorsement clause)(제3절)을 추가로 포함되어 있음.
    • 의미: "UC Berkeley나 기여자들이 이 제품을 추천한다"고 광고에서 말하는 것을 금지
    • 구체적 예시:
      • "UC Berkeley 추천 제품!"
      • "BSD 개발자들이 보증하는 소프트웨어!"
    • 목적: 원작자의 명성을 무단으로 마케팅에 악용하는 것을 방지
  • 변경 사항 알림 을 요구하지 않음 (MIT와 동일하게 수정 내역 알릴 의무 없음)
  • 수정, 배포, 상업적 사용이 저작권 표시면책 고지(disclaimer) 유지만으로 가능함.

구체적인 의무사항:

저작권 표시(Copyright Notice): 원본 소스코드나 바이너리에 다음과 같은 정보 포함

   Copyright (c) 1990, 1993
   The Regents of the University of California.  All rights reserved.

 

면책 고지(Disclaimer): 소프트웨어 결함으로 인한 손해에 대해 원작자가 책임지지 않는다는 법적 면책 문구

   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...

 

실무 적용: LICENSE 파일에 전체 라이선스 텍스트를 포함하거나, 각 소스파일 상단에 저작권 정보를 명시하면 됨.


실무 적용 예시 - BSD 라이브러리를 사용하는 경우:

시나리오: JSON 파서 라이브러리(BSD 라이선스)를 내 프로젝트에서 사용

 

방법 1: LICENSE 파일에 포함

my\_project/  
├── src/  
├── LICENSE ← 내 프로젝트와 사용한 라이브러리 라이선스 모두 포함  
└── README.md

LICENSE 파일 내용:  
\=== My Project License ===  
MIT License - Copyright (c) 2024 홍길동

\=== Third Party Libraries ===  
JSON Parser Library - BSD 3-Clause License  
Copyright (c) 2020, ABC Company  
All rights reserved.  
\[전체 BSD 라이선스 텍스트...\]

 

방법 2: 소스파일에서 사용 시 명시

/*
 * My Application
 * Copyright (c) 2024 홍길동 - MIT License
 */

/*
 * Using JSON Parser Library
 * Copyright (c) 2020, ABC Company - BSD 3-Clause License
 * All rights reserved.
 */
#include "json_parser.h"  // BSD 라이선스 라이브러리

int main() {
    // BSD 라이브러리 사용
    JsonObject* obj = json_parse("{\"name\":\"test\"}");

    // 내 코드
    printf("Parsed successfully\n");

    json_free(obj);
    return 0;
}

 

방법 3: NOTICE 파일 생성

  • 기업에서 많이 사용하는 방식
  • 써드파티 컴포넌트 집중 관리
NOTICE 파일:
This software includes the following third-party components:

1. JSON Parser Library (BSD 3-Clause License)
   Copyright (c) 2020, ABC Company
   Source: https://github.com/example/json-parser

 


BSD3-Clause 라이선스 전문:

BSD 3-Clause License

Copyright (c) [year], [fullname]
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.

라이선스 해석:

  • 조건1: 소스코드 배포 시 저작권 표시, 조건 목록, 면책 고지 유지
  • 조건2: 바이너리 배포 시 문서에 저작권 표시, 조건 목록, 면책 고지 포함
  • 조건3: 저작권자나 기여자 이름을 제품 홍보에 무단 사용 금지 (추천/후원 금지 조항)
  • 면책: 소프트웨어 사용으로 인한 모든 손해에 대해 원작자 면책

2. MIT 라이선스 (1984년)

역사:

  • MIT 라이선스의 기원은 1984년으로 거슬러 올라감.
  • 컴퓨터 과학자 Jerry Saltzer의 회고에 따르면, MIT 연구실에서 TCP/IP 구현(implementation) 작업 중 라이선스 아이디어가 나왔고, 1984년 1월 10일에 초기 버전(initial version)이 대학 간 네트워크(ARPANET 등)를 통해 전송(transmitted)되었다고 함.
  • 1984년 2월 1일: MIT 라이선스가 최초로 소프트웨어 출판(software publication)에 사용 됨:
    • 이때 "소프트웨어 출판"이란 현재처럼 GitHub에 올리는 것이 아니라, MIT가 개발한 소프트웨어를 외부 사람들이 사용할 수 있도록 공식적으로 배포(distribution)하는 것을 의미.
    • 1980년대에는 인터넷이 없었기 때문에:
      • 자기테이프(magnetic tape)나 플로피 디스크(floppy disk)에 소프트웨어를 복사해서 배포
      • 대학이나 연구소에서 공식 문서와 함께 소프트웨어를 "발표(release)"하고 배포
      • 마치 책을 출판하듯이 정식으로 세상에 내놓는다는 의미로 "출판(publication)"이라는 용어 사용
  • 1985년에는 X Window System과 Project Athena를 위한 새로운 버전이 만들어져 1986년 2월에 릴리즈(released)되었음.
  • 이후, X11과 함께 1987년 이후 널리 사용되었고 오늘날 우리가 아는 간결한 MIT 라이선스 형태로 정착함.

특징:

  • 허용적 라이선스(permissive license): BSD 라이선스와 함께 매우 자유로운 사용 조건임.
  • 매우 간결하고 명료한 문장으로 작성되어 이해하기 쉬움.
  • 저작권 표시(copyright notice)와 라이선스 표시(license notice) 만을 요구하며, 개발자에게 최소한의 제약만 부과함.
  • 사용(use), 수정(modify), 복제(copy), 배포(distribute), 서브라이선싱(sublicense), 상업적 판매(sell) 등이 거의 제한 없이 허용됨
  • 변경 사항 알림 을 요구하지 않음 (코드 수정해도 따로 알릴 의무 없음)
  • 이러한 간결성과 자유로운 특성으로 인해 오픈 소스뿐만 아니라 상업적 소프트웨어 개발에도 널리 사용되고 있음.

MIT 라이선스 전문:

MIT License

Copyright (c) [year] [fullname]

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.

라이선스 해석:

  • 조건(Conditions): 저작권 표시와 라이선스 표시만 유지하면 됨
  • 권한(Permissions): 사용, 수정, 배포, 서브라이선싱, 상업적 판매 모두 허용
  • 제한(Limitations): 책임과 보증을 제공하지 않음 (면책)

3. GNU General Public License - GPL (1989년)

역사:

  • 1989년에 Richard Stallman에 의해 GNU General Public License v1이 발표(released)됨.
  • 이는 GNU 프로젝트의 일환으로, 초기 GNU Emacs, GNU Debugger, GNU C Compiler에 사용된 유사한 라이선스를 통합(unifying)한 것이었음.
  • 1991년에 GPLv2가 발표되었으며, 가장 큰 변화는 "Liberty or Death" 조항의 도입(introduction)된 점임.

 


특징:

  • Copyleft 라이선스: 허용적 라이선스(permissive license)와 반대되는 상호적 라이선스!
  • Copyleft 개념을 구현한 최초의 라이선스임.

참고: Copyleft란?

  • 어원: Copyright(저작권)의 반대 개념으로 만든 일종의 언어유희 ("Copy"+"left")
  • 핵심 아이디어: 저작권법을 역이용하여 소프트웨어의 자유를 영구히 보장
  • 작동 원리:
    • copyright: 내 코드 함부로 쓰지 말 것!
    • copyleft: 내 코드를 써도 되지만, 너도 같은 조건으로 공개해!

Copyleft의 3단계 메커니즘:

  1. 자유 부여: GPL 소프트웨어를 자유롭게 사용/수정/배포 허용
  2. 조건 부과: 수정된 버전도 반드시 GPL로 공개해야 함
  3. 전파 효과: GPL 코드와 결합된 모든 소프트웨어가 GPL이 되는 효과를 가짐.

 


구체적 예시:

개발자 A: GPL 라이브러리 사용해서 상용 소프트웨어 개발
결과: 전체 소프트웨어를 GPL로 공개해야 함 (소스코드 포함)

vs.

개발자 B: MIT 라이브러리 사용해서 상용 소프트웨어 개발  
결과: 소스코드 공개 의무 없음
  • GPL 소프트웨어를 수정하여 배포하는 경우, 수정한 소프트웨어도 반드시 GPL로 배포해야 하며, 소스코드도 공개해야 함.
  • 변경 사항 알림 이 요구됨 (이를 같이 요구하는 Apache보다 더 엄격함 - 소스코드 전체 공개를 요구!)
  • "Liberty or Death" 조항 (GPLv2에서 도입): GPL의 핵심 철학을 구현한 강력한 조항
    • 의미: "자유롭게 배포할 수 없다면 아예 배포하지 마라"
    • 구체적 작동: 특허나 기타 제약으로 인해 GPL의 자유(소스 공개, 재배포 등)를 보장할 수 없다면, 그 소프트웨어는 배포 자체가 금지됨
    • 예시: A회사가 GPL 소프트웨어에 특허 제약을 걸어서 사용자들이 자유롭게 수정/재배포할 수 없게 만들면, 그 소프트웨어는 더 이상 배포될 수 없음
    • 목적: GPL의 자유를 훼손하려는 시도를 원천 차단
  • 상호적(reciprocal) 라이선스 또는 강한 copyleft(strong copyleft) 라이선스로, 소프트웨어의 자유로운 성격을 영구히 보장함.
  • 허용적 라이선스(permissive license)들과 달리, 독점 소프트웨어(proprietary software)에 통합될 수 없도록 설계됨.

4. GNU Lesser General Public License - LGPL (1991년)

역사:

  • 1991년 6월에 GNU Library General Public License v2.0으로 처음 발표(published)됨
  • GPLv2와 버전 번호를 맞추기 위해 버전 2로 시작함 (v1이 없다는 애기임).
  • 1999년에 2.1 버전에서 GNU Lesser General Public License로 이름이 변경(renamed)됨.
  • 2007년에 LGPLv3가 발표되었음.

특징:

  • 약한 copyleft 라이선스(weak copyleft license):
    • GPL보다 유연하지만 여전히 copyleft 계열
    • Weak copyleft 또는 약한 copyleft 라이선스로 불림.
  • 주로 소프트웨어 라이브러리(library)에 적용됨 (때문에 원래 이름에 Library가 포함됨).
  • 단순히 LGPL 라이브러리를 동적으로 링크하여 사용(dynamic linking)하는 프로그램은 LGPL을 따르지 않아도 됨.
  • 하지만 LGPL 라이브러리 자체를 수정한 경우에는, 해당 수정된 부분을 LGPL 조건하에 공개해야 함.
  • LGPL 라이브러리를 정적으로 링크(static linking)하는 경우에는,
    1. 라이브러리 자체를 수정했다면 해당 수정 사항을 LGPL 조건하에 공개해야 하고,
    2. 라이브러리를 수정하지 않았다 하더라도, 최종 사용자가 원래의 LGPL 라이브러리(또는 이후 변경된 LGPL 라이브러리)로 다시 링크(relink) 할 수 있도록 지원해야 함 (정적으로 링크시킬 수 있도록 애플리케이션의 object 파일 제공 등)
  • 변경 사항 알림 이 조건부로 요구됨 (라이브러리 자체를 수정한 경우에만 적용)
  • 이러한 특성으로 인해 상업적 소프트웨어(commercial software)에서도 사용하기 쉬운 라이선스임.

5. Apache 라이선스 (1995년)

역사:

  • 1995년에 Apache Group(후에 Apache Software Foundation)이 Apache HTTP Server와 함께 첫 번째 버전을 도입(introduced)했음.
  • 초기 라이선스는 본질적으로 4절 BSD 라이선스와 같았으며, 조직 이름만 바뀌고 Apache 이름을 파생된 소프트웨어(derivative software)에서 사용하지 못하게 하는 조항이 추가되었었음.
  • 2000년에 Apache License 1.1이 발표
  • 2004년 1월에 Apache License 2.0이 발표(released)됨.

특징:

  • 허용적 라이선스(permissive license): 특허 보호 기능이 강화된 허용적 라이선스!
  • Apache License 2.0의 주요 개선사항은 명시적 특허 권리 부여(explicit patent grant)특허 보복 조항(patent retaliation clause) 추가임.
    • Apache License 2.0으로 배포시 해당 코드와 관련된 특허도 자동으로 사용 허락된 것임.
    • 단, 특허권 “전부”가 아니라, 그 기여 코드에 필요한 범위까지만 허가됨.
  • 사용, 수정, 배포가 "원본 코드 변경 사항에 대한 알림(notice of changes)"과 "원본 Apache 코드의 라이선스 및 저작권 표시" 포함 시 자유롭게 가능합니다.
  • 변경 사항 알림 을 반드시 명시해야 함 (MIT, BSD와 달리 수정 내역 기록 의무를 가짐.)

변경 사항 알림 요구사항:

대상: Apache 라이선스 코드를 수정한 경우

내용: 어떤 파일을 언제 누가 수정했는지 명시

방법: 주석, CHANGES 파일, 또는 별도 문서에 기록

 

예시:

// Modified by 홍길동 on 2024-12-20
// Changed: Added error handling for null input
  • 목적: 원본 작성자가 버그 리포트를 잘못 받는 것을 방지

원본 라이선스/저작권 표시 요구사항:

대상: 사용한 Apache 라이선스 코드의 원본 정보

포함 내용:

Copyright 2019 Apache Software Foundation
Licensed under the Apache License, Version 2.0

 

유지 의무: 원본 Apache 코드의 저작권과 라이선스 정보를 삭제하거나 수정하면 안 됨

목적: 원작자에 대한 적절한 크레딧 제공


특허 보복 조항의 작동 방식:

  1. 특허 권리 부여: 기여자(contributor)가 자신의 특허를 사용자에게 무료로 사용할 수 있도록 허가함.
  2. 보복 메커니즘: 만약 사용자가 Apache 코드에 대해 특허 소송을 제기하면, 그 사용자가 받았던 모든 특허 사용 권리가 자동으로 종료됨.
  3. 구체적 예시: A회사가 Apache 라이브러리를 사용하다가 나중에 "이 Apache 코드가 우리 특허를 침해했다"며 소송을 걸면, A회사는 더 이상 그 Apache 라이브러리를 사용할 수 없게 됨.
  • 이는 "상호확증파괴" 전략으로, 특허 공격을 억제하고 Apache 생태계를 보호함.
  • MIT 라이선스와 달리 특허 관련 명시적 조항을 포함하여 상업적 사용에 더 안전한 법적 기반을 제공.

결론

각 오픈 소스 라이선스의 특성은 다음과 같음:

  • BSD (1980): 최초의 허용적 라이선스
  • MIT (1984): 최대한 간결하고 자유로운 허용적 라이선스
  • GPL (1989): 소프트웨어 자유를 영구히 보장하는 강한 copyleft 라이선스(strong copyleft license)
  • LGPL (1991): 라이브러리 사용에 특화된 약한 copyleft 라이선스(weak copyleft license)
  • Apache (1995): 허용적이면서도 특허 보호 기능을 강화한 라이선스

상업적 이용 자유도 순서 는 다음과 같음(자유로운 것부터 제한적 것으로):

  1. MIT, BSD: 거의 모든 상업적 이용 자유
    • 독점 소프트웨어에 통합 가능
    • 소스코드 공개 의무 없음
    • 라이선스 변경 가능
  2. Apache 2.0: 허용적이지만 특허 조건 존재
    • 독점 소프트웨어에 통합 가능
    • 소스코드 공개 의무 없음
    • 단, 특허 소송 시 사용 권리 상실
  3. LGPL: 라이브러리로만 사용 시 자유
    • 동적 링크로 사용: 상업적 이용 자유
    • 라이브러리 수정/정적 링크: 소스코드 공개 필요
  4. GPL: 가장 제한적
    • GPL 코드 포함 시 전체 소스코드 공개 필요
    • 상업적 판매는 가능하지만 소스 공개 의무

참고 자료:

728x90

'CE' 카테고리의 다른 글

glob 이란?  (0) 2025.10.04
Font: TTF vs. OTF  (1) 2025.09.20
vscode 실행하기 (Windows)  (0) 2025.09.15
[Term] Serialization-Data Exchanged Format  (1) 2025.08.06
[Term] Ligatures (합자), glyph  (0) 2025.08.04