2025. 1. 5. 20:13ㆍDeveloper 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를 지정하는 방식이 없더라고요..)
레포가 만들어진 이후에 추가적으로 라이선스를 등록하는 후자의 방식을 순서대로 설명할 겁니다!
바로 차근차근 따라가 봅시다💨
우선, 라이선스를 추가하고자 하는 레포에 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는 각 소스 코드 상단에 주석을 요구하고 있기도 해서,
동일한 내용을 각 소스코드 상단 부분에 주석으로 추가해줄 필요도 있습니다. 빼먹지 말고 같이 해주시면 됩니다!
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
'Developer Basis > Git, GitHub' 카테고리의 다른 글
[Git] .gitignore는 왜 필요하고, 어떻게 적용하는 것일까? (2) | 2024.03.30 |
---|---|
[GitHub] 코드 리뷰 문화 - 토스터 iOS팀이 코드 스타일과 구성을 깔끔하게 유지할 수 있는 이유 (0) | 2024.03.26 |
[GitHub] 깃허브에서 Create a new release를 눌러보자 (0) | 2022.01.08 |
[GitHub] 내가 보려고 정리하는 GitHub README 작성법 + 꾸미기 꿀팁 (0) | 2021.10.23 |