* 프로그래머스, 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 5기 강의 수강 내용을 정리하는 포스팅.
* 원활한 내용 이해를 위해 수업에서 제시된 자료 이외에, 개인적으로 조사한 자료 등을 덧붙이고 있음.
1. 라이선스가 없는 코드라면?
개요
- 라이선스를 명시하지 않은 코드를 사용할 때 발생할 수 있는 위험 요소와 주의사항을 살펴봅니다.
라이센스가 없는데?
- 일단 이 프로젝트가 오픈 소스가 아닐 가능성이 높다는 뜻.
- 무단으로 가져다 사용할 생각도, 여기에 내가 어떤 기여를 하겠다는 생각도 접어두자.
- 아니면 권리자에게 1:1로 직접 문의를 하거나..
상세 내용
- 불분명한 권리: 라이선스가 없으면 저작권자의 허락 없이 사용, 수정, 재배포가 불가능하거나 불법이 될 수 있습니다.
- 기여자 보호 부족: 기여자나 사용자 모두 권리와 의무가 명확히 정의되지 않아 분쟁 소지가 있습니다.
- 실제 적용 사례 부족: 오픈소스 커뮤니티에서는 일반적으로 명시적인 라이선스를 권장하며, 무라이선스 코드는 신뢰도가 떨어집니다.
- 대응 방안: 사용 전 해당 코드가 공개 도메인(공개 저작물)인지, 혹은 다른 라이선스 적용 가능 여부를 확인해야 합니다.
2. 오픈소스 라이선스 제시하기
개요
- 오픈소스 프로젝트를 공개할 때, 라이선스를 명시하는 방법과 고려해야 할 요소를 안내합니다.
상세 내용
- 라이선스 파일 생성: 프로젝트 루트 디렉토리에
LICENSE 파일을 추가하여 누구나 확인 가능하도록 합니다.
- 라이선스 선택: MIT, Apache, GPL 등 프로젝트 목적과 호환되는 라이선스를 선정해야 합니다.
- README 내 명시: 주요 라이선스 조항과 사용 방법을 README에 간단히 정리해둡니다.
- 프로젝트 정책 결정: 기여자 동의(Contributor License Agreement 등)가 필요한지 여부를 사전에 결정합니다.
3. 오픈소스 라이선스가 중간에 바뀔 수 있다? (없다?)
개요
- 프로젝트가 진행되는 도중에 라이선스를 변경할 수 있는지, 그리고 그 영향에 대해 알아봅니다.
상세 내용
- 라이선스 변경 사례: MongoDB, Elasticsearch 등 일부 프로젝트가 라이선스를 변경해 이슈가 된 바 있습니다.
- 기존 코드와의 호환성: 과거 버전의 코드는 기존 라이선스에 따라 배포되며, 새 버전부터 새 라이선스가 적용될 수 있습니다.
- 기여자 동의 필요성: 기여자들의 코드를 포함한 경우, 라이선스 변경 시 전체 기여자 동의가 필요할 수 있습니다.
- 사용자 영향: 사용자는 새 버전 라이선스를 준수해야 하며, 기존 버전을 계속 사용하는 경우는 과거 라이선스가 적용됩니다.
4. 몽고db vs AWS vs 엘라스틱서치
개요
- MongoDB와 Elasticsearch가 라이선스를 변경하면서, AWS 등 클라우드 서비스 업체와의 갈등이 발생했던 사례를 소개합니다.
상세 내용
- MongoDB의 SSPL: MongoDB가 서버 사이드 퍼블릭 라이선스(SSPL)로 전환해, 클라우드 서비스 업체가 MongoDB를 서비스로 제공하는 방식에 제한을 두었습니다.
- Elasticsearch 라이선스 변경: Elastic이 AWS Elasticsearch 서비스에 대한 불만으로 라이선스를 변경, 오픈소스 커뮤니티에 큰 파장을 일으켰습니다.
- 클라우드 업체 vs 개발사: 클라우드 업체가 오픈소스 DB나 검색 엔진을 서비스로 판매하면서 원 개발사가 수익을 얻지 못한다는 갈등이 주요 이슈였습니다.
- 결과와 시사점: 프로젝트가 라이선스를 변경함으로써 ‘오픈소스의 정의’와 비즈니스 모델에 대한 논의가 계속 이어지고 있습니다.
5. 끝나지 않는 논쟁 feat. RedHat
개요
- RedHat(레드햇)과 관련된 RHEL(Red Hat Enterprise Linux) 배포판 정책, CentOS 종료 이슈 등 오픈소스 논쟁을 살펴봅니다.
상세 내용
- RHEL 소스 공개 범위: GPL 기반 소프트웨어이지만, RedHat은 유지 보수와 인증 서비스에 대해 유료 모델을 운영합니다.
- CentOS 종료 이슈: RedHat이 CentOS 지원을 중단하고 CentOS Stream으로 전환하면서 커뮤니티가 반발했습니다.
- 오픈소스와 기업 비즈니스: 무료/오픈소스 모델을 기반으로 유료 지원 서비스를 제공하는 형태의 갈등과 협업 모델이 공존합니다.
- 향후 전망: AlmaLinux, Rocky Linux 등 다른 커뮤니티 기반 배포판이 등장하며, 오픈소스와 기업의 관계를 재정립하고 있습니다.
6. (실습) 오픈 소스 프로젝트 찾는 방법 in 깃허브
개요
- GitHub를 활용하여 자신에게 맞는 오픈소스 프로젝트를 검색하고 참여하는 방법을 실습합니다.
상세 내용
- Explore 기능: GitHub 메인에서 ‘Explore’를 통해 인기 프로젝트, 추천 레포지토리를 확인합니다.
- Advanced Search: 언어, 스타 수, 이슈 상태 등을 조건으로 검색해 원하는 프로젝트를 찾을 수 있습니다.
- 이슈 라벨 활용:
good first issue, help wanted 등 라벨을 통해 기여하기 쉬운 이슈를 찾아봅니다.
- 프로젝트 히스토리 분석: 커밋 빈도, 이슈 응답 속도, 유지보수 상태 등을 미리 확인해 적극적으로 운영되는 리포지토리인지 판단합니다.
7. (실습) 오픈 소스 프로젝트 찾는 방법 in 구글 코드
개요
- 구글 코드 검색을 이용해 오픈소스 프로젝트를 탐색하는 방법과 주의할 점을 살펴봅니다.
상세 내용
- 검색 연산자 사용:
site:github.com "open source" 같은 구글 검색 연산자를 사용해 특정 플랫폼, 키워드를 조합해 찾을 수 있습니다.
- 이슈 중심 검색: 버그 리포트나 기능 제안을 키워드로 검색해, 관심 분야 이슈를 발견합니다.
- 라이선스 확인: 검색 결과에서 라이선스 정보가 명확히 표시되어 있는지, 공식 문서를 통해 추가 확인이 필요합니다.
- 방치된 프로젝트 구분: 마지막 커밋 일자, 이슈 상태 등을 체크해 더 이상 유지보수되지 않는 프로젝트를 피합니다.
8. (실습) 오픈 소스 프로젝트 찾는 방법 in codetriage
개요
상세 내용
- 자동 분류 서비스: 다양한 오픈소스 프로젝트 이슈를 주제별, 난이도별로 분류해 매일/매주 메일로 받아볼 수 있습니다.
- 이슈 정리: 레포지토리별 이슈 목록을 모아둬, 관심 있는 프로젝트의 이슈만 집중적으로 살펴볼 수 있습니다.
- 추천 프로젝트: 활동이 활발한 프로젝트나 신규 기여자 환영 프로젝트를 자동으로 추천해줍니다.
- 기여 동기 부여: 주기적으로 알림을 받으면서, 꾸준히 이슈 해결에 참여할 기회를 얻을 수 있습니다.
9. 오픈소스 논란! (2019년 이벤트)
개요
- 2019년에 발생했던 주요 오픈소스 관련 논란을 살펴보고, 그 배경과 결과를 정리합니다.
무개념 논란 이벤트.
- 모 기업의 오픈소스 프로젝트의 GitHub 저장소에 Star를 더 받기 위해 경품 이벤트를 개최.
- 개발자도 아닌 일반 사용자들을 대상으로 GitHub 계정을 생성하여 해당 프로젝트에 Star를 주는 방법까지 설명.
- GitHub의 Star를 무슨 좋아요 정도로 이해한 것인지..
- 프로젝트 평가 기준을 뒤틀어버릴 수도 있는 부정행위에 해당한다.
상세 내용
- 라이선스 변경 붐: 일부 대형 프로젝트가 라이선스를 갑작스럽게 변경하면서 커뮤니티가 혼란에 빠졌습니다.
- OSS vs 클라우드 업체 갈등: 위에서 언급한 MongoDB, Elasticsearch 사례처럼 기업의 상업적 이용 문제가 부각됐습니다.
- 프로젝트 포크 증가: 라이선스 변경에 반발하는 커뮤니티가 포크하여 별도 프로젝트를 운영하는 움직임이 활발해졌습니다.
- 커뮤니티 학습: 이러한 논란을 계기로 오픈소스의 정의, 유지보수 모델, 기업 참여 등에 대한 폭넓은 토론이 이어졌습니다.
더 생각해보기..
- 오픈소스 프로젝트에서 라이선스 변경이 발생할 때, 기존 사용자나 기여자는 어떤 권리를 주장할 수 있을까요?
- 클라우드 업체와의 갈등을 피하기 위해 오픈소스 프로젝트들은 어떤 방안을 마련해야 할까요?
- 코드 검색 및 기여 플랫폼(예: GitHub, Codetriage 등) 중에서 본인에게 맞는 프로젝트를 고르는 구체적인 기준은 무엇인가요?