회색지대 - 이상과 현실 - 오픈소스 저작권 신정규님

Microsoft가 Github를 인수
CEO 스티브 발머가 소프트웨어를 돈을 받고 팔자라는 개념을 만들었다.
예전에는 네트워크가 없어 직접 만나서 소스코드를 복사 전달
Linux 인기 - Apache 재단
Microsoft가 Linux를 제거하겠다.

라이센스

특허와 저작권의 차이점?

특허
- 강력한 실시권이 존재
- 일반적인 권리를 모두 행사할 수 있음
- 회사에서 작성한 문서 - 소유권은 회사소유
- 자동적으로 생기지 않는다.
라이센스
- 유지에 필요한 비용이 없음
- 반복 출원 없이 국가를 초월하여 자동으로 반영되는 경우가 많음
- 자연적으로 생기는 권한

오픈소스 소프트웨어의 보급

문서는 특허가 적용되지 않았다.
70-80년대에는 문제가 발생하지 않았다.
- 오픈 소스가 등장하면서 문제가 발생하게 되었다.

Opensource Example

Android by Google
- Linux Kernel
OSS Libraries
- OpenGL
- LibWebCore
- Dalvik VM
OSS APIs
- XMPP
OSS applications

오픈소스의 성장

Apache
Firefox
Java
Solaris
Symbian / QT
소프트웨어 80%가 오픈소스
무어의 곡선처럼 상승하였다.

특허

권리발생 : 출원 심사 등록
권리내용 : 독점배타적 실시권
효력범위 : 아이디어의 동일성

라이센스(저작권)

권리발생 : 창작과 동시 발생
권리내용 : 인격권, 재산권
효력범위 : 표현의 실질적 유사성(표현이 다르면 안걸린다.)

라이센스 기반의 사업 모형

권리자 -> 사용 권한을 사용자에게 부여함
오픈소스 라이센스
- 비 오픈소스와 동일한 형태의 사업 모형이 가능
- 오픈소스로서 요구되는 몇가지 주의점이 존재함
사용권을 이전할 수 없다. -> 재판매는 불가능하다.

오픈소스 라이센스 권리

라이센스 자유롭게 사용할 수 있다.
복제할 수 있다.
재배포할 수 있다.
자유롭게 수정할 수 있으며, 수정한 것을 재배포할 수 있다.
소스코드를 자유롭게 획득할 수 있다.
개발하기 전에 라이센스를 검증해야 한다.

오픈소스 라이센스

역진 방지 조항
저작권 관련 문구 유지
제품명 중복 방지
라이센스의 조합시 충돌 방지 여부 확인
- 모질라 : MPL + GPL + LGPL

GPL2.0

현재 가장 많은 오픈소스 소프트웨어가 채택
의무사항이 타 라이센스에 비해 엄격함
역진 방지 조항
저작권 표시, 보증책임이 없다.
GPL에 의해 배포된다는 사실 명시
대표 소프트웨어 : Linux

LGPL

오픈 소스 소프트웨어의 사용을 장려하기 위한 전략

GPL3

소프트웨어 특허 문제에 대한 조항 추가
DRM 관련 내용 추가
Apache 라이센스와 GPL 라이센스 호환

MPL

GPL보다 수위가 낮다.

CPL / EPL

IBM의 오픈소스 라이센스
사용하는건 좋지만 문제가 생기면 사용하는 사람 책임

BSD

소스코드 공개 의무가 없음

Apache License

특허권 이름에 대한 상표권을 침해하지 않아야 함.
대표 소프트웨어 : 안드로이드

MIT License

거의 아무런 제약이 없음

특허권 / 듀얼 라이센스

라이센서 특허 - 공급자입장에서
- MPL, Apache : 관련 특허권의 라이센스도 무상 제공으로 간주
- GPL : 묵시적 라이센스 제공
- GPL 3 : 자신이 기여한 부분과 관련된 특허권 라이센스를 무상으로 기여하는 것으로 규정
사용자입장에서
- 이용자가 특허권을 가지고 있는 경우
- MPL의 특수예
  - 그냥 사용때는 문제가 없음
- Apache 2.0 / GPL 3의 경우 MPL과 유사한 조항 추가.
제3자의 특허
- 특허 소유자와 구현자가 다른 경우
듀얼 라이센스
- 개인사용자에게는 무료로 Enterprise에게는 사용요금을 받는다.

오픈소스를 둘러싼 소송들

Dalvik VM
Oracle Vs Google
- MS Java
- Mobile Java

Elastic Remote Working - 김종민님

Elastic에 메일을 통해 의견을 물어보다가 좋은 기회로 Elastic에서 먼저 offer가 왔다.
3번 인터뷰 보고 1달만에 합류하게 되었다.

Elastic

Elastic Search라는 오픈소스 검색엔진을 개발한 회사.
직원은 800명 한국은 9명.
Doug Culting이 개발한 루씬 기반 검색엔진기반으로 작성.
Automattic의 김태곤 - 침대에서 회사까지 1분
골드만삭스 개발자 > 페이스북 개발자
Elastic Search 사용하는 회사는 많고 다양하다.
- tinder
- Github
Elastic에서 Lucene Committer들이 점점 많아지는 추세이다.

돈($)은 어떻게 벌죠?

기술지원
유료 사용자 기능
교육
컨설팅

Elastic Remote Working

전 세계 직원들이 매년 1~2차례 모입니다.
Elastic
Automatic
GitLab
집값이 어마무시합니다.
- 실리콘벨리에서 연봉 2억이면 잘 산다고 보기가 어렵다.
미국은 비동기하게 일 하는 것이 원래 익숙했습니다.

Tools

github.com/elastic
Slack
salesforce
zoom.us - 화상통화, 대화 Script 제공
pingboard

Elastic Culture

Work Hard, Play Harder
Diversity

정리하자면

절대적으로 좋은 회사는 존재하지 않는다.
사람이 기대하고 부여하는 가치가 다릅니다.
동료들 간의 신뢰
세밀한 자기 관리

오픈소스 생태계 일원으로서의 개발자 - 변정훈님

공개 저장소는 공짜니까 - Github
issue & PR
개발하다 보니 어느새 오픈소스에 참여
이미 우리는 오픈소스 세계에 들어와있다.

오픈소스 프로젝트에 참여(기여)하는 방법

Contribution

사용
홍보
번역
Report
Doc
코드 제출

오픈소스를 하는 이유는?

오픈소스 생태계에 의존하고 있으므로
소스 코드 공개
공유 문화

오프소스의 예제

사이드 프로젝트

오픈소스가 가장 진보된 개발 프로세스를 가지고 있다.

CI
코드 리뷰
커뮤니케이션의 방법
협업의 방법과 중요성
테스트 코드의 중요성
지속적 통합 / 지속적 배포
코드의 품질 관리

오픈소스 개발자들에게 조금 더 고마운 마음을 가질 필요가 있다.

오픈소스를 구매한 제품처럼 대하지 말고 자신이 속한 팀처럼 대하라.

오픈소스 생태계가 더 잘 돌아가도록 만들 책임이 있다.

알아서 잘 돌아가지 않는다.
Bus Factor : 팀원 중 일부가 버스에 치였을 때 프로젝트에 영향을 줄 수 있는 수
메인테이너나 프로젝트를 비난하지 말자.
- 생산적인 피드백을 하자.
- 상대방이 쉽게 이해할 수 있게 예제코드 만들기.
재현가능한 예제와 상황을 제공해야 한다.
자신의 이슈를 빨리 처리해 달라고 요청하지 말자.
처리할 수 있는 이슈는 답변을 달거나 Pull Request를 제출한다.

해외 오픈소스 컨퍼런스 발표와 참여 - KossLab 송태웅님

Linux Foundation - Events
발표 내용에 따라 다른 Track으로 나뉠 수 있다.
발표 Type
- Discussion 위주인지
- 튜토리얼도 공유하는것도 중요합니다.
- 다양하다.
영어도 중요햐지만 기술, 경험 공유하는게 목적.

세미나에 가면 질문 하나는 꼭 하기. 듣는것보다 질문에 대한 내용은 오래 기억이 남는다.

Python, PyCon, and the PSF - 김영근님

Python Communities
Python 2는 제거될 예정.
12살, 14살도 발표자.

Code of Conduct(행동 강령)

Respect, Diversity

다양한 산업에 쓰이는 Python

Data / Scientific
- NASA
Education
- BBC microbit
CG
- Walt Disney Studios
- Mays, Blender
Music
- Ableton Live

Sprint

프로젝트를 관리하시는 분이 옆에서 committer가 될 수 있게 도와주는 프로그램.
Worldwide pandas sprint 2018
- 246 PRs for one day

PSF

- Python 홍보
- Python 보안
- 개발 Sprint

아파치 제플린, 프로젝트 시작부터 아파치 탑레벨 프로젝트가 되기까지 - 이문수님

제플린을 만든 시작이유

필요성을 느껴서 만들게 되었습니다.

홍보

Mailing List
- Stackoverflow
Apache에 Proposal을 제안
- “Community over code”
- Incubator -> Top Level Project
- Graduation vote -> 커뮤니티의 활성화가 중요.

Project를 관리하는 Level

PMC(Project Management Committee)
Committer : 코드 수정 권한
Contributor : PR

의사결정

제안
토론
공감대 형성
투표
공감대 형성 -> 투표(O)
투표 -> 공감대 형성(X)
투표는 Document용도로 사용하기!
- 공감대 형성으로 문제 해결하는게 가장 좋다.

Apache가 되는것의 가장 큰 장점

Apache 2 License
Quality
Standard
Open desision making process
Conference에서 발표가 쉽다.

Apache가 되는것의 가장 큰 단점

브랜드 및 트레이드마크 소유권이 없음

Q & A

오픈소스 쉽게 기여할 수 있는 방법?

태웅님
- 크게 생각하지 말고, 가장 쉬운 것부터 시작하자.
- 예를 들면 문서번역부터 시작하자. issue를 보면 Beginner를 위한 issue가 있다.
영근님
- 버그 Report, 기술 Feedback, 굳이 코드만 기여하는게 전부가 아니다.
- 끝나지 않은 issue 해결하기, sprint 모임 참여하기.

오픈소스 어떻게 사람들을 모을까?

종민님
- 타이밍. 먼저 광고부터하고 그다음이 비즈니스
문수님
- 소프트웨어. commercial 상품인지. 내가 쓰기좋은거 쓸래.
- Software가 주는 가치. 가치가 높고 중요하다면 사람들이 많이 참여하지 않을까?

어떤 오픈소스가 좋은 것이고 어떤 것을 파야하나요?

정훈님
- 인기도는 나와있다. 파본다? -> 인기가 많은 건 보기 힘들다.
- 추상화 Level도 높아져서 읽기 힘들다.
- 중간 프로젝트를 찾아야 하는데 찾기 힘들다.
- 괜찮은 개발자의 토이 프로젝트 확인하기.
- 유명한 프로젝트의 초기 모습을 확인하기.

리모트로 일하는 방법

문화도 중요하고 사람도 가장 중요하다.
잘될 때는 잘 되지만 커뮤니케이션이 힘든 부분도 있다.

오픈소스에서 활동하는 것. 장단점. 오픈소스 경력이 입사 면접

재미있다.
입사때 도움이 된다.
지원을 받을때 github 계정도 받는다.
협업. PR. 코드를 보기위해.

내가 얻은 것.

오픈 소스는 단순히 소프트웨어를 공개하는 것이 아니다.
- 하나의 커뮤니티가 생기고 끊임없이 사람들과 교류하며 가치를 만들어 내는 문화.
  - CI
  - 코드 리뷰
  - 커뮤니케이션의 방법
  - 협업의 방법과 중요성
  - 테스트 코드의 중요성
  - 지속적 통합 / 지속적 배포
  - 코드의 품질 관리
- 유지하기 위해선 많은 비용이 들어가지만 얻는 가치는 엄청나다.
Software를 제작하기 전에 생각하기.
- 내가 어떤 가치를 전달하기 위해 작성하는지 고민해 볼 필요가 있을 것 같다.
- 가치가 확실하고 사람들이 좋아한다면 자연스럽게 가치는 점점 커지게 될 것.