데브코스 14주차 - 오픈소스 / 오픈소스 라이선스
🎈오픈소스란?
누구나 특별한 제한 없이 공개되어있는 소스코드
+ 리뷰, 수정 등 개선사항을 마음껏 펼칠 수 있다.
OSI - 오픈소스 소프트웨어 인증마크를 달고 인증해주는 비영리 조직
🎈오픈 소스 라이선스란?
(OSI - open source initiative)
오픈소스로 배포/준비/ 공개된 소스코드를 사용할 때 지켜야하는 규칙을 명시하는 것
🎈오픈 소스 라이선스 종류
- OLIS 사이트 참고할 수 있다. (한국어)
1. GPL (GNU General Public License)
Free Software Foundation(자유 소프트웨어 재단)에서 만들었다.
의무사항이 강력한 편이다.
=> "어떤 목적으로, 어떤 형태로든 사용할 수 있지만, 사용/배포하는 경우엔 무조건 공개"
소프트웨어 유통을 활성화하려는 의도가 강하다. 특허 라이선스 금지, 상업적 웹 사이트를 구축할 수도 있다. 그러나 저작권을 완전히 포기하는 것은 아님
ex) Linux, Git, MariaDB, Wordpress ..
2. MIT
의무사항이 "덜" 강력한 편이다.(자유로움) => 인기가 많다.
=> 라이선스 이름, 명시 조건
ex ) bootstrap, react, angular, jQuery ..
3. Apache
license.text
소스 코드에 대한 공개 의무 등 의무사항 X
ex ) 안드로이드
4. BSD
Berkeley Software Distribution에서 만들었다.
공공기관에서 만들어서 공공의 몫으로 돌리려는 경향이 강하다.
라이선스 및 저작권 표시 조건 => 인기가 많다.
참고 라이선스
BEERWARE
- 제약조건이 매우 낮은 라이선스 - 가치있다고 생각한다면 나중에 만났다면 맥주한잔 사달라
🎈in github
깃허브에도 라이선스에 대한 도움을 준다.
- 새로운 레포지토리를 만들 때, 라이선스를 선택할 수 있다.
- 라이선스를 추가할 수도 있다.
참고 - 라이선스 사용법 ( 웹어플리케이션 크롬 예시)
=> chrome://credits/
오픈 소스 라이선스 표기 방법
- 오픈소스명
- 공식 홈페이지 주소
- 라이선스 종류/이름
- 라이선스 전문(공식내용, 문서)
- (OLIS에서 참고 가능)
프로젝트에 사용시
=> 레포지토리 Readme or License.txt 파일에.
🎈오픈소스 문서 구조
<기본 문서>
LICENSE.md/.text : 오픈소스 라이선스 전문 명시 문서
즉, 이 파일이 프로젝트에 있으면 오픈소스 라이선스 하에 배포된다, 되어야한다.
위치: 디렉토리 최상위
<추가 문서>
README.txt : 프로그램 코드의 목적, 사용방법 설명 문서
NOTICE.txt : 오픈소스 라이선스개요
COPYRIGHT.txt : 저작권자 포커싱
CONTRIBUTING.md : 프로젝트에 기여할 수 있는 방법 설명한 문서
CODE_OF_CONDUCT.md : 기여할 때 이런 것을 지키면 좋습니다. (서로 존중)
🎈오픈소스 프로젝트(=커뮤니티) 상태파일 - 커뮤니티 건전성 테스트 / github
- 깃허브는 행동기준을 중요하게 생각한다!
- 커뮤니티 프로필 체크 리스트 => 깃허브에서 체크리스트를 제공함 ( insights / community standards)
🎈오픈소스 구성원 역할
저작자: 오픈 소스 프로젝트를 만든 사람 조직
사용자: 오픈 소스 사용하는 사람
//메인테이너: 프로젝트의 방향을 알고있는/직접 설정한 프로젝트를 관리하는 컨트리뷰터 (없을 수 있다.)
//커미터: 컨트리뷰터가 컨트리뷰션을 하면 리뷰를 하는 컨트리뷰터 / 프로젝트 반영 여부 결정권을 가지고 있다. (없을 수 있다.)
컨트리뷰터: 오픈 소스 프로젝트에 컨트리뷰션(기여) 활동을 하는 모든 사람
컨트리뷰터의 유형은 매우 다양하다.
+제안하는 것만도 컨트리뷰션이다.
- 버그픽스, 문서 작업, 기능추가/수정/삭제, 리팩토링, 버전, 테스트 케이스 추가
- 컨트리뷰트 하는 것을 추천!!! = > 관심을 가지고 보기
🎈오픈소스 협업 주의 사항
- 커뮤니케이션
- 소스코드 충돌
- 이미 구현하고 있지는 않은지, 구현하지 않기로 결정한 것은 아닌지
- 시작하기 전에 내가 작업을 시작할 것을 알리는 것이 좋다. (=> 이슈 오픈, 디스커션)
- but, 너무 오래된 open 이슈라면 디스커션 또는 커뮤니티 문의 => 정리되지 않은 이슈 정리? 컨트리뷰션 O
- 새롭고, 큰 중요한 기능을 추가하고 싶을 때,,,
- 방향성과 맞을지 의견을 물어보기
- PR
- 템플릿 또는 문서 확인 ( 테스트 유무, 컨벤션 등)
🎈컨트리뷰트 절차
- 오픈소스 프로젝트 Fork
- 저작자 계정에서 내 계정 레포지토리로 복제 ( 원 레포지토리의 변경사항 받을 수 O)
- 내 계정 레포지토리 Clone => 내 로컬
- 코드컨벤션, 커밋메세지 등 규칙 체크
- 코드 구현, 수정 / 내 계정에 commit and push
- 저작자 계정에 PR
- Contributor License Agreement
- 리뷰어, 커미터, 메인테이너, 저작자 등 검토
- merge되었다 => PR closed 알림
- 컨트리뷰터 리스트에 추가됨!
🎈오픈소스를 제안할 때
규정 (OSI,OLIS, OSS)와 같은 규정이 있지만 제안하는 경우이므로 사용자 관점에서 알아보도록 하겠다.
1. 어떤 프레임워크에서 작동하는지, 어떤 모듈이랑 같이 쓰이는지?
(ex. node.js => npm)
npm 다른 모듈들이 어떤 라이선스가 적용되어있는지
그중에서 가장 많이 쓰이는 MIT 라이선스
2. 딱히 고려할 것이 없다면
가장 간단하고, 이해하기 쉬운 "저작자만 보호해주세요" => MIT 라이선스
3. 기업이 사용하기를 원하면, 웹 관련 Apache : 특허
4. GNU GPL v3
저작권자 뿐만 아니라 모든 이력, 구성원 등 모든 히스토리 오픈
모든 것을 오픈
open된 이슈가 많은 오픈소스를 찾아볼만한 곳: CODETRIAGE
🎈저작자 체크리스트
Readme
1. 프로젝트를 만든 이유, 목적, 용도
2. 코드 사용 방법/ 설치 사용 방법
contributing
환영 메세지 또는 가이드
license
라이선스 전문
+기존 프로젝트 라이선스 고려
코드
명명법, 주석, 데드코드 정리
# 중복없는 명확한 프로젝트 이름
참고 - 흥미로운 논란! with 라이선스 변경
1. mongoDB vs AWS
- 공공의 이익을 위해 오픈한 mongoDB 오픈소스를 이용해 상업적으로 사용하는 AWS 때문에 라이선스를 바꾼 사건. 새로 만든 SSPL 라이선스를 OSI에서는 인정해주지 않는다.
- mongoDB (오픈소스 라이선스 AGPL > SSPL)
- AGPL - 가져다 쓴 코드 수정한 부분 오픈
- SSPL (OSI 인정 X) - 클라우드 서비스에서 우리를 상업적으로 사용 x 아니라면 써도 되는데 서비스를 기동하는데 필요한 연동된 모든 코드를 공개
2. elasticsearch vs AWS
- 마찬가지로 공공의 이익을 위해 오픈한 코드를 이용해 상업적으로 사용하는 AWS에 맞서 라이선스를 바꾼 사건. 이후 또 OSI에 라이선스 인정을 요구했지만 받아주지 않았다.
- elasticsearch (오픈 소스 라이선스 > SSPL + Elasticsearch)
- SSPL + Elasticsearch
- Elasticsearch : 호스팅, 클라우드 등을 하는 서비스들은 우리를 추가해서 상업적으로 사용 x