コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「オープンソースソフトウェア」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
やなぎ0 (会話 | 投稿記録)
3,165 回編集
カテゴリの追加
Cewbot (会話 | 投稿記録)
ボット
783,048 回編集
m cewbot: ウィキ文法修正 1: Template contains useless word template
392行目: 392行目:
* [http://www.oreilly.com/catalog/opensources/book/toc.html Open Sources: Voices from the Open Source Revolution] - オープンソース共同体の著名なメンバーのエッセイ
* [http://www.oreilly.com/catalog/opensources/book/toc.html Open Sources: Voices from the Open Source Revolution] - オープンソース共同体の著名なメンバーのエッセイ


{{Template:FOSS}}
{{FOSS}}


{{DEFAULTSORT:おおふんそうすそふとうえあ}}
{{DEFAULTSORT:おおふんそうすそふとうえあ}}

2018年3月11日 (日) 01:10時点における版

オープンソースソフトウェア（英: Open Source Software、略称: OSS）とは、ソフトウェアのソースコードが一般に公開され、利用者の目的を問わずソースコードの利用、修正、再頒布が可能なソフトウェアの総称である[1]。

一般に使われている基準として、オープンソース・イニシアティブの提唱する「オープンソース」、および、フリーソフトウェア財団の提唱する「フリーソフトウェア」のカテゴリに含まれるソフトウェアが「オープンソースソフトウェア」である[1][2]。ソフトウェアのソースコードが公開されていても、その利用、修正、再頒布に費用がかかる、商用利用は禁止されるなどの制限がある場合は、オープンソースソフトウェアではなくプロプライエタリ・ソフトウェアやシェアードソース・ソフトウェアと呼ばれる。オープンソースソフトウェアに課すソフトウェアライセンスは管理団体やコミュニティによってある程度精査されており、GNU GPL、Apache-2.0、MITなどの、既存の汎用的なライセンスを利用することが推奨されている[3][4]。

ソフトウェアのソースコードを利用者が共有し、修正、再頒布する文化は、1950年代のコンピュータ上でソフトウェアが稼働するようになった頃から学術機関、研究機関の間で存在していた。1970年代以降、ソフトウェア開発は徐々に商業となり、ソフトウェアの再頒布を禁止するソフトウェアライセンス、ソースコードを非公開とするクローズドソースの文化ができあがった。1980年代以降、利用者がソフトウェアのソースコードを自由に利用できないことをストレスに感じた人たちはフリーソフトウェア財団やオープンソース・イニシアティブを立ち上げ、ソースコードを一般に公開してソフトウェアの利用者による利用、修正、再頒布を許すことによるソフトウェア開発の発展を提唱した。

類似した概念にオープンソースハードウェア、オープンシステム、オープンコンテントなどがある。

定義

オープンソースソフトウェア（OSS）の定義は、ソフトウェアのソースコードが一般に公開され、商用および非商用の目的を問わずソースコードの利用、修正、再頒布が可能なソフトウェアの総称である[5]。オープンソース・イニシアティブの承認したオープンソースライセンスが課せられたソフトウェアや、パブリックドメインに置かれたソースコードとそのソフトウェアなどがそれに当たる。

アメリカ国防総省による定義

アメリカ国防総省（DoD）はオープンソースソフトウェアの定義を「可読性のあるコードが利用、学習、再利用、修正、改善、再頒布が可能であるソフトウェア」としている[1]。

ソフトウェアに課せられたライセンスが本当にオープンソースソフトウェアであることを認めるソフトウェアライセンスであるかについて慎重な法的レビューをするべきであるとし、ライセンスのレビューを実施する団体としてオープンソース・イニシアティブ[6]、GNUプロジェクト[7]、Fedora[8]、Debian[9]を挙げている[10]。それらの団体は個々にライセンスのレビューを実施しており、オープンソースソフトウェアに適したライセンスの一覧を公開している。特に前者２つの団体によるライセンスのレビューは重要であり、少なくともその２つのレビューを通ったライセンスがオープンソースソフトウェアに課すライセンスとして望ましいとしている。

商用を目的として利用されるソフトウェアはオープンソースソフトウェアとは区分せず、プロプライエタリ・ソフトウェアやクローズドソース・ソフトウェアに区分している[11]。

オープンソース・イニシアティブによる定義

→「オープンソースの定義」も参照

オープンソース・イニシアティブ（OSI）は「オープンソースの定義」に従ったソフトウェアをオープンソースのソフトウェアと定義している[12]。オープンソースの定義は単純にソースコードへのアクセスが開かれていることを定義するものではなく、オープンソースのソフトウェアは利用者がそのソースコードを商用、非商用の目的を問わず利用、修正、頒布することを許し、それを利用する個人や団体の努力や利益を遮ることがないことを定義している[13]。

オープンソース・イニシアティブはオープンソースライセンスというライセンスカテゴリを管理しており、そのオープンソースの定義に準拠したライセンスのみをオープンソースライセンスとして承認している。オープンソースソフトウェアはオープンソースライセンスが課せられたソフトウェアであると言い換えることが出来る。オープンソースライセンスはライセンスの氾濫を防ぐために虚栄心による独自ライセンスや複製ライセンスを承認していないため、オープンソースの定義に準拠しているがオープンソースライセンスと承認されていないライセンス、およびそのライセンスが課せられたオープンソースソフトウェアは存在している。基準はオープンソースの定義であり、その定義に準拠したソフトウェアはオープンソースソフトウェアである。

2007年、オープンソース・イニシアティブは、SugarCRMが自社のことを「Commercial Open Source」と表現し、オープンソースライセンスとして承認されていないライセンスをソフトウェアに課していたことを非難した[14][15]。後に、SugarCRMはライセンスをオープンソースライセンスとして承認されているGPLv3に切り替えている[16]。

日本の総務省はオープンソース・イニシアティブのオープンソースの定義を満たすソフトウェアをオープンソースソフトウェアを定義するものとして参照している[17]。

フリーソフトウェア財団による定義

→「フリーソフトウェアの定義」も参照

フリーソフトウェア財団（FSF）は「オープンソースソフトウェア」という単語についての定義は行なっていないが、類似した概念として「フリーソフトウェア」（フリーは無料ではなく自由という意味）という単語を定義している[18]。フリーソフトウェアは利用者の自由とコミュニティに敬意を払い、利用者にソフトウェアを実行、複製、頒布、学習、改善する自由を提供する。その自由を提供するために、フリーソフトウェアのソースコードは一般に公開され、利用者はソフトウェアのソースコードを自由に利用、修正、再頒布することが可能である。

フリーソフトウェア財団の代表であるリチャード・ストールマンはオープンソース・イニシアティブの定義する「オープンソース」という単語およびその活動を否定的に発言しており[19]、同財団では「オープンソースソフトウェア」という単語の定義および意義については消極的である。

オープンソースソフトウェアのライセンス

法的拘束力

オープンソースソフトウェアに課せられたライセンスは、ライセンサーとライセンシーの間の契約だけではなく、著作権法の下に法的拘束力を持ち、ライセンスを違反することは著作権法を違反することと同義である。

オープンソースソフトウェアおよびフリーソフトウェアのソフトウェアライセンスは重要な法的マイルストーンを2008年に通過した。アメリカ合衆国連邦裁判所がフリーソフトウェアライセンスは著作権のある成果物の使用において明確に法的拘束力の条件を設定すると判決を出し[20]、それゆえに著作権法の下で強制力を持つことが明示された。オープンソースソフトウェアのソフトウェアライセンスの法的拘束力の有無はそれ以前には明確には判断されておらず、この訴訟でも下級裁判所の判決はArtistic Licenseは法的拘束力を持たず、ライセンス条項を無視することは著作権侵害ではないと判決を出していた。

ライセンスのカテゴリ

OSI オープンソースライセンス

OSI公認ラインセンスのロゴ
→詳細は「オープンソースライセンス」を参照

オープンソースライセンスはオープンソース・イニシアティブ（OSI）が承認したオープンソースのソフトウェアに課するソフトウェアライセンスの総称である。

オープンソース・イニシアティブは「オープンソースの定義」に基づいてオープンソースライセンスを承認している[21]。このライセンスはソフトウェアのソースコードの利用者（個人および団体）の目的（商用および非商用）を問わず利用、修正、再頒布を認める。オープンソースライセンスとして主要なソフトウェアライセンスの一覧を公開しており[22]、ソフトウェアがオープンソースを冠する場合はこの承認されたオープンソースライセンスを課すことを推奨している[3]。また、ライセンスの氾濫を抑制するためにオープンソースのソフトウェアに課すソフトウェアライセンスとして既存のライセンスの利用を推奨している[23]。

FSF フリーソフトウェアライセンス

→詳細は「フリーソフトウェアライセンス」を参照
フリーソフトウェアライセンスの選択例[24]

フリーソフトウェアライセンスはフリーソフトウェア財団（FSF）が承認したフリーソフトウェアに課するソフトウェアライセンスの総称である。

フリーソフトウェア財団は「フリーソフトウェアの定義」に基づいてフリーソフトウェアライセンスを承認している。フリーソフトウェアライセンスはソフトウェアとそのソースコードの利用者による実行、複製、頒布、学習、改善する自由を尊重している。フリーソフトウェア財団はフリーソフトウェアの利用者の自由を提供、拡散するため、ソフトウェアに課すべきフリーソフトウェアライセンスの一覧を保守している[25]。この一覧では、フリーソフトウェアライセンスに適合しているか、コピーレフト条項を含むか、GNU GPLと互換性があるか、および特記事項を記述している。

フリーソフトウェア財団はフリーソフトウェアのソフトウェアライセンス選択時の推奨ガイドラインを出している[4]。ソフトウェアライセンスはそれに応じた異なるライセンスを選択するべきとしている。例えば、一般的なソフトウェアではコピーレフト特性をもつGNU General Public License、小さなプログラムではコピーレフト特性を持たないApache License、ライブラリではGNU Lesser General Public License、サーバソフトウェアではGNU Affero General Public Licenseを採用することを推奨している。

Fedora Licensing List

Fedoraは同プロジェクトのソフトウェアに課せられるべきソフトウェアライセンスの一覧を管理している[8]。

Fedoraの公式パッケージに含まれるソフトウェアはこの一覧にあるソフトウェアライセンスが課せられたものであり、これらのライセンスはフリーソフトウェア財団、オープンソース・イニシアティブおよびRed Hat法務担当が公認したものである[2]。公認ライセンスはFedoraのメーリングリストで公に検証されており、過去に議論されたライセンスの適正判断や、新規に一覧に追加を求めるライセンスの検証要望などを受け付けている[26]。ただし、コンフィデンシャルな情報を送ることや、ソースコードについての法的な助言を求めるために利用してはならないし、メーリングリストの参加者が法律家や弁護士であることを仮定するべきではない。

DFSG準拠ライセンス

→「Debianフリーソフトウェアガイドライン」も参照

DebianはDebianフリーソフトウェアガイドライン（DFSG）に準拠したソフトウェアライセンスの一覧を管理している[9]。

Debianの公式パッケージに含まれるソフトウェアは原則としてDebianフリーソフトウェアガイドラインに準拠したソフトウェアライセンスが課せられたものであり、そのガイドラインはソフトウェアの利用者によるソースコードの利用、修正、再頒布が認められていることを求めている。Debianフリーソフトウェアガイドラインに準拠したソフトウェアライセンスの課せられたソフトウェアはオープンソースソフトウェアの定義に符号するものであり、DFSG準拠ライセンスはオープンソースソフトウェアに課すソフトウェアライセンスの一例として参考にできる。

パブリックドメイン

パブリックドメインを表すロゴ
→詳細は「パブリックドメイン」を参照

パブリックドメインにソフトウェアのソースコードを置くことは、その成果物の製作者の著作権を放棄する手段の一つである。パブリックドメイン以下に公開されたソースコードは全ての権利が放棄されていると見なし、利用者はそのソースコードおよびソフトウェアの利用、修正、再頒布が可能である。パブリックドメインと同等の手段として、ソフトウェアのソースコードに課すツール、ライセンスとしてのCC0、WTFPLなどが存在する。

パブリックドメインにソースコードが置かれている場合はソースコードおよびソースコードから生成されるソフトウェアの利用、修正、再頒布は可能であるが、パブリックドメインにソフトウェアのみが置かれている場合はその限りではない。この場合、ソフトウェアの著作権の放棄は想定されるが、そのソフトウェアのソースコードの著作権の放棄は想定できず、ソースコードを利用、修正、再頒布する権利は別途考えなければならない。

デュアルライセンス

→詳細は「デュアルライセンス」を参照

オープンソースソフトウェアには複数のソフトウェアライセンスを課すものがあり、そのようなライセンス形態をデュアルライセンス（マルチライセンス）と呼ぶ。デュアルライセンスが課せられたソフトウェアを利用する場合、利用者は課せられたソフトウェアライセンスのいずれかを一つだけ選択して、選択したライセンスの課せられたソフトウェアとして扱う。オープンソースソフトウェアにデュアルライセンスを課す主な用途は二種類あり、一つはソフトウェアを用いたビジネスモデル、一つはライセンスの互換性である。

ビジネスモデル用途

オープンソースソフトウェアのソフトウェアライセンスには広告条項の有無が異なるライセンスがあり、一つのソフトウェアにそれらのライセンスを併用してビジネス上のメリットを教授するためにデュアルライセンスを利用する。

広告条項の有無の異なるソフトウェアライセンスをデュアルライセンスとして課したソフトウェアで利用者が広告条項のあるライセンスを選択してソフトウェアを利用した場合、利用者は広告条項に基づきソフトウェアの名称やソフトウェアのソースコードの配布場所を二次利用者に伝える義務を伴う。ソフトウェアの開発者（開発元）にとっては利用者が善意の広告塔となり、ソフトウェアの名称や配布場所を多数の人に知ってもらう機会を得ることができる。なお、利用者が広告条項のないライセンスを選択してソフトウェアを利用することもできるため、必ずしも利用者が広告塔となりうるわけではない。一例としては、広告条項のあるApache Licenseと広告条項のないMIT Licenseのデュアルライセンスがある。

商業目的で利用する場合は有償とするソフトウェアライセンスを課し、非商業目的で利用する場合は無償とするソフトウェアライセンスを課すビジネスモデルを確立するデュアルライセンスのソフトウェアもある。そのようなソフトウェアはオープンソースソフトウェアではなくプロプライエタリ・ソフトウェアと呼ばれる[11]。

ライセンスの互換性用途

ソフトウェアライセンスにはライセンスの互換性の有無があり、互換性のないライセンスが課せられたソフトウェアは併用することが出来ない。そのようなライセンスの互換性の課題を回避するためにデュアルライセンスを利用する。

ソースコードの利用時に同一のソフトウェアライセンスを課すことを要求する条項があるライセンスが課せられたソフトウェアと併用する場合、その条項に基づき自身の開発したライセンスは同一のソフトウェアライセンスを課さなければならない。しかしながら、そのような条項がないライセンスが課せられたソフトウェアと併用する場合、自身の開発したソフトウェアライセンスは他のものを採用することができる。利用者がどのようなライセンスが課されたソフトウェアと併用するか、利用者が二次開発するソフトウェアにどのようなライセンスを課すか、などのソフトウェアライセンス採用選択の幅を広げる。一例としては、GNU GPLとMIT Licenseのデュアルライセンスがあり、GNU GPLの課せられたソフトウェアと併用する場合はGNU GPLを採用し、GNU GPLの課せられていないソフトウェアと併用する場合はMIT Licenseを採用する。

ライセンスの課題

ライセンスの氾濫

→詳細は「ライセンスの氾濫」を参照

利用者によるソースコードの利用、修正、再頒布を認めるソフトウェアライセンスは幾つも存在していたが、よく似た条文で一部分だけ異なるという有象無象のライセンスがいたずらに作られていったことを問題視し、その事象はライセンスの氾濫と呼ばれ批判の対象となった[27]。

初期のオープンソース・イニシアティブは「オープンソースの定義」に準拠するソフトウェアライセンスを適切な選別をすることなくオープンソースライセンスとして承認しており、その結果、有用無用な独自のソフトウェアライセンスが多く作られるライセンスの氾濫が起きた。ライセンスの氾濫はライセンス製作者の虚栄心を満たすだけの無害なものではなく、オープンソースソフトウェアに課せられたライセンスの内容を精査しなければならない利用者を疲弊させる有害なものであった。2006年にオープンソース・イニシアティブはこの問題を解決するため「ライセンス氾濫問題プロジェクト（License Proliferation Project）」を立ち上げ[28]、ライセンスレビューを通して承認ライセンスの選別を行うようになった[29]。

2018年2月現在、オープンソース・イニシアティブはライセンスレビュープロセスを通ったライセンスのみをオープンソースライセンスとして承認している[22]。同様に、フリーソフトウェア財団はフリーソフトウェアに課すのに適したライセンスの一覧を公開している[25]。

ライセンス感染

CC BY-SAとパブリックドメインを合わせた時にSA属性によりCC BY-SAが強制されるライセンス感染の例
→「コピーレフト」、「継承 (クリエイティブ・コモンズ)」、および「ライセンス感染」も参照

ライセンスの継承条文を伴うソフトウェアライセンスが課せられたソフトウェアは、その継承条項に基づき、ソフトウェアのソースコードを利用、修正したソフトウェアのソフトウェアライセンスを同一のものとするよう縛る。このライセンスの縛りはソースコードの二次利用、三次利用と伝播し、ライセンスがウイルスのように感染していくことからライセンス感染（ウイルス性ライセンス）と呼ばれる[30]。

ライセンス感染するライセンスの例としては、GNU GPL (コピーレフト条文)やCC BY-SA (SA属性)がある。ライセンス感染の影響は元となったソフトウェアライセンスの内容に依るが、GNU GPLのコピーレフト条項のようにソースコードの公開を義務とするものや、CC BY-SAのSA属性ように同一のライセンスを課すだけ（ソースコードの公開を求めるかどうかは別条文に依る）のものがある。

強いコピーレフト特性を持つGNU GPLは利用したソースコードから生成されるソフトウェア（ライブラリ）だけではなく、そのソフトウェアを内包するパッケージに含まれる動的リンク、静的リンクを問わず他の全てのモジュール（ライブラリ）にも同様のライセンスを課し、その全てのソースコードを利用、修正、再頒布する自由を提供する義務を負う。弱いコピーレフト特性を持つGNU LGPLは利用したソースコードおよびソースコードに静的リンクしたソフトウェアのソースコードには同様のライセンスを課すが、利用したソースコードから生成されるソフトウェア（ライブラリ）に動的リンクしたソフトウェアのソースコードには同様のライセンスは課さない。

ライセンス感染は二次利用ソースコードのライセンスを同一のものに強制することでライセンスの氾濫を防ぐ一方で、二次利用ソースコードおよびそのソフトウェアのライセンスを選択する権利を失い、課せられるライセンスの内容に依っては広範囲にソースコードを公開しなければならなくなる恐れがある。ソースコードを開示しないことによるセキュリティ強化、デジタル著作権管理（DRM）のための暗号化アルゴリズム、実装の困難さによる一般化されていない表現を提供するソフトウェア特許などの分野ではライセンス感染するライセンスが課されたソースコードを扱うことは検討課題となる。

著作権の放棄の有効性

→「パブリックドメイン § 著作権法に特有の問題」も参照

パブリックドメインによる著作権の放棄は著作権法の下に完全に認められたという実績（判決）は存在しておらず、法的な判断が不明瞭である[31]。

ソースコード作成者が著作権を放棄する意図でパブリックドメイン以下で公開していたソースコードに対して、ソースコード作成者が考えを変えて著作権の保持を主張してソースコードの二次利用者を訴えた場合に、サブマリン特許のように見解を翻して権利を行使することの是非という道徳的な観点は別として、著作権の放棄の有効性について著作権法の下にどのような判断がなされるのか明確になっていない。つまり、パブリックドメインはソースコード作成者の当初の意図に反して著作権の放棄はできておらず、著作権の保持を根拠にしたソースコードの二次利用者に対する訴えは有効であるとされる可能性がある。

そのような不確定性のため、オープンソース・イニシアティブはパブリックドメインに相当するCC0を有効なオープンソースライセンスとして承認していない[32]。一方で、フリーソフトウェア財団はCC0を有効なフリーソフトウェアライセンスとして承認している[33]。パブリックドメインおよびそれに類するライセンスの著作権の放棄の有効性の疑義は著作権の放棄を条文に加えている一部のライセンスのみの課題であり、著作権の放棄について言及していないラインセンスでは著作権は放棄されていないものとして見なして疑義の課題とはならない。

主要なライセンス

2018年2月現在、広く使われている、もしくは、著名なコミュニティが採用しているオープンソースソフトウェアのソフトウェアライセンスの一覧を以下に示す[22]。

主要なオープンソースソフトウェアのライセンス
ライセンス名 略称 OSI承認 FSF承認 GPL互換性 コピーレフト
Apache License 2.0 Apache-2.0 Yes[22] Yes[34] Yes[34] No[34]
修正BSDライセンス（三条項BSDライセンス） BSD-3-Clause Yes[22] Yes[35] Yes[35] No[35]
二条項BSDライセンス BSD-2-Clause Yes[22] Yes[36] Yes[36] No[36]
GNU General Public License, version 3 GPLv3 Yes[22] Yes[37] — Yes[37]
GNU Lesser General Public License, version 3 LGPLv3 Yes[22] Yes[38] Yes[38] Yes（weak）[38]
MIT License（X11 License） MIT Yes[22] Yes[39] Yes[39] No[39]
Mozilla Public License 2.0 MPL-2.0 Yes[22] Yes[40] Yes[40] Yes（weak）[41]
Common Development and Distribution License version 1.0 CDDL-1.0 Yes[22] Yes[42] No[42] Yes（weak）[43]
Eclipse Public License 2.0 EPL-2.0 Yes[22] Yes[44] No[44] Yes（weak）[44]
Creative Commons Attribution 4.0 license CC BY No Yes[45] Yes[45] No[45]
Creative Commons Attribution-Sharealike 4.0 license CC BY-SA No Yes[46] No[46] Yes[46]
Creative Commons Zero CC0 No[32] Yes[33] Yes[33] No[33]

オープンソースソフトウェア開発

開発モデル

利用者と共同開発者

オープンソースソフトウェアの利用者は共同開発者のように扱われる。利用者はソフトウェアのソースコードにアクセスすることができ、ソフトウェアへの機能追加、ソースコードの修正、バグの報告、ドキュメントの提出が可能である。利用者はそれらをソフトウェア開発のメインストリームに反映することができるし、利用者が望むのであれば自身の製品として頒布することもできる。オープンソースソフトウェアで複数の共同開発者を持つことは、ソフトウェアの発展を手助けする。リーナスの法則では、「十分な目玉を与えられることで、全てのバグは浅くなる」と述べている[47]。このことは、多くの利用者がソースコードを眺めれば、結局は全てのバグを発見しそれらの修正方法が提案される、ということを意味している。

細分化されたモジュール

オープンソースソフトウェアの機能は幾つもの細分化されたモジュールで構成されている。例えばコンパイラでは、字句解析、構文解析、意味解析、最適化、コード生成などの機能を持ち、それらはモジュールとして一つのソフトウェアに内包される。LAMPのようなSaaSでは、Linux、Apache、MySQL、PHPなどの複数のオープンソースソフトウェアの組み合わせで、一つのサービスを提供している。細分化されたモジュールはそれぞれの機能を得意とする利用者および開発者により改善がもたらされ、より良いソフトウェアへの発展を手助けする。

リリースサイクル

→「en:Continuous delivery」も参照

オープンソースソフトウェアのリリースサイクルは短い間隔でリリースされる。ソフトウェアのソースコードが公開されていることにより、利用者はスナップショットのソースコードでソフトウェアをビルドすることが可能で、そのソフトウェアを非公式リリースとして頒布することもできる。短い間隔でのリリースを実現するため、継続的インテグレーションツールを用いてナイトリー版のビルドをリリースするソフトウェアもある。

安定版と検証版

→「ベータ版」も参照

オープンソースソフトウェアのリリースは複数の公式バージョンを配布している。一つは「安定版」で、機能が安定している、致命的なバグがない、実行環境への最適化がなされているなどの、利用者がそのソフトウェアを定常的に利用しても大きな問題が発生することが想定されていないバージョンである。一つは「検証版」で、試験的な機能が実装されている、バグが存在している、幾つかの環境でのみ動作するなどの、利用者がソフトウェアの開発および検証を目的として用いるバージョンである。安定版は検証版より長い間隔でリリースされることもあり、幾つかの検証版のリリースを経て安定板がリリースされることがある。検証版はアルファ版、ベータ版、RC（Release Candidate、リリース候補）版などの名称を持つ。オープンソースソフトウェアの特性上、安定版ですべての機能が完成して開発が終了するものを示すものではなく、安定版もまた継続してリリースされる。

アーキテクチャの動的決定

→「エクストリーム・プログラミング」も参照

オープンソースソフトウェアのアーキテクチャは利用者および開発者により決定され、その戦略的決定を利用者の意見や他の多くの要因に依存する。長期に渡って固定された具体的な仕様や開発計画に依らず、複数の要因による柔軟なアーキテクチャ決定を通して仕様や開発計画を決定する。オープンソースソフトウェアの利用者は各個により良いアーキテクチャを決定する権利を持ち、メインストリームのソフトウェアおよび派生したソフトウェアのアーキテクチャとしてそれを採用することができる。

開発環境

開発ツール

オープンソースソフトウェア開発に使われる開発ツールはそれもまたオープンソースソフトウェアであることがある。オープンソースソフトウェア開発でオープンソースソフトウェアの開発ツールである利点は、オープンソースソフトウェアのライブラリの一部にオープンソースソフトウェアを利用する利点と同じく、その開発ツールがオープンソースソフトウェアであることによる利便性、安全性、信頼性を教授できることである。

ソースコードリポジトリ

→「OSSホスティングサービスの比較」も参照

ソフトウェアの開発者が複数名からなり、修正が頻繁になされるオープンソースソフトウェア開発では、ソースコードの修正内容、修正履歴の閲覧、そして修正の差し戻しを助けるためソースコードリポジトリにバージョン管理システムが用いられる。

ソースコードリポジトリはソフトウェアのソースコード一式を保存し、ソースコードの変更者、変更時刻、変更時コメントを残す。ソースコードの変更はユニークなID（連番の数字やハッシュ値）が割り当てられ、変更の記録を遡って特定して変更内容を確認することができる。ソースコードリポジトリはローカルファイルシステムに置くものや、インターネットを介したネットワーク上に置くものもある。オープンソースソフトウェアの利用者はソースコードリポジトリをフォークして独自のソースコードリポジトリを構築し、そのソースコードリポジトリ上でオープンソースソフトウェアを利用、修正、再頒布してより良いオープンソースソフトウェアを提供することができる。

ソースコードリポジトリをホスティングサービスとして提供するウェブサービスには、SourceForge、GitHub、Bitbucketなどがある。それらのウェブサービスは一般にソースコードが公開されるバージョン管理されたソースコードリポジトリを提供し、オープンソースソフトウェアの開発を支援している。それらのリポジトリはソースコードの閲覧、フォークは二次開発者が自由に行えるが、メインストリームのソースコードリポジトリに置かれたソースコード修正は主管開発者やその権限が与えられた開発者のみに許されており、不適切なソースコード修正がメインストリームのソースコードリポジトリに反映されて品質を損なうことを防いでいる。

コミュニケーションツール

オープンソースソフトウェアの開発者間のコミュニケーションはメーリングリスト、IRC、インスタントメッセージ、バグトラッキングシステムなどのインターネットコミュニケーションが用いられる。これらのコミュニケーションツールはオープンソースソフトウェアのソースコードの実装についてだけではなく、オープンソースソフトウェアの開発に関わるプロジェクトの方針、設計の検討、テストの実施、不具合の報告などの多岐に渡った話題のためのコミュニケーションに利用される。

コミュニケーションツールはプロジェクトの話題に限定したIRC、skype、slackなどのチャット、ソースコードリポジトリ、バグトラッキングシステム、ウィキを統合したGitHub、Bitbucketなどのホスティングサービス、プロジェクトやソフトウェアを限定しない雑多なStack Overflow、redditなどのコミュニティサイトが存在する。

ビジネスモデル

→詳細は「en:Business models for open-source software」を参照

多くのソフトウェアベンダー、ハードウェアベンダー、ソフトウェアライセンサーはオープンソースソフトウェアのフレームワーク、モジュール、ライブラリを彼らの製品に利用している[48][49]。一方で、オープンソースソフトウェア開発はソフトウェアのソースコードを開示し、利用、修正、再頒布を認めるという特性から収益を得るビジネスモデルを成立させることが難しく、様々な手法でのビジネスモデルの確立が試行されている[50]。

サービスサポートビジネス

→「サービスサポート」および「SaaS」も参照

ソフトウェアそのものよりも、トレーニング、テクニカルサポート、コンサルティングをサービスサポートとして販売して利益を得るビジネスモデルがある[51][52]。例えば、ソフトウェアのソースコードは無償で公開したまま、実行ファイルは購入者のみに提供する、もしくはコンパイルやパッケージングを手助けすることを有償サービスサポートとする手法がある。同様に、物理的なインストールメディア（例えばDVDやUSBメモリ）は有償サービスサポートとなりうる。Red HatやIBMはそれらの手法でオープンソースソフトウェアのビジネスモデルを確立している[53]。

クラウドファンディング

→「クラウドファンディング」も参照

オープンソースソフトウェアのための基金の機会として予約販売やプラエニュマレーション（英語版）に似たクラウドファンディングがある[54]。クラウドファンディングはKickstarter[55]、Indiegogo[56]、Bountysource[57]などのウェブプラットフォームの団体が支援している。クラウドファンディングを活用する場合は、開発するソフトウェアの目標を利用者に示し、それに対する賛意から寄付、投資、購入として基金を募る。カノニカルが開発を計画したUbuntu EdgeへのクラウドファンディングはIndiegogoで行われ、目標金額3,200万米ドルと非常に大きな規模のものだった[58]。

ドネーションウェア

→「ドネーションウェア」も参照

ドネーションウェアは開発者が利用者の任意での寄付（ドネーション）を受け取り、その寄付を収益の一環とする。2011年より、SourceForge.netは利用者からホスティングしているプロジェクトへ寄付する仕組みを追加した[59]。同様に、2012年にはイラストレーション・ソフトウェア・クリエイター（英語版）は利用者からオープンソースソフトウェア開発者へ寄付する仕組みを提供していた[60]。インターネットマイクロペイメントシステムであるPayPal、Flattr（英語版）、ビットコインが寄付の仕組みを手助けしている。知られている非常に大きな寄付キャンペーンは、2004年、Mozilla FoundationによるFirefox バージョン1.0の開発のためのもので、12月16日のニューヨーク・タイムズに２ページに渡って多くの寄付をした人の名前が並べられた[61][62]。

アドウェア

→「アドウェア」も参照

オープンソースソフトウェアで作られたアプリケーションで広告を扱うことで、広告代理店もしくは広告表示操作でビジネスモデルを構築する。MozillaやGoogle、カノニカルはソフトウェアで広告を表示するアドウェアによる経済モデル（英語版）へ向かっている。SourceForge.netは彼らのウェブサイトにバナー広告を設置することで、バナー広告の表示を求める企業からの収益モデルを確立している。SourceForge.netは、2006年の四半期には650万ドル[63]、2009年には2,300万ドルの利益を報告した[64]。オープンソースソフトウェアのアプリケーションであるAdblock Plusは広告表示の抑制を回避するホワイトリストにGoogleの広告を追加することを条件にGoogleから支払いを受けている[65]。

ブランドグッズビジネス

オープンソース企業のMozilla Foundationやウィキメディア財団はTシャツやコーヒーカップのようなブランドグッズを販売している[66][67]。これはユーザコミュニティへの追加サービスと見なすこともできる。

終焉時のオープンソースソフトウェア

→「en:List of commercial video games with later released source code」および「en:List of commercial software with available source code」も参照

商業終焉時のオープンソースソフトウェア化の極端な事例として、id Software[68][69]や3D Realms（英語版）[70][71]などによって普及させられている、長期の商業期間と投資利益の回収を終えた後に幾つかの製品をオープンソースソフトウェアとしてリリースするビジネスモデルがある。ソフトウェアが商用としての終わりを迎えた時にソースコードを公開する会社の動機は、ソフトウェアがユーザサポートをしないアバンダンウェアとなることや、時代遅れとなり忘れ去られることを防ぐためである[72]。ソースコードを公開することによりユーザコミュニティはオープンソースソフトウェアプロジェクトとして彼ら自身でユーザサポートを続けたり、開発を継続して時代遅れとなることを防ぐ機会を得ることができる[73]。ビデオゲーム業界ではソースコードが利用可能な商業ビデオゲームの一覧（英語版）にあるように多くの事例が存在する。

ゲーム以外の事例としては、1998年にオープンソースソフトウェアとなったネットスケープ・ナビゲーターや[74][75]、2000年10月にオープンソースソフトウェアとなったサン・マイクロシステムズのスター・スイートがある[76]。両ソフトウェアはオープンソースソフトウェアプロジェクトの重要な基礎となり、Mozilla FirefoxとLibreOfficeの名前で開発が続行した。ただし、Mozilla Firefoxは最終的には異なるビジネスモデルを確立して収益を得ているため、正確には商業終焉というわけではない。

ライセンス検証

→「ライセンスの互換性」も参照

オープンソースソフトウェア開発において自身のソフトウェアが課するライセンスの選定、およびソフトウェアが利用するソースコードのライセンスの検証は重要である。

「自身のソフトウェアが課すライセンス」はそのソフトウェアの「ソースコードに課すライセンス」であるが、オープンソースソフトウェアのためのライセンスは多数存在しており、ソフトウェア開発の手段や目的、ソースコードの利用者に課すべき制約に合わせて適切なライセンスを選択しなければならない。ソフトウェアのソースコードの利用、修正、再頒布を認めるオープンソースソフトウェアとしての定義の遵守の他、広告条項の付与、コピーレフト条項の付与、著作権の放棄などを考慮すべきである。ソフトウェア利用者のライセンスの解釈を検証する労力を減らすため（ライセンスの氾濫を防ぐため）、オープンソースソフトウェアには独自のライセンスを作成、適用するのではなく既存のライセンスから選択することが望ましい。

「ソフトウェアが利用するソースコードのライセンス」はモジュールとして利用するソフトウェアの各個ライセンスについて検証しなければならない。Apache Licenseのように広告条項が含まれている場合は、広告条項に基づいてソースコードリポジトリのCOPYRIGHT、LICENSEファイルに利用しているソフトウェアの名前を連ねる必要があったり、ソフトウェアの利用者が必ず閲覧できる箇所にソフトウェアの名前を表示させなければならない。GNU GPLのようにコピーレフト条項が含まれている場合は、コピーレフト条項に基づいて自身のライセンスを決定し、自身のソフトウェアで使っている他のソフトウェアとのライセンスの互換性を検証しなければならない。

ライセンスの互換性は特に注意すべきで、ソフトウェアが利用するソースコードにライセンスの互換性がない場合、そのソースコードおよびソフトウェアを利用することは出来ない。例えば、「GNU GPLでソースコードの公開が必須となるオープンソースソフトウェア」と「商用契約でソースコードの開示を禁じられたプロプライエタリ・ソフトウェア」を併用しようとした場合、GNU GPLを遵守すると商用契約に違反し、商用契約を遵守するとGNU GPLに違反することになる。

歴史

→「en:History of free and open-source software」も参照

1980年代以前

1950年代から1960年代のコンピュータでは、ハードウェア上で動作するOSとソフトウェアはソースコードと実行ファイルをハードウェアに同梱する形で利用者に提供されていた。そのソフトウェアはそのハードウェアでしか動作させることはできず、事実上それらは一つのものとして扱われ、ソフトウェアの購入費（利用費）はハードウェアの購入費に含まれていた。コンピュータは大学や研究機関が主な利用者であり、ソフトウェアのバグの修正や新しい機能の追加は利用者が同梱されたソースコードを用いて、利用者自身が行うことができた。規模の大きなOSの修正は幾つかの企業の研究機関で行われていた。多くのケースでソフトウェアはパブリックドメインソフトウェアとして共有されており、学術知見や共有知識として利用者に広く共有されていた。一方で、ソースコードの規模の大きな修正や画期的な修正は大学、研究機関の閉じた中で行われ、クローズドソースであった。

1974年以前はソフトウェアはコピーライトではないと考えられていたが、同年、Commission on New Technological Uses of Copyrighted Works（英語版）（CONTU）は「コンピュータプログラムは、著作者の制作を具体化する範囲で、著作権の適切な主題である」と言及した[77][78]。加えて、1983年にCONTUはオブジェクトファイルに関するApple-Franklin訴訟（英語版）でコンピュータプログラムは文学作品としての著作権を持ち、ソースコードを非公開とするクローズドソフトウェアのビジネスモデルは有効であるとコメントした[79]。

1970年代序盤、AT&TはUNIXの早期バージョンを開発し、行政機関と学術機関に無償で提供した。しかし、そのバージョンは再頒布や修正コードの頒布を認めておらず、オープンソースソフトウェアと呼ばれる条件を満たす物ではなかった。1980年代にはUNIXは広く使われるようになり、AT&Tは無償での提供を取り止め、システムパッチを有償で提供するようになった。広い普及によりアーキテクチャを切り替えることは難しく、多くの学術機関の利用者は有償ライセンスを購入して利用を続けた。

1970年代末から1980年代初頭、コンピュータベンダーとソフトウェアベンダーは「プログラム製品」としてソフトウェアのビジネスモデルを構築し、ソフトウェアを商用製品として販売していった。1976年、ビル・ゲイツは「Open Letter to Hobbyists」というエッセイでマイクロソフトの製品であるAltair BAISCが愛好者の間でライセンス費を支払うこのとなく広く共有されていることに失望していると言及した。1979年、AT&Tは企業がUNIXシステムを利用してビジネスをする場合は、UNIXの利用に有償ライセンスを課すことを決めた。1983年、IBMはソフトウェア製品にソースコードを同梱せず販売する方針を定めた。

1980年代：フリーソフトウェア運動の始まり

→「フリーソフトウェア運動」も参照

1982年、リチャード・ストールマンはソースコードを同梱しないソフトウェアにストレスを感じ、その流れに対抗する形でソースコードを利用者が自由に扱えるソフトウェアを開発および提供するプロジェクト、GNUプロジェクトを開始した。GNUプロジェクトの開発するソフトウェアは利用者がソフトウェアのソースコードを利用者が自由に扱えるフリーソフトウェアであった。1985年、フリーソフトウェアの更なる促進を図るため、フリーソフトウェア財団を立ち上げてフリーソフトウェア運動を始めた。

フリーソフトウェア運動の一貫として、GNUプロジェクトとフリーソフトウェア財団はコピーレフトの再定義とライセンス条文化、GNU宣言の発表、フリーソフトウェアの定義などを実施していった。

1997年：『伽藍とバザール』の出版

→「伽藍とバザール」も参照

1997年、エリック・レイモンドは『伽藍とバザール』を出版し、ソフトウェアのソースコードが公開された環境でのハッカーコミュニティとフリーソフトウェアの開発モデルについて言及した。1998年初頭に同著書は大きな注目を集め、ネットスケープコミュニケーションズがNetscapeをフリーソフトウェアとしてリリースする一つの要因となった。

『伽藍とバザール』ではFetchmailとLinuxカーネルの開発手法を参考に、伽藍の様にトップダウンで開発が進められるプロプライエタリ・ソフトウェアとバザールの様にボトムアップで開発が進められるオープンソースソフトウェアにおける、トップダウン設計とボトムアップ設計の比較がなされている。ソースコードが公開されたオープンソースソフトウェアの開発では末端の利用者が改善の意見やバグの改修などを実施し、ボトムアップでソフトウェア開発が進められていくことが一つのメリットであると言及している。

1990年代後期：「オープンソース」の始まり

→「オープンソース」も参照

1998年、「オープンソース」という単語はフリーソフトウェア運動の戦略会議の中で誕生した。エリック・レイモンドたちはフリーソフトウェアの主義と利益をネットスケープコミュニケーションズのような営利企業に理解させるための方法を考えていたが、フリーソフトウェア財団のフリーソフトウェア運動では達成できないと考え、ソースコードを共有することによるビジネスの将来性を強調する再ブランド化を検討し、利用者にソースコードを公開して、その利用、修正、再頒布を認めるオープンソースという単語と開発手法を定義した。その後、オープンソースという開発手法を広めるためオープンソース・イニシアティブを発足した。

2000年前後：論争および訴訟

→「GNU/Linux名称論争」、「ハロウィーン文書」、「SCO-Linux論争」、「Iceweasel」、および「TiVo化」も参照

フリーソフトウェア、および、オープンソースが普及を始めた2000年前後には、幾つかのオープンソースソフトウェアに関わる大きな論争および訴訟があった。

1990年代中程以降、リチャード・ストールマンはLinuxを「Linux」ではなく「GNU/Linux」と呼ぶことをDebianを含むLinux関連ソフトウェアベンダーに依頼していた[80]。他者の開発するソフトウェアの名称を指定する名称変更の依頼は賛成派と反対派に分かれるGNU/Linux名称論争となり、LinuxディストリビューションやLinux向けソフトウェアを開発する利用者がどのような名称でLinuxを扱うかの論争となった。

1998年、マイクロソフトの社内文書であるハロウィーン文書の一部がエリック・レイモンドによりリークされた[81]。ハロウィーン文書にはLinuxやオープンソースソフトウェアに関する潜在的な戦略についての検討情報が記載されていた。それらの文書では、オープンソースソフトウェアがマイクロソフトの自社製品と競合する製品であると認め、それらとどのように戦うかの戦略が検討されていた[82]。

2003年3月7日、UNIXおよびLinuxのソフトウェアを開発していたSCOグループは、同社が権利を持つUNIXのソースコードに基づく機能をIBMが同社の開発するLinux関連製品に不正に組み込んだとして、IBMを提訴した[83]。IBMはこれに対してSCOグループを反訴した。同様にSCOグループはIBM以外のNovellやRed HatのLinuxディストリビューションベンダーも訴えた[84][85] 。オープンソースソフトウェアのソースコードの著作権、開発機能の権利の在り処を争点として、各社と論争をした。

2006年2月、DebianプロジェクトのバグトラッキングシステムにFirefoxの商標の扱い、およびメンテナンス方法に関する指摘が挙げたれた[86]。要点としては、Mozilla Foundationがオープンソースソフトウェアとして開発しているFirefoxがDebianの公式リポジトリで修正を伴って再頒布されているが、公式ロゴとアートワークの適切な利用がなされていない、メンテナンス手法がセキュリティ等の観点から不適切であるなどの問題があるため、「Firefox」の商標を用いて再頒布をしてはならないというものであった。幾つかの問題の解決方法を模索した上で、DebianはFirefoxのソースコードを修正したソフトウェアを「Firefox」ではなく「Iceweasel」の名称で頒布することに決定した。

2006年、リチャード・ストールマンとGNUプロジェクトは、TiVoが開発するLinuxをOSに用いたハードディスクレコーダーがGNU GPLのライセンス条項を遵守せずソフトウェアの利用者の自由を妨げていることを指摘し、TiVo化という単語を作り批判した[87]。TiVoはコンテンツの権利を保護するDRMの観点からユーザの修正したソフトウェアをTiVoの開発したハードウェアで動作させることを抑制していた。リチャード・ストールマンは、コンテンツの保護のためのDRMアーキテクチャは理由にはならず、ライセンス条項の遵守破棄は不当であると論争した。

他のソフトウェアモデルとの比較

フリーソフトウェア

→「フリーソフトウェア」も参照

オープンソースソフトウェアとフリーソフトウェアは、そのソフトウェアのソースコードを利用、修正、再頒布を認めるという点では同じであるが、オープンソースソフトウェアとフリーソフトウェアは根源的なコンセプトが異なり、「オープンソースソフトウェア（オープンソース）」がソフトウェアのソースコードを公開、共有する「開発の方法論」である一方で、「フリーソフトウェア」は利用者の自由（実行し、研究して変更し、コピーを変更ありまたはなしで再配布するという自由）を尊重する「社会運動」である[19][88]。コンセプトが「開発の方法論」と「社会運動」と異なるため、本来は並列に比較するようなものではない。

その上で、フリーソフトウェアという社会運動のための一つのツールとしてオープンソースソフトウェアという開発の方法論を用いようとした場合、オープンソースソフトウェアは利用者の自由を尊重するのに機能不十分なツールである。この機能不十分な点を比較した場合、オープンソースソフトウェアが許容する幾つかのライセンスは不適切であり、フリーソフトウェアはソフトウェアにコピーレフトに代表されるような利用者の自由を尊重するための条項が含まれたライセンスを推奨している[4]。

機能不十分な例としては、オープンソース・イニシアティブがオープンソースライセンスとして承認しているSybase Open Watcom Public License（英語版）は利用者が修正したソースコードから作られたソフトウェアを個人的な用途で公開した場合にはソースコードの公開を必要としていない。これは修正されたソフトウェアは一般に公開されているにも関わらず、そのソフトウェアのソースコードは非公開となっており、二次利用者の自由を妨げている[89]。もう一つの例としては、オープンソースソフトウェアは利用者がソフトウェアもしくはそのソフトウェアが動作するハードウェアをTiVo化（tivoization）することを許容するライセンスの存在を許し、二次利用者の自由を妨げることを否定していない[90][91]。

シェアードソース・ソフトウェア

→「シェアードソース」も参照

シェアードソース・ソフトウェアはソースコードを開示し、利用者にソースコードおよびソフトウェアの動作の参照およびデバッグのための利用を認めている[92]。ソフトウェアのソースコードの共有を主な観点としており、営利企業の商業ソフトウェアのソースコードを協力機関（研究機関、大学、利用者）に開示する用途で利用されている。

オープンソースソフトウェアとシェアードソース・ソフトウェアの違いは、シェアードソース・ソフトウェアはソースコードの修正、再頒布に対して制約的である所である。利用者に対してソースコードの参照、デバッグを目的とした利用は認めているが、修正したソースコードそのものや、修正したソースコードから生成されるソフトウェアの頒布は私的使用に限って認めるなどの制約を伴う場合がある。また、シェアードソース・ソフトウェアでは商用目的でソースコードを利用（閲覧）することが出来ない場合がある。それらの制約は、シェアードソース・ソフトウェアに課せられるライセンスの内容に依る。

マイクロソフトは2001年より自社ソフトウェア製品のためにシェアードソース・イニシアティブを立ち上げている[93]。マイクロソフトのシェアードソースライセンスは幾つかの種類があり、制約の緩やかなライセンスはオープンソース・イニシアティブ公認のオープンソースライセンスであるが[94]、制約の厳しいライセンスは同社との提携契約の上でソースコードの参照のみが許されるライセンスである。Sony Computer Entertainment of America（SCEA）は2005年にプレイステーションのソフトウェアのためにSCEA Shared Source Licenseを設けていた[95][96]。

プロプライエタリ・ソフトウェア

→「プロプライエタリ・ソフトウェア」および「クローズドソース」も参照

プロプライエタリ・ソフトウェアはソフトウェアの利用、頒布に制限を課すことで利益を得るソフトウェアの総称であり、オープンソースソフトウェアが利用、修正、再頒布で直接的な利益を得ることをしない点が主な違いである。

プロプライエタリ・ソフトウェアのソースコードの公開、利用の可否に明確な線引きはないが、ソースコードを開示していてもソースコードの入手が有償である、ソースコードが非公開（クローズドソース）であるなど、基本的にソフトウェアの利用者がソースコードを利用、修正、再頒布することは出来ない。ソフトウェアのソースコードを非商用目的に限り利用、修正、再頒布を認め、商用目的での利用、修正、頒布を認めない場合、オープンソースソフトウェアではなくプロプライエタリ・ソフトウェアと呼ばれる[11]。

多くの主張者が、多くの人間がソースコードを閲覧し、編集し、変更するため、オープンソースソフトウェアはソースコードが非公開のプロプライエタリ・ソフトウェアに比べて本質的により安全であると主張している[97]。Linuxのソースコードは1000行あたり0.17個のバグがある一方で、プロプライエタリ・ソフトウェアのソースコードは一般的に1000行あたり20–30個のバグがある[98]。

個人や組織がオープンソースソフトウェアを選ぶ主要な4つの理由に、安価、情報セキュリティ、ベンダーロックインでない、より良い品質がある[99]。ソフトウェア開発企業は必ずしもソフトウェアの販売に依存しないため、プロプライエタリ・ソフトウェアは必要性が低くなってきている[100]。Novellのような企業は、製品の一部をオープンソースソフトウェアに切り替えているため、継続的にオープンソースソフトウェア上でのビジネスモデルを思案している[101]。

派生した用語

FLOSS

→詳細は「FLOSS」を参照

「フリーソフトウェア」と「オープンソース」を合わせた用語として「FLOSS（Free/Libre and Open Source Software）」がある[102]。

これは、フリーソフトウェア財団とオープンソース・イニシアティブが根源的な部分で活動理念を異にしており、フリーソフトウェア財団の定義する「フリーソフトウェア」とオープンソース・イニシアティブの定義する「オープンソース」は別物で区別しなければならないというリチャード・ストールマンの考えに基づいている[19]。ソースコードとソフトウェアの利用、修正、再頒布を認めるという表面的な同一視をした場合に、それらの用語を同列かつ個別のものと見なし、その上でそれらをまとめて言い表すために、複合語として「FLOSS」という用語が使われる。

オープンソース− / オープン−

オープンソースから派生した様々な用語

オープンソースソフトウェアという用語がソフトウェアおよびそのソースコードのみに適用される一方で、ソースコードを伴うソフトウェア以外の事柄の利用者にその事柄の利用、修正、再頒布を認める場合は、「オープンソース」を冠したオープンソースハードウェア、オープンソースジャーナリズム（英語版）、オープンソースガバナンス（英語版）、オープンソースエコロジー（英語版）のような用語が存在する。ソースコードは存在しないがその事柄の利用、修正、頒布を認める場合は、「オープン」を冠したオープンアクセス、オープンシステム、オープンコンテントのような用語が存在する。

「オープンソース」「オープン」を冠していても、オープンソースソフトウェアの定義と同じくその事柄の利用、修正、再頒布を認めているかどうかは各用語によって異なるため、それらの用語の意味するところについてはそれぞれ注意して扱うべきである。

関連項目

ポータル FLOSS
プロジェクト コンピュータ

脚注

  1. ^ a b c United States Department of Defense (2009年10月16日). “Defining Open Source Software (OSS)”. 2018年2月9日閲覧。 “defines OSS as "software for which the human-readable source code is available for use, study, re-use, modification, enhancement, and re-distribution by the users of that software"”
  2. ^ a b Fedora. “Licensing:Main Overview”. 2018年2月20日閲覧。 “This list is based on the licenses approved by the Free Software Foundation , OSI and consultation with Red Hat Legal.”
  3. ^ a b Open Source Initiative. “What is "Open Source" software?”. 2018年2月9日閲覧。
  4. ^ a b c GNU Project (2018年1月1日). “How to choose a license for your own work”. 2018年2月9日閲覧。
  5. ^ opensource.com. “What is open source?”. 2018年2月9日閲覧。
  6. ^ Open Source Initiative. “Licenses & Standards”. 2018年2月9日閲覧。
  7. ^ GNU Project. “Various Licenses and Comments about Them”. 2018年2月9日閲覧。
  8. ^ a b Fedora (2017-11--06). “Licensing:Main”. 2018年2月9日閲覧。
  9. ^ a b Debian (2018年2月4日). “License information”. 2018年2月9日閲覧。
  10. ^ United States Department of Defense (2009年10月16日). “Defining Open Source Software (OSS)”. 2018年2月9日閲覧。 “Careful legal review is required to determine if a given license is really an open source software license. The following organizations examine licenses; licenses should pass at least the first two industry review processes, and preferably all of them”
  11. ^ a b c United States Department of Defense (2009年10月16日). “Q: What are antonyms for open source software?”. 2018年2月9日閲覧。
  12. ^ annr (2017年5月16日). “What is open source, and what is the Open Source Initiative?”. 2018年2月9日閲覧。
  13. ^ Open Source Initiative (2007年3月22日). “The Open Source Definition”. 2018年2月9日閲覧。
  14. ^ Dana Blankenhorn (2006年12月7日). “Is SugarCRM open source?”. 2018年2月15日閲覧。
  15. ^ Tiemann, Michael (2007年6月21日). “Will The Real Open Source CRM Please Stand Up?”. Open Source Initiative. 2008年1月4日閲覧。
  16. ^ Vance, Ashlee (2007年7月25日). “SugarCRM trades badgeware for GPL 3”. The Register. http://www.regdeveloper.co.uk/2007/07/25/sugarcrm_gpl3/ 2008年9月8日閲覧。 
  17. ^ 総務省. “2　OSSの影響 ： 平成18年版 情報通信白書”. 2018年2月9日閲覧。 “Open Source Initiative（OSI）が定めた「The Open Source Definition（OSD）」と呼ばれる定義を満たすソフトウェアである”
  18. ^ GNU Project (2018年1月1日). “What is free software?”. 2018年2月9日閲覧。
  19. ^ a b c Richard Stallman (2016年11月18日). “Why Open Source misses the point of Free Software”. 2018年2月9日閲覧。
  20. ^ Maggie Shiels (2008年8月14日). “Legal milestone for open source”. 2018年2月9日閲覧。
  21. ^ Open Source Initiative. “Licenses & Standards”. 2018年2月8日閲覧。
  22. ^ a b c d e f g h i j k l Open Source Initiative. “Open Source Licenses by Category”. 2018年2月9日閲覧。
  23. ^ Open Source Initiative. “Is <SOME LICENSE> an Open Source license, even if it is not listed on your web site?”. 2018年2月8日閲覧。
  24. ^ Wheeler, David A. (2015年). “The fight for freedom”. 2018年2月9日閲覧。
  25. ^ a b GNU Porject (2018年2月10日). “Various Licenses and Comments about Them”. 2018年2月9日閲覧。
  26. ^ Fedora (2017年11月6日). “Discussion of Licensing”. 2018年2月15日閲覧。
  27. ^ Martin Michlmayr (2008年8月21日). “OSI and License Proliferation”. 2018年2月9日閲覧。
  28. ^ Open Source Initiative. “The Licence Proliferation Project”. 2011年5月10日閲覧。
  29. ^ Open Source Initiative. “The Licence Review Process”. 2018年2月8日閲覧。
  30. ^ “Speech Transcript - Craig Mundie, The New York University Stern School of Business” (2001年5月3日). 2005年6月21日時点のオリジナルよりアーカイブ。2011年2月7日閲覧。
  31. ^ webmink (2017年7月28日). “Public Domain Is Not Open Source”. 2018年2月25日閲覧。
  32. ^ a b “OSI Board Meeting Minutes, Wednesday, March 4, 2009” (2009年3月4日). 2018年2月9日閲覧。
  33. ^ a b c d GNU Project (2018年2月10日). “CC0”. 2018年2月9日閲覧。
  34. ^ a b c GNU Project (2018年2月10日). “Apache License, Version 2.0”. 2018年2月9日閲覧。
  35. ^ a b c GNU Project (2018年2月10日). “Modified BSD license”. 2018年2月9日閲覧。
  36. ^ a b c GNU Project (2018年2月10日). “FreeBSD license”. 2018年2月9日閲覧。
  37. ^ a b GNU Project (2018年2月10日). “GNU General Public License (GPL) version 3”. 2018年2月9日閲覧。
  38. ^ a b c GNU Project (2018年2月10日). “GNU Lesser General Public License (LGPL) version 3”. 2018年2月9日閲覧。
  39. ^ a b c GNU Project (2018年2月10日). “X11 License”. 2018年2月9日閲覧。
  40. ^ a b GNU Project (2018年2月10日). “Mozilla Public License (MPL) version 2.0”. 2018年2月9日閲覧。
  41. ^ Mozilla. “MPL 2.0 FAQ”. 2018年2月9日閲覧。 “The MPL is a simple copyleft license.”
  42. ^ a b GNU Project (2018年2月10日). “Common Development and Distribution License (CDDL), version 1.0”. 2018年2月9日閲覧。
  43. ^ Rami Sass. “Top 10 Common Development and Distribution License (CDDL) Questions Answered”. 2018年2月9日閲覧。 “The CDDL is considered a weak copyleft license.”
  44. ^ a b c GNU Project (2018年2月10日). “Eclipse Public License Version 2.0”. 2018年2月9日閲覧。
  45. ^ a b c GNU Project (2018年2月10日). “Creative Commons Attribution 4.0 license”. 2018年2月9日閲覧。
  46. ^ a b c GNU Project (2018年2月10日). “Creative Commons Attribution-Sharealike 4.0 license”. 2018年2月9日閲覧。
  47. ^ Raymond, Eric S. (1999). The Cathedral and the Bazaar. O'Reilly Media. p. 30. ISBN 1-56592-724-9. http://books.google.com/books?id=F6qgFtLwpJgC&pg=PA30#v=onepage&f=false 
  48. ^ Popp, Dr. Karl Michael; Meyer, Ralf (2010). Profit from Software Ecosystems: Business Models, Ecosystems and Partnerships in the Software Industry. Norderstedt, Germany: Books on Demand. ISBN 9783839169834. https://books.google.com/books?id=i1VGDLCMyKAC 
  49. ^ Wheeler, David A. (February 2009). “F/LOSS is Commercial Software”. Technology Innovation Management Review. Talent First Network. 18 June 2016閲覧。
  50. ^ Popp, Dr. Karl Michael (2015). Best Practices for commercial use of open source software. Norderstedt, Germany: Books on Demand. ISBN 978-3738619096 
  51. ^ Germain, Jack M. (5 November 2013). “FOSS in the Enterprise: To Pay or Not to Pay?”. LinuxInsider. ECT News Network, Inc.. 18 June 2016閲覧。
  52. ^ Rubens, Paul (13 February 2013). “6 Reasons to Pay for Open Source Software”. CIO. CXO Media Inc.. 18 June 2016閲覧。 “Open source software is free to download, modify and use, but that doesn't mean it's not worth paying for sometimes. If you're using open source software in a commercial, enterprise capacity, here are six reasons why you should pay for free software.”
  53. ^ McMillan, Robert (28 March 2012). “Red Hat Becomes Open Source’s First $1 Billion Baby”. Wired. https://www.wired.com/2012/03/red-hat/ 18 June 2016閲覧. "Other companies have made big money selling Linux — Intel, IBM, Dell, and others have used it as a way to sell hardware and support services — but Red Hat has managed the tricky business of building a software platform that big businesses will pay for." 
  54. ^ “What IS Crowdfunding And How Does IT Benefit The Economy” (November 27, 2012). 2012年12月6日閲覧。
  55. ^ Lunduke, Bryan (2013年8月7日). “Open source gets its own crowd-funding site, with bounties included - Bountysource is the crowd-funding site the open source community has been waiting for.”. networkworld.com. 2013年8月10日閲覧。 “Many open source projects (from phones to programming tools) have taken to crowd-funding sites (such as Kickstarter and indiegogo) in order to raise the cash needed for large-scale development. And, in some cases, this has worked out quite well.”
  56. ^ Arceri, Timothy (2013年7月26日). “Help improve OpenGL support for the Linux Graphics Drivers”. Indiegogo. 2013年8月11日閲覧。 “Helping fund the time for me to become a Mesa contributor and document the experience to make it easier for others to understand where to start with the Mesa codebase. Many people have brought up the idea of crowd sourcing open source driver development. This is a small scale experiment to see if it could actually work.”
  57. ^ “Bountysource Raises $1.1 Million for the First Crowdfunding Platform for Open-Source Software Projects”. Yahoo Finance. Marketwired (16 July 2013). 18 June 2016閲覧。
  58. ^ Jamie Rigg (2013年8月22日). “Ubuntu Edge Indiegogo campaign ends with over $19 million outstanding”. 2018年2月20日閲覧。
  59. ^ Naramore, Elizabeth (4 March 2011). “SourceForge.net Donation System”. SourceForge. Slashdot Media. 16 October 2017閲覧。
  60. ^ Sneddon, Joey-Elijah (2012年6月1日). “Will You Help Change The Way Open-Source Apps are Funded?”. OMGUbuntu. 2013年8月8日閲覧。 “Lunduke is pledging to open-source and distribute his portfolio of hitherto paid software – which includes the Linux distro management simulator Linux Tycoon - for free, under the GPL, if he can reach a donation-driven funding goal of $4000/m. Reaching this goal, Lunduke says, 'will provide proof for others, who would also like to move their software businesses to be open source, that it is doable.'”
  61. ^ Mozilla Foundation (December 15, 2004). “Mozilla Foundation Places Two-Page Advocacy Ad in the New York Times”. June 15, 2010閲覧。
  62. ^ Marson, Ingrid (2004年12月16日). “New York Times runs Firefox ad”. cnet.com. 2013年8月12日閲覧。 “Fans of the Mozilla Foundation's Firefox browser who funded an advertisement in The New York Times will finally get to see their names in print on Thursday.”
  63. ^ Hunt, Katherine (2007年5月24日). “Sourceforge quarterly profit surges as revenue rises”. marketwatch.com. 2013年8月13日閲覧。 “Software Corp., late Thursday reported third-quarter net earnings of $6.49 million, or 9 cents a share, up from $997,000, or 2 cents a share, during the year-ago period. Pro forma earnings from continuing operations were $2.1 million, or 3 cents a share, compared with $1.2 million, or 2 cents a share, last year. The Fremont, Calif.-based maker of computer servers and storage systems said revenue for the three months ended April 30 rose to $10.3 million from $7.9 million. Analysts, on average, had forecast a per-share profit of 2 cents on revenue of $12 million.”
  64. ^ “SourceForge Reports Second Quarter Fiscal 2009 Financial Results”. 2015年6月3日時点のオリジナルよりアーカイブ。2018年2月15日閲覧。
  65. ^ Callaham, John (2013年6月6日). “Report: Google paying AdBlock Plus to not block Google's ads”. neowin.com. 2013年8月13日閲覧。 “Google is paying money to Eyeo, the company behind AdBlock Plus, so that its ads get through the browser ad remover.”
  66. ^ Markham, Gervase (16 March 2004). “Mozilla Foundation Open Letter Orders Unofficial Mozilla Merchandise Sellers to Stop, Legal Action Hinted”. MozillaZine. 18 June 2016閲覧。
  67. ^ “Wikipedia Store”. Wikimedia Foundation (2016年). 18 June 2016閲覧。
  68. ^ “id Software releases Doom 3 source code”. The H Open (23 November 2011). 8 December 2013時点のオリジナルよりアーカイブ。2018年2月20日閲覧。
  69. ^ Spencer, Spanner (24 March 2009). “id Software makes iPhone Wolfenstein open source”. PocketGamer.co.uk. 2018年2月20日閲覧。
  70. ^ Siegler, Joe (1 April 2005). “Shadow Warrior Source Code Released”. 3D Realms. 2018年2月20日閲覧。
  71. ^ “Games”. 3D Realms. 2018年2月20日閲覧。 “Selected games have had their source code released by us. These games are: Duke Nukem 3D, Shadow Warrior, Rise of the Triad, Word Whiz, Beyond the Titanic, Supernova, & Kroz. You can obtain these from our downloads page.”
  72. ^ Andersen, John (2011年1月27日). “Where Games Go To Sleep: The Game Preservation Crisis, Part 1”. Gamasutra. 2013年1月10日閲覧。 “The existence of decaying technology, disorganization, and poor storage could in theory put a video game to sleep permanently -- never to be played again. Troubling admissions have surfaced over the years concerning video game preservation. When questions concerning re-releases of certain game titles are brought up during interviews with developers, for example, these developers would reveal issues of game production material being lost or destroyed. Certain game titles could not see a re-release due to various issues. One story began to circulate of source code being lost altogether for a well-known RPG, preventing its re-release on a new console.”
  73. ^ Bell, John (2009年10月1日). “Opening the Source of Art”. Technology Innovation Management Review. 2014年3月30日時点のオリジナルよりアーカイブ。2013年8月9日閲覧。 “[...]that no further patches to the title would be forthcoming. The community was predictably upset. Instead of giving up on the game, users decided that if Activision wasn't going to fix the bugs, they would. They wanted to save the game by getting Activision to open the source so it could be kept alive beyond the point where Activision lost interest. With some help from members of the development team that were active on fan forums, they were eventually able to convince Activision to release Call to Power II's source code in October of 2003.”
  74. ^ “NETSCAPE ANNOUNCES PLANS TO MAKE NEXT-GENERATION COMMUNICATOR SOURCE CODE AVAILABLE FREE ON THE NET”. Netscape Communications Corporation (1998年1月22日). 2007年4月1日時点のオリジナルよりアーカイブ。2013年8月8日閲覧。 “BOLD MOVE TO HARNESS CREATIVE POWER OF THOUSANDS OF INTERNET DEVELOPERS; COMPANY MAKES NETSCAPE NAVIGATOR AND COMMUNICATOR 4.0 IMMEDIATELY FREE FOR ALL USERS, SEEDING MARKET FOR ENTERPRISE AND NETCENTER BUSINESSES”
  75. ^ “MOUNTAIN VIEW, Calif., April 1 /PRNewswire/ -- Netscape Communications and open source developers are celebrating the first anniversary, March 31, 1999, of the release of Netscape's browser source code to mozilla.org”. Netscape Communications (1999年3月31日). 2013年1月10日閲覧。 “[...] The organization that manages open source developers working on the next generation of Netscape's browser and communication software. This event marked a historical milestone for the Internet as Netscape became the first major commercial software company to open its source code, a trend that has since been followed by several other corporations. Since the code was first published on the Internet, thousands of individuals and organizations have downloaded it and made hundreds of contributions to the software. Mozilla.org is now celebrating this one-year anniversary with a party Thursday night in San Francisco.”
  76. ^ Proffitt, Brian (2000年10月13日). “StarOffice Code Released in Largest Open Source Project”. linuxtoday.com. 2013年10月16日時点のオリジナルよりアーカイブ。2013年1月10日閲覧。 “Sun's joint effort with CollabNet kicked into high gear on the OpenOffice Web site at 5 a.m. PST this morning with the release of much of the source code for the upcoming 6.0 version of StarOffice. According to Sun, this release of 9 million lines of code under GPL is the beginning of the largest open source software project ever.”
  77. ^ Apple Computer, Inc. v. Franklin Computer Corporation Puts the Byte Back into Copyright Protection for Computer Programs in Golden Gate University Law Review Volume 14, Issue 2, Article 3 by Jan L. Nussbaum (January 1984)
  78. ^ Lemley, Menell, Merges and Samuelson. Software and Internet Law, p. 34.
  79. ^ Landley, Rob (2009年5月23日). “notes-2009”. landley.net. 2015年12月2日閲覧。 “So if open source used to be the norm back in the 1960's and 70's, how did this _change_? Where did proprietary software come from, and when, and how? How did Richard Stallman's little utopia at the MIT AI lab crumble and force him out into the wilderness to try to rebuild it? Two things changed in the early 80's: the exponentially growing installed base of microcomputer hardware reached critical mass around 1980, and a legal decision altered copyright law to cover binaries in 1983.”
  80. ^ Sam Williams (2002). “Chapter 10”. Free as in Freedom: Richard Stallman's Crusade for Free Software. O'Reilly. http://www.oreilly.com/openbook/freedom/ch10.html 
  81. ^ “Internal Memo Shows Microsoft Executives' Concern Over Free Software”. The New York Times (1998年11月3日). 2011年11月5日閲覧。
  82. ^ “Halloween Document 1”. www.catb.org. 2016年2月22日閲覧。
  83. ^ “Ladies and Gentlemen, SCO v. IBM Is Officially Reopened”. Groklaw (2013年6月15日). 2014年9月17日閲覧。
  84. ^ “SCO's Complaint In the Third Judicial District Court of Salt Lake County, State of Utah” (January 20, 2004). 2018年2月24日閲覧。
  85. ^ “Archived copy”. 2004年6月11日時点のオリジナルよりアーカイブ。2004年8月2日閲覧。
  86. ^ Mike Connor (2006年2月27日). “Uses Mozilla Firefox trademark without permission”. 2018年2月24日閲覧。
  87. ^ John Sullivan (2006年2月8日). “[Info-gplv3] “GPLv3 Update #2””. Free Software Foundation. 2011年4月27日閲覧。
  88. ^ Bertle King, Jr. (2017年2月21日). “Open Source vs. Free Software: What's the Difference and Why Does It Matter?”. 2018年2月9日閲覧。
  89. ^ “Various Licenses and Comments about Them - Sybase Open Watcom Public License version 1.0 (#Watcom)”. gnu.org. 2015年12月23日閲覧。 “This is not a free software license. It requires you to publish the source code publicly whenever you “Deploy” the covered software, and “Deploy” is defined to include many kinds of private use.”
  90. ^ “Richard Stallman explains the new GPL provisions to block "tivoisation"”. 2018年2月15日閲覧。
  91. ^ “InformationWeek: TiVo Warns Investors New Open Source License Could Hurt Business”. 2018年2月15日閲覧。
  92. ^ Microsft. “Shared Source Initiative”. 2018年2月15日閲覧。 “the Shared Source Initiative Microsoft licenses product source code to qualified customers, enterprises, governments, and partners for debugging and reference purposes”
  93. ^ Stephen R. Walli (2005年3月24日). “Perspectives on the Shared Source Initiative”. 2018年2月15日閲覧。
  94. ^ Mary Jo Foley (2007年10月16日). “Microsoft gets the open-source licensing nod from the OSI”. 2018年2月15日閲覧。
  95. ^ Sony Computer Entertainment Inc. (2005年). “SCEA Shared Source License 1.0”. 2007年1月2日時点のオリジナルよりアーカイブ。2018年2月14日閲覧。
  96. ^ Fedora (2017年11月6日). “Software License List”. 2018年2月14日閲覧。
  97. ^ Seltzer, Larry (2004年5月4日). “Is Open-Source Really Safer?”. PCMag.com. 2012年3月25日閲覧。
  98. ^ WIRED STAFF (2004年12月14日). “LINUX: FEWER BUGS THAN RIVALS”. 2018年2月15日閲覧。
  99. ^ Irina Guseva (2009年5月26日). “Bad Economy Is Good for Open Source”. 2018年2月15日閲覧。
  100. ^ Joab Jackson (2011年11月3日). “Open Source vs. Proprietary Software”. PCWorld Business Center. Pcworld.com. 2018年2月15日閲覧。
  101. ^ Martin LaMonica (2004年2月12日). “Pandora's box for open source - CNET News”. News.cnet.com. 2012年11月4日時点のオリジナルよりアーカイブ。2012年3月25日閲覧。
  102. ^ Richard Stallman (2016年11月18日). “FLOSS and FOSS”. 2018年2月9日閲覧。

外部リンク

ウィキメディア・コモンズには、オープンソースソフトウェアに関連するカテゴリがあります。
英語版ウィキブックスに本記事に関連した解説書・教科書があります。
全般
解説
開発（英語版）
OS（英語版）
ソフトウェア
ホスティング
団体
標準化団体
開発支援団体
ライセンス
指針
主要例
その他
課題
特性上の課題
対立と論争
その他
一覧
「https://ja-two.iwiki.icu/w/index.php?title=オープンソースソフトウェア&oldid=67666773」から取得