オープンソースソフトウェア
オープンソースソフトウェア︵英: Open Source Software、略称: OSS︶とは、利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称である[1]。
解説[編集]
1950年代のコンピュータ上でソフトウェアが稼働するようになった頃、学術機関・研究機関の間でソフトウェアのソースコードはパブリックドメインで共有されていた。1970年代前後よりソフトウェア開発は徐々に商業となり、ソフトウェアの再頒布を禁止するプロプライエタリソフトウェア、ソースコードを非公開とするクローズドソースの文化ができあがった[2]。1980年代より利用者がソフトウェアのソースコードを自由に利用できないことをストレスに感じた人たちはフリーソフトウェア財団やオープンソース・イニシアティブを立ち上げ、ソースコードを一般に公開してソフトウェアの利用者による利用・修正・再頒布を許すことによるソフトウェア開発の発展を提唱し、オープンソースソフトウェアの文化ができあがった。 一般に使われている基準として、オープンソース・イニシアティブの提唱するオープンソースおよびフリーソフトウェア財団の提唱する自由ソフトウェアのカテゴリに含まれるソフトウェアがオープンソースソフトウェアである[1][3]。ソフトウェアのソースコードが公開されていても、その利用・修正・再頒布が有償である、商用利用は禁止されるなどの制限がある場合は、オープンソースソフトウェアではなくプロプライエタリソフトウェアやシェアードソース・ソフトウェアと呼ばれる[4]。オープンソースソフトウェアに課すソフトウェアライセンスはオープンソースライセンスと呼ばれ、管理団体やコミュニティによってある程度精査されており、GNU GPL・Apache-2.0・MITなどの既存の汎用的なライセンスを利用することが推奨されている[5][6]。 類似した概念にオープンソースハードウェア・オープンシステム・オープンコンテントなどがある。歴史[編集]
詳細は「オープンソースソフトウェアの歴史」を参照
1950年代のコンピュータ上でソフトウェアが稼働するようになった頃、学術機関・研究機関の間でソフトウェアとソースコードはパブリックドメインで共有され、ソフトウェアのソースコードを利用者が共有・修正・再頒布する文化は存在していた。1970年代以降、ソフトウェア開発は徐々に商業となり、ソフトウェアの頒布に制約を付与するプロプライエタリソフトウェア、ソースコードを非公開とするクローズドソースの文化ができあがった[2]。
1980年代序盤、リチャード・ストールマンは利用者がソフトウェアのソースコードを自由に利用できないことは非道徳であると考えて自由ソフトウェアを提唱した[7]。リチャード・ストールマンはフリーソフトウェアだけで構成されたオペレーティングシステムを開発するGNUプロジェクトを立ち上げ、自由ソフトウェア運動を促進するフリーソフトウェア財団を設立した。フリーソフトウェアはソフトウェア利用者のソフトウェアを実行・複製・配布・研究・変更・改良する自由を守るためソースコードの公開を求め、コピーレフト・ライセンスを用いてソースコード共有文化のコモンズ︵ローカル・コモンズ︶の輪を広げた。
1990年代末、ネットスケープ・コミュニケーションズはエリック・レイモンドの著書The Cathedral and the Bazaarに感化されてクローズドソースで開発していたMozilla Application Suiteをフリーソフトウェアとしてソースコードを公開した。エリック・レイモンドやブルース・ペレンズ、リーナス・トーバルズたちはソースコードの共有は望ましいが、自由ソフトウェア運動のプロプライエタリソフトウェアへの攻撃的姿勢とコピーレフトの閉鎖性は企業には受け入れられ辛いと考えた[8]。そこでソースコードの共有文化の再ブランドを検討し、ソースコードを公開・共有したソフトウェア開発の実利的なメリットを主観にしたオープンソースを提唱し、オープンソース・イニシアティブを設立した[9][10]。オープンソースの開発手法はホビイストやハッカーの非商用ソフトウェアだけでなく企業・商用のプロプライエタリソフトウェアにも利用され、ソフトウェア開発の分野で広く利用されるようになった。
2000年代以降、オープンソースは一般的な用語となり、オープンソースソフトウェアとして様々なソフトウェア、例えばLAMP・Ruby on Railsなどのウェブプラットフォーム、Linux・FreeBSD・Androidなどのオペレーティングシステム、OpenCVなどのライブラリ、といったものが開発された。Javaのソフトウェア開発キットであるOpenJDKや、.NET仕様のオープン実装であるMonoや.NET Coreなど、もともとクローズドソースやプロプライエタリだったソフトウェアがオープンソース化されたり、オープンソース版の実装がサードパーティの企業やコミュニティによって別途開発されたりしているものもある。TypeScriptやGoなど、公式の処理系︵コンパイラやプログラミングツール︶がオープンソースとなっているプログラミング言語も存在する。マイクロソフトによる従来のC#/Visual Basic .NETのコンパイラ (csc/vbc) はプロプライエタリだったが、のちにオープンソース版のRoslynコンパイラが開発された。処理系がオープンソース化されるプログラミング言語は、言語仕様がオープン標準になっていたり、ISOやEcmaといった団体によって標準化されていたりするものも多い。
定義[編集]
オープンソースソフトウェアは、ソフトウェアのソースコードが一般に公開され、商用および非商用の目的を問わずソースコードの利用・修正・再頒布が可能なソフトウェアと定義される[1]。オープンソースライセンスが課せられたソフトウェアやパブリックドメインに置かれたソースコードとそのソフトウェアなどがそれに当たる。 アメリカ国防総省はオープンソースソフトウェアを﹁可読性のあるコードが利用・学習・再利用・修正・改善・再頒布が可能であるソフトウェア﹂と定義している[1]。ソースコードが開示されていても商用を目的として提供されるソフトウェアはオープンソースソフトウェアとは区分せず、プロプライエタリソフトウェアやクローズドソース・ソフトウェアに区分している[4]。 オープンソース・イニシアティブは﹁オープンソースの定義﹂に従ったソフトウェアをオープンソースのソフトウェアと定義している[11]。オープンソースの定義は単純にソースコードへのアクセスが開かれていることを定義するものではなく、オープンソースのソフトウェアは利用者がそのソースコードを商用および非商用の目的を問わず利用・修正・頒布することを許し、それを利用する個人や団体の努力や利益を遮ることがないことを定義している[12]。オープンソース・イニシアティブはオープンソースライセンスというライセンスカテゴリを管理しており[5]、そのオープンソースの定義に準拠したライセンスのみをオープンソースライセンスとして承認している。オープンソースソフトウェアはオープンソースライセンスが課せられたソフトウェアであると言い換えることが出来る[13]。 フリーソフトウェア財団はオープンソースソフトウェアという単語についての定義は行なっていないが、類似した概念としてフリーソフトウェア︵フリーは無料ではなく自由という意味︶という単語を﹁自由ソフトウェアの定義﹂において定義している[14]。フリーソフトウェアは利用者の自由とコミュニティに敬意を払い、利用者にソフトウェアを実行・複製・配布・学習・改善する自由を提供する。その自由を提供するために、フリーソフトウェアのソースコードは一般に公開され、利用者はソフトウェアのソースコードを自由に利用・修正・再配布することが可能である。フリーソフトウェア財団の代表であるリチャード・ストールマンはオープンソース・イニシアティブの定義するオープンソースという単語およびその活動を否定的に発言しており[15]、同財団ではオープンソースソフトウェアという単語の定義および意義については消極的である。 日本の総務省はオープンソース・イニシアティブのオープンソースの定義を満たすソフトウェアをオープンソースソフトウェアを定義するものとして参照している[16]。 まとめると、以下の条件がOSSとして備わっていなければならない。 ●1.自由な再頒布ができること ●2.ソースコードを入手できること ●3.派生物が存在でき、派生物に同じライセンスを適用できること ●4.差分情報の配布を認める場合には、同一性の保持を要求してもかまわない ●5.個人やグループを差別しないこと ●6.利用する分野を差別しないこと ●7.再配布において追加ライセンスを必要としないこと ●8.特定製品に依存しないこと ●9.同じ媒体で配布される他のソフトウェアを制限しないこと ●10.技術的な中立を保っていること標準化団体[編集]
広義のオープンソースソフトウェア︵オープンソースのソフトウェアやフリーソフトウェア︶の分野における標準化団体はオープンソース・イニシアティブとフリーソフトウェア財団が主要な団体である。それに加えて各専門分野において、 Linux分野ではLinux Foundation、デスクトップ環境分野ではfreedesktop.org、携帯機器分野ではOpen Handset Allianceなどの組織がある。オープンソース・イニシアティブ[編集]
詳細は「オープンソース・イニシアティブ」を参照
オープンソース・イニシアティブは、1998年2月にブルース・ペレンズとエリック・レイモンドにより設立されたオープンソースのソフトウェア︵英: open-source software︶の発展・促進を目的に活動している非営利団体である。
オープンソース・イニシアティブは、ソースコードの利用・修正・再頒布を可能とするソースコードの共有文化によるソフトウェア開発の発展のため、オープンソースのソフトウェアをオープンソースの定義において定義し、オープンソースのソフトウェアを利用者の商用・非商用などの目的を問わず利用しやすい文化の構築に貢献している。オープンソースのソフトウェアに適したソフトウェアライセンスをライセンスレビューを通して選定し、オープンソースのライセンスとして承認している。オープンソースのライセンスのリストを逐次更新し、より新しく適切なライセンスの推奨や、時代遅れとなり不適切となったライセンスの非推奨など、オープンソースライセンスの管理をしている。
オープンソース・イニシアティブはオープンソースの用語を用いる際はオープンソースの定義に準拠することを求めている。オープンソースの商標については、アメリカでは1999年6月に﹁Open Source﹂の商標登録を求めたが、Open Sourceは一般的な用語であり特定団体が権利を持つ商標にはならないと判断されている[17]。これについて、オープンソース・イニシアティブはOpen Sourceが一般的な用語として周知されたことを歓迎する立場を取っている。なお、日本では2002年3月にオープンソースグループ・ジャパンが﹁オープンソース・OPENSOURCE﹂を商標登録︵第4553488号︶している[18][19]。日本での用語の利用に際しては特に許諾や制限は求められないが、オープンソースの定義に準拠した扱いで利用されることが望まれている。
オープンソース・イニシアティブは、2006年にSugarCRMが自社のことを﹁Commercial Open Source﹂と表現し、オープンソースのライセンスとして承認していないライセンスをソフトウェアに課していたことを非難した[20][21]。後に、SugarCRMはライセンスをオープンソースのライセンスとして承認されているGPLv3に切り替えている[22]。
フリーソフトウェア財団[編集]
詳細は「フリーソフトウェア財団」を参照
フリーソフトウェア財団は、1985年10月4日にリチャード・ストールマンにより設立された自由ソフトウェア︵英: free software︶の発展・促進を目的に活動している非営利団体である。
フリーソフトウェア財団はソフトウェアの利用者の作成、頒布、改変する自由をユーザーに広く遍く推し進めることを狙い、フリーソフトウェアを自由ソフトウェアの定義において定義し、コピーレフトを基本とする社会運動の支援を目標に掲げている。コピーレフトは利用者がソフトウェアを実行・複製・配布・研究・変更・改良する自由を守り、その利用者の自由を派生ソフトウェアに展開してフリーソフトウェアのコモンズの輪を広げる概念である。フリーソフトウェア財団はコピーレフトの概念をGPLやAGPLなどのソフトウェアライセンスとして実装し、同ライセンスの利用を推進している。
フリーソフトウェア財団は利用者がソフトウェアを実行・複製・配布・研究・変更・改良する自由を尊重し、その自由であるソフトウェアを啓蒙する社会運動として自由ソフトウェア運動を行っている。フリーソフトウェア運動ではフリー︵自由︶を尊重するソフトウェアやファイルフォーマットをGNU宣言・フリーソフトウェアの歌・PlayOggなどを通して啓蒙している。利用者の自由を妨げるDRMやソフトウェア特許についてはDefective by DesignやTiVo化と表現して批判している。また、フリーソフトウェア財団はフリーソフトウェアとオープンソースのソフトウェアは異なるものであり、オープンソースはフリーソフトウェアの理念の的を外しているとして、広義のオープンソースソフトウェアのような表現ではなく、フリーソフトウェアとオープンソースソフトウェア、FLOSS (Free/Libre and Open Source Software) などの表現をすることを求めている。
フリーソフトウェア財団はフリーソフトウェアのみで構成されるオペレーティングシステムの開発、およびフリーソフトウェアライセンスの実装とレビューをするプロジェクトとしてGNUプロジェクトを遂行している。
その他の団体[編集]
freedesktop.orgは、2000年にハヴォック・ペニントンにより設立されたUnix系システムのデスクトップ環境の相互運用性の向上と共通基盤技術の整備を目指した非営利団体である[23]。GNOME・KDE・XfceなどのX11上のデスクトップ環境のユーザビリティの差異の問題を明確化し、共通化の方向性を模索・助力をしている。また、X.Org Server・D-BUS・HALなどの基礎基盤のリファレンス実装を開発し、各ソフトウェアでの実装の差異の削減を図っている。 Linux Foundationは、2007年1月にOpen Source Development LabsとFree Standards Groupを統合する形で設立されたLinuxオペレーティングシステムの普及をサポートする非営利のコンソーシアムである[24]。Linuxのカーネルを含む開発とそのオペレーティングシステムの成長と普及のための活動を実施している。Linuxの原作者であり開発の第一人者であるリーナス・トーバルズは2018年現在、Linux Foundationにフルタイムで勤務している[25]。 Open Handset Allianceは、2007年11月にGoogleを中心として設立された携帯機器の共通環境の開発を推進するために組織されたアライアンス︵コンソーシアム︶である[26]。通信キャリア・半導体メーカー・携帯電話メーカー・ソフトウェアベンダーなど携帯機器分野全般の企業・団体が参画している[27]。Open Handset Allianceはオープンソースの携帯電話のフラグシップ・ソフトウェアとしてAndroidを開発し、Android 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]。
オープンソースライセンスのライセンスの互換性、矢印が一方的な互換 性を表す[54]
ソフトウェアライセンスにはライセンスの互換性がある。異なるライセンスはそれぞれが定める誓約の下にソフトウェアとソースコードを利用することが出来るが、ライセンスによっては自身のソフトウェアの利用に対する誓約だけではなく併用するソフトウェアに対して求める誓約を含む場合があり、その際に複数のソフトウェアのライセンスに互換性がない場合はソフトウェアを併用することが不可能となる。例えば、GNU General Public Licenseは併用するソフトウェアに同一のライセンスを適用することを求めているため、同ライセンスと商用ソフトウェアのクローズドソースを求めるライセンスは併用出来ない。フリーソフトウェア財団はGPLのコピーレフト誓約違反に対して幾度も訴訟を起こしている。
2000年代前半、オープンソースソフトウェアのライセンスは多数の独自ライセンスが策定され、よく似た条文で一部分だけ異なるという有象無象のライセンスがいたずらに作られていったことを問題視し、その事象はライセンスの氾濫と呼ばれ批判の対象となった[55]。ライセンスの氾濫はライセンス製作者の虚栄心を満たすだけの無害なものではなく、オープンソースソフトウェアに課せられたライセンスの内容を精査しなければならない利用者を疲弊させる有害なものであった。オープンソース・イニシアティブは2006年にこの問題を解決するためライセンス氾濫問題プロジェクト (License Proliferation Project) を立ち上げ[56]、ライセンスレビューを通して承認ライセンスを選定することでライセンスの氾濫を抑えた歴史がある[57]。ライセンスの氾濫を再発させないため、オープンソースソフトウェアのライセンスは既存のオープンソースライセンスを採用することが推奨される[5][6]。ライセンスの作成者は新規ライセンスの必要性について慎重な検討を経て策定に至り[58]、ライセンスを承認する団体は新規のライセンスが既存のライセンスと本質的な差異がない場合は承認しない判断を下している[59]。
CC BY-SAとパブリックドメインを合わせた時にSA属性によりC C BY-SAが強制されるライセンス感染の例
ライセンスの継承条文を伴うオープンソースライセンスが課せられたソフトウェアは、その継承条文に基づき、ソフトウェアのソースコードを利用、修正したソフトウェアのソフトウェアライセンスを同等条件のものとするよう縛る。このライセンスの縛りはソースコードの二次利用、三次利用と伝播し、ライセンスがウイルスのように感染していくことからウイルス性ライセンス︵ライセンス感染︶と呼ばれる[60]。ライセンス感染するライセンスの例としては、GPL (コピーレフト条文)やCC BY-SA (SA条項)がある。ライセンス感染の影響は元となったソフトウェアライセンスの内容に依るが、GNU GPLのコピーレフト条項のようにソースコードの公開を義務とするものや[34]、CC BY-SAのSA条項ように同等条件のライセンスを強制するだけ︵ソースコードの公開を求めるかどうかは別条文に依る︶のものがある[61]。
パブリックドメインによる著作権の放棄は著作権法の下に完全に認められたという実績︵判決︶は存在しておらず、法的な判断が不明瞭である[62]。ソースコード作成者が著作権を放棄する意図でパブリックドメイン以下で公開していたソースコードに対して、ソースコード作成者が考えを変えて著作権の保持を主張してソースコードの二次利用者を訴えた場合に、サブマリン特許のように見解を翻して権利を行使することの是非という道徳的な観点は別として、著作権の放棄の有効性について著作権法の下にどのような判断がなされるのか明確になっていない。つまり、パブリックドメインはソースコード作成者の当初の意図に反して著作権の放棄はできておらず、著作権の保持を根拠にしたソースコードの二次利用者に対する訴えは有効であるとされる可能性がある。そのような不確定性のため、オープンソース・イニシアティブはパブリックドメインに相当するCC0を有効なオープンソースライセンスとして承認していない[63]。一方で、フリーソフトウェア財団はCC0を有効なフリーソフトウェアライセンスとして承認している[64]。
誓約[編集]
オープンソースライセンスは、ライセンサー︵作者︶の定めた誓約に従う範囲でライセンシー︵利用者︶にソフトウェアとソースコードの自由な利用を認める。オープンソースソフトウェアの性質上、ソフトウェアやその二次著作物は元の作者でも制御しきれない形で頒布されるため、多くのライセンスでソフトウェアおよびソースコードの利用に際して﹁無保証 (NO 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]。Fedoraの公式パッケージに含まれるソフトウェアはこの一覧にあるソフトウェアライセンスが課せられたものであり、これらのライセンスはフリーソフトウェア財団、オープンソース・イニシアティブおよびRed Hat法務担当が公認したものである[3]。ライセンスの検証はFedoraのメーリングリストで公に検証されている[52]。ただし、コンフィデンシャルな情報を送ることや、ソースコードについての法的な助言を求めるために利用してはならないし、メーリングリストの参加者が法律家や弁護士であることを仮定するべきではない。 DebianプロジェクトはDebianフリーソフトウェアガイドライン (DFSG) に基づいたソフトウェアライセンスの一覧を管理している[53]。Debianの公式パッケージに含まれるソフトウェアは原則としてDebianフリーソフトウェアガイドラインに準拠したソフトウェアライセンスが課せられたものである。Debianフリーソフトウェアガイドラインはオープンソースソフトウェアの定義に符号するものであり、DFSG準拠ライセンスはオープンソースソフトウェアに課すソフトウェアライセンスの一例として参考にできる。検討課題[編集]
OSS開発[編集]
開発手法[編集]
詳細は「オープンソースソフトウェア開発」を参照
オープンソースソフトウェアの利用者は共同開発者のように扱われる。利用者はソフトウェアのソースコードにアクセスすることができ、ソフトウェアへの機能追加、ソースコードの修正、バグの報告、ドキュメントの提出が可能である。利用者はそれらをソフトウェア開発のメインストリームに反映することができるし、利用者が望むのであれば自身の製品として頒布することもできる。オープンソースソフトウェアで複数の共同開発者を持つことは、ソフトウェアの発展を手助けする。リーナスの法則では、﹁十分な目玉を与えられることで、全てのバグは浅くなる﹂と述べている[65]。このことは、多くの利用者がソースコードを眺めれば、結局は全てのバグを発見しそれらの修正方法が提案される、ということを意味している。
オープンソースソフトウェア開発に使われる開発ツールはそれもまたオープンソースソフトウェアであることがある。オープンソースソフトウェア開発でオープンソースソフトウェアの開発ツールである利点は、オープンソースソフトウェアのライブラリの一部にオープンソースソフトウェアを利用する利点と同じく、その開発ツールがオープンソースソフトウェアであることによる利便性、安全性、信頼性を享受できることである。
モジュール分解[編集]
オープンソースソフトウェアの機能は幾つもの細分化されたモジュールで構成されている。例えばコンパイラでは、字句解析、構文解析、意味解析、最適化[要曖昧さ回避]、コード生成などの機能を持ち、それらはモジュールとして一つのソフトウェアに内包される。LAMPのようなSaaSでは、Linux、Apache、MySQL、PHPなどの複数のオープンソースソフトウェアの組み合わせで、一つのサービスを提供している。細分化されたモジュールはそれぞれの機能を得意とする利用者および開発者により改善がもたらされ、より良いソフトウェアへの発展を手助けする。 オープンソースソフトウェアのアーキテクチャは利用者および開発者により決定され、その戦略的決定を利用者の意見や他の多くの要因に依存する。長期に渡って固定された具体的な仕様や開発計画に依らず、複数の要因による柔軟なアーキテクチャ決定を通して仕様や開発計画を決定する。オープンソースソフトウェアの利用者は各個により良いアーキテクチャを決定する権利を持ち、メインストリームのソフトウェアおよび派生したソフトウェアのアーキテクチャとしてそれを採用することができる。ソースコード管理[編集]
「OSSホスティングサービスの比較」も参照
ソフトウェアの開発者が複数名からなり、修正が頻繁になされるオープンソースソフトウェア開発では、ソースコードの修正内容、修正履歴の閲覧、そして修正の差し戻しを助けるためソースコードリポジトリにバージョン管理システムが用いられる。
ソースコードリポジトリはソフトウェアのソースコード一式を保存し、ソースコードの変更者、変更時刻、変更時コメントを残す。ソースコードの変更はユニークなID︵連番の数字やハッシュ値︶が割り当てられ、変更の記録を遡って特定して変更内容を確認することができる。ソースコードリポジトリはローカルファイルシステムに置くものや、インターネットを介したネットワーク上に置くものもある。オープンソースソフトウェアの利用者はソースコードリポジトリをフォークして独自のソースコードリポジトリを構築し、そのソースコードリポジトリ上でオープンソースソフトウェアを利用、修正、再頒布してより良いオープンソースソフトウェアを提供することができる。
ソースコードリポジトリをホスティングサービスとして提供するウェブサービスには、SourceForge、GitHub、Bitbucketなどがある。それらのウェブサービスは一般にソースコードが公開されるバージョン管理されたソースコードリポジトリを提供し、オープンソースソフトウェアの開発を支援している。それらのリポジトリはソースコードの閲覧、フォークは二次開発者が自由に行えるが、メインストリームのソースコードリポジトリに置かれたソースコード修正は主管開発者やその権限が与えられた開発者のみに許されており、不適切なソースコード修正がメインストリームのソースコードリポジトリに反映されて品質を損なうことを防いでいる。
オープンソースソフトウェアの開発者間のコミュニケーションはメーリングリスト、IRC、インスタントメッセージ、バグトラッキングシステムなどのインターネットコミュニケーションが用いられる。これらのコミュニケーションツールはオープンソースソフトウェアのソースコードの実装についてだけではなく、オープンソースソフトウェアの開発に関わるプロジェクトの方針、設計の検討、テストの実施、不具合の報告などの多岐に渡った話題のためのコミュニケーションに利用される。
コミュニケーションツールはプロジェクトの話題に限定したIRC、Skype、Slackなどのチャット、ソースコードリポジトリ、バグトラッキングシステム、ウィキを統合したGitHub、Bitbucketなどのホスティングサービス、プロジェクトやソフトウェアを限定しない雑多なStack Overflow、redditなどのコミュニティサイトが存在する。
ブランチとフォーク[編集]
「ブランチ (ソフトウェア)」および「フォーク (ソフトウェア開発)」も参照
オープンソースソフトウェアのリリースは複数の公式バージョンを配布している。一つは「安定版」で、機能が安定している、致命的なバグがない、実行環境への最適化がなされているなどの、利用者がそのソフトウェアを定常的に利用しても大きな問題が発生することが想定されていないバージョンである。一つは「検証版」で、試験的な機能が実装されている、バグが存在している、幾つかの環境でのみ動作するなどの、利用者がソフトウェアの開発および検証を目的として用いるバージョンである。安定版は検証版より長い間隔でリリースされることもあり、幾つかの検証版のリリースを経て安定版がリリースされることがある。検証版はアルファ版、ベータ版、RC（Release Candidate、リリース候補）版などの名称を持つ。オープンソースソフトウェアの特性上、安定版ですべての機能が完成して開発が終了するものを示すものではなく、安定版もまた継続してリリースされる。
オープンソースソフトウェアのリリースサイクルは短い間隔でリリースされる。ソフトウェアのソースコードが公開されていることにより、利用者はスナップショットのソースコードでソフトウェアをビルドすることが可能で、そのソフトウェアを非公式リリースとして頒布することもできる。短い間隔でのリリースを実現するため、継続的インテグレーションツールを用いてナイトリー版のビルドをリリースするソフトウェアもある。
プロジェクト[編集]
多くのプロジェクト・ソフトウェアがオープンソースソフトウェアのソフトウェアを開発している。1980年代にプロプライエタリソフトウェア、クローズドソースに移行したオペレーティングシステム・プログラミング言語コンパイラも2000年代移行にオープンソースソフトウェアとして開発・普及している。
GNUプロジェクトはフリーソフトウェアのGNUユーティリティとしてLinux・Windows・macOS・その他OSで動作するユーティリティソフトウェアを開発している。
リーナス・トーバルズが1980年代から開発しているLinuxはオープンソースソフトウェアのオペレーティングシステムとして広く使われている。Linuxは様々なベンダー・ユーザーにより派生したソフトウェアが開発されLinuxディストリビューションの総称で呼ばれている。2007年以降、LinuxはLinux Foundationが開発主体となった。
Apacheソフトウェア財団はApache HTTP Serverを代表にC/C++のソフトウェア・ライブラリ、Javaのソフトウェア・ライブラリを開発している。また、Sun Microsystemsが開発していたオフィスソフトウェアの後継Apache OpenOfficeや、Adobeが開発していたFlashビルドツールの後継Apache Flex、HTML5アプリケーションプラットフォームの後継Apache Cordovaなど、企業が開発していたソフトウェアの後継メンテナンスも行っている。
カノニカルは2004年にユーザビリティの高いLinuxディストリビューションとなることを目標としてDebianから派生してUbuntuを開発した[66]。Googleは2009年にウェブブラウザChromeをベースにしたChrome OSを開発した[67]。
Googleは2012年3月にマルチコアのマシンでプログラマが意識することなくマルチスレッドを最適化して実行するGo言語を発表した[68]。Mozilla Foundationは2012年1月に速度、安全性、平行性を言語仕様特徴として謳うシステムプログラミング向けのRust言語を発表した[69]。Appleは2014年6月にiOS、macOS用プログラミング言語のObjective-Cの文法をモダンにリフォーマットしたSwiftを発表した[70][71]。
ビジネスモデル[編集]
詳細は「オープンソースソフトウェアのビジネスモデル」を参照
多くのソフトウェアベンダー・ハードウェアベンダー・ソフトウェアライセンサーはオープンソースソフトウェアのフレームワーク・モジュール・ライブラリを彼らの製品に利用している[72][73]。一方で、オープンソースソフトウェア開発はソフトウェアのソースコードを共有・利用・修正・再頒布を認めるという特性から収益を得るビジネスモデルを成立させることが難しく、様々な手法でのビジネスモデルの確立が試行されている[74]。
オープンソースソフトウェアをビジネスで利用するメリットは、開発者にとってはソフトウェアのソースコードを公開し、利用者を増やすことで市場シェアを伸ばすことができる。利用者にとっては無償で利用できる、目的に併せて改変できる、コミュニティによって新しいバグが即座に修正されるという利点がある。
ビジネスモデルの例として、デュアルライセンスやサポートサービスは、ソフトウェアのライセンスに複数の選択肢を与え、基本機能のソフトウェアや過去のバージョンのソフトウェアのソースコードはオープンソースライセンスで開示し、より良い機能のソフトウェアやテクニカルサポートを有償で提供する[75][76]。クラウドファンディングや投資組織は、ソフトウェア開発の前に開発資金を確保して、その資金をもってソフトウェア開発プロジェクトの運営を行い、完成したソフトウェアの販売やプロダクトの権利譲渡、先行投資アドバンテージなどにより資金援助元へ還元する[77][78]。有償コンテンツ・拡張機能の販売は、ソフトウェア本体は無償のオープンソースソフトウェアとして利用者にリリースし、ソフトウェアを利用するためのコンテンツやより便利にするための拡張機能を有償販売する[79][80]。ドネーションウェア・アドウェアは、ソフトウェアは完全に無償で全ての機能を利用可能とした上で、寄付や広告による収益を得る[81][82]。
オープンソース文化・運動[編集]
OSS啓発本・映画[編集]
The Cathedral and the Bazaar︵1999年、O'Reilly Media、ISBN 978-1565927247︶は、エリック・レイモンドによるオープンソースソフトウェア開発のエッセイである[83]。同著書ではGNUプロジェクトのトップダウン開発手法をカテドラル方式、Linux・Fetchmailのボトムアップ開発手法をバザール方式と評して、バザール方式のソースコードを公開・共有したソフトウェア開発の有効性について述べている。エッセイの主題はバザール方式におけるエリック・レイモンドが提起したリーナスの法則﹁十分な目玉があれば、全てのバグは洗い出される﹂という点で、オープンソースソフトウェアでは利用者を共同開発者と捉えて、利用者と共にソフトウェア開発を進めることでより良いソフトウェアを開発することができると述べている。 Open Sources: Voices from the Open Source Revolution︵1999年、O'Reilly Media、ISBN 1-56592-582-3︶、Open Sources 2.0︵2005年、O'Reilly Media、ISBN 0-596-00802-3︶は、オープンソースソフトウェア分野の著名人のエッセイをまとめた書籍である[84][85]。マーシャル・カーク・マキュージック、マイケル・ティーマン、リーナス・トーバルズ、ポール・ヴィクシー、ラリー・ウォール、イアン・マードック、ラリー・サンガー、ティム・オライリーなどが寄稿している。 Revolution OS︵2001年︶は、1970年代末から約20年間のGNUプロジェクト・Linux・フリーソフトウェア・オープンソースの歴史をまとめたドキュメンタリー映画である[86]。オープンソースソフトウェア分野の著名人のリチャード・ストールマン、リーナス・トーバルズ、エリック・レイモンド、ブルース・ペレンズが特別出演している。自由ソフトウェア運動[編集]
詳細は「自由ソフトウェア運動」を参照
フリーソフトウェア運動︵英: Free Software Movement︶は、フリーソフトウェア財団を主体にした自由ソフトウェアの利用者の自由を尊重する思想を啓蒙する社会運動である[87]。フリーソフトウェア運動はGNU宣言を代表として、自由ソフトウェアの定義・コピーレフト・Defective by Design・BadVista・TiVo化批判・フリーソフトウェアの歌など、理念的なものから他者批判的なもの、ユーモラス的なものまで多種多様である。
フリーソフトウェア運動の理念の1つとして、フリーソフトウェアとオープンソースは別物でありオープンソースソフトウェアの名の基にフリーソフトウェアを用いるのは不適切であるという考えがあり[87]、フリーソフトウェア運動家はフリーソフトウェアとオープンソースのソフトウェアの総称を﹁OSS︵オープンソースソフトウェア︶﹂ではなく﹁FLOSS︵Free/Libre and Open Source Software︶﹂もしくは﹁フリーソフトウェアとオープンソースソフトウェア﹂と明確に別けて呼称する。
他のソフトウェアモデルとの比較[編集]
自由ソフトウェア[編集]
詳細は「自由ソフトウェア」を参照
自由ソフトウェアは、広義のオープンソースソフトウェアの定義においてオープンソースソフトウェアの部分集合であるが、オープンソースソフトウェアと自由ソフトウェアは根源的なコンセプトが異なる。オープンソースソフトウェア︵オープンソース︶がソフトウェアのソースコードを公開・共有する﹁開発の方法論﹂である一方で、自由ソフトウェアは利用者の自由︵実行・研究・変更・コピーを変更ありまたはなしで再配布するという自由︶を尊重する﹁社会運動﹂である[15][88]。コンセプトが開発の方法論と社会運動と異なるため、本来は並列に比較するようなものではない。
その上で、自由ソフトウェアという社会運動のための一つのツールとしてオープンソースソフトウェアという開発の方法論を用いようとした場合、オープンソースソフトウェアは利用者の自由を尊重するのに機能不十分なツールである。この機能不十分な点を比較した場合、オープンソースソフトウェアが許容する幾つかのライセンスは不適切であり、自由ソフトウェアはコピーレフトに代表されるような利用者の自由を尊重するための条項が含まれたライセンスを推奨している[6]。
機能不十分な例としては、オープンソース・イニシアティブがオープンソースライセンスとして承認しているSybase Open Watcom Public Licenseは利用者が修正したソースコードから作られたソフトウェアを個人的な用途で公開した場合にはソースコードの公開を必要としていない。これは修正されたソフトウェアは一般に公開されているにもかかわらず、そのソフトウェアのソースコードは非公開となっており、二次利用者の自由を妨げている[89]。もう一つの例としては、オープンソースソフトウェアは利用者がソフトウェアもしくはそのソフトウェアが動作するハードウェアをTiVo化 (tivoization) することを許容するライセンスの存在を許し、二次利用者の自由を妨げることを否定していない[90][91]。
ソースアベイラブル・ソフトウェア[編集]
詳細は「ソースアベイラブル・ソフトウェア」を参照
ソースコードは開示しているという条件だけを満たしている物をソースアベイラブル・ソフトウェアと呼ぶ。ソフトウェアの範囲はオープンソースソフトウェアよりも広い。営利利用に制限がかかっていたり、改変禁止だったりするとソースアベイラブルとなる。
シェアードソースソフトウェア[編集]
詳細は「シェアードソース」を参照
シェアードソースソフトウェアは、ソースコードを開示し、利用者にソースコードおよびソフトウェアの動作の参照およびデバッグのための利用を認めている[92]。ソフトウェアのソースコードの共有を主な観点としており、営利団体の商業ソフトウェアのソースコードを協力機関︵研究機関・大学・利用者︶に開示する用途で利用されている。
オープンソースソフトウェアとシェアードソースソフトウェアの違いは、シェアードソースソフトウェアはソースコードの修正、再頒布に対して制約的である所である。利用者に対してソースコードの参照、デバッグを目的とした利用は認めているが、修正したソースコードそのものや、修正したソースコードから生成されるソフトウェアの頒布は私的使用に限って認めるなどの制約を伴う場合がある。また、シェアードソースソフトウェアでは商用目的でソースコードを利用︵閲覧︶することが出来ない場合がある。それらの制約はシェアードソースソフトウェアに課せられるライセンスの内容に依る。
マイクロソフトは2001年より自社ソフトウェア製品のためにシェアードソースイニシアティブを立ち上げている[93]。マイクロソフトのシェアードソースライセンスは幾つかの種類があり、制約の緩やかなライセンスはオープンソースイニシアティブ公認のオープンソースライセンスであるが[94]、制約の厳しいライセンスは同社との提携契約の上でソースコードの参照のみが許されるプロプライエタリライセンスである。Sony Computer Entertainment of America (SCEA) は2005年にPlayStationのソフトウェアのためにSCEA Shared Source Licenseを設けていた[95][96]。
プロプライエタリソフトウェア[編集]
詳細は「プロプライエタリソフトウェア」を参照
プロプライエタリソフトウェアは、ソフトウェアの利用・頒布に制限を課し、場合によってはその制限を解除することで利益を得るソフトウェアの総称であり、オープンソースソフトウェアとの違いは利用・修正・再頒布に制限を設ける・設けない点が主な違いである[4]。
プロプライエタリソフトウェアのソースコードの公開・利用の可否に明確な線引きはないが、ソースコードを開示していてもソースコードの入手が有償である、ソースコードが非公開︵クローズドソース︶であるなど、基本的にソフトウェアの利用者がソースコードを自由に利用することは出来ない。ソフトウェアのソースコードを非商用目的に限り利用・修正・再頒布を認め、商用目的での利用・修正・頒布を認めない場合もオープンソースソフトウェアではなくプロプライエタリソフトウェアと呼ばれる[4]。
個人や組織がオープンソースソフトウェアを選ぶ主要な4つの理由に安価・情報セキュリティ・ベンダーロックインでない・より良い品質がある[97]。ソフトウェア開発企業は必ずしもソフトウェアの販売に依存しないため、相対的にプロプライエタリソフトウェアの必要性は低くなってきている[98]。Novellのような企業は、製品の一部をオープンソースソフトウェアに切り替えているため、継続的にオープンソースソフトウェア上でのビジネスモデルを思案している[99]。
批評と論争[編集]
ソフトウェアの品質[編集]
多くの主張者が、多くの人間がソースコードを閲覧・編集・変更するため、オープンソースソフトウェアはソースコードが非公開のプロプライエタリソフトウェアに比べて本質的により安全であると主張している[100]。オープンソースソフトウェアであるLinuxのソースコードは1000行あたり0.17個のバグがある一方で、プロプライエタリソフトウェアのソースコードは一般的に1000行あたり20–30個のバグがある[101]。 コベリティは2014年にCoverity Scan Open Source 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]。DebianプロジェクトはGNU/Linuxの呼称を受け入れており[106]、公式なディストリビューションの名称としてDebian GNU/Linuxと名乗っている。
Linux名称支持者は、Linuxが既に十分に一般的な通称となっており名称を変更する必要性を感じていない[107]。明示的な理由を挙げているエリック・レイモンドは、ジャーゴンファイルのLinuxの節でGNU/Linux名称は縄張り争いと承認欲が根元にあり、リチャード・ストールマンとその近しい友人以外には受け入れるのは難しいと述べている[108]。Linuxの開発者リーナス・トーバルズは、Revolution 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の知的財産権を侵害しているという疑惑は払拭されている。
オープンソースから派生した様々な用語
オープンソースソフトウェアという用語がソフトウェアおよびそのソースコードのみに適用される一方で、ソースコードを伴うソフトウェア以外の事柄の利用者にその事柄の利用、修正、再頒布を認める場合は、﹁オープンソース﹂を冠したオープンソースハードウェア、オープンソースジャーナリズム、オープンソースガバナンス、オープンソースエコロジーのような用語が存在する。ソースコードは存在しないがその事柄の利用、修正、頒布を認める場合は、﹁オープン﹂を冠したオープンアクセス、オープンシステム、オープンコンテントのような用語が存在する。オープンソースおよびオープンを冠していても、オープンソースソフトウェアの定義と同じくその事柄の利用・修正・再頒布を認めているかどうかは各用語によって異なるため、それらの用語の意味するところについてはそれぞれ注意して扱うべきである。
派生した用語[編集]
FLOSS[編集]
FLOSS (Free/Libre and Open Source Software) は、フリーソフトウェアとオープンソースの複合語である[121]。これは、フリーソフトウェア財団とオープンソース・イニシアティブが根源的な部分で活動理念を異にしており、フリーソフトウェア財団の定義するフリーソフトウェアとオープンソース・イニシアティブの定義するオープンソースは別物で区別しなければならないというリチャード・ストールマンの考えに基づいている[15]。ソースコードとソフトウェアの利用、修正、再頒布を認めるという表面的な同一視をした場合に、それらの用語を同列かつ個別のものと見なし、その上でそれらをまとめて言い表すために、複合語としてFLOSSという用語が使われる。オープンソース- / オープン-[編集]
出典[編集]
(一)^ abcdUnited 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"”
(二)^ abLandley, 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.”
(三)^ abFedora. “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.”
(四)^ abcdUnited States Department of Defense (2009年10月16日). “Q: What are antonyms for open source software?”. 2018年2月9日閲覧。
(五)^ abcdeOpen Source Initiative. “Licenses & Standards”. 2018年2月8日閲覧。
(六)^ abcdGNU Project (2018年1月1日). “How to choose a license for your own work”. 2018年2月9日閲覧。
(七)^ “What is Free Software?”. GNU Project (1998年1月26日). 2018年3月10日閲覧。
(八)^ Karl Fogel (2016年). “Producing Open Source Software - How to Run a Successful Free Software Project”. O'Reilly Media. 2016年4月11日閲覧。
(九)^ History of the Open Source Initiative
(十)^ Technology In Government, 1/e. Jaijit Bhattacharya. (2006). p. 25. ISBN 978-81-903397-4-2
(11)^ annr (2017年5月16日). “What is open source, and what is the Open Source Initiative?”. 2018年2月9日閲覧。
(12)^ Open Source Initiative (2007年3月22日). “The Open Source Definition”. 2018年2月9日閲覧。
(13)^ Open Source Initiative (2007年3月22日). “Can I call my program "Open Source" even if I don't use an approved license?”. 2018年2月9日閲覧。
(14)^ GNU Project (2018年1月1日). “What is free software?”. 2018年2月9日閲覧。
(15)^ abcdeRichard Stallman (2016年11月18日). “Why Open Source misses the point of Free Software”. 2018年2月9日閲覧。
(16)^ 総務省. “2 OSSの影響 ‥ 平成18年版 情報通信白書”. 2018年2月9日閲覧。 “Open Source Initiative︵OSI︶が定めた﹁The Open Source Definition︵OSD︶﹂と呼ばれる定義を満たすソフトウェアである”
(17)^ “Open Source Certification:Press Releases”. Open Source Initiative (1999年6月). 2018年3月1日閲覧。
(18)^ “商標照会︵固定アドレス︶ 商標公報4553488”. 特許情報プラットフォーム. 2018年3月25日閲覧。
(19)^ “オープンソース商標について”. オープンソースグループ・ジャパン (2003年). 2018年3月1日閲覧。
(20)^ Dana Blankenhorn (2006年12月7日). “Is SugarCRM open source?”. 2018年2月15日閲覧。
(21)^ Tiemann, Michael (2007年6月21日). “Will The Real Open Source CRM Please Stand Up?”. Open Source Initiative. 2008年1月4日閲覧。
(22)^ Vance, Ashlee (2007年7月25日). “SugarCRM trades badgeware for GPL 3”. The Register 2008年9月8日閲覧。
(23)^ “The Big freedesktop.org Interview”. OSNews (2003年11月24日). 2018年3月26日閲覧。
(24)^ Lohr, Steve (2007年1月22日). “Group Formed to Support Linux as Rival to Windows”. The New York Times. ISSN 0362-4331 2016年4月14日閲覧。
(25)^ “Linux lab lands Torvalds”. CNET. 2016年4月14日閲覧。
(26)^ “Industry Leaders Announce Open Platform for Mobile Devices”. Open Handset Alliance (2007年11月5日). 2007年11月5日閲覧。
(27)^ “Open Handset Alliance members page”. Open Handset Alliance (2007年11月5日). 2007年11月5日閲覧。
(28)^ “Developers”. Open Handset Alliance (2007年11月5日). 2007年11月5日閲覧。
(29)^ “Alibaba: Google just plain wrong about our OS”. CNET News (2012年9月15日). 2018年3月26日閲覧。
(30)^ Amadeo, Ron (2013年10月21日). “Google’s iron grip on Android: Controlling open source by any means necessary”. Ars Technica (p.3) 2013年12月1日閲覧。
(31)^ “About The Licenses”. Creative Commons. 2018年3月2日閲覧。
(32)^ “Creative Commons FAQ: Can I use a Creative Commons license for software?”. Creative Commons. 2018年3月26日閲覧。
(33)^ “What is a "permissive" Open Source license?”. Open Source Initiative. 2018年3月26日閲覧。 “A "permissive" license is simply a non-copyleft open source license – one that guarantees the freedoms to use, modify, and redistribute, but that permits proprietary derivatives.”
(34)^ abc“What is Copyleft?”. Free Software Foundation (2018年1月1日). 2018年2月9日閲覧。
(35)^ abUnited 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.”
(36)^ “Apache License, Version 2.0”. GNU Project (2018年2月10日). 2018年2月9日閲覧。
(37)^ “Modified BSD license”. GNU Project (2018年2月10日). 2018年2月9日閲覧。
(38)^ “FreeBSD license”. GNU Project (2018年2月10日). 2018年2月9日閲覧。
(39)^ “X11 License”. GNU Project (2018年2月10日). 2018年2月9日閲覧。
(40)^ “GNU General Public License (GPL) version 3”. GNU Project (2018年2月10日). 2018年2月9日閲覧。
(41)^ “GNU Lesser General Public License (LGPL) version 3”. GNU Project (2018年2月10日). 2018年2月9日閲覧。
(42)^ “MPL 2.0 FAQ”. Mozilla. 2018年2月9日閲覧。 “The MPL is a simple copyleft license.”
(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)^ “Eclipse Public License Version 2.0”. GNU Project (2018年2月10日). 2018年2月9日閲覧。
(45)^ Pieter Gunst (2015年8月15日). “Open Source Software: a legal guide”. LawGives. 2018年3月8日閲覧。 “Most open source licenses do not provide any warranties, but instead will provide the software "AS IS."”
(46)^ Dennis Clark (2015年12月4日). “OSS Attribution Obligations”. nexB. 2018年3月8日閲覧。
(47)^ “Share Alike”. wiki.creativecommons.org. 2011年8月29日閲覧。 “The Share Alike aspect requires all derivatives of a work to be licensed under the same (or a compatible) license as the original.”
(48)^ Open Source Initiative. “The Licence Review Process”. 2018年2月8日閲覧。
(49)^ Open Source Initiative. “Open Source Licenses by Category”. 2018年2月9日閲覧。
(50)^ GNU Porject (2018年2月10日). “Various Licenses and Comments about Them”. 2018年2月9日閲覧。
(51)^ Fedora (2017-11--06). “Licensing:Main”. 2018年2月9日閲覧。
(52)^ Fedora (2017年11月6日). “Discussion of Licensing”. 2018年2月15日閲覧。
(53)^ Debian (2018年2月4日). “License information”. 2018年2月9日閲覧。
(54)^ The Free-Libre / Open Source Software (FLOSS) License Slide by David A. Wheeler on September 27, 2007
(55)^ Martin Michlmayr (2008年8月21日). “OSI and License Proliferation”. 2018年2月9日閲覧。
(56)^ Open Source Initiative. “The Licence Proliferation Project”. 2011年5月10日閲覧。
(57)^ Open Source Initiative. “The Licence Review Process”. 2018年2月8日閲覧。
(58)^ “Common Development and Distribution License (CDDL) Description and High-Level Summary of Changes”. sun.com. 2005年2月14日時点のオリジナルよりアーカイブ。2018年3月25日閲覧。
(59)^ “OSI Board Meeting Minutes, Wednesday, March 4, 2009”. Open Source Initiative. 2011年4月1日閲覧。 “It's no different from dedication to the public domain. ... Recommend: Reject”
(60)^ “Speech Transcript - Craig Mundie, The New York University Stern School of Business” (2001年5月3日). 2005年6月21日時点のオリジナルよりアーカイブ。2011年2月7日閲覧。
(61)^ “Share Alike”. Creative Commons. 2017年8月13日閲覧。
(62)^ webmink (2017年7月28日). “Public Domain Is Not Open Source”. 2018年2月25日閲覧。
(63)^ “OSI Board Meeting Minutes, Wednesday, March 4, 2009” (2009年3月4日). 2018年2月9日閲覧。
(64)^ GNU Project (2018年2月10日). “CC0”. 2018年2月9日閲覧。
(65)^ Raymond, Eric S. (1999). The Cathedral and the Bazaar. O'Reilly Media. p. 30. ISBN 1-56592-724-9
(66)^ Kent Roberts (2014年9月16日). “A Brief History of Linux/Open Source Distributions”. atlantic.net. 2018年3月15日閲覧。
(67)^ Pichai, Sundar (2009年7月7日). “Introducing the Google Chrome OS”. Official Google Blog. Google, Inc.. 2012年7月11日閲覧。
(68)^
Shankland, Stephen (2012年3月30日). “Google's Go language turns one, wins a spot at YouTube: The lower-level programming language has matured enough to sport the 1.0 version number. And it's being used for real work at Google.”. CBS Interactive Inc (2012-03-30発行) 2017年8月6日閲覧. "Google has released version 1 of its Go programming language, an ambitious attempt to improve upon giants of the lower-level programming world such as C and C++."
(69)^ catamorphism (2012年1月20日). “Mozilla and the Rust community release Rust 0.1 (a strongly-typed systems programming language with a focus on memory safety and concurrency)”. 2012年2月6日閲覧。
(70)^ Platforms State of the Union, Session 102, Apple Worldwide Developers Conference, June 2, 2014
(71)^ “Swift Has Reached 1.0” (2014年9月9日). 2014年9月10日閲覧。
(72)^ 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
(73)^ Wheeler, David A. (2009年2月). “F/LOSS is Commercial Software”. Technology Innovation Management Review. Talent First Network. 2016年6月18日閲覧。
(74)^ Popp, Dr. Karl Michael (2015). Best Practices for commercial use of open source software. Norderstedt, Germany: Books on Demand. ISBN 978-3738619096
(75)^ Solatan, Jean (2011). Advances in software economics: A reader on business models and Partner Ecosystems in the software industry. Norderstedt, Germany: BOD. ISBN 978-3-8448-0405-8
(76)^ Germain, Jack M. (2013年11月5日). “FOSS in the Enterprise: To Pay or Not to Pay?”. LinuxInsider. ECT News Network, Inc.. 2016年6月18日閲覧。
(77)^ Byfield, Bruce (2005年9月21日). “Google's Summer of Code concludes”. linux.com. 2016年6月18日閲覧。 “DiBona said that the SOC was designed to benefit everyone involved in it. Students had the chance to work on real projects, rather than academic ones, and to get paid while gaining experience and making contacts. FOSS projects benefited from getting new code and having the chance to recruit new developers.”
(78)^ 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.”
(79)^ “TTimo/doom3.gpl”. GitHub (2012年4月7日). 2013年8月10日閲覧。 “Doom 3 GPL source release [...] This source release does not contain any game data, the game data is still covered by the original EULA and must be obeyed as usual.”
(80)^ Hustvedt, Eskild (2009年2月8日). “Our new way to meet the LGPL”. 2009年2月20日時点のオリジナルよりアーカイブ。2011年3月9日閲覧。 “You can use a special keyword $ORIGIN to say 'relative to the actual location of the executable'. Suddenly we found we could use -rpath $ORIGIN/lib and it worked. The game was loading the correct libraries, and so was stable and portable, but was also now completely in the spirit of the LGPL as well as the letter!”
(81)^ Naramore, Elizabeth (2011年3月4日). “SourceForge.net Donation System”. SourceForge. Slashdot Media. 2017年10月16日閲覧。
(82)^ “SourceForge Reports Second Quarter Fiscal 2009 Financial Results”. 2015年6月3日時点のオリジナルよりアーカイブ。2018年2月15日閲覧。
(83)^ Raymond, Eric Steven. “The Cathedral and the Bazaar”. 2012年4月18日閲覧。
(84)^ “Open Sources: Voices from the Open Source Revolution”. O'Reilly Media. 2010年8月7日閲覧。
(85)^ “Open Sources 2.0”. atO'Reilly Media. 2017年9月8日時点のオリジナルよりアーカイブ。2017年10月3日閲覧。
(86)^ “Revolution OS (2001)”. IMDb.com, Inc.. 2018年4月5日閲覧。
(87)^ ab“Free Software Movement”. The Free Software Foundation (2014年4月12日). 2018年4月4日閲覧。
(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)^ マイクロソフト. “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)^ Irina Guseva (2009年5月26日). “Bad Economy Is Good for Open Source”. 2018年2月15日閲覧。
(98)^ Joab Jackson (2011年11月3日). “Open Source vs. Proprietary Software”. PCWorld Business Center. Pcworld.com. 2018年2月15日閲覧。
(99)^ Martin LaMonica (2004年2月12日). “Pandora's box for open source - CNET News”. News.cnet.com. 2012年11月4日時点のオリジナルよりアーカイブ。2012年3月25日閲覧。
(100)^ Seltzer, Larry (2004年5月4日). “Is Open-Source Really Safer?”. PCMag.com. 2012年3月25日閲覧。
(101)^ WIRED STAFF (2004年12月14日). “LINUX: FEWER BUGS THAN RIVALS”. 2018年2月15日閲覧。
(102)^ “Coverity Scan Report Finds Open Source Software Quality Outpaces Proprietary Code for the First Time”. Coverity, Inc. (2014年4月15日). 2018年4月5日閲覧。
(103)^ Bruce Perens (1999年2月17日). “It's Time to Talk about Free Software Again”. 2018年3月1日閲覧。
(104)^ “Linux and the GNU Project”. 2008年12月13日閲覧。
(105)^ “GNU/Linux FAQ”. 2008年12月13日閲覧。
(106)^ Stephen Benson (12 May 1994). "Linux/GNU in EE Times". Newsgroup: comp.os.linux.misc. Usenet: 178@scribendum.win-uk.net. 2008年1月31日閲覧。
(107)^ Govind, Puru (2006年5月). “The "GNU/Linux" and "Linux" Controversy”. 2008年10月26日閲覧。
(108)^ “Linux - The Jargon File, version 4.4.8”. 2018年2月9日閲覧。 “This claim is a proxy for an underlying territorial dispute; [..] RMS and friends wrote many of its user-level tools. Neither this theory nor the term GNU/Linux has gained more than minority acceptance”
(109)^ Christopher Tozzi (2013年10月30日). “The Halloween Documents: Microsoft's Anti-Linux Strategy 15 Years Later”. Channel Futures. 2018年4月4日閲覧。
(110)^ “De Nederlandse Open Source Pagina's”. De Nederlandse Open Source Groep (1998年11月5日). 2018年4月4日閲覧。
(111)^ “Microsoft Responds to the Open Source Memo Regarding the Open Source Model and Linux”. Windows NT Server 4.0 website. マイクロソフト (1998年11月5日). 1999年10月13日時点のオリジナルよりアーカイブ。2012年6月2日閲覧。
(112)^ abRaymond, Eric. “Halloween VII: Survey Says”. 2018年4月4日閲覧。
(113)^ Raymond, Eric. “Halloween Document II”. 2018年4月4日閲覧。
(114)^ Raymond, Eric. “Halloween Document I”. 2018年4月4日閲覧。
(115)^ “News Service”. P&L Communications (1998年12月30日). 1999年4月7日時点のオリジナルよりアーカイブ。2018年4月2日閲覧。
(116)^ “Microsoft exec dissects Linux's 'weak value proposition'”. ZDNet (1999年3月4日). 1999年5月8日時点のオリジナルよりアーカイブ。2018年4月2日閲覧。
(117)^ Raymond, Eric. “Halloween Document VI”. 2018年4月4日閲覧。
(118)^ “SCO Establishes SCOsource to License Unix Intellectual Property”. 2010年1月2日時点のオリジナルよりアーカイブ。2018年4月8日閲覧。
(119)^ Montalbano, Elizabeth (2007年8月15日). “Novell Won't Pursue Unix Copyrights”. PC World 2007年9月4日閲覧。
(120)^ Markoff, John (2007年8月11日). “Judge Says Unix Copyrights Rightfully Belong to Novell”. New York Times 2007年8月15日閲覧。
(121)^ Richard Stallman (2016年11月18日). “FLOSS and FOSS”. 2018年2月9日閲覧。
関連文献[編集]
「オープンソースソフトウェア」をさらに詳しく知るための発展資料
●DiBona, Chris、Ockman, Sam、Stone, Mark 著、倉骨彰 訳﹃オープンソースソフトウェア 彼らはいかにしてビジネススタンダードになったのか︵Web版︶﹄オライリー・ジャパン、1999年。
外部リンク[編集]
- ウィキメディア・コモンズ Open source software - オープンソースソフトウェアに関するメディア
- 英語版ウィキブックス Open Source - オープンソースソフトウェアに関する解説書・教科書
- OSS（Open Source）について - オープンソースに関するガイド
| 典拠管理データベース: 国立図書館 |
|
|---|
