可能なソフトウェアの総称である[1]。間でソフトウェアのソースコードはパブリックドメインで共有されていた。1970年代前後よりソフトウェア開発は徐々に商業となり、ソフトウェアの再頒布を禁止するプロプライエタリ・ソフトウェア、ソースコードを非公開とするクローズドソースの文化ができあがった[2]。許すことによるソフトウェア開発の発展を提唱し、オープンソースソフトウェアの文化ができあがった。一般に使われている基準として、オープンソース・イニシアティブの提唱するオープンソースおよびフリーソフトウェア財団の提唱するフリーソフトウェアのカテゴリに含まれるソフトウェアがオープンソースソフトウェアである[1][3]。有償である、商用利用は禁止されるなどの制限がある場合は、オープンソースソフトウェアではなくプロプライエタリ・ソフトウェアやシェアードソース・ソフトウェアと呼ばれる[4]。GPL・Apache-2.0・MITなどの既存の汎用的なライセンスを利用することが推奨されている[5][6]。類似した概念にオープンソースハードウェア・オープンシステム・オープンコンテントなどがある。する文化は存在していた。1970年代以降、ソフトウェア開発は徐々に商業となり、ソフトウェアの頒布に制約を付与するプロプライエタリ・ソフトウェア、ソースコードを非公開とするクローズドソースの文化ができあがった[2]。1980年代序盤、リチャード・ストールマンは利用者がソフトウェアのソースコードを自由に利用できないことは非道徳であると考えてフリーソフトウェアを提唱した[7]。リチャード・ストールマンはフリーソフトウェアだけで構成されたオペレーティングシステムを開発するGNUプロジェクトを立ち上げ、フリーソフトウェア運動を促進するフリーソフトウェア財団を設立した。する自由を守るためソースコードの公開を求め、コピーレフト・ライセンスを用いてソースコード共有文化のコモンズ(ローカル・コモンズ)の輪を広げた。Suiteをフリーソフトウェアとしてソースコードを公開した。エリック・レイモンドやブルース・ペレンズ、リーナス・トーバルズたちはソースコードの共有は望ましいが、フリーソフトウェア運動のプロプライエタリ・ソフトウェアへの攻撃的姿勢とコピーレフトの閉鎖性は企業には受け入れられ辛いと考えた[8]。そこでソースコードの共有文化の再ブランドを検討し、ソースコードを公開・共有したソフトウェア開発の実利的なメリットを主観にしたオープンソースを提唱し、オープンソース・イニシアティブを設立した[9][10]。オープンソースの開発手法はホビイストやハッカーの非商用ソフトウェアだけでなく企業・商用のプロプライエタリ・ソフトウェアにも利用され、ソフトウェア開発の分野で広く利用されるようになった。Railsなどのウェブプラットフォーム、Linux・FreeBSD・Androidなどのオペレーティングシステム、OpenCVなどのライブラリ、といったものが開発された。Coreなど、もともとクローズドソースやプロプライエタリだったソフトウェアがオープンソース化されたり、オープンソース版の実装がサードパーティの企業やコミュニティによって別途開発されたりしているものもある。TypeScriptやGoなど、公式の処理系(コンパイラやプログラミングツール)がオープンソースとなっているプログラミング言語も存在する。プロプライエタリだったが、のちにオープンソース版のRoslynコンパイラ(英語版)が開発された。処理系がオープンソース化されるプログラミング言語は、言語仕様がオープン標準になっていたり、ISOやEcmaといった団体によって標準化されていたりするものも多い。可能なソフトウェアと定義される[1]。オープンソースライセンスが課せられたソフトウェアやパブリックドメインに置かれたソースコードとそのソフトウェアなどがそれに当たる。可能であるソフトウェア」と定義している[1]。ソースコードが開示されていても商用を目的として提供されるソフトウェアはオープンソースソフトウェアとは区分せず、プロプライエタリ・ソフトウェアやクローズドソース・ソフトウェアに区分している[4]。オープンソース・イニシアティブは「オープンソースの定義」に従ったソフトウェアをオープンソースのソフトウェアと定義している[11]。オープンソースの定義は単純にソースコードへのアクセスが開かれていることを定義するものではなく、オープンソースのソフトウェアは利用者がそのソースコードを商用および非商用の目的を問わず利用・修正・頒布することを許し、それを利用する個人や団体の努力や利益を遮ることがないことを定義している[12]。オープンソース・イニシアティブはオープンソースライセンスというライセンスカテゴリを管理しており[5]、そのオープンソースの定義に準拠したライセンスのみをオープンソースライセンスとして承認している。オープンソースソフトウェアはオープンソースライセンスが課せられたソフトウェアであると言い換えることが出来る[13]。フリーソフトウェア財団はオープンソースソフトウェアという単語についての定義は行なっていないが、類似した概念としてフリーソフトウェア(フリーは無料ではなく自由という意味)という単語を「フリーソフトウェアの定義」において定義している[14]。することが可能である。フリーソフトウェア財団の代表であるリチャード・ストールマンはオープンソース・イニシアティブの定義するオープンソースという単語およびその活動を否定的に発言しており[15]、同財団ではオープンソースソフトウェアという単語の定義および意義については消極的である。日本の総務省はオープンソース・イニシアティブのオープンソースの定義を満たすソフトウェアをオープンソースソフトウェアを定義するものとして参照している[16]。標準化団体[編集]広義のオープンソースソフトウェア(オープンソースのソフトウェアやフリーソフトウェア)の分野における標準化団体はオープンソース・イニシアティブとフリーソフトウェア財団が主要な団体である。Allianceなどの組織がある。software)の発展・促進を目的に活動している非営利団体である。可能とするソースコードの共有文化によるソフトウェア開発の発展のため、オープンソースのソフトウェアをオープンソースの定義において定義し、オープンソースのソフトウェアを利用者の商用・非商用などの目的を問わず利用しやすい文化の構築に貢献している。オープンソースのソフトウェアに適したソフトウェアライセンスをライセンスレビューを通して選定し、オープンソースのライセンスとして承認している。オープンソースのライセンスのリストを逐次更新し、より新しく適切なライセンスの推奨や、時代遅れとなり不適切となったライセンスの非推奨など、オープンソースライセンスの管理をしている。オープンソース・イニシアティブはオープンソースの用語を用いる際はオープンソースの定義に準拠することを求めている。Sourceは一般的な用語であり特定団体が権利を持つ商標にはならないと判断されている[17]。Sourceが一般的な用語として周知されたことを歓迎する立場を取っている。日本では2002年3月にオープンソースグループ・ジャパンが「オープンソース・OPENSOURCE」を商標登録(第4553488号)している[18][19]。日本での用語の利用に際しては特に許諾や制限は求められないが、オープンソースの定義に準拠した扱いで利用されることが望まれている。Source」と表現し、オープンソースのライセンスとして承認していないライセンスをソフトウェアに課していたことを非難した[20][21]。後に、SugarCRMはライセンスをオープンソースのライセンスとして承認されているGPLv3に切り替えている[22]。software)の発展・促進を目的に活動している非営利団体である。フリーソフトウェア財団はソフトウェアの利用者の作成、頒布、改変する自由をユーザーに広く遍く推し進めることを狙い、フリーソフトウェアをフリーソフトウェアの定義において定義し、コピーレフトを基本とする社会運動の支援を目標に掲げている。する自由を守り、その利用者の自由を派生ソフトウェアに展開してフリーソフトウェアのコモンズの輪を広げる概念である。フリーソフトウェア財団はコピーレフトの概念をGPLやAGPLなどのソフトウェアライセンスとして実装し、同ライセンスの利用を推進している。する自由を尊重し、その自由であるソフトウェアを啓蒙する社会運動としてフリーソフトウェア運動を行っている。フリーソフトウェア運動ではフリー(自由)を尊重するソフトウェアやファイルフォーマットをGNU宣言・フリーソフトウェアの歌・PlayOggなどを通して啓蒙している。DesignやTiVo化と表現して批判している。Software)などの表現をすることを求めている。フリーソフトウェア財団はフリーソフトウェアのみで構成されるオペレーティングシステムの開発、およびフリーソフトウェアライセンスの実装とレビューをするプロジェクトとしてGNUプロジェクトを遂行している。その他の団体[編集]freedesktop.orgは、2000年にハヴォック・ペニントンにより設立されたUnix系システムのデスクトップ環境の相互運用性の向上と共通基盤技術の整備を目指した非営利団体である[23]。GNOME・KDE・XfceなどのX11上のデスクトップ環境のユーザビリティの差異の問題を明確化し、共通化の方向性を模索・助力をしている。Server・D-BUS・HALなどの基礎基盤のリファレンス実装を開発し、各ソフトウェアでの実装の差異の削減を図っている。Groupを統合する形で設立されたLinuxオペレーティングシステムの普及をサポートする非営利のコンソーシアムである[24]。Linuxのカーネルを含む開発とそのオペレーティングシステムの成長と普及のための活動を実施している。Foundationにフルタイムで勤務している[25]。Allianceは、2007年11月にGoogleを中心として設立された携帯機器の共通環境の開発を推進するために組織されたアライアンス(コンソーシアム)である[26]。通信キャリア・半導体メーカー・携帯電話メーカー・ソフトウェアベンダーなど携帯機器分野全般の企業・団体が参画している[27]。SDKをオープンソースソフトウェアとして公開している[28]。参画組織はアライアンスが開発したAndroidをフォークして試験的なクローズドソースのバージョンで試験実装をしたり、独自のAndroidディストリビューションを用いた携帯電話の開発・販売している[29][30]。クリエイティブ・コモンズは、2001年に著作物の適正な再利用の促進を目的として設立された非営利団体である。クリエイティブ・コモンズはクリエイティブ・コモンズ・ライセンスという著作物全般に適用可能なライセンスをリリースしている[31]。クリエイティブ・コモンズはソフトウェア分野の著作物には既に適したライセンス(ソフトウェアライセンス)が多数存在しており、クリエイティブ・コモンズ・ライセンスを利用する必要性はないとして、ソフトウェアとソースコードにクリエイティブ・コモンズ・ライセンスを適用することは推奨していない[32]。認めるソフトウェアライセンスである。オープンソースライセンスの多くはソフトウェアのソースコードを公開したパーミッシブ・ライセンスもしくはコピーレフト・ライセンスである。パーミッシブ・ライセンスはソフトウェアの利用に最低限の制約のみを課し[33]、コピーレフト・ライセンスはソフトウェアの利用に利用者の自由を制約として義務付ける[34]。ソフトウェアに課せられたライセンスが本当にオープンソースソフトウェアであることを認めるソフトウェアライセンスであるかについて慎重な法的レビューをするべきである[35]。2018年2月現在、広く使われている、もしくは、著名なコミュニティが採用しているパーミッシブ・ライセンスとしてApache-2.0[36]・BSD-3-Clause[37]・BSD-2-Clause[38]・MIT[39]、コピーレフト・ライセンスのGPLv3[40]・LGPLv3[41]、原作者特権条項のあるMPL-2.0[42]・CDDL-1.0[43]・EPL-2.0[44]が挙げられる[5]。誓約[編集]オープンソースライセンスは、ライセンサー(作者)の定めた誓約に従う範囲でライセンシー(利用者)にソフトウェアとソースコードの自由な利用を認める。WARRANTY)」と宣言した誓約を記す[45]。それに加えてライセンス毎に異なる誓約(条項・条文)が記す。著作権表示条項および広告表示条項は、適切な形でソースコードや付属文書に含まれる著作権表示を保持し、つまり二次的著作物を作った者が自分で0から作ったように偽らないことを定める[46]。著作権表示は改変していないソースコードファイルのヘッダのコピーライトを残した上で、ソフトウェアを利用するエンドユーザーに作品元を表示することを求めるApache-2.0や、ソフトウェアのソースコードツリーのCOPYRIGHTファイルに作品元を記すことを要求するMITなどがある。コピーレフト条項ないし継承条項は、そのライセンスで公開されたソフトウェアを修正して二次創作物として公開する場合に、同じライセンスもしくはそれと同等条件の利用許可を要求するライセンスで公開することを定める[34][47]。同等ライセンスを派生ソフトウェアに課すことで、ライセンスが規程するソースコードの共有文化のコモンズを展開する。派生ソフトウェアに同一ライセンスを要求するGPL・MPL-2.0・CDDL-1.0がある。原作者特権条項は、原則的には利用者にその事項を許可もしくは禁止するが、原作者が利用する場合にはその限りではないことを定める。原作者は利用者にソフトウェアのソースコードを開示することを要求するMPL-2.0・CDDL-1.0がある。ガイドライン[編集]オープンソースライセンスは多数のライセンスが存在しているが、オープンソース・イニシアティブ・GNUプロジェクト・Fedoraプロジェクト・Debianプロジェクトなどは対象のソフトウェアライセンスがオープンソースソフトウェアに課すライセンスとして適切であるかの法的レビューを個々に実施している[35]。オープンソース・イニシアティブとGNUプロジェクトのライセンスレビューは重要であり、それらの団体のレビューを通ったライセンスをオープンソースライセンスとして用いることが推奨される。オープンソース・イニシアティブはオープンソースの定義に基づいたライセンスレビューの実施とライセンスの一覧を管理をしている[48][49]。オープンソースのライセンスの中でも主要なライセンスを選定しており、オープンソースソフトウェアにはその主要なライセンスの中からライセンス選択することを推奨している[5]。オープンソースのライセンスと主要ライセンスの一覧は適宜更新されており、過去に承認・推奨されていたライセンスでも現在は非推奨となったライセンスなどもある。GNUプロジェクトはフリーソフトウェアの定義に基づいたフリーソフトウェアライセンスの一覧を管理している[50]。一覧にはフリーソフトウェアの定義に適合しているか、コピーレフト条項を含むか、GPLと互換性があるか、および特記事項を記載している。フリーソフトウェアはそれに応じた異なるライセンスを選択するべきとし、ライセンス選択時の推奨ガイドラインを出している[6]。一般的なソフトウェアではコピーレフト特性をもつGPL、小さなプログラムではコピーレフト特性を持たないApache-2.0、ライブラリではLGPL、サーバソフトウェアではAGPLを推奨している。Fedoraプロジェクトは同プロジェクトのソフトウェアに課せられるべきソフトウェアライセンスの一覧を管理している[51]。Hat法務担当が公認したものである[3]。ライセンスの検証はFedoraのメーリングリストで公に検証されている[52]。コンフィデンシャルな情報を送ることや、ソースコードについての法的な助言を求めるために利用してはならないし、メーリングリストの参加者が法律家や弁護士であることを仮定するべきではない。DebianプロジェクトはDebianフリーソフトウェアガイドライン(DFSG)に基づいたソフトウェアライセンスの一覧を管理している[53]。Debianの公式パッケージに含まれるソフトウェアは原則としてDebianフリーソフトウェアガイドラインに準拠したソフトウェアライセンスが課せられたものである。Debianフリーソフトウェアガイドラインはオープンソースソフトウェアの定義に符号するものであり、DFSG準拠ライセンスはオープンソースソフトウェアに課すソフトウェアライセンスの一例として参考にできる。検討課題[編集]オープンソースライセンスのライセンスの互換性、矢印が一方的な互換性を表す[54]ソフトウェアライセンスにはライセンスの互換性がある。異なるライセンスはそれぞれが定める誓約の下にソフトウェアとソースコードを利用することが出来るが、ライセンスによっては自身のソフトウェアの利用に対する誓約だけではなく併用するソフトウェアに対して求める誓約を含む場合があり、その際に複数のソフトウェアのライセンスに互換性がない場合はソフトウェアを併用することが不可能となる。Licenseは併用するソフトウェアに同一のライセンスを適用することを求めているため、同ライセンスと商用ソフトウェアのクローズドソースを求めるライセンスは併用出来ない。フリーソフトウェア財団はGPLのコピーレフト誓約違反に対して幾度も訴訟を起こしている。2000年代前半、オープンソースソフトウェアのライセンスは多数の独自ライセンスが策定され、よく似た条文で一部分だけ異なるという有象無象のライセンスがいたずらに作られていったことを問題視し、その事象はライセンスの氾濫と呼ばれ批判の対象となった[55]。ライセンスの氾濫はライセンス製作者の虚栄心を満たすだけの無害なものではなく、オープンソースソフトウェアに課せられたライセンスの内容を精査しなければならない利用者を疲弊させる有害なものであった。Project)を立ち上げ[56]、ライセンスレビューを通して承認ライセンスを選定することでライセンスの氾濫を抑えた歴史がある[57]。ライセンスの氾濫を再発させないため、オープンソースソフトウェアのライセンスは既存のオープンソースライセンスを採用することが推奨される[5][6]。ライセンスの作成者は新規ライセンスの必要性について慎重な検討を経て策定に至り[58]、ライセンスを承認する団体は新規のライセンスが既存のライセンスと本質的な差異がない場合は承認しない判断を下している[59]。BY-SAが強制されるライセンス感染の例ライセンスの継承条文を伴うオープンソースライセンスが課せられたソフトウェアは、その継承条文に基づき、ソフトウェアのソースコードを利用、修正したソフトウェアのソフトウェアライセンスを同等条件のものとするよう縛る。伝播し、ライセンスがウイルスのように感染していくことからウイルス性ライセンス(ライセンス感染)と呼ばれる[60]。BY-SAのSA条項ように同等条件のライセンスを強制するだけ(ソースコードの公開を求めるかどうかは別条文に依る)のものがある[61]。パブリックドメインによる著作権の放棄は著作権法の下に完全に認められたという実績(判決)は存在しておらず、法的な判断が不明瞭である[62]。ソースコード作成者が著作権を放棄する意図でパブリックドメイン以下で公開していたソースコードに対して、ソースコード作成者が考えを変えて著作権の保持を主張してソースコードの二次利用者を訴えた場合に、サブマリン特許のように見解を翻して権利を行使することの是非という道徳的な観点は別として、著作権の放棄の有効性について著作権法の下にどのような判断がなされるのか明確になっていない。パブリックドメインはソースコード作成者の当初の意図に反して著作権の放棄はできておらず、著作権の保持を根拠にしたソースコードの二次利用者に対する訴えは有効であるとされる可能性がある。そのような不確定性のため、オープンソース・イニシアティブはパブリックドメインに相当するCC0を有効なオープンソースライセンスとして承認していない[63]。一方で、フリーソフトウェア財団はCC0を有効なフリーソフトウェアライセンスとして承認している[64]。OSS開発[編集]開発手法[編集]詳細は「オープンソースソフトウェア開発(英語版)」を参照オープンソースソフトウェアの利用者は共同開発者のように扱われる。利用者はソフトウェアのソースコードにアクセスすることができ、ソフトウェアへの機能追加、ソースコードの修正、バグの報告、ドキュメントの提出が可能である。利用者はそれらをソフトウェア開発のメインストリームに反映することができるし、利用者が望むのであれば自身の製品として頒布することもできる。オープンソースソフトウェアで複数の共同開発者を持つことは、ソフトウェアの発展を手助けする。リーナスの法則では、「十分な目玉を与えられることで、全てのバグは浅くなる」と述べている[65]。このことは、多くの利用者がソースコードを眺めれば、結局は全てのバグを発見しそれらの修正方法が提案される、ということを意味している。オープンソースソフトウェア開発に使われる開発ツールはそれもまたオープンソースソフトウェアであることがある。享受できることである。モジュール分解[編集]オープンソースソフトウェアの機能は幾つもの細分化されたモジュールで構成されている。(英語版)、最適化、コード生成などの機能を持ち、それらはモジュールとして一つのソフトウェアに内包される。LAMPのようなSaaSでは、Linux、Apache、MySQL、PHPなどの複数のオープンソースソフトウェアの組み合わせで、一つのサービスを提供している。細分化されたモジュールはそれぞれの機能を得意とする利用者および開発者により改善がもたらされ、より良いソフトウェアへの発展を手助けする。オープンソースソフトウェアのアーキテクチャは利用者および開発者により決定され、その戦略的決定を利用者の意見や他の多くの要因に依存する。長期に渡って固定された具体的な仕様や開発計画に依らず、複数の要因による柔軟なアーキテクチャ決定を通して仕様や開発計画を決定する。オープンソースソフトウェアの利用者は各個により良いアーキテクチャを決定する権利を持ち、メインストリームのソフトウェアおよび派生したソフトウェアのアーキテクチャとしてそれを採用することができる。閲覧、そして修正の差し戻しを助けるためソースコードリポジトリにバージョン管理システムが用いられる。ソースコードの変更はユニークなID(連番の数字やハッシュ値)が割り当てられ、変更の記録を遡って特定して変更内容を確認することができる。ソースコードリポジトリはローカルファイルシステムに置くものや、インターネットを介したネットワーク上に置くものもある。良いオープンソースソフトウェアを提供することができる。ソースコードリポジトリをホスティングサービスとして提供するウェブサービスには、SourceForge、GitHub、Bitbucketなどがある。それらのウェブサービスは一般にソースコードが公開されるバージョン管理されたソースコードリポジトリを提供し、オープンソースソフトウェアの開発を支援している。それらのリポジトリはソースコードの閲覧、フォークは二次開発者が自由に行えるが、メインストリームのソースコードリポジトリに置かれたソースコード修正は主管開発者やその権限が与えられた開発者のみに許されており、不適切なソースコード修正がメインストリームのソースコードリポジトリに反映されて品質を損なうことを防いでいる。オープンソースソフトウェアの開発者間のコミュニケーションはメーリングリスト、IRC、インスタントメッセージ、バグトラッキングシステムなどのインターネットコミュニケーションが用いられる。これらのコミュニケーションツールはオープンソースソフトウェアのソースコードの実装についてだけではなく、オープンソースソフトウェアの開発に関わるプロジェクトの方針、設計の検討、テストの実施、不具合の報告などの多岐に渡った話題のためのコミュニケーションに利用される。Overflow、redditなどのコミュニティサイトが存在する。(ソフトウェア開発)」も参照オープンソースソフトウェアのリリースは複数の公式バージョンを配布している。一つは「安定版」で、機能が安定している、致命的なバグがない、実行環境への最適化がなされているなどの、利用者がそのソフトウェアを定常的に利用しても大きな問題が発生することが想定されていないバージョンである。一つは「検証版」で、試験的な機能が実装されている、バグが存在している、幾つかの環境でのみ動作するなどの、利用者がソフトウェアの開発および検証を目的として用いるバージョンである。安定版は検証版より長い間隔でリリースされることもあり、幾つかの検証版のリリースを経て安定板がリリースされることがある。Candidate、リリース候補)版などの名称を持つ。オープンソースソフトウェアの特性上、安定版ですべての機能が完成して開発が終了するものを示すものではなく、安定版もまた継続してリリースされる。オープンソースソフトウェアのリリースサイクルは短い間隔でリリースされる。ソフトウェアのソースコードが公開されていることにより、利用者はスナップショットのソースコードでソフトウェアをビルドすることが可能で、そのソフトウェアを非公式リリースとして頒布することもできる。短い間隔でのリリースを実現するため、継続的インテグレーションツールを用いてナイトリー版のビルドをリリースするソフトウェアもある。プロジェクト[編集]「Category:オープンソースソフトウェア」も参照オープンソースソフトウェアのマスコットとロゴ多くのプロジェクト・ソフトウェアがオープンソースソフトウェアのソフトウェアを開発している。1980年代にプロプライエタリ・ソフトウェア、クローズドソースに移行したオペレーティングシステム・プログラミング言語コンパイラも2000年代移行にオープンソースソフトウェアとして開発・普及している。GNUプロジェクトはフリーソフトウェアのGNUユーティリティとしてLinux・Windows・macOS・その他OSで動作するユーティリティソフトウェアを開発している。リーナス・トーバルズが1980年代から開発しているLinuxはオープンソースソフトウェアのオペレーティングシステムとして広く使われている。Linuxは様々なベンダー・ユーザーにより派生したソフトウェアが開発されLinuxディストリビューションの総称で呼ばれている。Foundationが開発主体となった。Serverを代表にC/C++のソフトウェア・ライブラリ、Javaのソフトウェア・ライブラリを開発している。Cordovaなど、企業が開発していたソフトウェアの後継メンテナンスも行っている。カノニカルは2004年にユーザビリティの高いLinuxディストリビューションとなることを目標としてDebianから派生してUbuntuを開発した[66]。OSを開発した[67]。Googleは2012年3月にマルチコアのマシンでプログラマが意識することなくマルチスレッドを最適化して実行するGo言語を発表した[68]。言語仕様特徴として謳うシステムプログラミング向けのRust言語を発表した[69]。Appleは2014年6月にiOS、macOS用プログラミング言語のObjective-Cの文法をモダンにリフォーマットしたSwiftを発表した[70][71]。多くのソフトウェアベンダー・ハードウェアベンダー・ソフトウェアライセンサーはオープンソースソフトウェアのフレームワーク・モジュール・ライブラリを彼らの製品に利用している[72][73]。認めるという特性から収益を得るビジネスモデルを成立させることが難しく、様々な手法でのビジネスモデルの確立が試行されている[74]。オープンソースソフトウェアをビジネスで利用するメリットは、開発者にとってはソフトウェアのソースコードを公開し、利用者を増やすことで市場シェアを伸ばすことができる。利用者にとっては無償で利用できる、目的に併せて改変できる、コミュニティによって新しいバグが即座に修正されるという利点がある。ビジネスモデルの例として、デュアルライセンスやサポートサービスは、ソフトウェアのライセンスに複数の選択肢を与え、基本機能のソフトウェアや過去のバージョンのソフトウェアのソースコードはオープンソースライセンスで開示し、より良い機能(英語版)のソフトウェアやテクニカルサポートを有償で提供する[75][76]。アドバンテージなどにより資金援助元へ還元する[77][78]。有償コンテンツ・拡張機能の販売は、ソフトウェア本体は無償のオープンソースソフトウェアとして利用者にリリースし、ソフトウェアを利用するためのコンテンツやより便利にするための拡張機能を有償販売する[79][80]。ドネーションウェア・アドウェアは、ソフトウェアは完全に無償で全ての機能を利用可能とした上で、寄付や広告による収益を得る[81][82]。978-1565927247)は、エリック・レイモンドによるオープンソースソフトウェア開発のエッセイである[83]。同著書ではGNUプロジェクトのトップダウン開発手法をカテドラル方式、Linux・Fetchmailのボトムアップ開発手法をバザール方式と評して、バザール方式のソースコードを公開・共有したソフトウェア開発の有効性について述べている。エッセイの主題はバザール方式におけるエリック・レイモンドが提起したリーナスの法則「十分な目玉があれば、全てのバグは洗い出される」という点で、オープンソースソフトウェアでは利用者を共同開発者と捉えて、利用者と共にソフトウェア開発を進めることでより良いソフトウェアを開発することができると述べている。0-596-00802-3)は、オープンソースソフトウェア分野の著名人のエッセイをまとめた書籍である[84][85]。マーシャル・カーク・マキュージック、マイケル・ティーマン、リーナス・トーバルズ、ポール・ヴィクシー、ラリー・ウォール、イアン・マードック、ラリー・サンガー、ティム・オライリーなどが寄稿している。OS(2001年)は、1970年代末から約20年間のGNUプロジェクト・Linux・フリーソフトウェア・オープンソースの歴史をまとめたドキュメンタリー映画である[86]。オープンソースソフトウェア分野の著名人のリチャード・ストールマン、リーナス・トーバルズ、エリック・レイモンド、ブルース・ペレンズが特別出演している。Movement)は、フリーソフトウェア財団を主体にしたフリーソフトウェアの利用者の自由を尊重する思想を啓蒙する社会運動である[87]。Design・BadVista・TiVo化批判・フリーソフトウェアの歌など、理念的なものから他者批判的なもの、ユーモラス的なものまで多種多様である。Software)」もしくは「フリーソフトウェアとオープンソースソフトウェア」と明確に別けて呼称する。他のソフトウェアモデルとの比較[編集]フリーソフトウェア[編集]フリーソフトウェアが推奨するコピーレフトのシンボルフリーソフトウェアは、広義のオープンソースソフトウェアの定義においてオープンソースソフトウェアの部分集合であるが、オープンソースソフトウェアとフリーソフトウェアは根源的なコンセプトが異なる。コピーを変更ありまたはなしで再配布するという自由)を尊重する「社会運動」である[15][88]。コンセプトが開発の方法論と社会運動と異なるため、本来は並列に比較するようなものではない。その上で、フリーソフトウェアという社会運動のための一つのツールとしてオープンソースソフトウェアという開発の方法論を用いようとした場合、オープンソースソフトウェアは利用者の自由を尊重するのに機能不十分なツールである。この機能不十分な点を比較した場合、オープンソースソフトウェアが許容する幾つかのライセンスは不適切であり、フリーソフトウェアはコピーレフトに代表されるような利用者の自由を尊重するための条項が含まれたライセンスを推奨している[6]。License(英語版)は利用者が修正したソースコードから作られたソフトウェアを個人的な用途で公開した場合にはソースコードの公開を必要としていない。これは修正されたソフトウェアは一般に公開されているにも関わらず、そのソフトウェアのソースコードは非公開となっており、二次利用者の自由を妨げている[89]。一つの例としては、オープンソースソフトウェアは利用者がソフトウェアもしくはそのソフトウェアが動作するハードウェアをTiVo化(tivoization)することを許容するライセンスの存在を許し、二次利用者の自由を妨げることを否定していない[90][91]。シェアードソース・ソフトウェア[編集]シェアードソース・ソフトウェアは、ソースコードを開示し、利用者にソースコードおよびソフトウェアの動作の参照およびデバッグのための利用を認めている[92]。)に開示する用途で利用されている。オープンソースソフトウェアとシェアードソース・ソフトウェアの違いは、シェアードソース・ソフトウェアはソースコードの修正、再頒布に対して制約的である所である。利用者に対してソースコードの参照、デバッグを目的とした利用は認めているが、修正したソースコードそのものや、修正したソースコードから生成されるソフトウェアの頒布は私的使用に限って認めるなどの制約を伴う場合がある。シェアードソース・ソフトウェアでは商用目的でソースコードを利用(閲覧)することが出来ない場合がある。それらの制約はシェアードソース・ソフトウェアに課せられるライセンスの内容に依る。マイクロソフトは2001年より自社ソフトウェア製品のためにシェアードソース・イニシアティブを立ち上げている[93]。マイクロソフトのシェアードソースライセンスは幾つかの種類があり、制約の緩やかなライセンスはオープンソース・イニシアティブ公認のオープンソースライセンスであるが[94]、制約の厳しいライセンスは同社との提携契約の上でソースコードの参照のみが許されるプロプライエタリ・ライセンスである。Licenseを設けていた[95][96]。制限を設ける・設けない点が主な違いである[4]。プロプライエタリ・ソフトウェアのソースコードの公開・利用の可否に明確な線引きはないが、ソースコードを開示していてもソースコードの入手が有償である、ソースコードが非公開(クローズドソース)であるなど、基本的にソフトウェアの利用者がソースコードを自由に利用することは出来ない。認め、商用目的での利用・修正・頒布を認めない場合もオープンソースソフトウェアではなくプロプライエタリ・ソフトウェアと呼ばれる[4]。個人や組織がオープンソースソフトウェアを選ぶ主要な4つの理由に安価・情報セキュリティ・ベンダーロックインでない・より良い品質がある[97]。ソフトウェア開発企業は必ずしもソフトウェアの販売に依存しないため、相対的にプロプライエタリ・ソフトウェアの必要性は低くなってきている[98]。Novellのような企業は、製品の一部をオープンソースソフトウェアに切り替えているため、継続的にオープンソースソフトウェア上でのビジネスモデルを思案している[99]。批評と論争[編集]ソフトウェアの品質[編集]多くの主張者が、多くの人間がソースコードを閲覧・編集・変更するため、オープンソースソフトウェアはソースコードが非公開のプロプライエタリ・ソフトウェアに比べて本質的により安全であると主張している[100]。オープンソースソフトウェアであるLinuxのソースコードは1000行あたり0.17個のバグがある一方で、プロプライエタリ・ソフトウェアのソースコードは一般的に1000行あたり20–30個のバグがある[101]。Reportにおいて、オープンソースソフトウェアの品質がプロプライエタリ・ソフトウェアの品質を越えたというレポートを発表した[102]。この評価は750百万行からなるソースコード、700以上のC/C++エンタープライズプロジェクトとJavaプロジェクトを対象に実施された。レポートの要点として4つ、C/C++プロジェクトではオープンソースソフトウェアがプロプライエタリ・ソフトウェアの品質を越えている、Linuxがオープンソースの品質向上に貢献している、C/C++開発者は重大なバグをより多く改修する傾向にある、JavaプロジェクトではHBaseが品質向上に貢献している、を挙げている。フリーソフトウェア支持者の批判[編集]フリーソフトウェア支持者はフリーソフトウェアの理念を社会に浸透させる社会運動において、オープンソースソフトウェアは不適切な概念であると考えている。フリーソフトウェア財団の代表リチャード・ストールマンはオープンソースの概念はフリーソフトウェアが主観にしている利用者の重要な自由を守るに足りえないとして、オープンソースソフトウェアはフリーソフトウェアの的を外していると批判している[15]。同様の観点でオープンソース・イニシアティブの創設者の一人ブルース・ペレンスは、オープンソース・イニシアティブの設立の1年後に、オープンソースがフリーソフトウェアから離れすぎていることを挙げて「今こそフリーソフトウェアについて再び語るべきときだ」と述べて、オープンソース・イニシアティブから離脱した[103]。GNU/Linux名称論争[編集]詳細は「GNU/Linux名称論争」を参照GNUプロジェクトのリチャード・ストールマンはGNUツールを用いてオペレーティングシステムとして成り立っているLinuxは「GNU/Linux」と呼称するべきであると主張しており[15]、GNU/Linux名称支持者とLinux名称支持者の間でLinuxに対する名称論争が存在している。GNU/Linux名称支持者は、オペレーティングシステム全体においてLinuxカーネルは機能の一部でありGNUプロジェクトのソフトウェア群によって完成していることを挙げて併記を求め[104]、また呼称への拘りがフリーソフトウェアコミュニティの理想主義への啓蒙を兼ねていることを説明している[105]。GNU/Linuxと名乗っている。Linux名称支持者は、Linuxが既に十分に一般的な通称となっており名称を変更する必要性を感じていない[107]。明示的な理由を挙げているエリック・レイモンドは、ジャーゴンファイルのLinuxの節でGNU/Linux名称は縄張り争いと承認欲が根元にあり、リチャード・ストールマンとその近しい友人以外には受け入れるのは難しいと述べている[108]。OSのインタビューの中で、GNU/Linuxの名称はGNUプロジェクトがGNUディストリビューションを開発したならば適切であるとした上で、Linuxの総称としては不適切であるとコメントしている。ハロウィーン文書[編集]詳細は「ハロウィーン文書」を参照エリック・レイモンドはマイクロソフトのオープンソースソフトウェア・Linuxへの潜在的戦略に関する機密文書を入手し、1998年11月3日にハロウィーン文書としてリークした[109]。マイクロソフトは1998年11月5日にリークされたハロウィーン文書に対して公式コメントとして、同文書の内容は内部的な検討資料として日常的な適切なものであるが、Linuxに対する公式の立場のものではないと発表した[110][111]。ハロウィーン文書でマイクロソフトは、オープンソースソフトウェアが公開された標準規格、プロプライエタリ・ソフトウェアに比べて低いTCOにより幅広く支持を受けていると述べ[112]、その上で、オープンソースソフトウェアに対抗する戦略としてFUD戦略・3E戦略を挙げている[113][114]。実際にマイクロソフトはFUD戦略として、オープンソースソフトウェアをロビン・フッドに例えて不安定性を訴える[115]、「Linuxを学ぶほどにコンシューマーにとっての価値の少なさを感じている」と紹介する[116]、第三者評価機関を援助してLinuxの否定的評価結果を挙げる[117]、などの活動を行った。オープンソースの低いTCOに対しては、シェアードソースで同等のTCOを模索し、一定の評価を得ていると自己評価を出している[112]。SCO-Linux論争[編集]詳細は「SCO・Linux論争」を参照SCOグループは2003年に自らがUnixの知的財産権保持者であり、更にLinuxにUnixのソースコードが盗用されていると主張した。SCOグループは、UNIXの知的財産権を保持している、LinuxがUnixのソースコードを利用している、の2点を根拠にLinux関係者に対して権利行使に基づくライセンスビジネスを発表したが[118]、Linux関係者は不適当な権利行使であるとして受け入れなかった。この主張の相違がSCOグループとLinux関係者の論争の起点となり、ここからSCO・Linux論争が始まった。SCOグループがUNIXの知的財産権を保持しているという主張は2007年8月10日に退けられ、NovellがUnixの権利を保持していると判決が出された[119][120]。NovellはLinuxにUnixのソースコードが含まれているとは考えていないと声明を出し、LinuxがUnixの知的財産権を侵害しているという疑惑は払拭されている。Software)は、フリーソフトウェアとオープンソースの複合語である[121]。これは、フリーソフトウェア財団とオープンソース・イニシアティブが根源的な部分で活動理念を異にしており、フリーソフトウェア財団の定義するフリーソフトウェアとオープンソース・イニシアティブの定義するオープンソースは別物で区別しなければならないというリチャード・ストールマンの考えに基づいている[15]。認めるという表面的な同一視をした場合に、それらの用語を同列かつ個別のものと見なし、その上でそれらをまとめて言い表すために、複合語としてFLOSSという用語が使われる。認める場合は、「オープンソース」を冠したオープンソースハードウェア、オープンソースジャーナリズム(英語版)、オープンソースガバナンス(英語版)、オープンソースエコロジー(英語版)のような用語が存在する。ソースコードは存在しないがその事柄の利用、修正、頒布を認める場合は、「オープン」を冠したオープンアクセス、オープンシステム、オープンコンテントのような用語が存在する。認めているかどうかは各用語によって異なるため、それらの用語の意味するところについてはそれぞれ注意して扱うべきである。2018年2月9日閲覧。2015年12月2日閲覧。2018年2月20日閲覧。2018年2月9日閲覧。2018年2月8日閲覧。2018年2月9日閲覧。2018年3月10日閲覧。2016年4月11日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年3月1日閲覧。2018年3月25日閲覧。2018年3月1日閲覧。2018年2月15日閲覧。2008年1月4日閲覧。2008年9月8日閲覧。2018年3月26日閲覧。2016年4月14日閲覧。2016年4月14日閲覧。2007年11月5日閲覧。2007年11月5日閲覧。2007年11月5日閲覧。2018年3月26日閲覧。2013年12月1日閲覧。2018年3月2日閲覧。2018年3月26日閲覧。2018年3月26日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年3月8日閲覧。2018年3月8日閲覧。2011年8月29日閲覧。2018年2月8日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年2月15日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2011年5月10日閲覧。2018年2月8日閲覧。2005年2月14日時点のオリジナルよりアーカイブ。2018年3月25日閲覧。2011年4月1日閲覧。2005年6月21日時点のオリジナル[リンク切れ]よりアーカイブ。2011年2月7日閲覧。2017年8月13日閲覧。2018年2月25日閲覧。2018年2月9日閲覧。2018年2月9日閲覧。2018年3月15日閲覧。2012年7月11日閲覧。2012年2月6日閲覧。2014年9月10日閲覧。2016年6月18日閲覧。2016年6月18日閲覧。2016年6月18日閲覧。2013年8月10日閲覧。2013年8月10日閲覧。2009年2月20日時点のオリジナルよりアーカイブ。2011年3月9日閲覧。2017年10月16日閲覧。2015年6月3日時点のオリジナルよりアーカイブ。2018年2月15日閲覧。2012年4月18日閲覧。2010年8月7日閲覧。2017年9月8日時点のオリジナルよりアーカイブ。2017年10月3日閲覧。2018年4月5日閲覧。2018年4月4日閲覧。2018年2月9日閲覧。2015年12月23日閲覧。2018年2月15日閲覧。2018年2月15日閲覧。2018年2月15日閲覧。2018年2月15日閲覧。2018年2月15日閲覧。2007年1月2日時点のオリジナルよりアーカイブ。2018年2月14日閲覧。2018年2月14日閲覧。2018年2月15日閲覧。2018年2月15日閲覧。2012年11月4日時点のオリジナルよりアーカイブ。2012年3月25日閲覧。2012年3月25日閲覧。2018年2月15日閲覧。2018年4月5日閲覧。2018年3月1日閲覧。2008年12月13日閲覧。2008年12月13日閲覧。2008年1月31日閲覧。2008年10月26日閲覧。2018年2月9日閲覧。2018年4月4日閲覧。2018年4月4日閲覧。2012年6月2日閲覧。2018年4月4日閲覧。2018年4月4日閲覧。2018年4月4日閲覧。1999年4月7日時点のオリジナルよりアーカイブ。2018年4月2日閲覧。1999年5月8日時点のオリジナルよりアーカイブ。2018年4月2日閲覧。2018年4月4日閲覧。2010年1月2日時点のオリジナルよりアーカイブ。2018年4月8日閲覧。2007年9月4日閲覧。2007年8月15日閲覧。2018年2月9日閲覧。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。