[오픈소스] 중간고사(AWS, 성당과시장,깃)

오픈소스 중간고사 시험범위

---

• 오픈 소스 기여자 3명
• 오픈소스 라이센스 비교 테이블 문제
• AWS를 사용할 때의 장점
• 특징 : 말을 고쳐서 함정을 만들었다. 아리까리한 것은 답이 아닐 가능성이 높다고 교수님이 언급하셨다.
• 성당과 시장 방식의 차이점
• 성당과 시장은 오픈소스 운동의 시작이다.
• 오픈 소스를 적용하기 강점이 있는 분야
• 성당과 시장 책에서 언급된 "전략적 무기"라는 것이 무엇인가?
• 오픈 소스의 금기 - 오픈 소스에서 하면 안되는 것 책에서 찾아보기
• 깃이 만들어진 목적, 이유
• 깃의 구성요소 : 박스, 동그라미, 삼각형 나오는 객체 저장소 그림 그대로 나온다
• 깃의 Init, add, commit, push, pull 등의 과정들이 있는데, 이것들을 작성하는 문제
• 깃 명령어별로 차이점 : Merge, fetch, pull, push 등 각각의 차이점에 대해 공부
• 그림문제는 총 3개 나온다
• 라이센스 테이블 비교표
• 깃의 구성요소 그림(박스, 동그라미, 삼각형)
• 마지막 13번문제 : ABCD가 있고 ~~
• 마지막 문제 : 깃문제이다. 원래 origin이 있고 user 커밋이 있을 때 2개의 차이가 있다.
• ABCD에서 X,Y가 생기고 올라가고 내려가고 해서 머지하고 푸쉬하는것

오픈소스 기여자 3명

---

1. 리처드 스톨먼(미국)

- MIT 인공지능 연구소 출신

- FSF(Free Software Foundation) 설립

- GNU 프로젝트 시작

2. 리누스 토발즈(핀란드)

- 리눅스 커널 개발

3. 에릭 레이먼드(미국)

- 저서 : 성당과 시작

- 특징 : 오픈소스라는 단어를 이 사람이 사용하기 시작하였다. 오픈 소스 운동의 시작을 알린 저서가 바로 성당과 시장.

오픈소스 라이센스 비교 테이블

---

라이센스란?

소프트웨어에 대한 저작권은 여전히 원래의 권리자에게 남아있고, 일부 사용에 대한 권리만을 부여하는 것.

BSD/ MIT 라이센스

- 수정된 소스코드를 공개하지 않아도 되는 라이센스

- 공공이익을 위해 지정된 라이센스

- 미국 정부의 재원으로 운영

- 라이센스 변경 후 상용으로 판매 가능

Apache 2.0

- Apache라는 상표권 침해하지 않아야 한다.

- 수정 프로그램의 소스코드 공개의무 없음

- 특허 시 GPL 3.0과 결합하여 GPL 3.0으로 배포 가능

GPL 2.0 라이센스(General Public License 2.0)

- 소스코드 수정시 수정사실, 내용 및 그 날짜 등을 파일 안에 명시

- 수정하거나 새로운 Source code에 Link 시키는 경우 Source code를 GPL로 공개

- GPL 라이센스를 적용하면 특허료를 받을 수 없다.

GPL 3.0 라이센스

- 설치에 필요한 모든 정보 제공 : 설치 방법, 절차, 인증 키 등등

- DRM 관련해서는 법률에 의해 보호되는 이익을 포기

- 특허를 개선하여 배포한 경우 자신이 기여한 부분에 대해 비차별적이고 무료라는 라이선스 제공 필수

- 특허와 관련되서 특허소송을 제기한 경우 그 날부터 해당 제품의 GPL은 종료

LGPL 2.1 License(Lesser GPL)

- 공개 SW의 활용을 장려하기 위한 라이센스 정책

1) 상용 SW를 만들고 있는 경우 강력한 GPL은 사용하기 꺼린다.

2) 추가 작성된 원 Source code 공개 없이 사용된 GPL Source Code만 공개하도록 제한

- LGPL 라이브러리 수정한 경우 수정한 라이브러리의 소스코드 공개

- LGPL 적용을 명시해 배포

- 특허는 GPL과 동일

AWS의 장점

---

1. 자본비용 <->가변 비용

- 장비 구매에서 임대로

2. 규모의 경제

- 공급자는 대용량 장비 구매

3. 용량 추정 불필요

- 필요한 만큼 사용

- 확장/ 축소 손쉽게

4. IDC 운영 및 유지비용 제거

- 운영은 Cloud에서

- 프로젝트에 집중

5. 속도 및 민첩성 개선

- 클릭 한번으로 확장

- 실험 및 개발 비용 최소

- 비용 절감

- 민첩성 향상

6. 몇 분만에 전세계 배포

- 전세계 Revision 사용

- 최소 비용으로 배포

성당과 시장방식의 차이점

---

1. 성당식 개발

• 폐쇄적인 개발

• 명확한 개발 목표가 있을 때

• 소규모 체계적이고 권위주의적으로 운영

• Release 간격이 길다

• 소수의 뛰어난 개발자들에 의해서 개발되는 방식

2. 시장식 개발

• 개인과 개인으로 분산 운영
• Release 간격이 짧고 외부 사용자들에게 Feedback 요구
• 대량의 개별적 상호 테스트
• 많은 사람들에 의해 개발되고 버그가 해결 --> 눈이 많으면 버그가 해결된다

오픈 소스의 장점, 강점 분야

---

1. 신뢰성/ 안정성/ 확장성이 핵심인 분야

2. 설계와 구현이 독립적인 동료 검토 이외의 방법으로는 검증이 어려운 분야

3. 소프트웨어가 사업의 핵심인 분야

4. 일반적인 컴퓨팅과 통신 인프라 확립

5. 핵심 방법이 일반적인 공학지식인 분야

사례 : Id Software : Doom 둠(성당과 시장 159쪽)

- 시장 확대를 위한 성능 개선에 비용이 증가하고 개발 시간이 부족했다

- 기술 명세 출판 허락 --> Doom 자료 인터넷 배포 권장 --> 독립 업체가 추가 기능 출시 장려

성당과 시장에서 언급된 "전략적 무기" (pg 161)

---

오픈 소스는 전략적 무기로 사용될 수 있는데 그 용도는 시장 확대, 기업 경쟁에 대비한 전략 등으로 효과적이다. 오픈 소스는 직접적인 매출 수단으로 작용하기보단 시장을 뚫고 들어가는 수단으로 살펴보자.

1. 경쟁 무기로서의 비용 분담

: 아파치 웹 서버는 저렴한 가격으로 사용되기도 하지만 시장 경쟁에서의 무기로도 사용된다.

아파치 서버는 마이크로소프트의 웹서버(IIS)와 경쟁하는 무기로 사용된다. 

아파치와 같은 공유된 인프라의 장점은 다음과 같다.

1. 많은 고객들이 사용하기 때문에 제품, 서비스를 만드는 비용이 낮아진다.

2. 기술이 버려져서 고객이 낭패보는 일이 적어진다. 왜냐면 많은 사람들이 쓰는 시장 지위가 높은 기술이기 때문이다.

2. 경쟁 초기화

: 썬 마이크로시스템스의 NeWS 윈도우 시스템의 독주를 막기 위해 DEC에서는 오픈소스 X 윈도우 시스템 개발에 자금을 제공하였다. 그리고 표준을 만들기 위해 군소 업체들과 동맹.

경쟁 초기화 무기로서의 오픈소스는 다음과 같다

1. 경쟁력 있는 개발에 자금을 혼자서 제공하기 어려운 경우, 작은 규모의 동맹자 고객에게 오픈소스는 매력적이다.

2. 타이밍이 적절하다면 폐쇄소스와 경쟁하는 것 이상으로 경쟁을 초기화 하고 시장 지위를 높일 수 있다.

3. 연못 넓히기

: 래드햇의 RMP(Red hat Package Manager) 사례에서 볼 수 있듯이, 기술 공용 표준을 만들어서 장기적인 이익뿐만 아니라 큰 회사의 시장 및 대중 지배력을 초기화할 때 오픈 소스가 경쟁 무기가 될 수 있다.

** 레드햇의 RPM 표준화 --> MS의 윈도우 시스템 관리 이점 무력화

연못을 빨리 넓힌다 --> 표준화를 시켜서 많은 동맹이 사용할 수 있게 한다.

4. 목 조르기 막기

: 넷스케이프가 모질라 브라우저 오픈소스화한 사례에서 보듯이

특정 기술을 직접 통제하는 것보다 경쟁자가 해당 기술을 좌우하지 못하게 막는 것이 중요할 때가 많다.

오픈 소스의 금기(pg 69)

---

1. 프로젝트 분기

2. 프로젝트 수정 후 배포

3. 기여자의 이름을 삭제하는 행위

소프트웨어 프로젝트 소유자 : 소유자는 개작판을 배포할 수 있는 배타적 권리를 갖고 있다고 인정 받는 사람

공개 재배포 여부 : 기본적으로 개작판을 배포하는 것은 신경쓰지 않는다. But!! 개작판이 원래의 소프트웨어와 경쟁하기 위해 오픈소스 공동체 안으로 들어올 때 문제.

깃이 만들어진 이유 및 목적

---

<주요이유>

- Linux Kernel 개발에서 활용

- 분산 개발의 용이성

- 수천 명의 개발자 관리할 수 있는 확장성

- 신속하고 효율적인 수행 성능

- 무결성과 신뢰성 유지

- 수십개의 파일들이 생성, 삭제, 변경 되는 과정에서 안정적인 소스코드 관리 필요성

- 효과적인 협업

- 손쉬운 개발 및 테스트 환경 구축

- 효율적인 배포 관리

- 소스코드 수정 내용이 커밋 단위로 관리

- 브랜치를 이용해 충분히 실험 가능.

- 중앙 저장소가 폭파되어도 다시 원상복구 가능

깃의 구성요소

---

1. 리포지토리 : 프로젝트의 revision과 history를 유지, 관리하기 위한 모든 정보를 보관, 복제본 생성 지원.

2. 객체 저장소

- Blob : Binary Large Object. 메타데이터가 없는 실제 데이터.

- Tree : 한 레벨의 디렉토리 정보, blob 정보, 경로 이름, 하위 tree 객체

- commit : 각 변경 사항에 대한 메타 데이터, Tree 객체를 갖는다.

- Tag : commit에 붙인 이름. 검색 등에서 활용.

3. Index : 특정 시점에서 캡쳐한 프로젝트 전체 구조의 한 버전 표현

깃 Init, add, commit, push, pull 의 활용

---

깃 Merge, Pull, Push, Fetch 명령어에 대한 이해

---

Merge : 브랜치를 병합하는 명령어입니다. git merge <브랜치> 명령어를 사용하여 

- git merge <브랜치> : 다른 브랜치를 현재 브랜치로 합치기

- git merge --no-commit : 커밋하지 않고 합치기

- git cherry-pick <커밋명> : 선택하여 합치기

Pull : 원격 저장소에 있는 소스코드를 현재 브랜치에 합치는 명령어

- git pull <원격저장소> : 원격저장소에서 변경사항을 가져와 현재 브랜치에 합치는 명령어입니다.

- git pull : origin 저장소에서 변경 사항을 가져와 현재 브랜치에 합치기

Fetch : origin 저장소에 합치지 않고 지역브랜치로 변경사항 가져오기

- git fetch <원격 저장소> : 원격 저장소에서 합치지 않고 지역 브랜치로 변경사항 가져오기

**Fetch와 Pull의 차이점 : 

fetch는 리모트 저장소에는 존재하지만 local에는 없는 데이터를 받아와서 저장한다. 이 때 Working Directory의 파일은 변경되지 않는다. 즉 사용자가 merge를 하도록 준비만 해둔다.

pull은 git fetch + git merge라고 보면 된다. 현재 로컬의 브랜치의 커밋 스냅샷과 리모트 트래킹 브랜치의 스냅샷을 비교하여 없는 데이터를 받아온 후 합친다. 즉 리모트 저장소에서 로컬에는 없는 데이터를 받아와서 저장한 후 merge 한다.

Push : local 브랜치를 서버로 전송한다. 즉 나의 코딩의 결과물을 다른 사람과 공유한다.

명시적으로 리모트 트랙킹 브랜치를 push 하거나

- git push <원격 저장소> <지역 브랜치> : 지역 브랜치를 동일한 이름의 원격 브랜치에 푸싱하기.

- git push <원격 저장소> <지역 브랜치> : <원격 브랜치> : 지역 브랜치를 원격 브랜치에 푸싱하기