[GitHub] 깃허브에서 오픈소스 라이선스 등록하는 방법 (feat. MIT License)

2025. 1. 5. 20:13Developer Basis/Git, GitHub

1. 선생님 오픈소스가 뭔가요? 왜 오픈소스 라이선스를 등록해야 하는 건가요?

Swift Package를 릴리즈하면서 수업시간에 배운 오픈소스 라이선스를 써먹게 되는 날이 찾아왔습니다. (feat. 오픈소스SW프로그래밍)
이 글을 보시는 분들이 오픈소스 수업을 들은 것은 아니니까 간단한 설명을 해볼게요!

오픈소스가 뭐고? 오픈소스 라이선스는 뭐인가요 선생님

  • 오픈소스 : 배포된 소스코드를 자유롭게 복사 (copy)하고, 수정 (change)하고, 사용 (run)하고, 연구 (study)하고, 재배포 (distribute)할 수 있는 소프트웨어 -> 누구든지 코드를 추가하거나, 구조 개선, 버그를 해결하는 등의 개발을 참여할 수 있도록 공개한 소프트웨어 (그러니까, 라이브러리도 오픈소스죠!)
  • 라이선스 : 정확한 의미는 "해당 소프트웨어를 누구나 자유롭게 사용할 수 있도록 권리를 부여한다는 허가증"의 내용입니다! -> 권리가 주어졌으면 그만큼 "책임"도 따른다는 점에서, 해당 오픈소스 소프트웨어를 재배포 (redistribute)할 때 준수해야 하는 의무사항을 요구하고 있는 것도 역시 라이선스입니다.

*주의해야 할 개념은 GitHub public으로 공개되어 있더라도, 라이선스가 붙어있지 않으면 오픈소스가 아니라는 점입니다. 함부로 그 코드를 오픈소스처럼 사용할 수 있는 권리는 우리들에게 없습니다!
**우리가 어떤 오픈소스 코드를 가져와 새로운 소프트웨어를 배포한다면, 우리가 배포한 새로운 소프트웨어 역시 라이선스가 적응되어 있어야 할 겁니다!

💡 길고 길었는데 결국 정리하자면,
"제가 개발한 소프트웨어를 누구나 자유롭게 사용하거나 수정해도 됩니다." "단, 지켜야 할 규칙도 있습니다."라고 명시하는 것이 바로 오픈소스 라이선스입니다! [소프트웨어 저작권의 개념] 

대신 각 라이선스 종류마다 지켜야 하는 규칙 (정확한 표현으로는 의무사항이자 요구사항)이 다르기 때문에,
내가 배포하는 소프트웨어는 어떤 라이선스를 등록해야 할지, 다른 말로는 <나는 어떤 요구사항을 지켜야 하고> <다른 사람들에게 내 소프트웨어에 대해서 얼마큼의 권리를 부여할지>를 고민해야 한다는 점에서 오픈소스 라이선스를 등록해야 하는 것입니다!

그럼 이제 본격적으로 라이선스를 등록하는 방법에 대해 알아볼까요?

 

2. 깃허브에서 오픈소스 라이선스 등록하기

GitHub에서 라이선스를 등록하는 방법은 두 가지가 있는 것 같아요.
새로운 Repositiry를 만드는 시점 (Create a new repository)에 라이선스를 지정할 수도 있고, 이미 만들어진 Repository에 대해 (Existing Repository) 뒤늦게 라이선스를 지정해 줄 수도 있습니다.

저는 Xcode로 Repository를 바로 만들어줬기 때문에, (Xcode에서 바로 Git Repo를 만들 때 License를 지정하는 방식이 없더라고요..)
레포가 만들어진 이후에 추가적으로 라이선스를 등록하는 후자의 방식을 순서대로 설명할 겁니다!
바로 차근차근 따라가 봅시다💨

1. new repository를 create하는 시점에 라이선스를 지정할 수 있습니다!

우선, 라이선스를 추가하고자 하는 레포에 Add file -> Create new file을 순서대로 눌러주세요.

그리고 파일 이름에 License를 입력해 줄 겁니다.
입력과 동시에 하단에는 Choose a licesnse template라는 없었던 버튼이 하나 등장하게 될 건데요! 눌러줍시다.

*You have unsaved changes. Do you want to discard them? 경고는 그냥 무시해도 상관없습니다 ^__^

들어가게 되면, 좌측에는 프로젝트에 추가할 수 있는 라이선스 목록이 나오게 됩니다.

익숙한 MIT License나 Apache License가 보이고, 그 외에도 생소한 각종 라이선스들의 목록이 나오는데요! 추가하고자 하는 라이선스를 지정해 주면 됩니다. 저 같은 경우에는 가장 제약조건이 적은 MIT License를 추가해 줬습니다.
MIT는 추가적으로 Year와 Full name이 필요해 입력해줘야 했고, 이후 Review and submit 버튼을 눌러 다음 단계로 넘어가볼게요!

*라이선스를 아무거나 지정해도 되나요? 라고 묻는다면, 당연히 아니겠죠!
*라이선스에 따라 수행해야 하는 요구사항과 제약, 그리고 보장받을 수 있는 저작권의 범위까지 모두 달라지게 됩니다. 각 라이선스에 대한 설명은 글 마지막 부분에 별도로 이어가 볼게요!

버튼을 누르면, 다시 원래의 파일 부분으로 돌아와 라이선스 게시 글이 자동으로 작성된 것을 확인할 수 있습니다!
마지막으로, Commit changes 버튼을 눌러서 변경사항을 커밋시켜줄게요!

자 이제 여러분은 해당 라이선스를 본인의 레포에 성공적으로 추가해 준 것입니다. MIT License가 레포에 추가된 것을 볼 수 있네요!
아 물론 MIT License는 각 소스 코드 상단에 주석을 요구하고 있기도 해서,
동일한 내용을 각 소스코드 상단 부분에 주석으로 추가해줄 필요도 있습니다. 빼먹지 말고 같이 해주시면 됩니다!

ToolTipKit은 MIT License가 등록되어 있는거죠!

 

3. 나는 어떤 라이선스를 추가해야 하는 거지? 각 라이선스 특징 빠르게 살펴보기!

자 그럼 위에서 넘어갔던 것을 다시 이어서, 각 라이선스별로는 어떤 특징이 있는지 알아보도록 할게요.

기본적으로 라이선스는 의무사항 고지 (깃허브에 라이선스를 추가하고 / 소스 코드 파일 상단에 추가하는 주석)와 소스코드 공개 (public repo), 그리고 재배포시 동일 라이선스를 적용한다는 Copyleft 라이선스로 구성되어 있습니다.
하지만 같은 라이선스라도 조금씩 큰 틀아래 바뀌는 내용이 있기 때문에 자신의 소프트웨어에는 어떤 라이선스가 적합한지를 살펴볼 필요가 있죠!

*자세한 내용은 깃허브에서 라이선스를 지정할 때 문서로 확인할 수 있으니, 여기서는 간단한 특징들만 모아볼게요!

1️⃣ Apache License - Permissive License
- 오픈소스의 사용, 수정, 배포에 대해서 제약이 없고 + 소스코드 공개 의무도 없는 제한사항이 매우 적은 라이선스입니다!
- 단, 재배포 시 원본 아파치 라이선스에 대한 고지와 수정 사항에 대한 변경사항은 명시가 필요합니다.
2️⃣ MIT License - Permissive License
- 이름 그대로 MIT에서 소프트웨어를 다루는 학생들을 위해 만들어진 라이선스입니다.

- 원본 저작권 고지와 라이선스 사본만 포함한다면, 소프트웨어 사용, 수정, 배포에 대해 아파치처럼 마찬가지로 거의 제약이 없는 라이선스죠. 매우 단순하고 광범위하게 사용돼서 가장 많이 사용되는 라이선스입니다!
3️⃣ BSD (Berkely Software Distribution) License - Permissive License
- 버클리 캘리포니아대학에서 배포한 라이선스입니다. -> 공공성을 강조하는 측면이 있죠!
- 아파치, MIT처럼 라이선스 및 저작권 고지 조건 외에 사용, 배포에 대한 아무런 제약 없이 굉장히 자유롭게 사용할 수 있습니다.
4️⃣ GNU General Public License - Strong Copyleft License
- 강한 Copylieft 라이선스라는 특징 -> 수정된 소프트웨어를 배포하는 경우 무조건 동일한 라이선스를 적용해야 합니다.
- (상업적 이용 가능하지만) 바이너리 배포 시 반드시 소스코드도 함께 공개해야 합니다.
5️⃣ GNU Lesser General Public License - Weak Copyleft License
- GPL의 강한 copyleft 부담을 덜기 위해 등장 -> 동적 링크 시 LGPL 라이브러리 부분을 제외한 부분은 공개하지 않아도 됩니다.
- Copyleft 특징은 남아있음 -> 단, 라이브러리 자체의 수정사항은 역시 동일하게 LGPL로 배포해야 합니다.
6️⃣ Mozilla Public License - Weak Copyleft License
- 소스코드와 실행 파일의 저작권을 분리할 수 있습니다. -> 한 프로젝트지만, 파일 단위로 Copyleft를 적용할 수 있다는 의미!
- 예를 들어, MPL을 재배포한 소스코드는 Copyleft를 따라 Mozila License로 공개, 배포해야하지만 - 실행 파일에 있어서는 별도의 독점 라이선스로 지정, 배포할 수 있다는 듯이겠네요.


저는 해당 Package를 배포함으로써 특별한 수익을 창출할 목적도 아니고,
어떤 특정 오픈소스로부터 재배포를 진행한 것도 아니었기 때문에 - 가장 광범위하고 쉽게 적용할 수 있는 MIT License를 적용하게 된 것입니다.

오픈소스 라이선스!
생각보다 중요하게 생각하지 않았던 부분이지만, 아래의 Reference를 참고해서 더 자세하게 공부할 필요가 있어보이는군요😊
오늘 글은 여기서 끝!

 

4. Reference

 

메인화면 | 오픈소스SW 라이선스 종합정보시스템 OLIS

오픈소스 라이선스 종류 라이선스를 클릭하여 내용을 확인해보세요.

www.olis.or.kr

 

Open Source at SK telecom

Open Source Software at SK telecom

sktelecom.github.io

 

[2024년] 오픈소스SW 라이선스 가이드 개정판 발간 - 공개SW 포털

『오픈소스SW 라이선스 가이드』의 2024년도 개정판을 발간하였습니다. 오픈소스SW 라이선스 가이드는 라이선스에 대한 전반적인 개념과 주요 준수사항과 특허 이슈 등에 관하여 기존의...

www.oss.kr

 

The Legal Side of Open Source

Everything you’ve ever wondered about the legal side of open source, and a few things you didn’t.

opensource.guide