TL;DR

깃헙에서 특정 repository 들어갔을 때 메인에서 우측 라이센스를 클릭하면 됩니다.

2019-03-11-07_17_38-CampbellSoftwareSolutions_docker-osticket_-Run-OSTicket-in-a-docker-container-wi

깃헙에서 특정 repository에 들어가면 위와 같은 형태의 바가 나옵니다.

왼쪽부터 순서대로 커밋횟수, 브랜치의 수, 릴리즈 수, 컨트리뷰터의 수, 라이센스 명칭 입니다.

커밋(commit) 횟수란 CVS인 git에 커밋을 몇 회나 했는지를 의미합니다.
커밋이 빈번하다는 건 기본적으로 소스의 변화가 잦다는 걸 의미합니다.

브랜치의 수는 형상관리에서 가지(branch)가 얼마나 많은가 입니다. 이건 보통 CI를 사용하는 조직에서 전략적으로 쓰는 구조인 경우가 많은데, 오픈소스의 경우에는 컨트리뷰터가 많을수록 테스트 등의 이슈가 발생합니다. 그래서 컨트리뷰터가 fork 하고 merge request 하는 건을 "테스트" 하는 등의 단계를 거치기 위해 별도 브랜치가 필요로 합니다.

릴리즈 수는 말 그대로 정식 넘버링이 된 릴리즈의 횟수입니다. 사용자들에게 의미있게 전달되는 배포본의 숫자입니다. (릴리즈 없이 clone 커맨드로 알아서 가져가서 빌드해서 사용하라는 프로젝트들도 많습니다.)

마지막으로 라이센스입니다. 오픈소스 라이센스는 GPL, Apache, MIT 등 종류가 다양하지만 근래 들어서는 MIT 라이센스가 가장 무난하게 쓰입니다.

2019-03-11-07_19_03-docker-osticket_LICENSE-at-master---CampbellSoftwareSolutions_docker-osticket--

위에가 GitHub에서 특정 프로젝트 클릭 했을 때 나오는 내용입니다.

권한, 제약, 의무(조건) 이 명시적으로 나옵니다.

MIT 라이센스가 요새 인기 있는 이유는 사실 상 라이센스와 저작권에 대한 명시만 한다면 모든 사용 권한이 있기 때문이고 복잡하지 않기 때문입니다.

그렇지만 여러 라이센스의 오픈소스가 혼재 되어 있을 가능성이 많으므로 상용 소프트웨어를 정식적으로 개발 하는 경우에는 오픈소스에서 참조하는 오픈소스의 라이센스 정책도 확인해야 할 필요가 있습니다. (현실적으로 이런 것들을 일일이 단속하는 건 불가능합니다만.)