라이선스 종류 및 주의사항 (feat. 라이선스 위반시 소송 가능;;)

가장 무시하기 쉽지만 가장 중요한 부분

ㅇ..아앗.. (출처 : Go라니10)

오픈소스를 조사할 일이 있었는데 막바지에 가서 라이선스 때문에 오픈소스 사용 결정이 빠그라질뻔 했다

이에 오픈소스의 라이선스 종류에 대해 관심이 생겨서 정리해둔 것을 간단히 포스팅 해두려고 한다

---

1. 오픈소스 라이선스란

- 그 정의는 소프트웨어의 소스코드를 누구나 자유롭게 열람/사용/수정/재배포를 허용하며, 그 사용 조건과 의무사항을 명시한 법적 규약

- 쉽게 말해 남이 갖다 쓰라고 만들어둔 것에 공개범위에 대한 약속이 있다는 것이다

- '이거 갖다 써도 되는데 쓸 때 OO 해야한다~'

---

2. 오픈소스 라이선스 종류

- 우선 라이선스의 종류에는 여러가지가 있으니 재배포 시 의무 수준(= Copyleft 강도)으로 나열하면 다음과 같다 

관대함 ─────────────────────────── 강함
MIT / BSD / Apache ─ LGPL ─ GPL ─ AGPL

---

2-1) MIT, BSD, Apache - 자유 사용형 라이선스

- 실무에서 가장 편하게 쓰는 유형

- 수정 및 상업적 이용이 자유롭다

- 소스코드 공개 의무가 거의 없다

- 저작권 표시 및 라이선스 고지만 유지하면 된다

- 기업 서비스 및 SaaS 제품에서 활용도가 높다

---

2-2) LGPL - 부분 공개형 라이선스

- 라이브러리는 공개해도, 서비스 전체를 공개할 필요 X

- 라이브러리를 단순 링크하여 사용하는 경우, 전체 프로그램의 소스 공개 의무는 발생하지 않는다

- 다만 해당 LGPL 라이브러리를 수정하거나 정적으로 포함하는 경우 수정된 부분의 소스 공개 의무가 발생할 수 있다

---

2-3) GPL - 전체 공개형 라이선스

- 제품에 포함 시 사업 구조 자체에 영향 가능

- 해당 라이선스 포함한 프로그램 전체를 동일 라이선스로 공개해야 함

- 파생 저작물 전체 공개 의무 발생

---

2-4) AGPL - 서비스까지 공개 강제 라이선스

- SaaS 서비스 기업이 가장 주의해야하는 라이선스

- GPL 의무 + 네트워크 서비스 형태로 제공해도 소스 공개 의무 발생

---

3. 주의해야할 점

- 결국 오픈소스는 공짜가 아니라는 점 

- 무료 사용이 가능하다는 것이지 법적 의무가 없다는 것은 아니다

- 의존성(Dependency)까지 체크해야 한다는 것

MIT 라이브러리 쓴 줄 알았는데 내부적으로 GPL을 끌어 쓰고 있었다면?
그것을 써서 유료 서비스를 출시했다면?
=> 재앙 ㅠㅠ

- 라이선스 위반 시

- 소스 공개 요구
- 서비스 중단 요구
- 손해배상 가능성까지 존재함 (e.g. 한글과컴퓨터 GPL 사례)

---

번외

- 적절한 오픈소스의 활용은 많은 시간을 단축해주지만, 자칫하면 실제 서비스 중단 및 손해를 불러일으킬 수 있다는 점을 배웠다

- 한컴 GPL 사례는 이 글을 정리하며 실제로 합의금을 지불한 사례가 있나? 하며 찾다가 알게됐다

- 오픈소스를 맘대로 쓰고 이행하지 않다가 해외에 거액의 합의금을 지불한 대표적인 사례라고..

- 한컴이 자사 소프트웨어에 PDF 인터프리터인 오픈소스 'Ghostscript'를 포함해 배포
- Ghostscript는 GPL로써 전체 소스코드 공개 or 사용 라이선스 구매 필수
- But, 둘다 안함
- 소송걸림
- 수백만달러 합의금 지불하고 분쟁종결

관련 기사 : https://www.sisaweek.com/news/articleView.html?idxno=109614

- 그래서 또 궁금한게 소스코드를 공개하지도 않았는데 해당 오픈소스가 포함된건 어떻게 알았을까? 궁금해져서 조사해보니 아래와 같은 방법들이 있다고 한다

1. 바이너리 정밀 분석 (Software Composition Analysis)
- Black Duck/FOSSA/Synopsys/FOSSID 같은 SCA 도구들 -> 바이너리만으로 오픈소스 포함 여부 탐지 가능
- 코드 지문(Code Fingerprinting) : 오픈소스 프로젝트마다 고유한 함수 호출 패턴, 알고리즘 구조, 특정 문자열(String)이 존재하는데, 이를 데이터베이스화하여 대상 소프트웨어의 기계어와 대조하면 일치 여부를 확인할 수 있다고 한다.. (ㄷㄷ)
- 컴파일 특징 : 특정 라이브러리가 컴파일될 때 생성되는 고유한 흔적이나 에러 메시지, 로그 포맷 등이 실행 파일 내에 그대로 남아 있는 경우가 많아 체크 가능

2. 고유한 식별 정보 노출 (Metadata & Strings)
- 저작권 문구 : 소프트웨어 정보(About) 메뉴나 속성 보기에서 라이브러리의 저작권 공지(Copyright notice)가 발견되기도 함
- 함수 및 변수명 : 실행 파일 내부를 들여다보면(Reverse Engineering) 오픈소스에서 가져온 함수 이름이나 전역 변수 이름이 그대로 노출되는 경우도 많음
- 에러 메시지 : 프로그램 오류 발생 시 출력되는 팝업창이나 로그에 특정 오픈소스 프로젝트에서만 사용하는 고유한 에러 코드가 찍히면 바로 들통남

3. 기능적 유사성과 리버스 엔지니어링
- 특정 기능을 구현하는 방식이 독특하거나, 오픈소스의 버그(Bug)까지 똑같이 재현될 때 의심을 받는다고 한다

- 참... 조사하고 공부할수록 신기하고 주의할게 많은 점들이 많았음