Day 2 - 자유 소프트웨어와 배포판: 라이선스가 만든 생태계

📌 핵심 정리

• 자유 소프트웨어(FSF, 1985)는 윤리적 자유를, 오픈소스(OSI, 1998)는 실용적 개발 방법론을 강조한다. 코드는 거의 같다.
• 카피레프트 = 저작권법을 역이용해 자유를 강제 보존. 파생물도 같은 라이선스로 공개해야 한다(전염성).
• GPL(전체 공개 의무) / LGPL(동적 링크 시 앱 비공개 가능) / BSD·MIT·Apache 2.0(공개 의무 없음)의 구분이 핵심 출제 포인트.
• 배포판 3대 계열: 레드햇(RPM+dnf/yum), 데비안(DEB+apt), SUSE(RPM이지만 zypper+YaST).
• 패키지 도구는 **저수준(rpm·dpkg, 의존성 수동) ↔ 고수준(dnf/yum·apt, 저장소 기반 자동)**으로 짝을 이룬다.

자유 소프트웨어 vs 오픈소스 — 같은 코드, 다른 철학

라이선스와 배포판 계열은 1급 단골 출제 영역이다. 출발점은 "공짜 소프트웨어"와 "오픈소스"가 역사적·철학적으로 다른 두 운동이라는 사실이다.

자유 소프트웨어(Free Software)

• 1985년 리처드 스톨먼이 설립한 **자유 소프트웨어 재단(FSF)**에서 시작.
• 여기서 "Free"는 무료가 아니라 자유(freedom) — 스톨먼의 유명한 문구 "free as in free speech, not as in free beer(공짜 맥주가 아니라 언론의 자유)".
• 네 가지 자유를 핵심으로 한다.
  • 자유 0: 목적에 상관없이 프로그램을 실행할 자유
  • 자유 1: 프로그램의 작동 원리를 연구하고 수정할 자유(소스 코드 접근 필요)
  • 자유 2: 복제본을 재배포할 자유
  • 자유 3: 수정한 버전을 배포할 자유

오픈소스(Open Source)

• 1998년 **오픈소스 이니셔티브(OSI)**가 주도.
• 에릭 레이먼드 등은 "자유"의 이념적·정치적 색채가 기업 참여를 막는다고 보고, 더 실용적이고 비즈니스 친화적인 "오픈소스"라는 용어를 내세웠다.
• 강조점: 기술적 우수성과 협업 모델.

📚 유래/사례: 스톨먼이 자유 소프트웨어 운동을 시작한 계기는 사소한 사건이었다. MIT 시절 그는 제록스 프린터의 종이 걸림을 알려주는 기능을 추가하려 했지만, 제조사가 소스 코드 공개를 거부했다. "내 손에 있는 도구를 내가 고칠 수 없다"는 좌절이 평생의 운동으로 이어졌다. 작은 프린터 한 대가 거대한 자유 소프트웨어 운동의 씨앗이 된 셈이다.

카피레프트 — GPL의 핵심 무기

• 일반 저작권(copyright)은 "권리를 보유(reserved)"해 복제·수정을 막는다. **카피레프트(Copyleft)**는 저작권법을 역이용해 자유를 강제로 보존한다.
• 핵심 규칙: "자유롭게 쓰고 고칠 수 있다. 단, 배포하는 파생물도 반드시 같은 자유를 보장해야 한다."
• 자유를 받은 사람은 그 자유를 다음 사람에게도 넘겨주어야 한다 → 이 전염성(viral) 때문에 카피레프트 코드를 가져다 쓰면 결과물도 같은 라이선스로 공개할 의무가 생긴다.
• 이를 구현한 대표 라이선스가 **GPL(GNU General Public License)**이다.

💡 개념: "Copyleft"는 "Copyright"의 반대말 말장난이다. Right(오른쪽/권리)를 Left(왼쪽)로 뒤집어, 권리를 독점하는 대신 자유를 보존한다는 뜻을 담았다. FSF 로고에 "All rights reversed(모든 권리 역전)"라고 써 있는 것도 같은 농담이다.

주요 오픈소스 라이선스 비교

라이선스는 크게 **카피레프트 계열(GPL)**과 **허용적(permissive) 계열(BSD, MIT, Apache)**로 나뉜다. 시험에서는 "파생물 공개 의무"의 유무를 정확히 구분하는 것이 핵심이다.

• GPL: 가장 강력한 카피레프트. GPL 코드를 포함하거나 링크한 프로그램은 전체를 GPL로 공개해야 한다. 리눅스 커널이 GPLv2를 채택했으므로 커널에 통합되는 드라이버 등은 원칙적으로 GPL을 따라야 한다.
• LGPL(Lesser GPL): GPL을 완화한 "약한 카피레프트". 주로 라이브러리에 적용되며, 폐쇄 소스 프로그램이 LGPL 라이브러리를 동적 링크해 쓰는 것을 허용한다. 단 라이브러리 자체를 수정하면 그 부분은 공개해야 한다.
  • glibc(C 표준 라이브러리)가 LGPL인 이유: 모든 프로그램이 glibc를 링크하는데 GPL을 강제하면 리눅스에서 폐쇄 소스 프로그램을 만들 수 없게 되기 때문.
• BSD/MIT: 허용적 라이선스의 대표. "저작권 표시만 유지하면 무엇이든 해도 좋다" → 수정본을 폐쇄 소스 상업 제품으로 만들어도 된다. 기업이 선호한다. macOS 커널 일부가 BSD에서 왔고, 수많은 상업 제품이 BSD/MIT 코드를 품고 있다.
• Apache 2.0: MIT처럼 허용적이지만 명시적인 특허 라이선스 부여 조항으로 기여자의 특허 소송으로부터 사용자를 보호한다. 안드로이드, 쿠버네티스 등이 채택.

# 시스템에 설치된 패키지의 라이선스 정보 확인
# RPM 계열
rpm -qi bash | grep License
# Debian 계열 - 패키지 저작권 문서 위치
ls /usr/share/doc/bash/copyright

⚠️ 함정: 시험에서 "LGPL 라이브러리를 동적 링크한 폐쇄 소스 프로그램은 소스를 공개해야 하는가?"라는 함정이 자주 나온다. 답은 공개하지 않아도 된다이다. LGPL의 핵심이 바로 이 점이다. 반면 GPL 라이브러리를 링크하면 전체를 공개해야 한다. "동적 링크 + LGPL = 비공개 가능"을 기억하자.

🔍 더 깊이: GPL에는 버전이 있다. GPLv2(1991)와 GPLv3(2007)가 대표적이다. GPLv3는 "Tivoization(하드웨어로 GPL 소프트웨어 수정을 막는 행위)"을 금지하고 특허 조항을 강화했다. 리누스 토르발스는 GPLv3의 일부 조항에 반대해 리눅스 커널을 여전히 GPLv2에 묶어두고 있다. 이는 리눅스 커널의 중요한 라이선스 특징이다.

배포판이란 무엇인가

Day 1에서 "리눅스는 커널만"이라 배웠다. 우리가 설치하는 우분투·CentOS는 배포판(distribution, distro), 즉 다음을 하나로 묶은 완제품이다.

• 리눅스 커널

• GNU 시스템 도구(bash, coreutils, gcc 등)

• 패키지 관리 시스템(설치·업데이트·의존성 관리)

• 데스크톱 환경(GNOME, KDE 등, 서버판은 생략)

• 기본 응용 프로그램과 설정

• 배포판마다 철학과 대상이 다르다: 안정성 최우선 서버용, 최신 기술을 빠르게 도입하는 데스크톱용, 학습용, 보안 특화 등 수백 개.

• 시험에서 중요한 것은 **계열(family)**이다. 대부분의 배포판은 세 뿌리에서 갈라졌고, 같은 계열은 패키지 관리 방식과 디렉터리 구조가 비슷하다.

레드햇(Red Hat) 계열 — RPM의 세계

• 기업 서버 시장의 강자. 1994년 설립된 레드햇사의 RHEL(Red Hat Enterprise Linux)이 중심.
• 특징: RPM(Red Hat Package Manager) 패키지 형식 + 의존성을 자동 해결하는 YUM/DNF.

• 패키지 관리는 두 단계다.
  • 저수준 rpm: 개별 .rpm 파일을 설치하지만 의존성을 자동 해결하지 못한다.
  • 고수준 yum(구버전)·dnf(신버전): 저장소(repository)에서 패키지와 의존성을 함께 내려받아 자동 설치.

# 저수준 - 개별 패키지 파일 설치(의존성 수동)
rpm -ivh package.rpm        # install, verbose, hash
rpm -qa                     # 설치된 모든 패키지 조회
rpm -e package              # 패키지 제거
 
# 고수준 - 의존성 자동 해결(저장소 기반)
dnf install httpd           # 또는 yum install httpd
dnf update                  # 전체 업데이트
dnf remove httpd
dnf search keyword

📚 유래/사례: "Fedora"라는 이름은 레드햇 로고의 빨간 중절모(fedora hat)에서 왔다. Fedora는 레드햇의 실험실 역할을 한다. 여기서 검증된 최신 기술이 안정화되면 RHEL에 들어간다. 즉 Fedora → RHEL → CentOS(클론)로 기술이 흘러내려가는 구조다.

데비안(Debian) 계열 — DEB와 APT의 세계

• 커뮤니티 중심으로 자유 소프트웨어 정신을 가장 충실히 따르는 계열.
• 1993년 이안 머독(Ian Murdock)이 시작. 이름은 그와 당시 여자친구 데브라(Debra)의 이름을 합친 것(Deb + Ian).
• 형식/도구: DEB(.deb) 패키지 + APT(Advanced Package Tool).

• 저수준 dpkg: 개별 .deb 파일을 다루지만 의존성 자동 해결 불가.
• 고수준 apt(또는 apt-get): 저장소에서 의존성까지 자동 처리.

# 저수준 - 개별 패키지 파일(의존성 수동)
dpkg -i package.deb         # 설치
dpkg -l                     # 설치된 패키지 목록
dpkg -r package             # 제거
dpkg -L package             # 패키지가 설치한 파일 목록
 
# 고수준 - 의존성 자동 해결(저장소 기반)
apt update                  # 저장소 패키지 목록 갱신
apt install nginx           # 설치
apt upgrade                 # 업그레이드
apt remove nginx            # 제거

💡 개념: RPM 계열과 DEB 계열의 대응 관계를 표로 외워두면 시험에 매우 유용하다. 저수준: rpm ↔ dpkg. 고수준(의존성 자동): dnf/yum ↔ apt/apt-get. 패키지 확장자: .rpm ↔ .deb. 이 대응을 묻는 문제가 거의 매 회차 출제된다.

SUSE 계열 — 유럽의 강자

• 1992년 독일에서 시작된 유럽 중심 배포판.
• RPM 패키지 형식을 사용해 레드햇 계열과 형식을 공유하지만, 독자적인 시스템 관리 도구 **YaST(Yet another Setup Tool)**와 패키지 관리자 zypper를 쓴다.

zypper install apache2      # SUSE의 패키지 설치
zypper update               # 업데이트
yast                        # 텍스트/GUI 통합 시스템 설정 도구

🔍 더 깊이: SUSE는 RPM을 쓰지만 레드햇 계열로 분류하지 않고 독립 계열로 보는 것이 일반적이다. 패키지 "형식"(.rpm)과 패키지 "관리 도구"(zypper vs dnf), 그리고 시스템 관리 철학(YaST)이 모두 다르기 때문이다. 시험에서 "SUSE는 어떤 패키지 형식을 쓰는가"라는 함정 문제가 나오면 답은 RPM임에 주의하자. 계열은 다르지만 형식은 RPM이다.

패키지 관리의 본질 — 의존성 지옥의 해결

• 저수준(rpm, dpkg)과 고수준(dnf, apt)이 따로 있는 이유는 의존성(dependency) 때문이다.
• 프로그램 A → 라이브러리 B → 다시 C … 식으로 의존성이 사슬처럼 얽힌다. 저수준 도구로 하나씩 설치하면 필요한 의존성을 사람이 일일이 찾아 순서대로 설치해야 하는 **"의존성 지옥(dependency hell)"**에 빠진다.
• 고수준 도구는 **저장소(repository)**라는 중앙 패키지 창고와 메타데이터로 이를 해결한다. apt install nginx 한 번이면 nginx가 필요로 하는 모든 라이브러리를 자동으로 찾아 함께 설치한다. 현대 리눅스 배포판이 쓰기 편한 핵심 이유다.

⚠️ 함정: rpm -ivh로 패키지를 설치하다 "Failed dependencies" 오류가 나는 것은 정상이다. 저수준 도구는 의존성을 해결하지 못하기 때문이다. 이때 --nodeps 옵션으로 강제 설치하면 프로그램이 깨질 수 있으므로, 의존성이 필요하면 반드시 dnf/yum 같은 고수준 도구를 써야 한다는 점이 출제 포인트다.

다음 시간에는 실제로 리눅스를 설치할 때 마주치는 파티션 설계, 부트로더 GRUB2, 그리고 전원을 켜는 순간부터 시스템이 살아나는 부팅 과정을 다룬다.

📖 용어

• 카피레프트(Copyleft) : 저작권을 뒤집어 쓴 장치. 자유를 준 대신, 파생물도 같은 자유를 넘기라고 강제한다.
• GPL : 가장 강한 카피레프트 라이선스. 이 코드를 쓰면 결과물 전체를 GPL로 공개해야 한다.
• LGPL : 라이브러리용 완화판. 동적 링크만 하면 내 앱 소스는 공개하지 않아도 된다.
• 허용적(permissive) 라이선스 : BSD·MIT처럼 저작권 표시만 남기면 폐쇄 소스 상업 제품으로 만들어도 되는 라이선스.
• 배포판(distribution) : 커널 + GNU 도구 + 패키지 관리자 + 응용 프로그램을 묶어 설치 가능하게 만든 완제품.
• RPM : 레드햇·SUSE가 쓰는 패키지 형식(.rpm)이자 저수준 설치 명령.
• DEB / dpkg : 데비안 계열의 패키지 형식(.deb)과 그것을 다루는 저수준 명령.
• 저장소(repository) : 패키지와 의존성 정보를 모아둔 중앙 창고. apt·dnf가 여기서 내려받는다.
• 의존성 지옥 : 필요한 라이브러리를 사람이 일일이 찾아 설치해야 하는 상황. 고수준 도구가 이를 없앴다.
• YaST : SUSE만의 통합 시스템 설정 도구. 텍스트 모드와 GUI 모두 지원한다.