지난 시간에는 오픈 소스 프로젝트의 컨트리뷰션에 대해 알아보았습니다. 이번 시간에는 오픈 소스 라이선스의 개념과 활용 방법에 대해 더 자세히 정리했습니다.
1. 라이선스 확인의 중요성
오픈 소스 소프트웨어(OSS)를 활용할 때 가장 먼저 확인해야 할 것은 해당 프로젝트가 정말 오픈 소스인지 구별하는 일입니다. 깃허브의 퍼블릭 레포지토리는 누구나 코드를 열람할 수 있지만, 그렇다고 해서 그 코드를 마음대로 가져다 써도 된다는 의미는 아닙니다.
무단으로 사용할 경우 법적인 문제가 발생할 수 있으므로 반드시 프로젝트에 명시된 라이선스를 먼저 확인해야 합니다.
2. 라이선스가 없는 경우
탐색 중 유용해 보이는 코드를 발견했는데 라이선스가 명시되어 있지 않은 경우가 있습니다. 이때는 깃허브에서 제공하는 라이선스 제안(Propose) 기능을 활용할 수 있습니다.
코드의 원저작자에게 적절한 라이선스를 설정하고 프로젝트를 공식적인 오픈 소스로 전환하는 것이 어떨지 제안하는 기능입니다. 라이선스가 없는 코드는 사용 자체가 법적으로 불명확하기 때문에 이 기능을 통해 먼저 소통하는 것이 좋습니다.
3. 적절한 라이선스 선택 기준
저작자에게 라이선스를 제안하거나 본인의 프로젝트에 적용할 때, 해당 코드가 어떤 환경이나 생태계에서 주로 사용되는지 고려하면 선택하기 쉬워집니다.
| 라이선스 | 주요 사용처 | 특징 |
|---|---|---|
| MIT | npm 생태계 패키지 | 저작자 표시만 하면 자유롭게 사용 가능. 가장 관대한 라이선스 |
| Apache 2.0 | 기업 주도 웹 관련 오픈 소스 | 특허권 관련 조항이 명시되어 있습니다 |
| GNU GPL v3 | 소스 코드 전체 공개 지향 프로젝트 | 배포 시 파생 저작물의 모든 소스 코드와 히스토리를 공개해야 합니다 |
4. 라이선스 변경
프로젝트 진행 중 필요에 따라 라이선스를 변경하는 것도 가능합니다. 하지만 이미 기여한 사람들의 동의를 구하는 등 변경 과정이 법적으로나 절차상으로 매우 복잡해질 수 있기 때문에 처음 선택할 때 신중하게 결정하는 것이 중요합니다.
실제 라이선스 변경 사례를 보면 그 파급력이 얼마나 큰지 알 수 있습니다.
| 프로젝트 | 변경 전 | 변경 후 |
|---|---|---|
| MongoDB | AGPL | SSPL |
| Elastic Search | Apache | SSPL |
| Grafana | Apache | AGPL |
| Sentry | BSD 3-Clause | BUSL |
이처럼 대형 오픈 소스 프로젝트도 라이선스를 변경하는 경우가 있지만, 그 과정에서 커뮤니티의 큰 반발이나 포크(fork) 프로젝트가 생겨나는 등 적지 않은 파장이 생깁니다. 처음 라이선스를 결정할 때 충분히 고민해야 하는 이유입니다.
5. 오픈 소스 프로젝트 탐색 방법
참여하거나 참고할 만한 오픈 소스 프로젝트를 찾는 방법은 다양합니다.
깃허브(GitHub) — 가장 대중적이고 방대한 오픈 소스 프로젝트들이 모여 있는 플랫폼입니다. 검색 필터를 활용해 언어, 라이선스, 활동량 등으로 프로젝트를 찾을 수 있습니다.
기업 오픈 소스 포털 — 네이버나 카카오 등 IT 기업들이 자체적으로 운영하는 오픈 소스 포털을 통해 양질의 프로젝트를 참고할 수 있습니다.
CodeTriage — 다양한 오픈 소스 프로젝트들을 모아두고 등록된 이슈의 개수나 활동량에 따라 우선순위를 분류해서 보여주는 유용한 서비스입니다. 오픈 소스 기여를 처음 시작할 때 특히 유용하게 활용할 수 있습니다.
