LinuC レベル1 Version10.0
技術解説無料セミナー
2020/08/01 開催

オープンソースの⽂化を知ろう

本⽇の講師

ワイズプランニング
吉⽥ ⾏男© LPI-Japan / EDUCO all rights reserved.

⾃⼰紹介
n【経歴】
 ⼊社当時は、⾦融端末のソフトウェア開発に従事。
 2000年頃から、Linux/OSSのビジネス開発を担当。
 2012年から、オープンソース専⾨組織に所属。
 2019年、定年退職により独⽴。

#LinuC学習中

n【現在の業務】
 OSSを活⽤したビジネス構築のための⽀援- 新しい技術/OSSの発掘・評価検証- ビジネス・ソリューションの⽴ち上げ⽀援 OSSコンプライアンス管理- ガイドライン作成、社内プロセス構築⽀援(*)2018/11 : 北東アジアOSS推進フォーラムにて「OSS貢献賞受賞」

 各種講演、執筆© LPI-Japan all rights reserved.

2

LinuCレベル１／レベル２ Version10.0とは

nLinuCとは#LinuC学習中

クラウド時代の即戦⼒エンジニアであることを証明するLinux技術者認定資格

ü現場で「今」求められている新しい技術要素に対応• オンプレミス／仮想化を問わず様々な環境下でのサーバー構築• 他社とのコラボレーションの前提となるオープンソースへの理解• システムの多様化に対応できるアーキテクチャへの知⾒ü全⾯的に⾒直した、今、⾝につけておくべき技術範囲を網羅
今となっては使わない技術やコマンドの削除、アップデート、新領域の取り込みüLinuxの範疇だけにとどまらない領域までカバー
セキュリティや監視など、ITエンジニアであれば必須の領域もカバー© LPI-Japan all rights reserved.

3

新しくなった「LinuC」の紹介

nVersion10.0と従来の出題範囲の⽐較
テーマ

LinuC-1

Version 10.0

#LinuC学習中
従来

仮想技術

・仮想マシン／コンテナの概念
・クラウドセキュリティの基礎←（Version10.0で新設）

オープンソースの文化・オープンソースの定義や特徴
・コミュニティやエコシステムへの貢献←（Version10.0で新設）

その他→（Version10.0で削除）

アクセシビリティ、ディスククォータ、プリンタの管理、SQLデータ管理、他

仮想化技術

・仮想マシンの実行と管理（KVM）
・コンテナの仕組みとDockerの導入←（Version10.0で新設）

システムアーキテクチャ

・クラウドサービス上のシステム構成
・高可用システム、スケーラビリティ、他←（Version10.0で新設）

LinuC-2
その他

・統合監視ツール（zabbix）
・自動化ツール（Ansible）→（Version10.0で削除）←（Version10.0で出題範囲に含む）
RAID、記憶装置へのアクセス方、FTP
サーバーの保護、他© LPI-Japan all rights reserved.

4

#LinuC学習中

今回のテーマオープンソースの⽂化を知ろう© LPI-Japan all rights reserved.

5

OSSの歴史と定義© LPI-Japan all rights reserved.

6

OSSの始まり
nOSSの始まり#LinuC学習中1969 : AT&T ベル研究所にてUnix開発 教育機関向けにソースコードを無償公開
1983 :独占禁⽌法違反裁定によるAT&T分割に伴いUnixを製品化
1985 : Free Software Foundation(FSF)設⽴
GNUプロジェクトが「GNU宣⾔」を発表
1991 : Linux開発着⼿ ➡ 1994︓Linux1.0 リリース
1997 : 「伽藍とバザール」発表
1998 : Mozillaのソースコードを公開
ブラウザ戦争「オープンソースソフトウェア」誕⽣

1996 :MS Internet Explorerを無償化
1994 :インターネット商⽤利⽤開始© LPI-Japan all rights reserved.

7

OSSの定義
nOSI(*1)が定めるOSSの定義
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩

#LinuC学習中
⾃由な再頒布が出来ること
オープンソースの権利
ソースコードを⼊⼿できること
派⽣物が存在でき、派⽣物に同じライセンスを適⽤できること
差分情報の配布を認める場合には、同⼀性の保持を要求してもかまわない
個⼈やグループを差別しないこと
適⽤領域に対する差別をしないこと
再配布において追加ライセンスを必要としないこと
オープンソースライセンスが備えるべき条件
特定製品に依存しないこと
同じ媒体で配布される他のソフトウェアを制限しないこと
技術的な中⽴を保っていることポイント

・ オープンソース ≠ 著作権を放棄されたソフトウェア
・ ソースコードがインターネット等で公開されている
・ 再配布の⾃由と改変の⾃由がある※1・・Open Source Intiative(オープンソース⽂化の啓蒙を⽬的に設⽴された組織）© LPI-Japan all rights reserved.

8

OSSのライセンス© LPI-Japan all rights reserved.

9コピーレフト(Copyleft)という考え⽅
nコピーレフトという考え⽅(FSFの⾏動原理)
 著作物の利⽤、コピー、再配布、翻案を制限しない
 改変したもの（⼆次的著作物）の再配布を制限しない
 ⼆次的著作物の利⽤、コピー、再配布、翻案を制限してはならない コピー、再配布の際には、その後の利⽤と翻案に制限が無いよう、全ての情報を含める必要がある（ソフトウェアではソースコード含む）
 翻案が制限されない反⾯、原著作物の⼆次的著作物にも同⼀のコピーレフトのライセンスを適⽤し、これを明記しなければならない#LinuC学習中

Free(無償)ではなく、Free(⾃由)© LPI-Japan all rights reserved.

10

ライセンスの類型
nライセンスの類型
類型#LinuC学習中
主なライセンス

1 コピーレフト型

Ø ライセンシの派⽣物にまで同じライセンスの適⽤を要求する。
Ø ライセンサが配布するOSSをライセンシが他のソフ
トウェアと組み合わせた場合、 ライセンサはライ
センシに組み合わせ先のソフトウェアにまで同じライセンスの適⽤を要求する。

GNU GPL
GNU AGPLEUPL(European Union Public
License)2 準コピーレフト型

Ø ライセンサに派⽣物にまで同じライセンスの適⽤を要求する。
Ø ライセンサが配布するOSSを、ライセンシが他のソ
フトウェアと組み合わせた場合、ライセンサはライ
センシに組み合わせ先のソフトウェアまでは、同じライセンスの適⽤を要求しない。

GNU LGPLMPL (Mozilla Public License)
Eclipse Public License
CPL (Common Public License)
IBM Public License
Artistic License (Perl License)

3 ⾮コピーレフト型(Permissive型)

Ø ライセンシに派⽣物にまで同じライセンスの適⽤を要求しない。
Ø ライセンサが配布するOSSを、ライセンシが他のソ
フトウェアと組み合わせた場合でも、ライセンサは
ライセンシに組み合わせ先のソフトウェアにまでは同じライセンスの適⽤を要求しない。

BSD License
FreeBSD Copyright
MIT License
X11 License
ZPL (Zope Public License)
Apache License© LPI-Japan all rights reserved.

11

ライセンスの適⽤状況①
nコピーレフト型が減少傾向、MITとApacheで約半数。
Permissive vs Copyleft

Top Open Source Licenses 2019

100%

75%

0%

59%

45%

41%

36%

33%

10%

27%
23%
13%

GPLv2

41%

55%

59%

67%

0%

2012

2016

2017

Permissive

2018
Copyleft

2019

30%

MIT

GPLv3

64%

20%

Apache-2.0

50%

25%

#LinuC学習中

10%

BSD3

5%

LGPLv2.1

5%

BSD 2

2%

Microsoft Public

2%

Eclipse 1.0

1%

BSD

1%

https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions© LPI-Japan all rights reserved.

12

ライセンスの適⽤状況➁
nApache2.0が増加傾向、 GPL系の減少は⽌まらず。

GPL License Family Popularity Over Time

Apache-2.0 Popularity Over Time
21%

22%

#LinuC学習中

23%

19%
18%

16%
13%

15%

14%
11%

10%10%
6% 6% 6%

GPLv3
2016

2017

2018

2019

GPLv2
2016

2017

https://resources.whitesourcesoftware.com/blog-whitesource/top-open-source-licenses-trends-and-predictions

5%

LGPLv2.1
2018

2019© LPI-Japan all rights reserved.

13著名なライセンス紹介(①)① GPLおよびLGPL（最新版は v3）#LinuC学習中
 Free Software Foundation が作成したライセンス。
 GPLが適⽤された OSSを改変して派⽣著作物を作成し、配布する場合、その全体についてGPLの条件を遵守する義務あり。
- GPLプログラムと他のプログラムをリンクや結合した場合、他のプログラムにもGPLの条件を適⽤する必要あり

 LGPL は、GPL の条件を少し弱めたライセンスで、LGPLが適⽤されたOSS（LGPL プログラム）と他のプログラムをリンクした場合、リンクした他のプログラムに LGPLを適⽤する必要はないが、リバースエ
ンジニアリングを許諾する（禁⽌しない）義務あり。
 最新のバージョンは GPLv3 、GPLv2 の OSS も多数存在。

- GPLv3で追加された条件は、OSS で実施された特許権について、当該 OSS の開発者が保有する特許権を許諾する条件や、ユーザ製品に OSS を利⽤する場合には修正したOSS を再インストールできるように、「インストール
⽤情報」を提供する義務などが追加された。

 また、LGPLv3 については、GPLv3 の追加的許諾条項となった。
 なお、GPL や LGPL は、OSS を配布した際に条件が課されるため、誰にも配布しない場合は、ソースコードの提供等の義務はない。これをカバーするためにAfferoGPLv3 が作成された。
 このライセンスは、クラウドサービス等のサーバでOSS（AfferoGPLv3）を利⽤した場合、（OSS のバ
イナリを配布しない場合でも）サーバにアクセスするクライアントへソースコードを提供する条件がGPLv3に追加されたライセンス。
© LPI-Japan all rights reserved.

14著名なライセンス紹介(②)② CPL v1.0

#LinuC学習中
 IBMが作成したライセンス。
 CPLv1.0が適⽤されたOSSを配布する場合は、ソースコードも提供する義務あり。
 CPLプログラムのコントリビュータに対する特許訴訟（訴訟対象は OSS に限定されていない）を制限。

③ EPL v1.0

 Eclipse Foundation が CPLv1.0 を基に作成したライセンス。
 上記記載の特許訴訟の制限が削除。

④ MPL（最新版は v2.0）

 Mozilla Foundation で作成されたライセンス。もともとは Netscape Communications の弁護⼠により作成されたもの。
 MPLが適⽤された OSS（MPLプログラム）のソースコードを配布する場合は、ソースコードも提供する義務あり。
 最新のバージョンは MPLv2.0。MPLv1.1 の OSS も多数存在。
 MPL v2.0 で追加された条件としては、GPL関連のOSSと組み合わせて配布する場合、“Secondary
License”（GPLv2.0/LGPLv2.1/AfferoGPLv3.0、以降のバージョンを含む）を適⽤することを許諾するか否かを定めることが可能に。
© LPI-Japan all rights reserved.

15著名なライセンス紹介(③)⑤ Apache License（最新版は v2.0）#LinuC学習中
 Apache Software Foundation が作成したライセンス。
 最新のバージョンは Apache License v2.0 。Apache Software License v1.1も多数存在。
 Apache Software Licensev1.1は、ドキュメントへの謝辞の記載義務がある。
 Apache License v2.0 では、謝辞の記載義務は削除され、開発者による著作権や特許権の許諾が明確に。

⑥ BSD License カリフォルニア⼤学で作成されたライセンス。
 制限は緩く、著作権表⽰と許諾リスト、免責条項を記載する義務あり。
 以前の OLD BSD License（4-Clause）には、宣伝媒体に所定の謝辞を記載する条件があったが、NEW
BSD License（3-Clause）では、削除された。2-Clauseの BSD License もあり、3-Clause から開発者
名等の利⽤許諾に関する条件を無くし、ソースコードとバイナリの配布条件を記載したライセンス。

© LPI-Japan all rights reserved.

16著名なライセンス紹介(④)⑦ MIT License#LinuC学習中
 マサチューセッツ⼯科⼤学で作成されたライセンス。
 制限は緩く、著作権表⽰と許諾表⽰を記載する義務がある。
 BSD License（2-Clause）と利⽤条件は類似しているが、MIT License では、サブライセンスの許諾等、著作権者が許諾する内容が細かく記載されている。

⑧ CC ライセンス（最新版は v4.0）

 クリエイティブ・コモンズで作成されたライセンス。
 条⽂とは別に、条件をマークで⽰すことで分かりやすくしたライセンスで、マークにはクレジットの表⽰
義務、営利⽬的での利⽤禁⽌、改変禁⽌、ライセンス継承義務の４種類があり、これらの組み合わせにより条件を⽰す。
 なお、本ライセンスは、OSI 承認のライセンスには含まれない。

© LPI-Japan all rights reserved.

17主要なライセンスの条件
OSSライセンスの種類（例）
著作権表
⽰義務

主要なライセンス条件
ラ イ セ ン スの承 継(同⼀条件
で配布)

特許権の⾏使制 限
等 (注 2)#LinuC学習中
保証免責

有

必須特許許諾。差別的ライセンス禁⽌

無保証で配
布

有

明⽂なし

同上

OSS(改変部分を結合する他コー含む)のソースコー ド への伝搬 性
ド提供義務
(注 1)
有

責任制限

GPLv3

有

有

GPLv2

有

有

LGPLv2.01

有

有

有

無(注３)

明⽂なし

同上

MPLv1.1,
v2.0

有

有

有

無

ソース開⽰で権利不⾏使約束同上Apache V2.0

有

有

無

無

必須特許許諾。特許
ライセンス終了条件

同上

修正版BSD

有

有

無

無

明⽂なし

同上

MIT

有

有

無

無

明⽂なし

同上

（注 1）「伝搬性」とは、ある OSS と⼀体化したソフトウェア全体（OSS の派⽣物）に対して、ソースコードの公開等、OSS ライセンス（許諾条件）が適⽤されること。
（注 2）「特許権の⾏使制限」には、①OSS の貢献者（作者）や配布者が OSS を配布する相⼿⽅（下流のユーザ）に対する「特許ライセンス義務」と、②OSS のライセンサーやコントリビュータに対して特許権を⾏使すると、⾃⼰に対する当該 OSS に実施されている特許ライセンスが⾃動的に消滅しまたは解除される「特許ライセンス終了条件」がある。
（注 3）LGPLv2.1 は、リンクによる⾃社開発プログラムへの伝搬性はないが、ユーザ⾃⾝の利⽤のための著作物の改変を許可し、その改変をデバッグするためのリバースエンジニアリングを許可しなければならない（LGPLv2.1 第 6 条）。数字のパラメタやデータ構造のレイアウト、アクセス機構または⼩さなマクロや⼩さなインライン関数(⻑さが 10⾏かそれ以下)のみ利⽤するならば、そのオブジェクトファイルの利⽤は制限されないとされている（LGPLv2.1 第 5 条）。

© LPI-Japan all rights reserved.

18ユーザに提供すべき情報
n⾃社製品にOSSを組み込んだ場合、ユーザに提供すべき情報 利⽤している OSS の名称とバージョンの情報（対象の特定）
 OSS に添付されているライセンス条件と同⼀のライセンス⽂書
 無保証であること（免責条項）の表⽰
 配布する OSS の著作権表⽰（記載されていた著作権表⽰を削除しない）
 その他、個々の OSS のライセンス条件で定められた情報。
（例）OSS を改変した場合には、改変の事実と改変者の名前
 謝辞の記載
 GPL の場合は、ソースコードを提供すること等#LinuC学習中© LPI-Japan all rights reserved.

19

OSSコミュニティ© LPI-Japan all rights reserved.

20

OSSコミュニティとは︖
nOSSコミュニティとは︖
 オープンソースソフトウェアの開発・改善、情報交換などを⽬的に、さまざまな⽴場の有志によって構成された仮想の組織。

#LinuC学習中

nコミュニティの種類
 開発コミュニティ- オープンソースを開発するコミュニティ- 企業がコミュニティを主導する場合もある（例）MySQL（Oracle）、JBoss（RedHat）など

 ユーザーコミュニティ- オープンソースを利⽤するにあたり、情報交換を⾏ったり、⽇本語ドキュメントの作成を⾏ったりするコミュニティ（例）⽇本MySQLユーザ会、⽇本PostgreSQLユーザ会など

nOSSコミュニティの変化
 ボランティア主導→企業主導へ。
 ⼤⼿企業が貢献を競争する場所© LPI-Japan all rights reserved.

21

主なOSSコミュニティ
n主なOSSコミュニティ
 Linux Foundation#LinuC学習中- Linux だけではなく、各種オープンソースコミュニティに対して、種々の施策を⾏って活動の⽀援をしている組織- 各種オープンソースプロジェクトの運営、コミュニティへの資⾦援助、インフラの提供、イベントの開催、トレーニングの提供などを実施。

 Apache Software Foundation- Web アプリケーションサーバー「Apache HTTP Server」をはじめとして、数多くのオープンソー
スプロジェクトを⽀援する⾮営利団体。
- 代表的なプロジェクト︓「Apache Tomcat」、「Log4j」、「JMeter」など。

 GNUプロジェクト- UNIX ライクな OS である「GNU」を開発するためにスタートしたプロジェクト。
- OS 本体のほか、ユーティリティやアプリケーションなども開発。
- Free Software Foundation (FSF)が⽀援。

© LPI-Japan all rights reserved.

22

OSSコミュニティに参加する⽅法
nOSSコミュニティに参加する⽅法
 コミュニティの活動内容#LinuC学習中① 開発（コア、拡張機能）② QA （バグレポート、テスト）③ L10N: ローカライゼーション（翻訳 / ⾔語ごとの機能開発）④ ドキュメント作成⑤ テンプレート作成⑥ マーケティング
コードを書くことだけが貢献ではない︕⑦ インフラ（ Web 、ビルドサーバー）⑧ ユーザーサポート（ Q&A サイト、 ML)⑨ イベント運営⑩ コミュニティ運営© LPI-Japan all rights reserved.

23

誰が開発しているのか？①n主なOSSコミュニティの開発者の状況
Kubernetes

VMware 2.1%

FathomDB

IBM 1.5%

1.3%

Microsoft 2.1%
Huawei 3.9%
ZTE

Intel 4.3%

NEC 4.7%
Huawei 4.9%
HP 7.3%

Corporation
2.6%

OpenStackRed Hat18.5%

Google 47.8%

Red Hat 34.1%*independent
9.6%*independent
20.2%

Rackspace

IBM

10.4%

11.1%

Mirantis
13.6%

個人の技術者が少ない
https://www.stackalytics.com/© LPI-Japan all rights reserved.

24

誰が開発しているのか？➁
u Linuxカーネルの場合

Ø Linux Foundationが発⾏している「Linux Kernel Development Report(*)」によると
ü 「不明」と「なし」のグループを含めた上位 10 社が、カーネルに対する貢献の約 55%
ü カーネル開発の 80% 以上は、企業の正規の仕事として⾏われている。
ü 企業の⽀援を受けていない開発者からの貢献は、⻑期にわたって緩やかに減少傾向。
2012年版︓17.9%, 2013 年度版︓13.6%, 2015 年度版︓12.4%今回︓ 8.2%
2011
社名

2012
企業名

2013
企業名

2015
企業名

2017
企業名

割合
18.90% なし
12.40% R ed H at
7.00% N ovell
6.90% Intel
6.40% IB M
5.80% 不明
2.60% C onsultant
2.30% O racle

割合17.90% なし
11.90% R ed H at
6.40% Intel
6.20% Texas Instrum ents
6.10% Linaro
5.10% SU SE
3.00% 不明
2.10% IB M

割合13.60% なし
10.20% Intel
8.80% R ed H at
4.10% Linaro
4.10% Sam sung3.50% 不明
3.30% IB M
3.10% SU SE

割合
12.40% Intel
10.50% なし
8.40% R ed H at
5.60% Linaro
4.40% 不明
4.00% IB M
3.20% consultants
3.00% Sam sung割合13.10%
8.20%
7.20%
5.60%
4.10%
4.10%
3.30%
3.20%

1.40% A cadem ia

1.30% Sam sung2.60% C onsultants

2.50% SU SE

3.00%

1.30% N okia

1.20% G oogle

2.40% Texas Instrum ents

2.40% G oogle

3.00%

academ ics

1.30% 富士通

1.20%

2.20% A M D

2.70%

SG I

1.30% Texas Instrum ents

2.10% R enesas Electronics

2.00%

富士通

1.20% B roadcom

2.10% M ellanox

2.00%

なし
R ed H at
N ovell
IB M
不明
Intel
consultants
O racleR enesas
Technology
The Linux
Foundation

V ision Engraving
System s
1.10% C onsultants
W olfson
1.10%
M icroelectronics

V ision Engraving
System s
1.70% G oogle
R enesas
1.60%
Electronics
2.30%(*)https://go.pardot.com/l/6342/2017-10-24/3xr3f2/6342/188781/Publication_LinuxKernelReport_2017.pdf© LPI-Japan all rights reserved.

25

なぜコントリビュートするのか︖
nなぜコントリビュートするのか︖
Ø個⼈的な理由#LinuC学習中

ü既に持っているスキルを改善する
ü似たようなことに興味を持っている⼈に出会うüメンターを⾒つけ互いに教え合うüあなたの評判（やキャリア）を育てるのに役⽴つ成果物を作り上げるüピープルスキルを学ぶ
ü変化を起こせるようになる助けとなる、たとえそれが⼩さな変化であったとしてもØビジネス上の理由
ü優秀なOSS開発者の採⽤
üメンテナンスコストの削減
üプロジェクトの⽅向性への影響⼒© LPI-Japan all rights reserved.

26

コントリビュートするプロジェクトの⾒つけ⽅①nコントリビュートするプロジェクトを⾒つけ⽅
Øプロジェクトのチェックリスト①#LinuC学習中

üオープンソースの定義に適っているかüコミットアクティビティのチェック– 最新のコミットはいつか︖– そのプロジェクトには何⼈のコントリビューターがいるか︖– どのくらいの頻度でコミットしているか︖

üプロジェクトのイシューへの対応状況– いくつのイシューがあるか︖– メンテナーはイシューがオープンされたらすばやく反応しているか︖– イシューでアクティブな議論は⾏われているか︖– イシューは最近のものか︖– イシューがクローズされているか︖© LPI-Japan all rights reserved.

27

コントリビュートするプロジェクトの⾒つけ⽅➁
nコントリビュートするプロジェクトを⾒つけ⽅➁
Øコントリビュートする前のチェックリスト➁#LinuC学習中

üプルリクエストへの対応状況– いくつのプルリクエストがあるか︖– メンテナーはプルリクエストがオープンされたらすばやく反応しているか︖– プルリクエストでアクティブな議論は⾏われているか︖– プルリクエストは最近のものか︖– どのくらい最近プルリクエストがマージされたか︖

üプロジェクトは歓迎してくれるか– メンテナーはイシューでの質問に助けとなるような回答をしているか︖– ⼈々はイシューやディスカッションフォーラム、チャットで友好的か?
– プルリクエストはレビューされているか︖– メンテナーはコントリビュートに対して感謝しているか︖© LPI-Japan all rights reserved.

28

良き企業市⺠になるために
n良き企業市⺠になるためにØまずコミュニティに参加する。

#LinuC学習中- メーリングリスト、フォーラム、インターネット リレー チャット（IRC）、Slack、バグ トラッカ
ー、ソースコード リポジトリなどが。

Ø最初はリードオンリー ユーザーで。

- コミュニティ⽂化を吸収するために相当な時間を費やし、このコミュニティの⾏動規範や期待される振る舞いを理解する。

Øガバナンスを理解する。
- プロジェクト内で、どのように意思決定が⾏われ、さまざまなコントリビューションに対して、誰が意思決定しているのかについて理解する。

Ø⼩さく始める。
- 簡単なバグやドキュメントの修正から始める。

Øイベント等で良い関係を構築する。
Ø早めに、⾼頻度でコミュニティを巻き込む。
Øアップストリームにコントリビューションする。

© LPI-Japan all rights reserved.

29

コントリビューションするためのベストプラクティス
nコードをアップストリームにコントリビューションするためのベストプラクティス
あなたの組織内部で推進すること
1. 正当な理由づけによって、アップストリ
ームにコントリビューションする決定を下すこと。
2. アップストリームを念頭に置いてコードを設計し、実装すること。
3. 「上流第⼀（upstream first）」ポリシーを採⽤し、まずパッチをアップストリー
ムに提出し、⾃社製品ではダウンストリ
ームのものを採⽤すること。
4. たとえ⼤きな関与でなくても、あなたの開発者をオープンソース プロジェクトに関わり続けるようにすること。

#LinuC学習中

外部との関わりで推進すること
1. あなたのコントリビューションが他の⼈にも役⽴つことを確認すること。
2. 適切なコーディング スタイルに従うこと。
3. プロジェクトのコントリビューション提出プロセスに従って作業すること。
4. あなたのコントリビューションについての説明やドキュメントを提供すること。
5. フィードバックに⽿を傾けて、それに対応すること。
6. ⾟抱強く、受け⼊れられるまでコードの改良、修正を続けること。

https://www.linuxfoundation.jp/resources/open-source-guides/participating-open-source-communities/© LPI-Japan all rights reserved.

30

オープンソース コントリビューションを習得するための11項⽬の秘訣
nオープンソース コントリビューションを習得するための11項⽬の秘訣#LinuC学習中
 オープンソース コントリビューションのためのポリシーとプロセスを確⽴する
 すべてのオープンソース コントリビューションの承認を監督するチームを設置する
 あなたのテクノロジーが活かせる領域に焦点を当てる
 コントリビューターに必要なITインフラとツールを提供する
 コントリビューションのためのベストプラクティスのトレーニングをスタッフに提供する
 コントリビューションをトラッキングし、効果を評価し、改善し、コミュニケーションをとる 経験の少ない開発者をトレーニングするための指導プログラムを確⽴する
 コントリビューション ガイドライン（どのようにすれば良いか、しても良いこと、してはいけないことなどを⽰す）を提供する
 開発者がオープンソース関連で法務サポートを受けられるようにする
 あなたにとって最も価値のあるオープンソース コミュニティから雇⽤される
 各プロジェクト コミュニティの持っている固有のプロセスやプラクティスに常に従う

https://www.linuxfoundation.jp/resources/open-source-guides/participating-open-source-communities/© LPI-Japan all rights reserved.

31

OSSの開発スタイル
nOSSの開発スタイル
 伽藍とバザール#LinuC学習中- ソフトウェアの開発⽅式- 伽藍⽅式– 中央集権的に伽藍を組み上げるようなやり⽅。
– 少数の⾼スキルの開発メンバーで慎重に開発。
– 完成するまでベータ版すら出さないような、リリースに対して厳しい考え⽅。

- バザール⽅式– Linuxの開発で採⽤されているやり⽅。
– 任せられるものは他⼈に任せ、早めに頻繁にリリースする。
– リリースに対しては厳しくない。

© LPI-Japan all rights reserved.

33

OSSコミュニティの構造①n(⼀般的な)OSSコミュニティの構造#LinuC学習中

＃ 役割

説明

1 リーダ

各コミュニティの調整を⾏う⼈物。企業内プロジェクトと異なり、⼀般的に⺠主的に選ばれ、⺠主的な運営を⾏う。

2 コミッタ（開発コミュニティのみ）プログラムを変更する権限をもつ⼈物。コミュニティによって選出される。
ソフトウェアの⽅向性について投票が⾏われる場合の投票権を持ちソフト
ウェアの⽅向性に関与できることが特徴。

3 活動メンバ（開発コミュニティでは
ディベロッパともいう）

コミュニティに参加し、発⾔する、アクションを起こす⼈物。開発コミュ
ニティでは、⼀部の機能の実装を⾏うこともある。

4 参加者

コミュニティに何らかの形で参加しているが、積極的なアクションを起こしていない、もしくは今後アクションをしようとしている⼈物。

5 ⽀援者

コミュニティ運営に必要な資⾦、⼈材、物資などの提供を⾏う⼈もしくは団体。⼀般に、ソフトウェアの⽅向性に対する発⾔は⾏わずに⽀援する⽴場をとる。

© LPI-Japan all rights reserved.

34

OSSコミュニティの構造➁
nASFプロジェクトの構成#LinuC学習中

 トッププロジェクトの数︓373プロジェクト
 コミッターの⼈数︓7,826名
PMC(プロジェクト管理委員会)
・コミュニティ全体の運営・⽅針決定
・新たなコミッタの選出
・プロダクトのリリース判断
コミッタ・プログラムの書き換え・投稿された修正をプログラム本体に反映

開発者
・修正の投稿
新機能・機能改善・バグ修正
などを投稿

利⽤者
・ソフトウェアの利⽤・改善リクエスト・不具合の報告
・利⽤⽅法の問い合わせ© LPI-Japan all rights reserved.

35

コミュニティのライフサイクル①
uコミュニティの発展と終焉
エコシステムの確⽴

OSSの派⽣・別の⽬的のため・コミュニティ存続のため

関連プロジェクトの誕⽣

ユーザ
コミュニティ
の設⽴

OSS認知

開発
コミュニティ
の設⽴
・少⼈数の開発者による形成
・企業のソフトウェア公開から形成
・既存OSSの派⽣から形成

コミュニティ
の終焉
・開発/保守など維持ができなくなる（資⾦不⾜）
・ユーザの⽀持を失う
・同じ役割を果たす新たなOSSの出現(世代交代)
・リーダの興味がなくなる© LPI-Japan all rights reserved.

36

コミュニティのライフサイクル②
uOpenOfficeの場合(誕⽣から・・・・)
1999 : Sun Microsystems、StarVision買収
2000/10 : 「OpenOffice.org」プロジェクト⽴ち上げ
2010/01 : Oracle、 Sun Microsystems買収 →プロジェクトの管理がOracleに移管
2010/05 : ⼀部メンバーが、「The Document Foundation」を⽴上げ→「Libre Office」プロジェクト⽴ち上げ
エンジニアの流出始まる

2011/04 : Apache Software Foundationに移管→「OpenOffice.org」終了。
2011/07 : IBMが「Lotus Symphony」のソースコードを「Apache OpenOffice」プロジェクトに寄贈。
2012/05 : 「Apache OpenOffice 3.4.0」リリース「開発者不⾜」でプロジェクトが存続するための条件を満たせない

2016/09 : 「Apache OpenOffice 」存続が困難に
2017/10 : 「Apache OpenOffice 4.1.4」リリース© LPI-Japan all rights reserved.

37

OSSとビジネスモデル© LPI-Japan all rights reserved.

38

ビジネスモデルについて
u ビジネスモデルØ およそOSSのビジネスモデルは、下記の4つに分類できる。
#

モデル

内容

例

1 ディストリビューション

⾃社またはコミュニティにて開発されたソフト
RedHat, SRA OSS,
ウェアの配布とサポートを⾏うモデル
Oracle, Zabbix,(ex.Red Hat Enterprise Linux, PowerGres, サイバートラスト等
MySQL, Miracle ZBX 等)

2 システムOSSを活⽤したシステム構築およびプロフェッショナルサービス（コンサルテーションを含む)を実施するモデル

NTTデータ, SIOS,SCSK,CTC等

3 サービスモデル

OSSを活⽤して構築したサービスを提供する
モデル(ex. Amazon RDS 等)

AWS, Google,Facebook,
楽天,ヤフー,リクルート等

4 その他

ハードウェア販売などの⽬的達成のためにOSSを ハードウェアベンダー
活⽤するモデル(⽇⽴、富⼠通、NEC等)
クラウドベンダ︖

モデル

インテグレーションモデル

© LPI-Japan all rights reserved.

39
39

ビジネスモデル事例(コミッタの輩出)
uNTTデータの場合
nコミッタ就任#LinuC学習中Ø2014/12︓Apache Hadoopおよびその関連のプロジェクトのコミッタに、⼩沢健史⽒（NTTソフ
トウェアイノベーションセンタ）、鯵坂明⽒、岩崎正剛⽒（NTTデータ システム技術本部）の3⼈が就任。
Ø2015/6︓猿⽥浩輔⽒(NTTデータ システム技術本部)が、分散データ処理ソフト「Spark」のコミッタに就任。
Ø2016/1︓鯵坂明⽒と⼩沢健史⽒は、Hadoopおよびその関連のプロジェクトのプロジェクトマネジ
メント委員(以下PMC)に就任。
Ø2019/12︓Apache AirflowのコミッターおよびPMCに関 堅吾⽒が、Apache Ambariのコミッタに⽥中 正浩⽒がそれぞれ就任。

nコミッタになるということ
Øコミュニティとの連携により、⾼品質なサポートサービスが可能Ø社外への技術⼒のアピール© LPI-Japan all rights reserved.

40

ビジネスモデル事例(OSS化の意義)
uミドクラの場合
nネットワーク仮想化ソフト「MidNet」をOSS化。(2014/11)#LinuC学習中

Ø「MidoNet」とは︖
ü オーバーレイ型のネットワーク仮想化を実現するソフトウェア。
ü 物理的なネットワーク構成の上に、仮想的なレイヤ2ネットワーク、レイヤ3ネットワークを構成し、ファイアウォール、ロードバランス、アクセスコントロールやセキュリティグループなどの機能を実現。

Ø⾜掛け5年で25億円を要して開発したソフトウェア。

nなぜOSS化したか︖
Ø⽶国⼤⼿企業から、「ベンチャーが開発するソフトウェアは、OSSでなければ導⼊できない」と⾔われた。
Ø開発ベンダーが買収されたり、開発が継続できなくなるようなことが発⽣し、継続的に利⽤することに⽀障が起きるようでは困る。

nOSS化の効果
ØOSS化したことで、他社のエンジニアが検証した結果をブログ等で公開。
→ 認知度がそれまでに⽐べ⾶躍的に向上。
Ø技術⼒の⾼さの証明。

© LPI-Japan all rights reserved.

41

OSSの「これまで」と「これから」© LPI-Japan all rights reserved.

42

オープンソースの『これまで』
普及まで
20年

Linux
領域

2010:東証、新売買システム(arrowhead)にLinuxを適⽤
2008︓東証がLinuxを本格採⽤

2003:Linux2.6.0リリース︓⼤規模システム適⽤可能に。
2000:OSDL(現Linux Foundation)発⾜

新しいOSSは進化のスピードが速い

1999:⼤⼿ハードベンダがLinux⽀持を表明し、開発コミュニティへ参加
1994:Linux1.0リリース

2014:Docker1.0リリース

1991:Linuxプロジェクト開始
1983:GNUプロジェクト開始

2004︓⽇本OSS推進フォーラムにOSSの普及促進に向けて産学官ユーザが集結

1995:Apacheプロジェクト開始

普及まで
20年

1995:MySQL1.0リリース
1996:PostgresSQL※6.0リリース
OSSミドル領域

1998:ネットスケープ社がブラウザソフトのソースを公開
2002:Nutchプロジェクト開始※原型のPostgreプロジェクトは1986年にスタート

Ver 2.４
Ver 8.0
Ver
10.5

2014:Spark1.0.0リリース

2006:NutchからHadoopプロジェクト独⽴
2010:OpenStackプロジェクト開始© LPI-Japan all rights reserved.

43

オープンソースの『これから』OSSの利活⽤度・企業競争⼒

OSS利活⽤の意義[2000年]-Unix → Linux-アンチ Windows OS-RedHat 市場拡⼤牽引-サーバH/W市場拡⼤[2010年]- 仮想化技術- ⾮構造化データ増⼤- クラウドサービスの利⽤拡⼤

旧来のOSS推進

ビジネスイノベーション
(SoE)

今後の
OSS推進
コスト削減
(SoR)

[2015年]-クラウド前提のシステム連携・開発-ビジネス部⾨とITの直結-BigDataやIoT、AIなど新分野でのOSS適⽤

適⽤領域・成熟度
主領域

OS領域

ミドル領域

アプリ・サービス領域

主導

情報システム部⾨

事業部⾨

企業体

⽬的

改善活動

IT化速度向上

市場創成、⾰新、企業競争⼒向上

企業間

コスト競争

協業・連携

エコシステム化

基盤

物理・仮想

単⼀クラウドマルチクラウド、IoT、M2M© LPI-Japan all rights reserved.

44

ご清聴ありがとうございました© LPI-Japan / EDUCO all rights reserved.