라이선스와 배포판 계열은 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 시절 그는 제록스 프린터의 종이 걸림을 알려주는 기능을 추가하려 했지만, 제조사가 소스 코드 공개를 거부했다. "내 손에 있는 도구를 내가 고칠 수 없다"는 좌절이 평생의 운동으로 이어졌다. 작은 프린터 한 대가 거대한 자유 소프트웨어 운동의 씨앗이 된 셈이다.
일반 저작권(copyright)은 "권리를 보유(reserved)"해 복제·수정을 막는다. 카피레프트(Copyleft)는 저작권법을 역이용해 자유를 강제로 보존한다.
핵심 규칙: "자유롭게 쓰고 고칠 수 있다. 단, 배포하는 파생물도 반드시 같은 자유를 보장해야 한다."
자유를 받은 사람은 그 자유를 다음 사람에게도 넘겨주어야 한다 → 이 전염성(viral) 때문에 카피레프트 코드를 가져다 쓰면 결과물도 같은 라이선스로 공개할 의무가 생긴다.
이를 구현한 대표 라이선스가 GPL(GNU General Public License)이다.
"Copyleft"는 "Copyright"의 반대말 말장난이다. Right(오른쪽/권리)를 Left(왼쪽)로 뒤집어, 권리를 독점하는 대신 자유를 보존한다는 뜻을 담았다. FSF 로고에 "All rights reversed(모든 권리 역전)"라고 써 있는 것도 같은 농담이다.
라이선스는 크게 카피레프트 계열(GPL)과 허용적(permissive) 계열(BSD, MIT, Apache)로 나뉜다. 시험에서는 "파생물 공개 의무"의 유무를 정확히 구분하는 것이 핵심이다.
라이선스
계열
파생물 소스 공개
특징
GPL
강한 카피레프트
의무(전체)
링크된 코드까지 GPL 강제
LGPL
약한 카피레프트
라이브러리만
동적 링크 시 비공개 앱과 결합 가능
BSD
허용적
의무 없음
저작권 표시만 유지하면 자유 사용
MIT
허용적
의무 없음
가장 간결, 상업적 폐쇄 소스 가능
Apache 2.0
허용적
의무 없음
특허 보호 조항 포함
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에 묶어두고 있다. 이는 리눅스 커널의 중요한 라이선스 특징이다.
기업 서버 시장의 강자. 1994년 설립된 레드햇사의 RHEL(Red Hat Enterprise Linux)이 중심.
특징: RPM(Red Hat Package Manager) 패키지 형식 + 의존성을 자동 해결하는 YUM/DNF.
배포판
위치
설명
RHEL
상용
레드햇의 유료 엔터프라이즈 제품, 기술 지원 포함
CentOS
무료 클론
RHEL 소스 기반 무료판(현재 CentOS Stream으로 전환)
Fedora
선행 개발
최신 기술 테스트베드, RHEL의 상류(upstream)
Rocky/AlmaLinux
무료 클론
CentOS의 노선 변경 후 등장한 RHEL 호환 클론
Amazon Linux
클라우드
AWS 최적화 RHEL 계열
패키지 관리는 두 단계다.
저수준 rpm: 개별 .rpm 파일을 설치하지만 의존성을 자동 해결하지 못한다.
고수준 yum(구버전)·dnf(신버전): 저장소(repository)에서 패키지와 의존성을 함께 내려받아 자동 설치.
# 저수준 - 개별 패키지 파일 설치(의존성 수동)rpm -ivh package.rpm # install, verbose, hashrpm -qa # 설치된 모든 패키지 조회rpm -e package # 패키지 제거# 고수준 - 의존성 자동 해결(저장소 기반)dnf install httpd # 또는 yum install httpddnf update # 전체 업데이트dnf remove httpddnf search keyword
"Fedora"라는 이름은 레드햇 로고의 빨간 중절모(fedora hat)에서 왔다. Fedora는 레드햇의 실험실 역할을 한다. 여기서 검증된 최신 기술이 안정화되면 RHEL에 들어간다. 즉 Fedora → RHEL → CentOS(클론)로 기술이 흘러내려가는 구조다.
RPM 패키지 형식을 사용해 레드햇 계열과 형식을 공유하지만, 독자적인 시스템 관리 도구 YaST(Yet another Setup Tool)와 패키지 관리자 zypper를 쓴다.
배포판
위치
설명
SLES
상용
SUSE Linux Enterprise Server, 기업용
openSUSE
무료
커뮤니티판(Leap: 안정, Tumbleweed: 롤링릴리스)
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, 그리고 전원을 켜는 순간부터 시스템이 살아나는 부팅 과정을 다룬다.