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