情報と社会
第12回: 標準化とオープンソース
Martin J. Dürst
duerst@it.aoyama.ac.jp
O 棟 529号室
テュールスト マーティン
ヤコブ
https://www.sw.it.aoyama.ac.jp/2021/InfoSociety/lecture12.html
© 2005-21 Martin
J. Dürst 青山学院大学
今日の内容
- 第一部: オープンソース
- 第二部: 標準化
- 第三部: 標準化とオープンソースの関係
個人的背景
第一部: オープンソース
(Open Source Software, Open
Source)
簡単な定義:
ソースコードがただで入手、変更も可能なソフトウェア
例:
反例: Microsoft, Apple, Adobe, Google, Facebook
などの多くの製品
オープンソースの歴史
オープンソースの例: Ruby
- まつもとゆきひろによって作られたプログラミン言語
- 最初 (1993) からオープンソース
- ソースが自由に閲覧、ダウンロード可能
- 現時点で ~63000
個のコミット (貢献・改善)
- 100人以上のコミッタ
(ソースを変更する権利を持つ人)、他にも多くの貢献者
オープンソースの種類
- オープンソースではない:
- シェアウェア等: 低価格
- フリーウェア: 無料、しかしソースは非公開
- ソースが公開されたが、使用、変更が制限されているもの
(スクリプトなど)
- オープンソースの主な流れ
(両種類のライセンスを許すプロジェクトも存在)
オープンソースの背景
なぜオープンソースソフトウェアがあるが、例えばオープン自動車がないのか
?
- 複写・配布はほぼ無料
- 様々な形に対応可能
- ユーザの多様な要求に対応可能
- インターネットで物理的な距離と関係なく配信・協力可能
- ツールによって遠隔開発のサポート:
- 電子メール、チャット、Wiki, Blog, Skype, Twitter, Line,
Slack,...
- 版管理システム (SVN; git, Mercurial, Bazaar, darcs)
- 開発用ウェブサイト (例: Github, Sourceforge)
- 配布用ウェブサイト (例: Freecode)
- バグ・提案管理ツール (例: Redmine,..., Ruby bug
tracker)
- バグの修正を促すサイト (例: CodeTriage)
「オープン」の普及
最近は「オープン」が広がる:
オープンソースが無料な開発サイト
会社向けの有料サービスはオープンソースの場合、無料
一部の例:
オープンソースの作成・公開の動機: 企業
- ソフトウェアではなく、サービスで勝負
- 企業の共同開発や一般人の協力でコスト削減
- 他の企業と違う作戦
- オープンソースによる市場の拡大
(具体例: Cisco
と H.264)
- 近年、オープンソースが飛躍的増加
オープンソースの作成・公開の動機: 個人、大学など
- 就職、転職に有利
- 商品化は大変、オープンソース化は簡単
- 少しのお金より名誉が嬉しい
- 他人からの修正・改善・拡張など期待
- 会社お越しにオープンソースを利用
オープンソースの使用の動機
- コストの低下
- 変更はいつでも可能
- 内容のチェックが可能
- 選択肢の拡大
- プログラミングの勉強
オープンソースに必要な注意点
作成者側も利用者側も注意点が類似
- セキュリティの脆弱性,...
- 利用に合ったライセンスの有無 (商業ライセンスの方が複雑)
- 提供されたコードが問題無しか
(第三者が所有するコードを提供されたら困る)
- 特許の侵害の有無
会社としての対策:
オープンソースに基づくソフトを専門の会社 (例: RedHat) から提供
オープンソースの詳細
- 単純な定義では色々な問題が起こりうる
- Open Source Initiative による定義 (日本語):
- ソースがほぼただで見える
- 再配布が自由
- 派生の許可
- 完全性 (著者など) の保証
- 差別の禁止: 個人やグループ、利用分野に対して
- 追加ライセンス契約、特定商品との結びつき、他のソフトウェアの制約の禁止
第二部: 標準化
(標準: standard; 標準化: standardization)
標準は、基本的なもの (秒、メートル等)
をはじめ、生活において大切な役割
例: トイレットペーパに書かれた文書:
「幅が114ミリのトイレットペーパーで、日本工業規格（ＪＩＳ規格）に準じた製品サイズ（幅＝114ミリ：直径＝120ミリ以下）ですので、一般的なホルダーにも使用できます。」
標準の定義
- 標準化プロセスと標準化団体のコンテキストで
- ステークホルダーで合意された
- 技術的な成果物のための
- 要件を記述する
- 文書 (仕様(書))
情報テクノロジーでの標準の大切さ
- データの長期保存
- 通信でのやり取り
- 大量化によるコスト削減
一企業が作った商品 (例: MS Word)
も標準として宣伝されていることがあるが、それだけでは標準と言えない
標準作成機関: 標準化団体
[標準・仕様のリスト: W3C, IETF, IEEE,
ISO,
OMG, The Open Group, Oasis]
標準化のプロセス
- アイディア、提案、標準化団体への提供 (submission)
- 委員会 (working group) の設置、議論
- 文書化、草案 (draft) 公開、意見募集・投票
- 正式決定、発表
- 実装 (もっと前から行った方が良い場合が多い)
- 普及
- 製品の認証 (certification)
- 正誤表、格上げ、見直し、拡張・第二版など
標準化団体の評価
標準化団体が多く存在する中で、評価が大切
標準の評価
- 必要な機能が揃っているか
- 無駄な機能が少ないか
- 普及度、普及の見込み
- 誤りが少ない
- 正誤表 (errata, 例) の整備
- 拡張性が高い
- 関連規格との整合性
- 分かりやすさ
- オープン標準か
第三部: 標準化とオープンソース
- 標準化と標準はオープンなのかどうか
- オープンソースに標準が有利
個人的な事例
例: ユニコードの正規化 (NFC, サ+゛→ ザ)
オープン標準
(Open
Standards と Business
Case for Open Standards 参照)
- だれでも読める、誰でも実装できる
- ユーザの選択肢を最大限に活かす
(特定のメーカ、製品に制限しない)
- 実装は無料で可能
(必要不可欠な特許やライセンス料などがない)
- 実装や利用者の差別がない
- 実装、利用は拡張や部分的で可能
- 乗っ取り防止
- プロセスの透明性、一般人からの提案の可能性
標準のオープンソースへの影響
- オープンソースの開発者の間の調整が難しい
- 面識が殆どない
- 活動の時間帯が異なる
- 多数のプログラマーによる実装
- 標準によって目的がはっきりされる
(標準がオープンソースの仕様書)
- 典型例: Linux の開発
- Unix:
会社によって開発された人気 OS
- Posix: Unix の
API の標準化
- Linux: Posix に準拠の実装
(内部は Unix と違う)
オープンソースの標準化への影響
- 早い段階での実装・検証・テスト
- フィードバックがしやすい
- 締め切り (製品販売日に向けて) はない
- 普及のきっかけ
- 複数の実装の保証
(多くの標準の場合い、格上げの条件)
まとめ
- 標準 (化)
とオープンソースは情報テクノロジーにとって非常に大切
- 使用する機会を検討しましょう
- 貢献を是非検討してください
(バグの報告、新機能の提案など)
レポート: 別紙参照
提出: 2021年12月23日 (木曜日) 18:40 時 (厳守) O棟
5階の529号室前の箱に投稿
参考文献
- Producing Open Source Software: How to Run a Successful Free
Software Project, Karl Fogel, O'Reilly, 2006.
- Innovation Happens Elsewhere: Open Source as a Business
Strategy, Ron Goldman and Richard P. Gabriel, Morgan Kaufmann,
2005.
- Intellectual Property and Open Source: A Practical Guide to
Protecting Code, Van Lindberg, O'Reilly, 2008.
- Open Source Licencing: Software Freedom and Intellectual Property
Law, Lawrence Rosen, Prentice Hall, 2005.
- Free Software, Free Society: selected essays of Richard M.
Stallman, Joshua Gay, Ed., GNU Press, 2002.