オープンソースソフトウェア
チェック済み
ページは変更保留のため保護されています

Cinnamonデスクトップ環境を実行しているDebian Linuxのスクリーンショット。Firefox（MediaWikiを使用するWikipediaにアクセス）、LibreOffice Writer、Vim、VLC、Nemoファイルマネージャーが搭載されており、これらはすべてオープンソースソフトウェアです。

オープンソースソフトウェア（OSS）とは、著作権者がユーザーにソフトウェアとそのソースコードを誰に対しても、いかなる目的でも使用、調査、変更、配布する権利を付与するライセンスに基づいて公開されるコンピュータソフトウェアです。 [ 1 ] [ 2 ]オープンソースソフトウェアは、共同で公開的に開発される場合があります。オープンソースソフトウェアは、オープンコラボレーションの顕著な例であり、つまり、能力のあるユーザーであれば誰でもオンラインで開発に参加できるため、貢献者の数は無制限です。コードを検査できることで、ソフトウェアに対する公衆の信頼が促進されます。[ 3 ]

オープンソースソフトウェア開発は、単一企業を超えた多様な視点をもたらす可能性があります。2024年には、オープンソースソフトウェアが企業にもたらす価値は8.8兆ドルと推定されています。これは、オープンソースソフトウェアを利用しない場合、企業は現在の3.5倍の費用を費やす必要があるためです。[ 4 ]

オープンソース コードは学習に使用でき、有能なエンド ユーザーは、ユーザー スクリプトやカスタムスタイル シートがWeb サイトに許可するのと同じように、ソフトウェアを自分のニーズに合わせて調整し、最終的には同様の好みを持つユーザー向けにフォークとして変更を公開し、改善点をプル リクエストとして直接送信することができます。

定義

オープンソース・イニシアティブのロゴ

オープンソース・イニシアティブ（OSI）の定義は、国際的に複数の政府によって標準または事実上の定義として認められています[ 5 ] 。OSIは、ソフトウェアライセンスをオープンソースとみなすかどうかを判断する際に、このオープンソース定義を用いています。この定義は、主にブルース・ペレンズによって執筆・改訂されたDebianフリーソフトウェアガイドラインに基づいています[ 6 ] [ 7 ] [ 8 ]。ペレンズは、後に広く公開されたフリーソフトウェア財団（FSF）の「4つの自由」に基づいて執筆したわけではありません[ 9 ] 。

ペレンズの定義によれば、オープンソースとは、コードの使用と改変に関する制限が緩和されているか、あるいは全く制限がない状態で、ソースコードを一般大衆に公開する広範なソフトウェアライセンスである。ソフトウェアの急速な進化を可能にするため、いかなる組織やユーザーによる使用や配布にもほとんど制限を設けないことが、オープンソースの明確な「特徴」である。[ 10 ]

フェラーら（2005）によると、「フリーソフトウェア」および「オープンソースソフトウェア」という用語は、「ユーザーがソフトウェアの作者にロイヤリティや料金を支払うことなく、適切と思われる方法でソフトウェアを使用、変更、再配布することを許可する条件で配布されるソフトウェア製品」に適用されるべきである。[ 11 ]

FSFのリチャード・ストールマンは当初は「オープンソース」という用語を受け入れていたものの、[ 12 ] 、現在では「フリーソフトウェア」と呼ばれるものに「オープンソース」という用語が適用されることに断固として反対している。ストールマンは、この2つの用語が「ほぼ同じカテゴリーのソフトウェア」を表すことには同意するものの、両者を同一視することは誤りであり誤解を招くと考えている。 [ 13 ]ストールマンはまた、オープンソース・イニシアチブが公言する実用主義にも反対している。FSFのソフトウェアの自由に関する理想主義的な基準を妥協することで、自由とコミュニティというフリーソフトウェアの理想が脅かされるのではないかと懸念しているからだ。[ 14 ] FSFはフリーソフトウェアをオープンソース・ソフトウェアのサブセットと見なしており、リチャード・ストールマンは、例えばDRMソフトウェアはオープンソースとして開発できるものの、ユーザーに自由を与えない（制限する）ため、フリーソフトウェアの資格を満たさないと説明した。[ 13 ]

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

開発モデル

オープンソースの有力な貢献者であるエリック・S・レイモンドは、 1997年のエッセイ『伽藍とバザール』の中で、バザールモデルとして知られるOSS開発モデルを提唱しています。レイモンドは、伝統的な方法論によるソフトウェア開発を、個人または少人数のグループによる綿密で孤立した作業を伴う大聖堂の建設に例えています。彼は、すべてのソフトウェアは、異なるアジェンダとアプローチを持つバザール様式で開発されるべきだと提唱しています。[ 15 ]

彼が「大聖堂モデル」と呼んだ伝統的な開発モデルでは、開発は集中的に行われます。役割は明確に定義されています。役割には、設計に専念する人々（アーキテクト）、プロジェクト管理を担当する人々、実装を担当する人々が含まれます。伝統的なソフトウェアエンジニアリングは、この大聖堂モデルに従っています。[ 15 ]

しかし、バザールモデルは異なります。このモデルでは、役割が明確に定義されていません。[ 15 ]バザールモデルを用いて開発されたソフトウェアの特徴として、次のようなパターンが挙げられます。[ 16 ]

  • ユーザーは共同開発者として扱われるべきです。ユーザーは共同開発者として扱われるべきであり、ソフトウェアのソースコードにアクセスできるべきです。さらに、ユーザーにはソフトウェアへの追加、コード修正、バグ報告、ドキュメントなどの提出が奨励されます。共同開発者の数が増えるほど、ソフトウェアの進化速度は速まります。リーナスの法則によれば、十分な数のユーザーがソースコードを閲覧すれば、最終的にはすべてのバグが発見され、修正方法を提案してくれるでしょう。中には高度なプログラミングスキルを持つユーザーもおり、さらに各ユーザーのマシンは追加のテスト環境を提供します。この新しいテスト環境は、新しいバグを発見し修正する能力を提供します。 [ 16 ]
  • 早期リリース：ソフトウェアの最初のバージョンは、共同開発者を早期に見つける可能性を高めるために、できるだけ早くリリースされるべきです。 [ 16 ]
  • 頻繁な統合：コードの変更は、プロジェクトのライフサイクルの終わりに多数のバグを修正するオーバーヘッドを避けるために、できるだけ頻繁に統合（共有コードベースにマージ）する必要があります。 [ 16 ] [ 17 ]一部のオープンソースプロジェクトでは、統合が自動的に行われる夜間ビルドが採用されています。 [ 16 ]
  • 複数のバージョン：ソフトウェアには少なくとも2つのバージョンが必要です。バグが多く機能が多いバージョンと、より安定していて機能が少ないバージョンが必要です。バグのあるバージョン（開発版とも呼ばれます）は、最新の機能をすぐに使いたいユーザー向けであり、まだ十分にテストされていないコードを使用するリスクを負う覚悟のあるユーザー向けです。 [ 16 ]ユーザーは共同開発者として、バグを報告し、バグ修正を提供することができます。 [ 16 ] [ 18 ]
  • 高度なモジュール化：ソフトウェアの全体構造はモジュール化されており、独立したコンポーネントの並行開発が可能になっている必要があります。 [ 16 ]
  • 動的な意思決定構造：変化するユーザー要件やその他の要因に応じて戦略的な意思決定を行う、公式・非公式を問わず意思決定構造が必要である。これはエクストリーム・プログラミングと比較される。 [ 16 ]

オープンソース開発のプロセスは、要件抽出から始まります。開発者は、プロジェクトに新機能を追加するか、バグを修正する必要があるかを検討します。これは、バグ報告や追跡、メーリングリスト、プロジェクトページなどの手段を通じてOSSコミュニティとコミュニケーションをとることで確立されます。次に、OSS開発者はタスクを選択するか、タスクに割り当てられ、解決策を特定します。OSSでは解決策には多くの選択肢があるため、慎重な検討と、時には同僚からのフィードバックも得ながら、最適な解決策を選択する必要があります。その後、開発者はコードの開発とコミットを開始します。その後、コードは同僚によってテストとレビューが行われます。開発者は、継続的インテグレーションからのフィードバックを通じて、コードを編集し、進化させることができます。リーダーシップとコミュニティがプロジェクト全体に満足したら、部分的にリリースし、ユーザーへの説明を文書化することができます。プロジェクトのリリース準備が整ったら、重大なバグ修正またはセキュリティ対策のみを実施して凍結します。最終的に、プロジェクトは完全にリリースされ、軽微なバグ修正のみが実施されます。[ 18 ]

利点

標準規格のオープンソース実装は、その標準規格の採用率と長期的な存続可能性を高めることができます。[ 19 ]開発者は開発プロセスと最終製品への参加意識と所有権をより強く感じるため、開発者の忠誠心を育むことがよくあります。[ 20 ]

さらに、OSSではマーケティングや物流サービスのコスト削減が求められています。[ 21 ] OSSは、商用製品を含め、企業のイメージを宣伝するためのツールとなり得ます。[ 22 ] OSS開発アプローチは、信頼性が高く高品質なソフトウェアを迅速かつ安価に生産するのに役立っています。[ 21 ]

オープンソース開発は、イノベーションを加速させ、社会的な価値を生み出す可能性を秘めています。例えばフランスでは、政府によるフリーのオープンソースソフトウェアの推進を奨励する政策により、年間約60万件のOSSへの貢献が増加し、オープンソースソフトウェアの量と質の向上によって社会的な価値が創出されました。また、この政策により、テクノロジー系スタートアップ企業の数は最大18%増加し、IT部門の雇用者数は14%増加したと推定されています。[ 23 ]

OSSは、何千人もの独立したプログラマーがソフトウェアのバグをテストし修正することで、高い信頼性を実現できます。[ 16 ]オープンソースは、それを最初に作成した企業や作者に依存しません。たとえ企業が倒産したとしても、コードは存在し続け、ユーザーによって開発され続けます。[ 24 ]

OSSは、モジュール式のシステムによりプログラマがカスタムインターフェースを構築したり、新しい機能を追加したりできるため柔軟性があり、オープンソースプログラムは多数の異なるプログラマのコラボレーションの成果であるため革新的です。[ 16 ]多様な視点、企業目標、個人の目標の組み合わせによりイノベーションが加速されます。[ 25 ]

さらに、フリーソフトウェアは純粋に技術的な要件に基づいて開発できるため、ソフトウェアの品質を低下させる商業的圧力を考慮する必要がありません。商業的圧力は、従来のソフトウェア開発者がセキュリティ要件よりも顧客の要件に重点を置く原因となります。なぜなら、セキュリティ要件は顧客にとって目に見えないものだからです。[ 26 ]

開発ツール

オープンソースソフトウェア開発では、製品の開発と開発プロセス自体をサポートするためにツールが使用されます。[ 18 ]

集中型バージョン管理システム (CVCS) や分散型バージョン管理システム(DVCS) などのバージョン管理システムは、多くの場合オープンソースであり、ソフトウェアプロジェクトのソースコードファイルとそれらのファイルへの変更を管理してコラボレーションを促進するのに役立つツールの例です。CVCS は中央リポジトリで集中管理されていますが、DVCS は分散型で、ユーザーごとにローカルリポジトリがあります。同時バージョン管理システム(CVS) とその後のSubversion (SVN) は CVCS の例であり、Gitは DVCS であり、最も広く使用されているバージョン管理ソフトウェアです。[ 27 ]リポジトリは、 GitHubやGitlabなどのソースコードホスティング施設でホストされ、公開されます。[ 28 ]

オープンソースプロジェクトでは、問題追跡ツールなどのユーティリティを使用してオープンソースソフトウェアの開発を整理しています。一般的に使用されているバグ追跡ツールには、 BugzillaやRedmineなどがあります。[ 18 ]

メーリングリストやIRCなどのツールは、開発者間の調整やバグに関する議論の手段となります。プロジェクトのウェブページ、Wikiページ、ロードマップリスト、ニュースグループは、エンドユーザーに焦点を当てたプロジェクト情報の配信を可能にします。[ 18 ]

参加の機会

貢献

OSS参加者の基本的な役割は複数のカテゴリーに分類できます。まず、プロジェクトの中心に立ってプロジェクトの実行を統制するリーダーシップが挙げられます。次に、プロジェクトにおいて豊富な経験と権限を持ち、他の貢献者を指導するコア貢献者がいます。コア貢献者以外の貢献者は経験と権限は少ないものの、定期的に貢献し、プロジェクトの発展に不可欠な存在です。新規貢献者は経験が最も浅いですが、メンターシップと指導があれば、定期的に貢献する存在になることができます。[ 29 ]

オープンソースソフトウェアへの貢献方法としては、プログラミング、メンテナンス、ユーザーインターフェースの設計とテスト、ウェブデザイン、バグトリアージ、アクセシビリティの設計とテスト、UXデザイン、コードテスト、セキュリティレビューとテストなどが挙げられます。しかし、コーディングスキルがなくても、OSSプロジェクトに貢献する方法はいくつかあります。例えば、技術的なスキルを必要としない参加方法としては、ドキュメントの作成と編集、翻訳、プロジェクト管理、イベントの企画と調整、マーケティング、リリース管理、コミュニティ管理、広報とアウトリーチなどがあります。[ 29 ]

資金援助は、個人や組織がオープンソースプロジェクトに貢献するもう一つの方法です。Open Collectiveのような団体は、個人がお気に入りのプロジェクトを支援するために毎月寄付できる手段を提供しています。[ 30 ] Sovereign Tech Fundのような組織は、ドイツ政府が使用するツールを支援するために数百万ドルを寄付することができます。[ 31 ]国立科学財団は、オープンソースイノベーションを支援するために、Pathways to Enable Open-Source Ecosystems (POSE)プログラムを設立しました。[ 32 ]

業界の参加

業界によるオープンソースソフトウェアの採用は、時間とともに増加しています。[ 33 ] OSSは、そのメリットから、通信、航空宇宙、ヘルスケア、メディア＆エンターテイメントなどの多くの業界で人気があります。 [ 34 ] OSSの採用は大規模な組織でより一般的であり、企業のIT利用、運用効率、従業員の生産性に依存します。[ 33 ]

産業界がOSSを利用する主な理由は、バックオフィス機能、営業サポート、研究開発、ソフトウェア機能、迅速な導入、プラットフォーム間の移植性、商用ライセンス管理の回避などです。さらに、ハードウェアと所有コストの削減も重要なメリットです。[ 33 ]

著名な組織

フリーソフトウェアやオープンソースソフトウェアの運動の発展と拡大に貢献する組織は世界中に存在し、これらの組織は教育や技術の普及などの目標に取り組んでいます。オープンソース・イニシアティブの元副会長が挙げているように、アメリカの組織にはフリーソフトウェア財団、ソフトウェア自由保護協会、オープンソース・イニシアティブ、ソフトウェア・イン・ザ・パブリック・インタレストなどがあります。ヨーロッパの著名な組織としては、フリーソフトウェア財団ヨーロッパ、オープンソースプロジェクトEU（OSP）、オープンフォーラムヨーロッパ（OFE）などがあります。オーストラリアにはLinuxオーストラリア、アジアにはオープンソースアジアとFOSSAsiaがあります。アフリカの組織にはアフリカのフリーおよびオープンソースソフトウェア（FOSSFA）とOpenAfrica、中央アジアと南アジアにはFLISOLやGRUP de usuarios de software libre Peruなどの組織があります。これら以外にも、オープンソースソフトウェアの推進に専念する組織が数多く存在します。[ 29 ]

ライセンス

FOSS製品は、一般的に、パーミッシブ ライセンスとコピーレフト ライセンスの 2 種類のライセンスでライセンス供与されます。これらの 2 種類のライセンスは、より多くのユーザーがソフトウェアにアクセスできるようにし、各ライセンスに独自のルールがあるため、特定のライセンスの条件で指定された派生作品の作成を許可できる点で、プロプライエタリライセンスとは異なります。 パーミッシブ ライセンスでは、ソフトウェアの受領者は、配布に同じライセンスを使用しなくても、作成者の著作権を実装できます。この種類のライセンスの例には、 BSD ライセンス、 MIT ライセンス、 Apache ライセンスなどがあります。コピーレフトライセンスは、受領者に対して、配布物の少なくとも一部に同じライセンスを使用することを要求する点で異なります。 強いコピーレフト ライセンスでは、すべての派生作品に同じライセンスを使用する必要がありますが、弱いコピーレフト ライセンスでは、特定の条件下でのみ同じライセンスを使用する必要があります。 この種類のライセンスの例には、GNU ライセンス ファミリー、およびMPLライセンスとEPLライセンスがあります。これら2つのライセンスの類似点としては、著作権の広範な付与、受領者による著作権表示の保持の義務付け、ライセンスのコピーがコードと共に受領者に提供されることなどが挙げられます。[ 35 ]

オープンソースソフトウェアに関する重要な法的先例の一つは、2008年にJacobson対Katzer事件で創出されました。この事件では、改変の帰属表示や特定を含むArtisticライセンスの条項が執行されました。この判決により、ライセンスの条件が遵守されていない場合でも著作権法に基づく執行が確固たるものとなりました。Artisticライセンスは他のオープンソースソフトウェアライセンスと類似していたため、この判決は広く適用される先例となりました。[ 35 ]

フリーソフトウェアライセンス/オープンソースライセンスの例としては、Apacheライセンス、BSDライセンス、GNU一般公衆利用許諾書、GNU劣等一般公衆利用許諾書、MITライセンス、Eclipseパブリックライセンス、Mozillaパブリックライセンスなどがあります。[ 35 ]

ソフトウェア規制には、オープンソースソフトウェアに大きな影響を与えるグレーゾーンがいくつか存在します。例えば、ソフトウェアは商品かサービスか、何が改変とみなされるか、契約かライセンスかによるガバナンス、所有権と使用権などです。これらの問題については進展が見られてきましたが、しばしば新たな疑問が生じます。規制におけるこうした不確実性の存在は、テクノロジーに関わる業界全体に悪影響を及ぼします。[ 35 ]

ソフトウェア全体の法制史においては、ソフトウェアを知的財産として特許法、著作権法、あるいは独自の規制を制定すべきかという議論が盛んに行われました。最終的には、独自の規制による若干の修正はあるものの、コンピュータプログラムは文学作品の一種とみなされ、著作権法が標準となりました。[ 35 ]

ソフトウェアは一般にソースコードとオブジェクトコードの両方として考えられており、どちらも保護対象ですが、この定義には法的に多様な側面があります。一部の法域では、独自の目的でこの概念を拡大または縮小しようとしています。たとえば、欧州司法裁判所は、コンピュータプログラムにはプログラムの機能、プログラミング言語、またはデータファイルの形式は含まれないと定義しています。ソフトウェアのさまざまな側面の保護を制限することで、法律はソフトウェアの使用に対するオープンソースアプローチを支持しています。特に米国はソフトウェアに対してオープンなアプローチを採用しており、ほとんどのオープンソースライセンスは米国で生まれています。しかし、これによりこれらのライセンス内の特許権への注目が高まり、他の形式の知的財産保護を好むOSSコミュニティからの反発を受けています。[ 35 ]

もう一つの問題は、1996年の世界知的所有権機関（WIPO）条約で国際的に法的に認められ保護された技術的保護手段（TPM）とデジタル著作権管理（DRM）技術です。オープンソースソフトウェア支持者は、これらの技術が著作権法の枠を超えてエンドユーザーを制限する可能性があるため、これらの技術を嫌っていました。欧州はこうした不満に対し、TPMを法的規制下に置くことで対応し、OSS支持者の勝利となりました。[ 35 ]

経済/ビジネスへの影響

オープンソースとオープンデータ指向のゲームジャム、 Free Knowledge Game Jam 2015の参加者

オープンソースコミュニティでは、制作者は制作したソフトウェアを所有するのではなく、進化するソフトウェアの開発そのものを所有する。このように、ソフトウェアの将来はオープンであり、OSS内での所有権や知的財産権の確保は困難である。ライセンスとブランディングによって他者による盗用を防ぎ、公共財としての地位を維持することができる。オープンソースソフトウェアは誰もが利用可能であり、1人がダウンロードしたからといって他者にとっての価値が下がるわけではないため、公共財とみなすことができる。オープンソースソフトウェアは、リソースを減少させるのではなく、使用され、貢献されるにつれて価値が高まるという点で独特である。これは、評判への投資やネットワーク効果などの概念によって説明される。[ 36 ]

オープンソースソフトウェアの経済モデルは、開発者がプロ​​ジェクトに貢献することで公共の利益を生み出すという形で説明できます。開発者は、プロジェクトの評判や価値の向上といった、認識される利益やコストに基づいてプロジェクトを選択します。開発者のモチベーションは様々な場所や理由から生まれますが、重要なのは、金銭が唯一の、あるいは最も重要なインセンティブではないということです。[ 36 ]

経済理論は主に希少資源の消費に焦点を当てているため、OSSのダイナミクスを理解するのは難しい場合があります。OSSでは、生産者はプロジェクトへの貢献による報酬を得ることで消費者になります。例えば、開発者はOSSプロジェクトへの貢献が成功すれば、同僚から高い評価を得ます。OSSの社会的便益と相互作用は、経済モデルでも考慮することが困難です。さらに、技術革新は価値観に関する議論や見通しを絶えず変化させ、経済モデルでは社会行動を予測できなくなります。[ 36 ]

OSSは経済モデルにおいて理論的に難しい側面があるものの、資源を必要とする持続可能な社会活動として説明可能です。これらの資源には、時間、資金、技術、そして貢献が含まれます。多くの開発者は、大学や政府などの組織が資金提供した技術を利用しています。しかし、これらの組織もOSSの成果から利益を得ています。OSSが成長するにつれて、OSSと独自システムを組み合わせたハイブリッドシステムが一般的になりつつあります。[ 36 ]

2000年代半ばにかけて、ますます多くのテクノロジー企業がOSSの利用を開始しました。例えば、DellはLinuxを既にインストールしたコンピュータを販売しました。Microsoft自身も、かつてOSS運動に敵意を抱いていたにもかかわらず、 LinuxベースのOSをリリースしました。こうした動きにもかかわらず、これらの企業はOSSを特定の用途にのみ利用する傾向があり、OSSが企業に利用され、何の見返りも得られていないのではないかという懸念が生じています。[ 24 ]

政府が使用

多くの政府は、オープンソースソフトウェアがもたらす多くのメリットから、その導入と推進に関心を示しています。例えば、英国政府は2004年にオープンソースとオープンスタンダードを推進する政策を発表し、2009年にはこの政策を再確認し、「政府はオープンソースソリューションをプロプライエタリソリューションと並行して積極的かつ公平に検討する」としました。[ 37 ]しかし、考慮すべき課題としてサイバーセキュリティがあります。偶発的な脆弱性はあり得ますが、外部からの攻撃も考えられます。こうした懸念から、ソフトウェアガバナンスへの貢献に対する政府の関心は高まっています。しかし、これらは問題の大まかな概要に過ぎず、各国はオープンソースソフトウェアとの政治的な関わり方や導入目標をそれぞれ独自に持っています。例えば、米国は、中国やロシアなどの国々におけるオープンソースソフトウェア活動の増加が脅威であると認識されているため、オープンソースソフトウェアの導入に関して国家安全保障に重点を置いており、国防総省はOSSの利用に関する複数の基準を検討しています。これらの基準には、信頼できる情報源から提供され、維持されているかどうか、継続的に維持されるかどうか、ソフトウェアのサブコンポーネントへの依存関係があるかどうか、コンポーネントのセキュリティと整合性、外国政府の影響などが含まれます。[ 38 ]

オープンソースに関して政府にとってもう一つの課題は、オペレーティングシステム、半導体、クラウド、人工知能といった技術への投資である。これらの技術はすべて国際協力に影響を与え、安全保障上の問題や政治的影響を及ぼしかねない。多くの国は、こうしたパートナーシップにおいて技術革新と技術依存のバランスを取らなければならない。例えば、中国のオープンソース依存企業であるファーウェイは、2019年にGoogleのAndroidシステムの使用を阻止された後、独自の代替オペレーティングシステムであるHarmony OSの開発を開始した。[ 38 ]

ドイツは最近、自国が使用するソフトウェアのガバナンスとメンテナンスを支援するために、 ソブリン・テック・ファンドを設立しました。

オープンソフトウェア運動

歴史

コンピュータの黎明期、特に1950年代から1960年代にかけては、プログラマーと開発者は互いに学び合い、その分野を発展させるためにソフトウェアを共有することが一般的でした。Unixなどの初期のシステムでは、ユーザーがソースコードにアクセスできるようにし、共同作業や修正を可能にしていました。しかし、1970年代から1980年代にかけて商用ソフトウェア産業が台頭し、プロプライエタリなモデルが主流になるにつれて、このオープンな共有文化は衰退し始めました。このような変化にもかかわらず、学術機関や研究機関は共同ソフトウェア開発の実践を推進し続けました。[ 39 ]

これに対応して、ハッカーまたはハッカー文化として広く呼ばれる熟練したプログラマーの熱狂的な活動からオープンソース運動が生まれました。[ 40 ]これらの熱狂者の1人、リチャード・ストールマンは、後のオープンソース運動を可能にするフリーソフトウェア運動の原動力でした。1984年、研究室のプログラマー文化がプロプライエタリソフトウェアによってソースコードの共有や改良が妨げられたため、彼はMITを辞職し、フリーオペレーティングシステムであるGNUを作成しました。GNUはUNIXと互換性があり、プログラマーの熱狂者にとってその仕組みは馴染み深いものでした。しかし、ストールマンがフリーソフトウェアに選んだラベルに混乱があることがすぐに明らかになりました。彼はそれをフリービールではなく、言論の自由の意味でフリーであると説明し、フリーが価格ではなく自由であるという意味に言及しました。彼は後にこの自由の概念を4つの基本的な自由にまで拡張しました。 GNUを通じて、他者のソースコード、コミュニティによるバグ修正、新機能のコード提案を取り入れるというオープンソースの規範が生まれた。 1985年、ストールマンはソフトウェアの変更を促進し、GNUの作成を支援するためにフリーソフトウェア財団（FSF）を設立した。 自分の作品がプロプライエタリソフトウェアに利用されるのを防ぐため、ストールマンはコピーレフトの概念を生み出し、特定の条件の下で誰でも自分の作品を利用できるようにした。 これを実現するために、彼は1989年にGNU一般公衆利用許諾書（GNU GPL）を作成し、これは1991年に更新された。[ 17 ] 1991年、GNUにはカーネルがなかったため、リーナス・トーバルズが書いたLinuxカーネル とGNUが統合された。 [ 41 ]このオペレーティングシステムは現在、通常Linuxと呼ばれている。[ 17 ]この期間中、当時は他にも多くのフリーソフトウェアプロジェクトやライセンスが存在し、それぞれがフリーソフトウェアの概念がどのようなものであるか、またどうあるべきか、またプロプライエタリソフトウェアの倫理性について異なる考えを持っていました。例えば、Berkeley Software Distribution、TeX、X Window Systemなどです。[ 42 ]

フリーソフトウェアが発展するにつれ、フリーソフトウェア財団は、フリーソフトウェアのアイデアと認識されている利点を商用ソフトウェア業界にもたらす方法を模索し始めました。FSFの社会運動は企業にとって魅力的ではなく、ソフトウェアのソースコードの共有とコラボレーションのビジネス上の可能性を強調するためにフリーソフトウェア運動のブランドを変更する方法が必要であるという結論に達しました。 [ 42 ]オープンソースという用語は、1998年にフリーソフトウェアの支持者の会議でクリスティン・ピーターソンによって提案されました。グループの多くは、フリーソフトウェアという名前は新規参入者を混乱させ、業界の関心を阻害すると感じていたため、オープンソースという新しい名称をすぐに受け入れ、オープンソース・イニシアティブ（OSI）とオープンソース・ソフトウェアに関するOSIの定義を作成しました。[ 17 ]オープンソース・イニシアティブ（OSI）の定義は現在、国際的にいくつかの政府によって標準または事実上の定義として認められています。[ 41 ]この定義は、主にブルース・ペレンズによって書かれ、改訂されたDebianフリーソフトウェアガイドラインに基づいています。 [ 43 ] OSIの定義は、プロプライエタリソフトウェアの組み込みを許容し、ライセンスに関してより自由な点において、フリーソフトウェアの定義とは異なっています。ストールマン氏のように、プロプライエタリソフトウェアに対して強い道徳的立場を取っているフリーソフトウェアの本来の概念に賛同する人もいますが、ソフトウェアの運用という点では、この二つの運動の間には多くの共通点があります。[ 17 ]

オープンソース・イニシアティブが新しい​​用語の使用を奨励し、その遵守する原則を広めようと努める一方で、商用ソフトウェアベンダーは、自由に配布されるソフトウェアの概念とアプリケーションのソースコードへの普遍的なアクセスによってますます脅威を感じるようになり、2001年にはマイクロソフトの幹部がオープンソースを知的財産の破壊者と呼んだ。しかし、フリー・オープンソース・ソフトウェア（FOSS）は歴史的に主流の民間ソフトウェア開発の外で役割を果たしてきたが、マイクロソフトのような大企業はインターネット上で公式のオープンソースの存在を展開し始めている。IBM、オラクル、ステート・ファームは、今日の競争の激しいオープンソース市場に重大な社会的関心を持つ企業のほんの一例に過ぎず、FOSSの開発に関する企業哲学の大きな転換を示している。[ 44 ]

未来

オープンソースソフトウェアコミュニティ、ひいてはフリーソフトウェアコミュニティの未来は、その理念を誤解していなければ、成功を収めていると言えるでしょう。例えば、AndroidとUbuntuは、2000年代初頭の技術革新の傍らからオープンソースソフトウェアが台頭してきた成功例です。しかし、コミュニティの中には、AndroidのOSS中心性をGoogleとそのパートナーが軽視していること、Apacheライセンスの使用によってフォークが可能になりAndroid内でのコラボレーションの機会が失われていること、Ubuntuにおいて自由よりも利便性が優先されていること、Ubuntu内にマーケティング目的でユーザーを追跡する機能があることなどから、AndroidとUbuntuはOSSの代表として失敗していると考える人もいます。[ 24 ]

OSSの利用はビジネスにおいてより一般的になり、企業の78%が業務の全部または一部をFOSS上で実行していると報告しています。OSSの人気は高まり、かつてはOSSを批判していたマイクロソフトでさえ、自社のシステムにOSSを採用するに至りました。しかし、この成功はOSSの将来を決定づける懸念を引き起こしています。コミュニティは、OSSとは何か、OSSはどうあるべきか、そして保護する必要があるとすれば、それを守るために何をすべきかといった疑問に答えなければならないからです。全体として、フリーオープンソース革命は市場で均衡が見られるまで減速しましたが、それは革命が終わったことを意味するわけではありません。その将来を決定するためには、多くの理論的議論が行われなければなりません。[ 24 ]

他のソフトウェアライセンス/開発モデルとの比較

クローズドソース/プロプライエタリソフトウェア

オープンソースソフトウェアは、公開されていること、ライセンスに料金がかからないこと、ライセンス仕様に基づいて改変や配布が許可されているという点で、プロプライエタリソフトウェアとは異なります。これらすべてが、プロプライエタリソフトウェアの目標であるOSS製品の独占を防ぐ役割を果たします。プロプライエタリソフトウェアは、顧客の選択肢を、そのソフトウェアの使用を約束するか、アップグレードするか、他のソフトウェアに切り替えるかのいずれかに制限し、顧客のソフトウェアに対する好みが金銭的なコストによって左右されることを余儀なくさせます。プロプライエタリソフトウェアベンダーにとって理想的なシナリオは、顧客がこれらのコストのためにソフトウェアを切り替えることができない、あるいは切り替えないというロックインです。 [ 45 ]

プロプライエタリソフトウェアでは、バグ修正はベンダーのみが提供でき、プラットフォームの変更には別途購入が必要であり、製品の存在はベンダーに依存しており、ベンダーはいつでも製品を廃止することができます。[ 40 ]さらに、プロプライエタリソフトウェアはソースコードを提供しないため、ユーザーが変更することはできません。企業にとって、これはセキュリティリスクとなり、フラストレーションの原因となる可能性があります。なぜなら、製品を自社のニーズに合わせてカスタマイズできず、ソフトウェア内に隠れた脅威や情報漏洩が発生する可能性があり、アクセスや変更ができないからです。[ 17 ]

フリーソフトウェア

OSIの定義によれば、オープンソースとは、コードの使用と改変に関する制限が緩和されているか、あるいは全く制限がない状態で、ソースコードを一般大衆に公開する広範なソフトウェアライセンスです。ソフトウェアの急速な進化を可能にするため、いかなる組織やユーザーによる使用や配布にもほとんど制限を設けないことが、オープンソースの明確な特徴です。[ 46 ]

フリーソフトウェア運動の指導者であり、フリーソフトウェア財団のメンバーであるリチャード・ストールマンは、彼らがフリーソフトウェアと呼ぶものに「オープンソース」という用語が適用されることに反対している。ストールマンは、この2つの用語がほぼ同じカテゴリのソフトウェアを説明することに同意しているものの、この2つの用語を同一視することは誤りであり誤解を招くものだと考えている。 [ 13 ] ストールマンは、どちらかの用語を選択することで、他の人に自分の目標が開発（オープンソース）なのか社会的な立場（フリーソフトウェア）なのかを知らせることができるというのが主な違いだと考えている。[ 47 ]しかし、オープンソースソフトウェアとフリーソフトウェアには重なり合う部分もかなりある。[ 13 ]ストールマンは、オープンソース・イニシアティブの公言している実用主義にも反対しており、FSFのソフトウェアの自由に関する理想的な基準に妥協することで、フリーソフトウェアの理想である自由とコミュニティが脅かされることを懸念している。[ 47 ] FSFはフリーソフトウェアをオープンソースソフトウェアのサブセットとみなしており、リチャード・ストールマンは、例えばDRMソフトウェアは、ユーザーを制限するにもかかわらずオープンソースとして開発できるため、フリーソフトウェアの資格を満たさないと説明しました。[ 13 ]

FSFは、「オープンソース」という用語は、単にソースコードが利用可能であることと、それを使用、変更、再配布する自由とを混同するような、別の種類の曖昧さを生み出すと述べています。[ 13 ]一方、「フリーソフトウェア」という用語は、「フリー」という言葉の曖昧さがビジネスでの採用を阻むものと見なされ、歴史的に曖昧な用法であったことから批判されました。[ 47 ]

開発者は、フリーソフトウェアでもあるオープンソースソフトウェアを説明するために、フリーでオープンソースソフトウェア（FOSS）、またはフリー/リブレでオープンソースソフトウェア（ FLOSS）という別の用語 を使用しています。[ 29 ]

ソース利用可能なソフトウェア

ソフトウェアはソースコード（読み取り可能なコード）とともに配布できます。このソースコードが閲覧可能な場合、ソフトウェアはソースコードが公開されています。ただし、ソースコードが公開されている、つまりFOSSであるためには、ソースコードにアクセスできるのはすべての人ではなく、そのソフトウェアのユーザーだけです。オープンソースの定義ではソースコードが公開されていることが要件となっているため、すべてのFOSSソフトウェアはソースコードが公開されていますが、ソースコードが公開されているすべてのソフトウェアがFOSSであるとは限りません。たとえば、ソフトウェアがオープンソースの定義の他の側面、例えば改変や再配布の許可などを満たしていない場合、ソースコードが公開されていてもそのソフトウェアはFOSSではありません。[ 48 ]

オープンソース化

ソフトウェア企業における最近の傾向は、オープンソース化、つまり、以前のプロプライエタリソフトウェアをオープンソースライセンスの下でリリースすることでオープンソースソフトウェアに移行することです。[ 49 ] [ 50 ]これを行った企業の例としては、Google、Microsoft、Appleなどが挙げられます。[ 49 ]また、オープンソース化とは、オープンソースソフトウェアのプログラミングやオープンソースソフトウェアのインストールを指すこともあります。[ 50 ]オープンソース化には、新しい視点や問題解決能力をもたらす外部貢献者をより多く引き付けるなど、さまざまな利点があります。オープンソース化の欠点としては、ベースコードを理解しやすくすること、新しい開発者のためのコミュニケーションチャネルを設定すること、新しい開発者が簡単に参加できるようにドキュメントを作成することなど、新しいコミュニティを維持するために必要な作業が挙げられます。しかし、いくつかのオープンソースプロジェクトを調査したところ、新しくオープンソース化されたプロジェクトは多くの新規参加者を引き付けるものの、その多くがすぐにプロジェクトを離れる可能性が高く、彼らのフォークも影響力が薄いことがわかりました。[ 49 ]

他の

オープンソースと類似点を持つ可能性のある他の概念としては、シェアウェア、パブリックドメインソフトウェア、フリーウェア、そして無料で利用できるもののソースコードを提供しないソフトウェアビューア／リーダーなどがあります。しかし、これらはソースコードへのアクセス、ライセンス、著作権、料金といった点でオープンソースソフトウェアとは異なります。[ 17 ]

社会と文化

人口統計

オープンソースソフトウェアの貢献者は、国際的な協力が可能にもかかわらず、シリコンバレーなどの大規模なクラスターに多く存在し、そのほとんどはクラスター内での協力が中心であることがわかった。この現象の理由としては、OSS貢献者の人口統計上は主にソフトウェア関連の仕事に従事しているため、OSSの地理的な位置がその分散と密接に関係し、仕事やソーシャルネットワークを通じて協力が促進される可能性があることが考えられる。[ 51 ]コードの受け入れはこれらのソーシャルネットワーククラスター内でのステータスに左右される可能性があり、場所に基づいてコードの受け入れに不公平な傾向が生じる可能性がある。[ 52 ]国際協力の障壁には、言語や文化の違いも含まれる。[ 53 ]さらに、インドを除く各国では、国内の貢献者からのコードの受け入れ率が高く、文化的に類似した協力者への偏りが見られる。[ 53 ]

2021年にオープンソースソフトウェアへの貢献度が最も高かった国は、順に、米国、中国、ドイツ、インド、英国であった。[ 51 ] 2021年の調査によると、人口1人あたりのOSS開発者数が最も多かった国は、順に、アイスランド、スイス、ノルウェー、スウェーデン、フィンランドであったが、2008年にはSourceForgeへの推定貢献者数が最も多かった国は、米国、ドイツ、英国、カナダ、フランスであった。[ 51 ] [ 53 ] OSS開発者の分布と貢献度についてはいくつかの研究が行われてきたが、これはまださまざまな方法で測定できる未解決の分野である。例えば、情報通信技術への参加、人口、富、インターネットへのアクセスの割合は、OSSの貢献度と相関関係にあることが示されている。[ 53 ]

ジェンダーの多様性はチームの生産性を高めることがわかっているが、性別が特定できる場合、女性はオープンソースソフトウェアプロジェクトに貢献する際に依然として偏見に直面している。 [ 54 ] 2002年には、国際的なオープンソースソフトウェア開発者のうち女性はわずか1.5％であったが、技術業界の役割の28％を女性で占めており、ソフトウェア分野における女性の割合が低いことがわかった。[ 55 ] OSSの貢献には前提条件がないにもかかわらず、貢献者の間では性別は関係なく、コードの品質だけがコードの受け入れの唯一の考慮事項であるという一般的な考えがあるため、このジェンダーバイアスは存在し続け、コミュニティが女性の代表性における体系的な格差に対処できない可能性がある。 [ 40 ]しかし、2005年から2021年にかけて国際的に計算された女性のOSS参加のより最近の数字は9.8％であり、そのほとんどが最近の貢献者であり、女性の参加が増加している可能性があることを示している。[ 56 ]

動機

OSSコミュニティに貢献する動機は数多くあります。まず、コーディングやその他の技術関連能力といった複数のスキルを学び、実践する機会となるだけでなく、コミュニケーションやコラボレーションといった基礎スキル、そして課題追跡やバージョン管理といった技術関連分野で優れた成果を上げるために必要な実践的なスキルも身に付けられます。教室や仕事を通して学ぶのではなく、OSSへの貢献を通して学ぶことで、参加者は自分のペースで学び、興味のあることに取り組むことができます。OSSに貢献することで、貢献者は業界の最新ベストプラクティス、技術、トレンドを学ぶことができ、さらにはOSSが技術分野でますます人気が高まるにつれて、次の大きなイノベーションに貢献する機会も得られます。OSSに無償で貢献することは、評判が傷つく可能性はあるものの、解雇される心配がないことを意味します。一方、OSSに貢献する大きな動機は、公開ポートフォリオを拡大することで得られる評判です。[ 29 ]

格差

プログラミングはもともと女性の職業とみなされていたが、コンピューティングの世界では依然として大きなギャップがある。[ 57 ]技術業界の女性は男性の望まない注目や嫌がらせを招いたり、技術知識において女性らしくないと思われたりするのではないかという不安に直面しており、社会的アイデンティティが大きな懸念事項となる傾向があり、これが自信に大きな影響を与えている。[ 40 ]男性の技術関係者の中には、女性が文化に溶け込むことは不可能だと考えていることを明らかにする者もおり、女性とその技術業界における立場の不安を助長している。さらに、オープンソースソフトウェアのような自発的な貢献の環境でさえ、OSSへの貢献において女性と男性は同じ生産性を示しているにもかかわらず、女性は手動テストやドキュメント作成など、プロジェクトの技術的でない側面を担当することになる傾向がある。明示的な偏見には、フィードバックに時間がかかること、コードがより精査されること、コードの受け入れ率が低いことなどがある。 [ 54 ]特にオープンソースソフトウェアコミュニティでは、性的に不快な言葉がよく使われ、OSS貢献者としてよりも女性としての女性のアイデンティティが重視されると女性は報告している。性別は関係ないという考えがあるため、偏見に対処するのは難しく、ほとんどの参加者は女性が特別扱いを受けるのは不公平であり、成功はスキルに依存するべきだと感じており、より包括的なものへの変更を妨げています。[ 40 ]

採用と応用

主要プロジェクト

オープンソースソフトウェアプロジェクトは、多くの場合ボランティアであるプログラマーのネットワークによって構築および維持され、無料製品だけでなく商用製品でも広く使用されています。[ 58 ]

  • Unix : UnixはAT&Tが開発したオペレーティングシステムで、オープンソースソフトウェアの先駆けとして始まりました。フリーソフトウェアおよびオープンソースソフトウェア革命は、開発者がUnixコードを使わずにオペレーティングシステムを作成しようと試み始めたことから始まりました。Unixは1960年代に開発され、ソフトウェアが商用化される前、オープンソースソフトウェアの概念が必要になる前だったため、真のオープンソースソフトウェアプロジェクトとは見なされていませんでした。1980年代半ばに商用化される前は、研究プロジェクトとして始まりました。商用化される前は、世界中のユーザーによる分散型のコラボレーション、ローリングリリース、プロプライエタリソフトウェアを嫌うコミュニティ文化など、フリーソフトウェアおよびオープンソースソフトウェア革命が掲げた多くの理想を体現していました。[ 24 ]
  • BSD： Berkeley Software Distribution（BSD）は、 1978年にUnixの派生として始まったオペレーティングシステムです。機能性を高めるため、UnixのコードとBerkeley研究所のコードを混合しました。BSDは機能性の向上に重点を置いていたため、主要なUnixオペレーティングシステムとBSDの優れた革新性を共有していました。これは、今日のFOSSの中心的な特徴である、自由なコード共有の一例です。1980年代にUnixが商用化されると、プロプライエタリソフトウェアを支持しない開発者やコミュニティのメンバーはBSDに注目し始め、Unixのコードを一切含まないオペレーティングシステムへと転換しました。BSDの最終バージョンは1995年にリリースされました。[ 24 ]
  • GNU : GNUは1984年にリチャード・ストールマンによって作成されたフリーのオペレーティングシステムで、その名前は「GnuはUnixではない」という意味です。そのアイデアは、誰でも使用でき、プログラマーがコードを自由に共有できる、 Unixの代替オペレーティングシステムを作成することでした。しかし、GNUの目標はUnixを置き換えることではなく、より技術的な機能を備えた優れたバージョンを作成することでした。フリーオープンソースソフトウェア革命の哲学的信念が真に定義される前にリリースされました。著名なFOSSプログラマーであるリチャード・ストールマンによって作成されたため、GNUはFOSS活動に深く関与しており、GNUの最大の功績の一つは、開発者が合法的に共有および改変可能なソフトウェアをリリースすることを可能にしたGNU一般公衆利用許諾書（GPL）の作成です。[ 24 ]
  • Apache: Apacheは1995年、 NCSA HTTPdコードベースへの不満から、独自のウェブサーバーをリリースした開発者グループの共同作業として始まりました。Apacheという名前は、このコードベースに複数のパッチを適用したことから付けられました。リリースから1年以内に、Apacheは世界をリードするウェブサーバーとなりました。その後まもなく、Apacheは独自のライセンスを導入し、FOSSコミュニティ全体に不和を生じさせましたが、最終的には成功を収めました。Apacheライセンスは、許可されたメンバーがソースコードに直接アクセスすることを可能にしており、GNUやLinuxのアプローチとは大きく異なっていました。[ 24 ]

ソフトウェア以外の用途のための拡張機能

オープンソースという用語は、もともとソフトウェアのソースコードにのみ適用されていましたが、現在ではオープンソースエコロジーなど、技術を分散化して誰でも使用できるようにする運動など、他の多くの分野にも適用されています。[ 13 ] [ 59 ]しかし、部分的にしか重複しない、異なる競合する原則を持つ他の分野に誤って適用されることがよくあります。[ 40 ]

オープンソースソフトウェアの根底にある同じ原則は、オープンソース、オープンコンテンツ、オープンコラボレーションなど、他の多くの事業にも見られます。[ 60 ] [ 3 ]

この「文化」あるいはイデオロギーは、営利企業で典型的に使用されるような、より中央集権化された開発モデルとは対照的に、異なる課題、アプローチ、優先事項の同時入力を容易にするために、原則がより一般的に適用されるという見解をとっています。[ 15 ]

価値

企業の90%以上がオープンソースソフトウェアを自社のプロプライエタリソフトウェアのコンポーネントとして使用しています。[ 61 ]オープンソースソフトウェアを使用するか、あるいは既存のオープンソースソフトウェアを改良するためにオープンソースプロジェクトに参加するかという決定は、典型的には実用的なビジネス上の決定です。[ 62 ] [ 63 ]プロプライエタリソフトウェアがオープンソースの代替品と直接競合する場合、その競争がプロプライエタリ製品の価格と品質に与える影響について、研究では矛盾する結果が示されています。[ 64 ]

数十年にわたり、一部の企業は、企業ユーザー向けのオープンソースソフトウェア製品のサービス提供をビジネスモデルとしてきました。これらの企業はオープンソースソフトウェア製品を管理し、ライセンス料や使用料ではなく、改良、統合、その他のサービス料を請求しています。[ 65 ]オープンソースコンポーネントをベースとしたSaaS（ Software as a Service）製品はますます普及しています。[ 66 ]

オープンソースソフトウェアは透明性を高め、科学的結果の検証と受け入れを助けるため、科学的なアプリケーションには好まれています。[ 67 ]

参照

参考文献

  1. ^ St. Laurent, Andrew M. (2008). 『オープンソースとフリーソフトウェアライセンスの理解』 O'Reilly Media. p. 4. ISBN 978-0-596-55395-1. 2023年4月22日時点のオリジナルよりアーカイブ。2023年3月21日閲覧。
  2. ^ Corbly, James Edward (2014年9月25日). 「フリーソフトウェアの代替手段：フリーウェア、オープンソースソフトウェア、そして図書館」 . Information Technology and Libraries . 33 (3): 65. doi : 10.6017/ital.v33i3.5105 . ISSN 2163-5226 . 2021年5月1日時点のオリジナルよりアーカイブ。 2021年4月28日閲覧。 
  3. ^ a b Levine, Sheen S.; Prietula, Michael J. (2013年12月30日). 「イノベーションのためのオープンコラボレーション：原則とパフォーマンス」. Organization Science . 25 (5): 1414– 1433. arXiv : 1406.7541 . doi : 10.1287/orsc.2013.0872 . ISSN 1047-7039 . S2CID 6583883 .  
  4. ^ホフマン、マヌエル、ネーグル、ヤヌオ、周（2024年）「オープンソースソフトウェアの価値」SSRN電子ジャーナル. doi : 10.2139/ssrn.4693148 . ISSN 1556-5068 . 
  5. ^ 「国際機関と承認」 Opensource.org、2015年4月21日。2019年7月23日時点のオリジナルよりアーカイブ。 2017年12月7日閲覧。
  6. ^ Perens, Bruce. Open Sources: Voices from the Open Source Revolution. Archived 15 September 2014 at the Wayback Machine . O'Reilly Media . 1999.
  7. ^ディボナ、クリス;サム・オックマン（1999年1月）。ブルース・ペレンズによるオープンソースの定義. オライリー. ISBN 978-1-56592-582-3。
  8. ^ 「オープンソースの定義」 2006年7月7日。2013年10月15日時点のオリジナルよりアーカイブ。 2008年8月24日閲覧。オープンソース・イニシアティブによるオープンソースの定義
  9. ^ 「オープンソースライセンスはいくつ必要か？ – Slashdot」 News.slashdot.org 2009年2月16日. 2013年7月17日時点のオリジナルよりアーカイブ。2012年3月25日閲覧。
  10. ^ Open Source Initiative (2006年7月24日). 「オープンソースの定義（注釈付き）」 . opensource.org . 2021年5月5日時点のオリジナルよりアーカイブ。2016年7月22日閲覧。
  11. ^ジョセフ・フェラー、ブライアン・フィッツジェラルド、スコット・ヒッサム、カリム・R・ラカニ (2005). 「序論」.フリーソフトウェアとオープンソースソフトウェアの展望. マサチューセッツ州ケンブリッジ: MITプレス. p. xvii. ISBN 0-262-06246-1。
  12. ^ Tiemann, Michael. 「OSIの歴史」 . Open Source Initiative. 2006年9月24日時点のオリジナルよりアーカイブ。2014年5月13日閲覧。
  13. ^ a b c d e f gリチャード・ストールマン（2007年）「なぜオープンソースはフリーソフトウェアの本質を見失うのか」。
  14. ^リチャード・ストールマン（2007年6月19日）「なぜ「フリーソフトウェア」は「オープンソース」よりも優れているのか」「GNUプロジェクトの理念」フリーソフトウェア財団。2021年3月27日時点のオリジナルよりアーカイブ。2007年7月23日閲覧。
  15. ^ a b c dレイモンド、エリック (2005). 「大聖堂とバザール（初版第3巻第3号、1998年3月）」 . First Monday . doi : 10.5210/fm.v0i0.1472 . ISSN 1396-0466 . 
  16. ^ a b c d e f g h i j k Robles, Gregorio (2006). 「フリー/リブレ/オープンソースソフトウェアに関する実証的ソフトウェアエンジニアリング研究」2006年第22回IEEE国際ソフトウェアメンテナンス会議. pp.  347– 350. doi : 10.1109/icsm.2006.25 . ISBN 0-7695-2354-4. S2CID  6589566 .
  17. ^ a b c d e f g Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). 「オープンソースソフトウェア開発プロセス：体系的レビュー」. 2020 IEEE 第24回国際エンタープライズ分散オブジェクトコンピューティング会議 (EDOC) . IEEE. pp.  135– 144. arXiv : 2008.05015 . doi : 10.1109/EDOC49727.2020.00025 . ISBN 978-1-7281-6473-1。
  18. ^ a b c d e Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). 「オープンソースソフトウェア開発プロセス：体系的レビュー」. 2020 IEEE 第24回国際エンタープライズ分散オブジェクトコンピューティング会議 (EDOC) . IEEE. pp.  135– 144. arXiv : 2008.05015 . doi : 10.1109/EDOC49727.2020.00025 . ISBN 978-1-7281-6473-1。
  19. ^米国国防総省. 「オープンソースソフトウェアに関するFAQ」 .最高情報責任者. 2016年8月28日時点のオリジナルよりアーカイブ。2016年7月22日閲覧。
  20. ^ Sharma, Srinarayan; Vijayan Sugumaran; Balaji Rajagopalan (2002). 「ハイブリッドオープンソースソフトウェアコミュニティを構築するためのフレームワーク」(PDF) . Information Systems Journal . 12 : 7– 25. doi : 10.1046/j.1365-2575.2002.00116.x . S2CID 5815589. 2008年10月30日時点のオリジナルよりアーカイブ(PDF) . 2008年9月8日閲覧. 
  21. ^ a bカール・レイノルズ、ジェレミー・ワイアット（2011年2月）「オープンソース、オープンスタンダード、そして医療情報システム」。メディカル・インターネット・リサーチ誌。13 (1): e24。doi : 10.2196/ jmir.1521。PMC 3221346。PMID 21447469。  
  22. ^ランドリー、ジョン、ラジブ・グプタ（2000年9月）「オープンソースから利益を得る」ハーバード・ビジネス・レビュー、doi：10.1225/F00503（2025年7月12日現在非アクティブ）。{{cite journal}}: CS1 maint: DOIは2025年7月時点で非アクティブです（リンク）
  23. ^ Nagle, Frank (2019年3月3日). 「政府の技術政策、社会的価値、そして国家競争力」 ( PDF) .情報システムジャーナル. 12. doi : 10.2139/ssrn.3355486 . S2CID 85509685. SSRN 3355486 .  
  24. ^ a b c d e f g h iトッツィ、クリストファー (2017). 『楽しさと利益のために：フリーソフトウェアとオープンソースソフトウェア革命の歴史』米国：MIT出版. ISBN 978-0-262-34118-9。
  25. ^ Plotkin, Hal (1998年12月). 「オープンソースソフトウェアについて知っておくべきこと（そしてその理由）」ハーバード・マネジメント・アップデート8–9ページ.
  26. ^ペイン、クリスチャン（2002年2月）「オープンソースソフトウェアのセキュリティについて」『情報システムジャーナル』12（1）：61-78。doi：10.1046 / j.1365-2575.2002.00118.x。S2CID 8123076。 
  27. ^ Shirey, Russell G. (2015年3月1日). 「Gitを暗号化された分散バージョン管理システムとして活用する」(PDF) .国防技術情報センター. p. 38. 2025年9月5日閲覧。
  28. ^ゾルキフリ、ナザトゥル・ヌルリサ;ガー、アミール。アジズ・デラマン (2018)。「バージョン管理システム: レビュー」。プロセディアコンピュータサイエンス。135 : 408 – 415.土井: 10.1016/j.procs.2018.08.191。
  29. ^ a b c d e Brasseur, VM (2018).オープンソースで未来を築く：スキルを磨き、ネットワークを構築し、テクノロジーの未来を築く。プラグマティック・プログラマーズ。ノースカロライナ州ローリー：The Pragmatic Bookshelf. ISBN 978-1-68050-301-2。
  30. ^ 「オープンソース」 . Open Collective . 2022年10月20日. 2024年5月28日閲覧。
  31. ^ 「テクノロジー」 .ソブリン・テック・ファンド. 2024年5月28日閲覧。
  32. ^ 「NSF、オープンソースプロジェクトに2,600万ドル以上を投資 | NSF - National Science Foundation」 new.nsf.gov 2023年10月25日. 2024年5月28日閲覧。
  33. ^ a b c Spinellis, Diomidis; Giannikas, Vaggelis (2012). 「オープンソースソフトウェアの組織的導入」 .システム・アンド・ソフトウェアジャーナル. 85 (3): 666– 682. doi : 10.1016/j.jss.2011.09.037 .
  34. ^ Zhang, Yiming; Malhotra, Baljeet; Chen, Cheng (2018). 「オープンソースセキュリティの業界全体にわたる分析」. 2018 第16回プライバシー、セキュリティ、トラストに関する年次会議 (PST) . IEEE. pp.  1– 10. doi : 10.1109/PST.2018.8514185 . ISBN 978-1-5386-7493-2. S2CID  53234981 .
  35. ^ a b c d e f gブロック、アマンダ（2023年）。オープンソースの法律、ポリシー、実践（第2版）。英国：オックスフォード大学出版局。ISBN 978-0-19-886234-5。
  36. ^ a b c d Wynants, M., & Cornelis, J. (編). (2005).未来はどれだけ開かれているのか? : フリーソフトウェアおよびオープンソースソフトウェアが生み出す経済、社会、文化のシナリオ. ASP.
  37. ^内閣府、「オープンソースのすべて：政府ITのためのオープンソースソフトウェア入門」バージョン2.0、8ページ、2012年4月発行、2025年10月1日にアクセス
  38. ^ a bパニエ、アリス（2022年）。「ソフトウェアパワー：オープンソースソフトウェアの経済的・地政学的影響」イフリ研究。ISBN 979-10-373-0641-8。
  39. ^ Maracke, Catharina (2019). 「フリー・オープンソースソフトウェアとFRANDベースの特許ライセンス：標準必須特許とフリー・オープンソースソフトウェアの仲介方法」 . The Journal of World Intellectual Property . 22 ( 3–4 ): 78– 102. doi : 10.1111/jwip.12114 . ISSN 1422-2213 . 
  40. ^ a b c d e f Bretthauer, David (2001). 「オープンソースソフトウェア：歴史」情報技術と図書館21 ( 1).
  41. ^ a b「International Authority & Recognition」 . Open Source Initiative . 2015年4月21日. 2023年12月18日閲覧。
  42. ^ a bカール・フォーゲル (2006).オープンソースソフトウェアの制作：フリーソフトウェアプロジェクトを成功させる方法(第1巻, [Nachdr.] 編). 北京ケルン: O'Reilly. ISBN 978-0-596-00759-1。
  43. ^ケルティ、クリストファー（2008年）『2つのビット：フリーソフトウェアの文化的意義』デューク大学出版局、ISBN 978-0-8223-8900-2。
  44. ^ミラー, キース・W.; ヴォアス, ジェフリー; コステロ, トム (2010). 「フリーソフトウェアとオープンソースソフトウェア」. IT Professional . 12 (6): 14– 16. Bibcode : 2010ITPro..12f..14M . doi : 10.1109/mitp.2010.147 . ISSN 1520-9202 . S2CID 265508713 .  
  45. ^ Zhu, Kevin Xiaoguo; Zhou, Zach Zhizhong (2012). 「研究ノート — ソフトウェア競争におけるロックイン戦略：オープンソースソフトウェア vs. プロプライエタリソフトウェア」情報システム研究23 ( 2): 536– 545. doi : 10.1287/isre.1110.0358 . ISSN 1047-7047 . 
  46. ^ 「オープンソースの定義（注釈付き）」Open Source Initiative、2006年7月24日。 2023年12月18日閲覧。
  47. ^ a b cリチャード・M・ストールマン、ジョシュア・ゲイ（2002年）『フリーソフトウェア、フリー社会』ボストン（マサチューセッツ州）：フリーソフトウェア財団。ISBN 978-1-882114-98-6。
  48. ^ Fortunato, Laura; Galassi, Mark (2021年5月17日). 「研究と学術におけるフリーソフトウェアとオープンソースソフトウェアの活用」 . Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences . 379 ( 2197 ) rsta.2020.0079. Bibcode : 2021RSPTA.37900079F . doi : 10.1098/rsta.2020.0079 . ISSN 1364-503X . OSTI 1836982. PMID 33775148. S2CID 232387092 .    
  49. ^ a b c Pinto, Gustavo; Steinmacher, Igor; Dias, Luiz Felipe; Gerosa, Marco (2018). 「オープンソース化プロプライエタリソフトウェアプロジェクトの課題について」 . Empirical Software Engineering . 23 (6): 3221– 3247. doi : 10.1007/s10664-018-9609-6 . ISSN 1382-3256 . S2CID 254467440 .  
  50. ^ a b Ågerfalk; Fitzgerald (2008). 「未知の労働力へのアウトソーシング：グローバルソーシング戦略としてのオープンソーシングの探求」MIS Quarterly . 32 (2): 385. doi : 10.2307/25148845 . ISSN 0276-7783 . JSTOR 25148845 .  
  51. ^ a b c Wachs, Johannes; Nitecki, Mariusz; Schueller, William; Polleres, Axel (2002年3月). 「オープンソースソフトウェアの地理：GitHubからの証拠」 .技術予測と社会変化. 176 121478. arXiv : 2107.03200 . doi : 10.1016/j.techfore.2022.121478 .
  52. ^ Rastogi, Ayushi; Nagappan, Nachiappan; Gousios, Georgios; van der Hoek, André (2018年10月11日). 「GitHubにおける開発者の貢献に対する地理的位置と評価の関係」 .第12回ACM/IEEE国際経験的ソフトウェア工学・計測シンポジウム論文集. ACM. pp.  1– 8. doi : 10.1145/3239235.3240504 . ISBN 978-1-4503-5823-1. S2CID  215822439 .
  53. ^ a b c dゴンザレス＝バラオナ、ジーザス M.ロブレス、グレゴリオ。アンドラダス・イスキエルド、ロベルト。ゴーシュ、リシャブ・アイイヤー (2008 年 8 月)。「リブレ ソフトウェア開発者の地理的起源」。情報経済と政策。20 (4): 356–363。土井: 10.1016/j.infoecopol.2008.07.001。
  54. ^ a b Bosu, Amiangshu; Sultana, Kazi Zakia (2019). 「オープンソースソフトウェア（OSS）プロジェクトにおける多様性と包摂性：現状と展望」2019 ACM/IEEE 国際経験的ソフトウェア工学・計測シンポジウム (ESEM) . IEEE. pp.  1– 11. doi : 10.1109/ESEM.2019.8870179 . ISBN 978-1-7281-2968-6. S2CID  197640269 .
  55. ^ Nafus、Dawn（2012年6月）。「パッチに性別はない：オープンソースソフトウェアにおいてオープンではないもの」 . New Media & Society . 14 (4): 669– 683. doi : 10.1177/1461444811422887 . ISSN  1461-4448 . S2CID  206727320 .
  56. ^ Trinkenreich, Bianca; Wiese, Igor; Sarma, Anita; Gerosa, Marco; Steinmacher, Igor (2022年10月31日). 「オープンソースソフトウェアにおける女性の参加：文献調査」 . ACM Transactions on Software Engineering and Methodology . 31 (4): 1– 37. arXiv : 2105.08777 . doi : 10.1145/3510460 . ISSN 1049-331X . S2CID 234778104 .  
  57. ^ Albusays, Khaled; Bjorn, Pernille; Dabbish, Laura; Ford, Denae; Murphy-Hill, Emerson; Serebrenik, Alexander; Storey, Margaret-Anne (2021年4月). 「ソフトウェア開発における多様性の危機」 . IEEE Software . 38 (2): 19– 25. Bibcode : 2021ISoft..38b..19A . doi : 10.1109/MS.2020.3045817 . ISSN 0740-7459 . 
  58. ^ Popp, Karl Michael編 (2020).オープンソースソフトウェアの商用利用に関するベストプラクティス：オープンソースソフトウェア管理のためのビジネスモデル、プロセス、ツール. Synnomic Academy. Norderstedt: BoD – Books on Demand. ISBN 978-3-7386-1909-6。
  59. ^ Powers, Stephen M.; Hampton, Stephanie E. (2019). 「生態学におけるオープンサイエンス、再現性、透明性」 . Ecological Applications . 29 (1): e01822. Bibcode : 2019EcoAp..29E1822P . doi : 10.1002/eap.1822 . ISSN 1051-0761 . PMID 30362295 .  
  60. ^ Cheliotis, Giorgos (2009). 「オープンソースからオープンコンテンツへ：オープンな文化制作における組織、ライセンス、意思決定プロセス」 . Decision Support Systems . 47 (3): 229– 244. doi : 10.1016/j.dss.2009.02.006 . ISSN 0167-9236 . 
  61. ^バトラー他2022年、1頁。
  62. ^バトラーら。 2022、p. 11152.
  63. ^ダビラ 2015、7ページ。
  64. ^周＆チョードリー 2022、731頁。
  65. ^オーガストら。 2021、1–2 ページ。
  66. ^ August et al. 2021、p.1。
  67. ^ Morin et al. 2012、「互換性、増殖、断片化、方向性」。

さらに読む

ウィキメディア コモンズには、フリー ソフトウェアに関連するメディアがあります。
Wikibooksにはオープンソースに関する書籍があります
ウィキブックスには「ソースの使用」に関する書籍があります。
ロゴ
Scholia には、オープンソース ソフトウェアに関するトピックプロファイルがあります。
「 https://en.wikipedia.org/w/index.php?title=Open-source_software&oldid=1334976712#Open-sourcing」より取得