“may be licensed” 한 줄이 만드는 오픈소스 리스크

오픈소스 라이선스 문구를 읽다가 “may be licensed” 같은 표현을 보면, 한 번쯤 멈칫하게 돼요. “어떤 조건에서 ‘될 수도 있고 아닐 수도’ 있다는 거지?”라는 의문이 생기고, 실제로 기업이나 팀에서 도입 검토할 때는 이 한 줄이 리스크로 번지기도 합니다. 오늘은 Mattermost 깃허브 이슈(#8886)에서 제기된 질문을 바탕으로, 이 문구가 왜 논란이 될 수 있는지와 실무적으로 어떻게 해석하면 좋을지 정리해볼게요.

Mattermost LICENSE의 ‘may be licensed’ 문구가 왜 문제인가

이슈 작성자는 Mattermost의 LICENSE.txt 일부(링크의 9번째 줄 부근)를 보고 “May be licensed?? Under what conditions?”라고 질문했어요. 핵심은 “라이선스가 확정적으로 부여되는 게 아니라, 특정 조건에서만 허용되는 것처럼 보인다”는 점이었습니다. 오픈소스는 보통 권한 부여가 명확해야(누가/무엇을/어디까지 가능한지) 하는데, **‘may be’(일 수 있다)**는 표현은 해석의 여지를 남기게 됩니다.

특히 조직에서 오픈소스를 쓰는 입장에서는 “이 코드를 사용해도 되는가”가 0/1로 결론 나야 하는데, 문구가 애매하면 법무/컴플라이언스 검토에서 보류가 나기 쉬워요. 이슈 작성자가 “This is not compliant with open source definition.”라고까지 말한 것도, 오픈소스 정의(OSI 기준 등) 관점에서 라이선스 권한이 조건부/불명확하면 문제가 된다는 맥락으로 이해할 수 있습니다. 즉, 이 문구는 단순한 영어 표현 문제가 아니라 권리 부여의 확실성과 연결돼요.

“Under what conditions?”가 실무에서 의미하는 것

이 질문은 단지 트집이 아니라, 실제 도입 체크리스트의 핵심이에요. 예를 들어 팀에서 Mattermost를 검토한다고 가정해보면, 아래 같은 상황에서 “조건”이 무엇인지가 중요해집니다.

• SaaS 형태로 제공할 때: 소스 수정 후 서비스로 제공해도 되는지(배포 의무, 소스 공개 의무 등) 판단이 필요해요.
• 사내 온프레미스 설치로 쓸 때: 내부 사용만 가능하다는 제한이 있는지, 재배포가 가능한지 확인해야 해요.
• 플러그인/커스터마이징을 할 때: 수정한 코드를 공개해야 하는지, 상업적 이용이 가능한지 같은 조건이 쟁점이 됩니다.

결국 “may be licensed”는 사용자가 기대하는 명확한 권한 부여(license grant) 대신, “특정 조건 충족 시에만 라이선스가 성립한다”는 느낌을 줘요. 그래서 이슈 작성자는 “그 조건이 뭐냐”를 못 박아달라고 요구한 거죠.

GitHub 이슈(#8886)에서 드러난 핵심 포인트 요약

이 참고 기사(이슈 페이지)에서 실제로 확인되는 본문은 짧지만, 포인트는 선명합니다. 작성자는 라이선스 문서의 특정 문구를 지목했고, 그에 대해 다음 두 가지 주장을 했어요.

• ‘May be licensed’는 조건이 불명확하다: 사용자가 임의로 해석해야 하는 여지가 생깁니다.
• 오픈소스 정의에 부합하지 않을 수 있다: 오픈소스는 권리/의무가 명료해야 하는데, 문구가 이를 흐릴 수 있다는 주장입니다.

이런 이슈는 “Mattermost가 나쁘다”의 문제가 아니라, 실제로 많은 프로젝트에서 종종 발생하는 라이선스 표현의 모호성 문제를 보여줘요. 특히 회사에서 쓰는 순간, 이건 기술 이슈가 아니라 법적 리스크 관리로 바로 전환됩니다.

실제로는 어떻게 대응/확인하면 좋을까 (사용 시나리오)

만약 여러분이 팀에서 Mattermost(또는 유사 프로젝트)를 도입하려는 입장이라면, 저는 아래 흐름으로 확인해보는 걸 추천해요. 이 방식은 “문구가 애매하다”에서 끝내지 않고, 실제 의사결정까지 이어지게 해줍니다.

• LICENSE.txt 전체를 먼저 읽고, **권리 부여 문장(license grant)**과 제한/조건(conditions) 섹션을 분리해서 체크해요.
  • 유용한 이유: “may be”처럼 애매한 표현이 전체 문맥에서 어떤 의미인지 파악할 수 있어요.
• 같은 저장소/조직에 상용 라이선스(enterprise/commercial) 안내가 있는지 확인해요.
  • 유용한 이유: 오픈코어(open core) 모델이면 “커뮤니티 버전”과 “엔터프라이즈 기능”의 경계가 라이선스로 나뉘는 경우가 많아요.
• 가장 확실한 방법은, 해당 프로젝트의 공식 문서/FAQ 또는 이슈 코멘트를 통해 **공식 답변(maintainer response)**을 확보하는 거예요.
  • 유용한 이유: 사내 결재나 법무 검토에서 “공식 근거”로 제출할 수 있습니다.

이슈 작성자도 결국은 이 지점을 요구한 셈이에요. “조건이 뭐냐”가 정리되지 않으면, 도입 검토가 멈추기 쉽거든요.

마무리: 라이선스는 ‘기술 스펙’만큼 정확해야 해요

정리하면, Mattermost 이슈(#8886)는 기능 논쟁이 아니라 라이선스 문구의 모호성이 실제 사용자에게 어떤 불안을 주는지 보여주는 사례예요. 특히 “may be licensed” 같은 표현은 오픈소스 도입 과정에서 “쓸 수 있나?”를 단번에 판단하기 어렵게 만들고, 결국 검토 비용을 급격히 올립니다.

여러분 팀에서도 비슷한 문구를 발견했다면, 그냥 넘기지 말고 “권리 부여가 명확한가/조건이 문서화돼 있는가”를 체크해보세요. 그리고 가능하면 LICENSE와 공식 FAQ/답변을 묶어서 근거를 남겨두는 것까지가 안전한 마무리입니다.