Loading article…
オープンソースソフトウェア（OSS）は、著作権者がユーザーにソフトウェアとそのソースコードを誰にでも、どのような目的でも使用、調査、変更、配布する権利を付与するライセンスに基づいてリリースされるコンピュータソフトウェアです。 [1] [2]オープンソースソフトウェアは、共同で公開された方法で開発される場合があります。オープンソースソフトウェアはオープンコラボレーションの顕著な例であり、能力のあるユーザーであれば誰でもオンラインで開発に参加できるため、貢献者の数は無制限です。コードを調べることができるため、ソフトウェアに対する一般の信頼が高まります。[3]
オープンソースソフトウェアの開発は、単一の企業を超えた多様な視点をもたらすことができます。オープンソースソフトウェアが企業にもたらす価値は2024年に8.8兆ドルと推定されており、オープンソースソフトウェアを使用しない場合、企業は現在の3.5倍の費用を費やす必要があるでしょう。[4]
オープンソース コードは学習に使用でき、有能なエンド ユーザーは、ユーザー スクリプトやカスタムスタイル シートがWeb サイトで許可するのと同様に、ソフトウェアを個人的なニーズに合わせて調整し、最終的には同様の好みを持つユーザー向けにフォークとして変更を公開し、プル リクエストとして可能な改善を直接送信できます。
定義
オープンソース・イニシアティブ（OSI）の定義は、国際的にいくつかの政府によって標準または事実上の定義として認められています[5]。OSIは、ソフトウェアライセンスをオープンソースと見なすかどうかを決定するために、オープンソース定義を使用しています。この定義は、主にペレンズによって作成および改訂されたDebianフリーソフトウェアガイドラインに基づいています。 [6] [7] [8]ペレンズは、後に広く利用可能になったフリーソフトウェア財団（FSF）の「4つの自由」に基づいて執筆したわけではありません。[9]
ペレンズの定義によれば、オープンソースとは、コードの使用や変更に対する制限が緩い、またはまったくない状態でソースコードを一般大衆に公開する広範なソフトウェアライセンスである。オープンソースの明確な「特徴」は、ソフトウェアの急速な進化を可能にするために、組織やユーザーによる使用や配布にほとんど制限を課さないことである。[10]
フェラーら（2005）によると、「フリーソフトウェア」および「オープンソースソフトウェア」という用語は、「ユーザーがソフトウェアの作者にロイヤリティや料金を支払うことなく、適切と思われる方法でソフトウェアを使用、変更、再配布することを許可する条件で配布されるソフトウェア製品」に適用されるべきである。[11]
当初は受け入れていたものの、[12] FSF のリチャード・ストールマンは、現在では「オープンソース」という用語が「フリーソフトウェア」と呼ばれるものに適用されることに断固反対している。ストールマンは、この 2 つの用語が「ほぼ同じカテゴリのソフトウェア」を表すことに同意しているものの、この用語を同一視することは誤りであり誤解を招くと考えている。 [13]ストールマンはまた、オープンソース・イニシアチブの公言する実用主義にも反対している。FSF のソフトウェアの自由に関する理想主義的な基準を妥協することで、自由とコミュニティというフリーソフトウェアの理想が脅かされるのではないかと懸念しているからだ。 [14] FSF はフリーソフトウェアをオープンソースソフトウェアのサブセットと見なしており、リチャード・ストールマンは、たとえばDRMソフトウェアは、ユーザーに自由を与えない (ユーザーを制限する) にもかかわらず、オープンソースとして開発できるため、フリーソフトウェアの資格を満たさないと説明した。[13]
オープンソースソフトウェア開発
開発モデル
オープンソースの有力な貢献者であるエリック・S・レイモンドは、1997年のエッセイ「大聖堂とバザール」で、OSSを開発するためのバザールモデルというモデルを提案しています。[15]レイモンドは、伝統的な方法論によるソフトウェア開発を、個人または小グループによる慎重で孤立した作業による大聖堂の建設に例えています。 [ 15]彼は、すべてのソフトウェアは、異なるアジェンダとアプローチでバザールスタイルを使用して開発されるべきであると提案しています。[15]
彼が大聖堂モデルと呼んだ伝統的な開発モデルでは、開発は集中的に行われます。[15]役割は明確に定義されています。[15]役割には、設計に専念する人々（アーキテクト）、プロジェクト管理の責任者、実装の責任者が含まれます。[15]伝統的なソフトウェアエンジニアリングは、大聖堂モデルに従います。[15]
しかし、バザールモデルは異なります。[15]このモデルでは、役割は明確に定義されていません。[15]バザールモデルを使用して開発されたソフトウェアの提案された特性には、次のパターンが見られるはずです。[16]
ユーザーは共同開発者として扱われるべき:ユーザーは共同開発者として扱われるべきであり、したがってソフトウェアのソースコードにアクセスできるべきである。 [16]さらに、ユーザーはソフトウェアへの追加、ソフトウェアのコード修正、バグレポート、ドキュメントなどを提出することが奨励される。共同開発者が増えるほど、ソフトウェアの進化速度が速まる。 [16] リーナスの法則によれば、十分な数の目があれば、すべてのバグは浅くなる。 [16]これは、多くのユーザーがソースコードを閲覧すれば、最終的にはすべてのバグが見つかり、修正方法を提案することになるということを意味する。 [16]一部のユーザーは高度なプログラミングスキルを持っており、さらに、各ユーザーのマシンは追加のテスト環境を提供する。 [16]この新しいテスト環境は、新しいバグを見つけて修正する機能を提供する。 [16]
早期リリース：ソフトウェアの最初のバージョンは、共同開発者を早期に見つける可能性を高めるために、できるだけ早くリリースされるべきです。 [16]
頻繁な統合：コードの変更は、プロジェクトのライフサイクルの終わりに大量のバグを修正するオーバーヘッドを避けるために、できるだけ頻繁に統合（共有コードベースにマージ）する必要があります。 [16] [17]一部のオープンソースプロジェクトでは、統合が自動的に行われる夜間ビルドを行っています。 [16]
複数のバージョン:ソフトウェアには少なくとも 2 つのバージョンが必要です。 [16]バグが多く機能が多いバージョンと、より安定していて機能が少ないバージョンが必要です。 [16]バグのあるバージョン (開発バージョンとも呼ばれます) は、最新の機能をすぐに使用したいユーザーや、まだ十分にテストされていないコードを使用するリスクを受け入れたいユーザー向けです。 [16]ユーザーは共同開発者として行動し、バグを報告したり、バグ修正を提供したりできます。 [16] [18]
高度なモジュール化：ソフトウェアの一般的な構造はモジュール化されており、独立したコンポーネントの並行開発が可能である必要があります。 [16]
動的な意思決定構造：変化するユーザー要件やその他の要因に応じて戦略的な決定を下す、公式または非公式の意思決定構造が必要である。 [16]エクストリームプログラミングと比較してください。 [16]
オープンソース開発のプロセスは、開発者がプロジェクトに新しい機能を追加する必要があるか、バグを修正する必要があるかを検討する要件抽出から始まります。 [18]これは、バグ報告と追跡、メーリングリスト、プロジェクトページなどの手段を通じてOSSコミュニティとコミュニケーションをとることによって確立されます。 [18]次に、OSS開発者はタスクを選択するか、タスクに割り当てられ、ソリューションを特定します。 OSSではソリューションに多くの異なるルートが考えられることが多いため、慎重に検討し、場合によってはピアフィードバックも得て、最善のソリューションを選択する必要があります。[18]次に、開発者はコードの開発とコミットを開始します。[18]次に、コードはピアによってテストされ、レビューされます。[18]開発者は、継続的インテグレーションからのフィードバックを通じてコードを編集および進化させることができます。[18]リーダーシップとコミュニティがプロジェクト全体に満足したら、部分的にリリースし、ユーザー向けの手順を文書化できます。[18]プロジェクトのリリース準備が整ったら、重大なバグ修正またはセキュリティ修復のみが行われて凍結されます。[18]最終的にプロジェクトは完全にリリースされ、マイナーなバグ修正のみが行われました。[18]
利点
標準規格のオープンソース実装は、その標準規格の採用を増やすことができます。[19]これにより、開発者は権限を与えられ、最終製品に対する所有権意識を持つようになるため、開発者の忠誠心が生まれます。[20]
さらに、OSSにはマーケティングや物流サービスのコスト削減も求められています。[21] OSSは、商用製品を含め、企業のイメージを宣伝するツールとなり得ます。[22] OSS開発アプローチは、信頼性が高く、高品質のソフトウェアを迅速かつ安価に生産するのに役立っています。[21]
オープンソース開発は、イノベーションを加速させ、社会的価値を生み出す可能性を秘めています。[23]例えばフランスでは、政府が無料のオープンソースソフトウェアを推奨するよう奨励する政策により、OSSの貢献が年間約60万件に増加し、オープンソースソフトウェアの量と質を高めることで社会的価値を生み出しました。[23]この政策により、技術系スタートアップが最大18%増加し、IT部門の雇用者数が14%増加したと推定されています。[23]
OSSは、何千人もの独立したプログラマーがソフトウェアのバグをテストし修正することで、高い信頼性を実現できます。[16]オープンソースは、それを最初に作成した会社や著者に依存しません。[24]たとえ会社が倒産しても、コードは存在し続け、ユーザーによって開発され続けます。[24]
OSSは柔軟性があり、モジュール式システムによりプログラマーがカスタムインターフェースを構築したり、新しい機能を追加したりすることができます。また、オープンソースプログラムは多数の異なるプログラマーのコラボレーションの成果であるため革新的です。[16]異なる視点、企業目標、個人の目標を組み合わせることでイノベーションが加速します。[25]
さらに、フリーソフトウェアは純粋に技術的な要件に従って開発することができます。 [ 26] ソフトウェアの品質を低下させることの多い商業的な圧力について考える必要はありません。[26]商業的な圧力により、従来のソフトウェア開発者はセキュリティ要件よりも顧客の要件に注意を払うようになります。なぜなら、そのような機能は顧客には見えないからです。[26]
開発ツール
オープンソースソフトウェア開発では、製品の開発と開発プロセス自体をサポートするためにツールが使用されます。[18]
集中型バージョン管理システム (CVCS) や分散型バージョン管理システム(DVCS)などのバージョン管理システムは、多くの場合オープンソースであり、ソフトウェアプロジェクトのソースコードファイルとそれらのファイルへの変更を管理してコラボレーションを促進するツールの例です。 [27] CVCS は中央リポジトリで集中化されていますが、DVCS は分散化されており、ユーザーごとにローカルリポジトリがあります。[27] 同時バージョン管理システム(CVS) や、その後のSubversion (SVN) とGitは CVCS の例です。[27]リポジトリは、 GitHubなどのソースコードホスティング施設でホストされ、公開されます。[27]
オープンソースプロジェクトでは、問題追跡ツールなどのユーティリティを使用してオープンソースソフトウェアの開発を整理します。一般的に使用されるバグ追跡ツールには、 BugzillaやRedmineなどがあります。[18]
メーリングリストやIRCなどのツールは、開発者間の調整やバグの議論の手段を提供します。[18]プロジェクトのWebページ、Wikiページ、ロードマップリスト、ニュースグループでは、エンドユーザーに焦点を当てたプロジェクト情報を配布できます。[18]
参加の機会
貢献する
OSS参加者の基本的な役割は、プロジェクトの中心にいて、その実行をコントロールするリーダーから始まり、複数のカテゴリーに分類されます。[28]次に、プロジェクトで豊富な経験と権限を持ち、他の貢献者を指導する可能性のあるコア貢献者がいます。[28]コア貢献者以外の貢献者は経験と権限は少ないですが、定期的に貢献しており、プロジェクトの発展に不可欠です。[28]新しい貢献者は経験が最も浅いですが、指導とガイダンスがあれば定期的な貢献者になることができます。[28]
オープンソースソフトウェアへの貢献方法としては、プログラミング、ユーザーインターフェースの設計とテスト、Webデザイン、バグトリアージ、アクセシビリティの設計とテスト、UX設計、コードテスト、セキュリティレビューとテストなどの役割が考えられます。[28]ただし、コーディングスキルがなくてもOSSプロジェクトに貢献する方法はいくつかあります。[28]たとえば、あまり技術的でない参加方法としては、ドキュメントの作成と編集、翻訳、プロジェクト管理、イベントの企画と調整、マーケティング、リリース管理、コミュニティ管理、広報とアウトリーチなどがあります。[28]
資金援助は、個人や組織がオープンソース プロジェクトに貢献するために選ぶもう 1 つの素晴らしい方法です。Open Collectiveのようなグループは、個人が自分の好きなプロジェクトを支援するために毎月寄付する手段を提供しています。[29] Sovereign Tech Fundのような組織は、ドイツ政府が使用するツールを支援するために数百万ドルを寄付することができます。[30] National Science Foundation は、オープンソース イノベーションを支援するために、Pathways to Enable Open-Source Ecosystems (POSE) プログラムを設立しました。[31]
業界の参加
業界によるオープンソースソフトウェアの採用は、時間とともに増加しています。[32] OSSは、そのメリットにより、通信、航空宇宙、ヘルスケア、メディア＆エンターテインメントなどの多くの業界で人気があります。 [33] OSSの採用は大規模な組織でより一般的であり、企業のIT使用状況、運用効率、従業員の生産性に依存します。[32]
産業界では、バックオフィス機能、販売サポート、研究開発、ソフトウェア機能、迅速な導入、プラットフォーム間の移植性、商用ライセンス管理の回避などの理由でOSSを使用する可能性が高い。[32]さらに、ハードウェアと所有コストの削減も重要な利点である。[32]
著名な組織
フリーソフトウェアやオープンソースソフトウェアの運動の発展と拡大に貢献する組織は世界中に存在します。[28]これらの組織は、教育や技術の普及などの目標に専念しています。[28]オープンソースイニシアティブの元副会長が挙げているように、アメリカの組織には、フリーソフトウェア財団、ソフトウェア自由保護協会、オープンソースイニシアティブ、公共の利益のためのソフトウェアなどがあります。[28]ヨーロッパでは、フリーソフトウェア財団ヨーロッパ、オープンソースプロジェクトEU（OSP）、オープンフォーラムヨーロッパ（OFE）などの組織が有名です。[28]オーストラリアの組織にはlinux australiaがあり、アジアにはopen source asiaとfossasiaがあります。[28]アフリカの組織にはfree and open source software for africa（FOSSFA）とopenafricaがあり、中央アジアと南アジアにはFLISOLやGRUP de usuarios de software libre peruなどの組織があります。 [28]これらのほかにも、オープンソースソフトウェアの推進に専念する組織が数多く存在します。[28]
法的および経済的問題
ライセンス
FOSS製品は、一般的に、パーミッシブライセンスとコピーレフトライセンス の2種類のライセンスでライセンス供与されます。[34]これらの2種類のライセンスは、より多くのユーザーがソフトウェアにアクセスできるようにし、ライセンスごとに独自のルールがあるため、特定のライセンスの条件で指定された派生作品の作成を許可するという点で、プロプライエタリライセンスとは異なります。 [34]パーミッシブライセンスでは、ソフトウェアの受領者は、配布に同じライセンスを使用しなくても、著者の著作権を実装できます。 [34]この種類のライセンスの例には、BSD、MIT、およびApache ライセンスがあります。[34]コピーレフトライセンスは、受領者が作品の配布の少なくとも一部に同じライセンスを使用することを要求するという点で異なります。[34]強いコピーレフトライセンスでは、すべての派生作品に同じライセンスを使用する必要がありますが、弱いコピーレフトライセンスでは、特定の条件下でのみ同じライセンスを使用する必要があります。[34]この種類のライセンスの例には、 GNU ファミリーのライセンス、およびMPLライセンスとEPLライセンスがあります。 [ 34]これら2つのライセンスの類似点としては、著作権の広範な付与、受領者による著作権表示の保存の義務付け、ライセンスのコピーがコードとともに受領者に提供されることなどが挙げられます。[34]
オープンソースソフトウェアに関する重要な法的先例の1つは、2008年にJacobson v Katzer事件で作成されたもので、この事件では、改変の帰属と識別を含むArtisticライセンスの条件が強制されました。 [34]この事件の判決により、ライセンスの条件が守られなかった場合の著作権法に基づく強制が確立されました。[34] Artisticライセンスは他のオープンソースソフトウェアライセンスと類似していたため、この判決は広く適用される先例を作成しました。[34]
フリーソフトウェアライセンス/オープンソースライセンスの例としては、Apacheライセンス、BSDライセンス、GNU一般公衆利用許諾書、GNU劣等一般公衆利用許諾書、MITライセンス、Eclipseパブリックライセンス、Mozillaパブリックライセンスなどがあげられる。[34]
法的問題
ソフトウェア規制には、オープンソースソフトウェアに大きな影響を与えるグレーゾーンがいくつかあります。たとえば、ソフトウェアは商品かサービスか、何が変更と見なされるか、契約とライセンスによるガバナンス、所有権と使用権などです。[34]これらの問題に関しては進展がありましたが、さらに多くの疑問が生じることがよくあります。[34]規制におけるこれらの不確実性の存在は、テクノロジーに関わる業界全体に悪影響を及ぼします。[34]
ソフトウェア全体の法的歴史においては、ソフトウェアを知的財産として特許法、著作権法の下で保護するか、あるいは独自の規制を確立するかについて多くの議論がありました。[34]最終的には、著作権法が標準となり、コンピュータプログラムは文学作品の一形態とみなされ、独自の規制が若干調整されました。[34]
ソフトウェアは一般にソースコードとオブジェクトコードと考えられており、どちらも保護可能ですが、この定義には法的多様性があります。[34]一部の法域では、独自の目的でこの概念を拡大または縮小しようとしています。[34]たとえば、欧州司法裁判所は、コンピュータプログラムには、プログラムの機能、プログラミング言語、またはデータファイルの形式は含まれないと定義しています。[34]ソフトウェアのさまざまな側面の保護を制限することにより、法律はソフトウェアの使用に対するオープンソースアプローチを支持しています。[34]特に米国はソフトウェアに対してオープンなアプローチを採用しており、ほとんどのオープンソースライセンスは米国で生まれています。[34]ただし、これによりこれらのライセンス内の特許権への焦点が高まり、他の形式の知的財産保護を好むOSSコミュニティからの反発が起こっています。[34]
もう一つの問題は、技術的保護手段（TPM）とデジタル著作権管理（DRM）技術です。これらは、1996年の世界知的所有権機関（WIPO）条約で国際的に法的に認められ、保護されています。 [34]オープンソースソフトウェアの支持者は、これらの技術が著作権法を超えてエンドユーザーを制限する可能性があるため、嫌っていました。[34]ヨーロッパは、このような苦情に応えてTPMを法的に管理し、OSS支持者の勝利を示しました。[34]
経済/ビジネスへの影響
オープンソースコミュニティでは、制作者が制作したソフトウェアを所有するのではなく、進化するソフトウェアの開発を所有します。[35]このように、ソフトウェアの将来はオープンであり、OSS内での所有権や知的財産権の保持は困難です。 [35] ライセンスとブランディングにより、他者による盗難を防ぎ、公共財としての地位を維持できます。[35]オープンソースソフトウェアは、誰でも利用でき、1人がダウンロードしたからといって他の人にとっての価値が下がるわけではないため、公共財と見なすことができます。 [ 35]オープンソースソフトウェアは、リソースが減少するのではなく、使用され、貢献されるにつれて価値が上がるという点でユニークです。これは、評判への投資やネットワーク効果などの概念によって説明されます。[35]
オープンソースソフトウェアの経済モデルは、開発者がプロジェクトに貢献することで公共の利益を生み出すという形で説明できます。[35]開発者は、プロジェクトの評判や価値の向上など、認識される利益やコストに基づいてプロジェクトを選択します。[35]開発者の動機はさまざまな場所や理由から生まれますが、重要なのは、お金が唯一の、あるいは最も重要なインセンティブではないということです。[35]
経済理論は主に希少資源の消費に焦点を当てているため、OSSのダイナミクスは理解しにくい場合があります。OSSでは、生産者はプロジェクトへの貢献の報酬を得ることで消費者になります。[35]たとえば、開発者はOSSプロジェクトへの貢献が成功すると、同僚から高く評価されます。[35] OSSの社会的利益と相互作用は、経済モデルでも説明が困難です。[35]さらに、技術革新によって価値に関する議論や見通しが絶えず変化するため、経済モデルでは社会的行動を予測できなくなります。[35]
OSSは経済モデルでは理論的に難しいが、資源を必要とする持続可能な社会活動として説明できる。[35]これらの資源には、時間、お金、技術、貢献などが含まれる。[35]多くの開発者は大学や政府などの組織が資金提供した技術を使用しているが、これらの組織もOSSの成果から利益を得ている。[35] OSSが成長するにつれて、OSSとプロプライエタリシステムを組み合わせたハイブリッドシステムが一般的になりつつある。[35]
2000年代半ばを通じて、ますます多くのテクノロジー企業がOSSを使い始めました。[24]例えば、デルはGNU/Linuxがすでにインストールされたコンピュータを販売しました。[24] マイクロソフト自身も、以前はOSS運動に敵意を持っていましたが、Linuxベースのオペレーティングシステムをリリースしました。 [24]これらの展開にもかかわらず、これらの企業は特定の目的にのみOSSを使用する傾向があり、OSSが企業に利用され、見返りがないのではないかとの懸念につながっています。[24]
政府が使用する
多くの政府がオープンソースソフトウェアの導入と推進に関心を示しているが、その多くの利点から、サイバーセキュリティという大きな問題も考慮すべきである。[36]偶発的な脆弱性はあり得るが、外部からの攻撃も起こり得る。[36]このような懸念から、ソフトウェアのガバナンスに貢献することへの政府の関心が高まっている。[36]しかし、これらは問題の大まかな概要であり、各国はオープンソースソフトウェアとの独自の政治的な関わりとその導入目標を持っている。[36]たとえば、米国は、中国やロシアなどの国でのオープンソースソフトウェア活動の増加が脅威であると認識されているため、オープンソースソフトウェアの導入に関して国家安全保障に焦点を当てており、国防総省はOSSの使用に関する複数の基準を検討している。 [36]これらの基準には、信頼できるソースから提供され、そのソースによって維持されているかどうか、それが継続的に維持されるかどうか、ソフトウェアのサブコンポーネントへの依存関係があるかどうか、コンポーネントのセキュリティと整合性、外国政府の影響などが含まれる。[36]
オープンソースに関する政府にとってのもう一つの問題は、オペレーティングシステム、半導体、クラウド、人工知能などの技術への投資である。[36]これらの技術はすべて、グローバルな協力に影響を与え、セキュリティの問題や政治的影響を引き起こします。[36]多くの国は、これらのパートナーシップにおいて技術革新と技術依存のバランスを取らなければなりません。[36]たとえば、中国のオープンソース依存企業であるHuaweiは、2019年にGoogleのAndroidシステムの使用を禁止された後、独自の代替オペレーティングシステムであるHarmony OSの開発を開始しました。[36]
ドイツは最近、自国が使用するソフトウェアのガバナンスとメンテナンスを支援するために、 ソブリン・テック・ファンドを設立しました。
オープンソフトウェア運動
歴史
1950年代から1960年代にかけてのコンピュータの黎明期には、プログラマーと開発者はソフトウェアを共有して互いに学び合い、コンピュータの分野を発展させていました。 [37]たとえば、Unixにはユーザー向けにオペレーティングシステムのソース コードが含まれていました。 [37]最終的には、1970年から1980年にかけてのソフトウェアの商用化により、この慣行は禁止され始めました。 [37]しかし、学者は依然として共同でソフトウェアを開発することが多かったです。[37]
これに応じて、ハッカーやハッカー文化として広く知られている熟練したプログラマーの活動からオープンソース運動が生まれました。[38]これらの熱狂者の一人、リチャード・ストールマンは、後にオープンソース運動を可能にするフリーソフトウェア運動の原動力でした。[17] 1984年、研究室のプログラマー文化がプロプライエタリソフトウェアによってソースコードの共有や改良が妨げられ、抑圧されたことを受けて、彼はMITを辞職し、フリーオペレーティングシステムのGNUを作成しました。 [17] GNUはUNIXと互換性があり、プログラマーの熱狂者にとってはまだその仕組みがよくわかっていました。[17]しかし、ストールマンがフリーソフトウェアに選んだラベルには混乱があることがすぐに明らかになりました。彼は、フリーをビールのフリーではなく、言論のフリーと表現し、フリーが価格ではなく自由であるという意味に言及しました。[17]彼は後に、この自由の概念を4つの基本的な自由にまで拡張しました。[17] GNUを通じて、他者のソースコード、コミュニティのバグ修正、新機能のコード提案を取り入れるというオープンソースの規範が生まれました。[17] 1985年、ストールマンはソフトウェアの変更を促進し、GNUの作成を支援するためにフリーソフトウェア財団（FSF）を設立しました。 [17]自分の作品がプロプライエタリなソフトウェアに使用されるのを防ぐために、ストールマンはコピーレフトの概念を生み出しました。これは、特定の条件の下で誰でも自分の作品を使用できるというものでした。[17]これを行うために、彼は1989年にGNU一般公衆利用許諾書（GNU GPL）を作成し、1991年に更新しました。[17] 1991年、GNUにはカーネルがなかったため、GNUはリーナス・トーバルズによって書かれたLinuxカーネルと統合されました。[39]このオペレーティングシステムは現在、通常Linuxと呼ばれています。[17]この期間中、当時は他にも多くのフリーソフトウェアプロジェクトやライセンスが存在し、フリーソフトウェアの概念がどのようなものであるべきか、また、Berkeley Software Distribution、TeX、X Window Systemなどのプロプライエタリソフトウェアの倫理性についてそれぞれ異なる考えを持っていました。[40]
フリーソフトウェアが発展するにつれ、フリーソフトウェア財団は、フリーソフトウェアのアイデアと認識されている利点を商用ソフトウェア業界にもたらす方法を検討し始めました。[40] FSFの社会運動は企業にとって魅力的ではなく、ソフトウェアソースコードの共有とコラボレーションのビジネス上の可能性を強調するために、フリーソフトウェア運動をリブランディングする方法が必要であるという結論に達しました。 [40]オープンソースという用語は、1998年にフリーソフトウェアの支持者の会議でクリスティン・ピーターソンによって提案されました。 [17]グループの多くは、フリーソフトウェアという名前は新参者を混乱させ、業界の関心を妨げていると感じ、オープンソースという新しい名称をすぐに受け入れ、オープンソース・イニシアティブ（OSI）とオープンソースソフトウェアに関するOSIの定義を作成しました。[17]オープンソース・イニシアティブ（OSI）の定義は現在、国際的にいくつかの政府によって標準または事実上の定義として認められています。[39]この定義は、主にブルース・ペレンズによって作成および改訂されたDebianフリーソフトウェアガイドラインに基づいています。[41] OSIの定義は、プロプライエタリソフトウェアの組み込みを許可し、ライセンスの自由度を高めている点でフリーソフトウェアの定義とは異なっている。 [17]ストールマンなど一部の人々は、プロプライエタリソフトウェアに対して強い道徳的立場を取っているため、結果としてフリーソフトウェアの本来のコンセプトに賛同しているが、ソフトウェアの運用という点では、この2つの運動の間には多くの重複がある。[17]
オープンソース・イニシアティブは、新しい用語の使用を奨励し、その遵守原則を広めようと努めたが、商用ソフトウェアベンダーは、自由に配布されるソフトウェアの概念とアプリケーションのソースコードへの普遍的なアクセスによってますます脅威を感じるようになり、 2001年にはマイクロソフトの幹部がオープンソースを知的財産の破壊者と呼んだ。[42]しかし、フリー・オープンソース・ソフトウェア（FOSS）は歴史的に主流の民間ソフトウェア開発の外で役割を果たしてきたが、マイクロソフトのような大企業はインターネット上で公式のオープンソースの存在を築き始めている。[42] IBM、オラクル、ステート・ファームは、今日の競争の激しいオープンソース市場に真剣に公的関心を持っている企業のほんの一例に過ぎず、FOSSの開発に関する企業哲学の大きな変化を示している。[42]
未来
オープンソースソフトウェアコミュニティ、ひいてはフリーソフトウェアコミュニティの将来は、その理念について混乱していなければ成功している。[24]たとえば、AndroidとUbuntu は、2000 年代初頭に存在した技術革新の傍らでオープンソースソフトウェアが台頭してきた成功のマイルストーンの例である。[24]しかし、コミュニティの一部は、Android の OSS センターを Google とそのパートナーが軽視していること、 Apache ライセンスを使用してフォークを許可し、Android 内でのコラボレーションの機会が失われたこと、Ubuntu で自由よりも共存が優先されていること、Ubuntu 内にマーケティング目的でユーザーを追跡する機能があることなどの問題により、これらを OSS の代表として失敗していると考えている。[24]
OSSの使用はビジネスでより一般的になり、企業の78％が業務のすべてまたは一部をFOSSで実行していると報告しています。[24] OSSの人気は高まり、かつてはOSSを批判していたMicrosoftが、自社のシステムにOSSの使用を組み込むほどになりました。 [24]しかし、この成功はOSSの将来を決定する懸念を引き起こしました。コミュニティは、OSSとは何か、それは何であるべきか、そして保護する必要があるのであれば、それを保護するには何をすべきかなどの質問に答える必要があります。[24]全体として、フリーオープンソース革命は市場で認識された均衡まで減速しましたが、それはそれが終わったことを意味するものではなく、その将来を決定するために多くの理論的議論が行われなければなりません。[24]
他のソフトウェアライセンス/開発モデルとの比較
クローズドソース/プロプライエタリソフトウェア
オープンソースソフトウェアは、公開されていること、ライセンスに料金がかからないこと、ライセンス仕様に従って変更や配布が許可されている点で、プロプライエタリソフトウェアとは異なります。[43]これらすべてが、プロプライエタリソフトウェアの目標であるOSS製品の独占を防ぐのに役立ちます。[43]プロプライエタリソフトウェアでは、そのソフトウェアの使用、アップグレード、または他のソフトウェアへの切り替えのいずれかに顧客の選択肢が制限されるため、顧客は金銭的なコストによってソフトウェアの好みが左右されることになります。[43]プロプライエタリソフトウェアベンダーにとって理想的なシナリオは、顧客がこれらのコストのためにソフトウェアを切り替えない、または切り替えることができず、そのベンダーから製品を購入し続けるというロックインです。[ 43]
プロプライエタリソフトウェアでは、バグ修正はベンダーのみが提供でき、プラットフォームを移行するには別の購入が必要であり、製品の存在はベンダーに依存しており、ベンダーはいつでも製品を中止することができます。[38]さらに、プロプライエタリソフトウェアはソースコードを提供しないため、ユーザーが変更することはできません。[17]企業にとって、これはセキュリティ上のリスクとフラストレーションの原因となる可能性があります。製品をニーズに合わせて特化することができず、ソフトウェア内に隠れた脅威や情報漏洩があり、アクセスしたり変更したりできない可能性があるためです。[17]
フリーソフトウェア
OSIの定義によれば、オープンソースとは、コードの使用や変更に対する制限を緩和または制限なしに、ソースコードを一般に公開する広範なソフトウェアライセンスである。[44]オープンソースの明確な特徴は、ソフトウェアの急速な進化を可能にするために、組織やユーザーによる使用や配布にほとんど制限を課さないことである。[44]
フリーソフトウェア運動の指導者であり、フリーソフトウェア財団のメンバーであるリチャード・ストールマンは、彼らがフリーソフトウェアと呼ぶものにオープンソースという用語が適用されることに反対している。 [13]ストールマンは、2つの用語がほぼ同じカテゴリのソフトウェアを説明することに同意しているが、この2つの用語を同一視することは誤りであり誤解を招くと考えている。[13]ストールマン は、主な違いは、どちらかの用語を他方よりも選ぶことで、自分の目標が開発（オープンソース）なのか、社会的な立場（フリーソフトウェア）なのかを他の人に知らせることができる点だと考えている。 [45]しかし、オープンソースソフトウェアとフリーソフトウェアにはかなりの重複がある。[13]ストールマンはまた、オープンソース・イニシアティブの公言した実用主義にも反対しており、FSFのソフトウェアの自由に関する理想的な基準に妥協することで、フリーソフトウェアの理想である自由とコミュニティが脅かされることを懸念している。[45] FSFはフリーソフトウェアをオープンソースソフトウェアのサブセットとみなしており、リチャード・ストールマンは、例えばDRMソフトウェアは、ユーザーを制限するにもかかわらずオープンソースとして開発できるため、フリーソフトウェアとはみなされないと説明した。[13]
FSFは、オープンソースという用語は、単にソースが利用可能であることと、それを使用、変更、再配布する自由とを混同するような、別の種類の曖昧さを助長すると述べた。[13]一方、フリーソフトウェアという用語は、フリーという言葉の曖昧さがビジネスでの採用を妨げると考えられ、また、この用語の歴史的な曖昧な使用法について批判された。[45]
開発者は、フリーソフトウェアでもあるオープンソースソフトウェアを説明するために、フリーでオープンソースソフトウェア（FOSS）またはフリー/リブレでオープンソースソフトウェア（FLOSS）という代替用語を 使用しています。[28]
ソース利用可能なソフトウェア
ソフトウェアは、読み取り可能なコードであるソースコードとともに配布することができます。 [46]このソースコードが閲覧可能である場合、ソフトウェアはソース利用可能です。[46] ただし、ソース利用可能、つまりFOSSであるためには、ソースコードにすべての人がアクセスできる必要はなく、そのソフトウェアのユーザーだけがアクセスできる必要があります。 [46]これはオープンソースの定義による要件であるため、すべての FOSS ソフトウェアはソース利用可能ですが、ソース利用可能なソフトウェアのすべてが FOSS であるわけではありません。[46]たとえば、ソフトウェアがオープンソースの定義の他の側面、たとえば許可された変更や再配布などを満たしていない場合、ソースコードが利用可能であっても、そのソフトウェアは FOSS ではありません。[46]
オープンソース
ソフトウェア企業における最近の傾向は、オープンソース化、つまり、以前のプロプライエタリソフトウェアをオープンソースライセンスの下でリリースすることによりオープンソースソフトウェアに移行することです。[47] [48]これを行った企業の例としては、Google、Microsoft、Appleなどがあります。[47]さらに、オープンソース化は、オープンソースソフトウェアのプログラミングやオープンソースソフトウェアのインストールを指すこともあります。[48]オープンソース化は、新しい視点や問題解決能力をもたらすより多くの外部貢献者を引き付けるなど、さまざまな点で有益です。[47]オープンソース化の欠点には、ベースコードを簡単に理解できるようにすること、新しい開発者のためのコミュニケーションチャネルを設定すること、新しい開発者が簡単に参加できるようにドキュメントを作成するなど、新しいコミュニティを維持するために必要な作業が含まれます。[47]ただし、いくつかのオープンソースプロジェクトをレビューしたところ、新しくオープンソース化されたプロジェクトは多くの新規参加者を引き付けるものの、その多くがすぐにプロジェクトを離れる可能性があり、彼らのフォークも影響力がない可能性が高いことがわかりました。[47]
他の
オープンソースと類似点を持つ他の概念としては、シェアウェア、パブリックドメインソフトウェア、フリーウェア、無料で利用できるがソースコードは提供されないソフトウェアビューア/リーダーなどがあります。[17]ただし、これらはソースコードへのアクセス、ライセンス、著作権、料金の点でオープンソースソフトウェアとは異なります。 [17]
社会と文化
人口統計
オープンソースソフトウェアの貢献者は、国際的に協力できるにもかかわらず、シリコンバレーなどの大規模なクラスターにほとんどが集まっており、そのほとんどは内部で協力していることがわかりました。[49]この現象の理由として考えられるのは、OSS貢献者の人口統計は主にソフトウェア関連の仕事に従事しているため、OSSの地理的な場所はその分散と密接に関連しており、仕事やソーシャルネットワークを通じて協力が促進される可能性があるということです。[49]コードの受け入れは、これらのソーシャルネットワーククラスター内のステータスによって影響を受ける可能性があり、場所に基づいてコードの受け入れに不公平な傾向が生じます。[50]国際協力の障壁には、言語や文化の違いも含まれます。[51]さらに、インドを除く各国では、国内の貢献者からのコードの受け入れ率が高く、文化的に類似した協力者への偏りが示されています。[51]
2021年にオープンソースソフトウェアへの貢献度が最も高かった国は、米国、中国、ドイツ、インド、英国の順でした。[49] 2021年の調査によると、人口1人あたりのOSS開発者数が最も多い国は、アイスランド、スイス、ノルウェー、スウェーデン、フィンランドの順でした。一方、2008年には、SourceForgeへの推定貢献者数が最も多かった国は、米国、ドイツ、英国、カナダ、フランスでした。[49] [51] OSS開発者の分布と貢献度についてはいくつかの研究が行われていますが、これはまださまざまな方法で測定できるオープンな分野です。[51]たとえば、情報通信技術への参加、人口、富、インターネットへのアクセスの割合は、OSSの貢献度と相関していることが示されています。[51]
ジェンダーの多様性はチームの生産性を高めることがわかっているが、性別が特定できるオープンソースソフトウェアプロジェクトに貢献する女性は依然として偏見に直面している。[52] 2002年には、国際的なオープンソースソフトウェア開発者のうち女性はわずか1.5％であったが、女性はテクノロジー業界の役割の28％を占めており、ソフトウェア分野における女性の割合が低いことがわかった。[53] OSSへの貢献には前提条件がないにもかかわらず、貢献者の共通認識である「性別は関係なく、コードの品質がコードの受け入れにおける唯一の考慮事項であるべき」という考え方により、このジェンダーバイアスは存在し続け、コミュニティが女性の代表性における体系的な格差に対処することを妨げている可能性がある。[38]しかし、2005年から2021年にかけて国際的に計算された女性のOSS参加のより最近の数字は9.8％であり、そのほとんどが最近の貢献者であり、女性の参加が増加している可能性があることを示している。[54]
動機
OSSコミュニティに貢献する動機は数多くあります。[28]一つには、コーディングやその他の技術関連能力などの複数のスキルを学び、実践する機会であるだけでなく、コミュニケーションやコラボレーションなどの基本的なスキル、問題追跡やバージョン管理などの技術関連分野で優れた成果を上げるために必要な実践的なスキルも学び、実践する機会です。[28]教室や仕事を通じて学ぶのではなく、OSSへの貢献を通じて学ぶことで、参加者は自分のペースで学び、興味のあることに従うことができます。[28] OSSに貢献すると、業界の現在のベストプラクティス、技術、トレンドを学ぶことができ、OSSが技術分野でますます人気が高まるにつれて、次の大きなイノベーションに貢献する機会さえ得られます。[28] OSSに無償で貢献するということは、解雇される恐れがないことを意味しますが、評判が傷つく可能性があります。[28]一方、OSSに貢献する大きな動機は、公開ポートフォリオを増やすにつれて得られる評判です。[28]
格差
プログラミングはもともと女性の職業とみなされていたが、コンピューティングの世界では依然として大きなギャップが残っている。[55]女性のテクノロジー業界における 社会的アイデンティティは大きな懸念事項となる傾向があり、男性からの望まない注目や嫌がらせを招いたり、テクノロジーの知識が女性らしくないと思われたりするのではないかという不安に直面し、それが自信に大きな影響を与えている。[38]技術系の男性参加者の中には、女性が文化に溶け込むのは不可能だと考えていることを明らかにする者もおり、女性とそのテクノロジー業界における立場に対する不安がさらに増している。[52]さらに、オープンソースソフトウェアのような自発的な貢献環境であっても、 OSSへの貢献において女性と男性は同じ生産性を示しているにもかかわらず、女性はプロジェクトの技術的でない側面、例えば手動テストやドキュメント作成を行うことになりがちである。 [52]明らかな偏見には、フィードバックに要する時間が長いこと、コードがより精査されること、コードの受け入れ率が低いことなどがある。[52]特にオープンソースソフトウェアコミュニティでは、性的に不快な言葉が一般的であり、女性としての女性のアイデンティティはOSS貢献者としてのアイデンティティよりも注目されていると女性は報告しています。[38]性別は関係ないという信念のために偏見に対処することは難しく、ほとんどの貢献者は女性が特別扱いを受けるのは不公平であり、成功はスキルに依存するべきだと感じており、より包括的な変更を妨げています。[38]
採用と応用
主なプロジェクト
オープンソースソフトウェアプロジェクトは、多くの場合ボランティアであるプログラマーのネットワークによって構築および維持され、無料製品だけでなく商用製品でも広く使用されています。[56]
Unix : UnixはAT&Tが開発したオペレーティングシステムで、オープンソースソフトウェアの先駆けとして始まりました。フリーでオープンソースなソフトウェア革命は、開発者がUnixコードなしでオペレーティングシステムを作成しようとし始めたことから始まりました。[24] Unixは1960年代に開発され、ソフトウェアが商用化される前、オープンソースソフトウェアの概念が必要になる前だったので、真のオープンソースソフトウェアプロジェクトとは見なされていませんでした。[24] Unixは研究プロジェクトとして始まり、1980年代半ばに商用化されました。[24]商用化される前は、世界中のユーザーの分散型コラボレーション、ローリングリリース、プロプライエタリソフトウェアを嫌うコミュニティ文化など、フリーでオープンソースなソフトウェア革命が掲げた多くの理想を体現していました。[24]
BSD: Berkely Software Distribution (BSD) は、 1978 年にUnixの派生として始まったオペレーティング システムで、Unix コードと Berkely 研究所のコードを混合して機能性を高めました。[24] BSD は機能性を高めることに重点を置いていたため、その最大の革新技術をメインの Unix オペレーティング システムと公開していました。[24]これは、今日の FOSS の中心的な特徴である、無料の公開コード共有の一例です。[24] Unix が 1980 年代に商用化されると、プロプライエタリ ソフトウェアをサポートしない開発者やコミュニティのメンバーがBSD に注目し、Unix のコードを一切含まないオペレーティング システムに変え始めました。[24] BSD の最終バージョンは 1995 年にリリースされました。[24]
GNU : GNUは、リチャード・ストールマンが1984年に作成したフリーのオペレーティングシステムで、その名前は「GnuはUnixではない」という意味です。[24]そのアイデアは、誰でも使用でき、プログラマーがコードを自由に共有できるUnixの代替オペレーティングシステムを作成することでした。 [24]しかし、GNUの目標はUnixを置き換えることではなく、より技術的な機能を備えた優れたバージョンを作成することでした。[24]これは、フリーでオープンソースのソフトウェア革命の哲学的信念が真に定義される前にリリースされました。[24]著名なFOSSプログラマーであるリチャード・ストールマンによって作成されたため、GNUはFOSS活動に深く関与しており、GNUの最大の成果の1つは、開発者が合法的に共有および変更できるソフトウェアをリリースできるようにしたGNU一般公衆利用許諾書（GPL）の作成でした。[24]
Linux : Linuxは、 1991年にLinus Torvaldsによって導入されたオペレーティングシステムカーネルです。[24] Linuxは、営利目的のオペレーティングシステムサービスMinuxの改良版を作ることから着想を得ました。 [24]完全に無料で分散化されていたため、当時他のハッカーが作っていたものとは根本的に異なっていました。[24]その後、LinuxはGPLライセンスの下に置かれ、人々はLinuxでお金を稼ぐことができるようになり、LinuxはFOSSコミュニティに加わりました。[24]
Apache: Apacheは、 NCSA HTTPdコードベースに不満を抱き、独自のWebサーバーをリリースした開発者グループのコラボレーションとして1995年に始まりました。 [24] Apacheという名前は、このコードベースに適用されたいくつかのパッチに由来しています。[24]リリースから1年以内に、Apacheは世界をリードするWebサーバーになりました。[24]すぐにApacheは独自のライセンスを発表しましたが、これはFOSSコミュニティ全体に不和を生みましたが、最終的には成功を収めました。[24] Apacheライセンスでは、許可されたメンバーがソースコードに直接アクセスできました。これは、GNUやLinuxのアプローチとは大きく異なります。[24]
ソフトウェア以外の用途向けの拡張機能
オープンソースという用語は、もともとソフトウェアのソースコードにのみ適用されていましたが、現在ではオープンソースエコロジーなど、他の多くの分野にも適用されています。オープンソースエコロジーとは、技術を分散化して誰でも使用できるようにしようとする運動です。[13] [57]しかし、部分的にしか重複しない、異なる競合する原則を持つ他の分野に誤って適用されることがよくあります。[38]
オープンソースソフトウェアの根底にある同じ原則は、オープンソース、オープンコンテンツ、オープンコラボレーションなど、他の多くのベンチャーにも見られます。[58] [3]
この「文化」またはイデオロギーは、商業企業で一般的に使用されるようなより中央集権的な開発モデルとは対照的に、原則がより一般的に適用され、さまざまな課題、アプローチ、優先事項の同時入力を促進するという見解をとっています。[15]
価値
企業の90％以上が、オープンソースソフトウェアを自社のプロプライエタリソフトウェアのコンポーネントとして使用しています。[59]オープンソースソフトウェアを使用するか、既存のオープンソースソフトウェアを改善するためにオープンソースプロジェクトに参加するかという決定は、通常、実用的なビジネス上の決定です。[60] [61]プロプライエタリソフトウェアがオープンソースの代替品と直接競合する場合、競争がプロプライエタリ製品の価格と品質に与える影響について、研究により矛盾する結果が明らかになっています。[62]
数十年にわたり、企業ユーザー向けのオープンソースソフトウェア製品のサービスをビジネスモデルとしてきた企業がいくつかあります。これらの企業はオープンソースソフトウェア製品を管理し、ライセンスや使用料を請求するのではなく、改善、統合、その他のサービスに対して料金を請求します。[63] オープンソースコンポーネントに基づくSaaS（サービスとしてのソフトウェア）製品はますます一般的になっています。 [64]
オープンソースソフトウェアは透明性を高め、科学的結果の検証と受け入れを助けるため、科学的なアプリケーションには好まれます。[65]
参照
.svg/500px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
- フリーソフトウェアとオープンソースソフトウェアのライセンスの比較
- フリーソフトウェア
- フリーソフトウェアライセンス
- フリーソフトウェア運動
- 無料およびオープンソースのソフトウェア パッケージの一覧
- 無料コンテンツ
- オープンソースハードウェア
- オープンソースイニシアチブ
- オープンソースライセンス
- オープンソースソフトウェアの推進
- オープンソースソフトウェア協会
- オープンソースソフトウェアのセキュリティ
- オープンソースのビデオゲーム
- タイトルに「オープンソース」を含むすべての記事
- 独自ソフトウェア
- シェアードソースイニシアチブ
- フリーソフトウェアとオープンソースソフトウェアのタイムライン
- ソフトウェア構成分析
参考文献
- ^ St. Laurent, Andrew M. (2008). オープンソースとフリーソフトウェアライセンスの理解。O'Reilly Media。p. 4. ISBN 978-0-596-55395-1. 2023年4月22日時点のオリジナルよりアーカイブ。2023年3月21日閲覧。
- ^ Corbly, James Edward (2014年9月25日). 「フリーソフトウェアの代替案：フリーウェア、オープンソースソフトウェア、およびライブラリ」.情報技術と図書館. 33 (3): 65. doi : 10.6017/ital.v33i3.5105 . ISSN 2163-5226. 2021年5月1日時点のオリジナルよりアーカイブ。2021年4月28日閲覧。
- ^ ab Levine, Sheen S.; Prietula, Michael J. (2013 年 12 月 30 日). 「イノベーションのためのオープンコラボレーション: 原則とパフォーマンス」.組織科学. 25 (5): 1414–1433. arXiv : 1406.7541 . doi :10.1287/orsc.2013.0872. ISSN 1047-7039. S2CID 6583883.
- ^ Hoffmann, Manuel; Nagle, Frank; Zhou, Yanuo (2024). 「オープンソースソフトウェアの価値」. SSRN電子ジャーナル. doi :10.2139/ssrn.4693148. ISSN 1556-5068.
- ^ 「International Authority & Recognition」。Opensource.org。2015年4月21日。2019年7月23日時点のオリジナルよりアーカイブ。 2017年12月7日閲覧。
- ^ Perens, Bruce. Open Sources: Voices from the Open Source Revolution Archived 2014年9月15日 at the Wayback Machine . O'Reilly Media . 1999年。
- ^ ディボナ、クリス、オックマン、サム（1999 年 1 月）。ブルース・ペレンズ著『オープンソースの定義』。オライリー。ISBN 978-1-56592-582-3。
- ^ 「オープンソースの定義」 2006年7月7日。2013年10月15日時点のオリジナルよりアーカイブ。2008年8月24日閲覧。オープンソース・イニシアティブによるオープンソースの定義
- ^ 「オープンソースライセンスはいくつ必要ですか? – Slashdot」。News.slashdot.org。2009年2月16日。2013年7月17日時点のオリジナルよりアーカイブ。2012年3月25日閲覧。
- ^ Open Source Initiative (2006年7月24日). 「オープンソースの定義（注釈付き）」. opensource.org . 2021年5月5日時点のオリジナルよりアーカイブ。2016年7月22日閲覧。
- ^ フェラー、ジョセフ、フィッツジェラルド、ブライアン、ヒッサム、スコット、ラクハニ、カリム R. (2005)。「序論」。フリーおよびオープンソースソフトウェアの展望。ケンブリッジ、マサチューセッツ州：MIT プレス。pp. xvii。ISBN 0-262-06246-1。
- ^ Tiemann, Michael. 「OSIの歴史」。Open Source Initiative。2006年9月24日時点のオリジナルよりアーカイブ。2014年5月13日閲覧。
- ^ abcdefgh リチャード・ストールマン (2007)。「オープンソースがフリーソフトウェアの本質を理解していない理由」
- ^ リチャード・ストールマン（2007年6月19日）。「なぜ「フリーソフトウェア」は「オープンソース」よりも優れているのか」。GNUプロジェクトの哲学。フリーソフトウェア財団。2021年3月27日時点のオリジナルよりアーカイブ。 2007年7月23日閲覧。
- ^ abcdefghijレイモンド、 エリック（2005年）。「大聖堂とバザール（1998年3月、第3巻第3号に初版発行）」。ファーストマンデー。doi ：10.5210/ fm.v0i0.1472。ISSN 1396-0466 。
- ^ abcdefghijklmnopqrs Robles, Gregorio (2006). 「フリー/リブレ/オープンソースソフトウェアに関する実証的ソフトウェアエンジニアリング研究」 2006 第 22 回 IEEE 国際ソフトウェアメンテナンス会議。pp. 347–350。doi :10.1109/ icsm.2006.25。ISBN 0-7695-2354-4. S2CID 6589566 . 2023年11月21日閲覧。
- ^ abcdefghijklmnopqrs Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). 「オープンソースソフトウェア開発プロセス：体系的レビュー」2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC) . IEEE. pp. 135–144. arXiv : 2008.05015 . doi :10.1109/EDOC49727.2020.00025. ISBN 978-1-7281-6473-1。
- ^ abcdefghijklmn Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). 「オープンソースソフトウェア開発プロセス：体系的レビュー」2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC) . IEEE. pp. 135–144. arXiv : 2008.05015 . doi :10.1109/EDOC49727.2020.00025. ISBN 978-1-7281-6473-1。
- ^ 米国国防総省。「オープンソースソフトウェア FAQ」。最高情報責任者。2016 年 8 月 28 日時点のオリジナルよりアーカイブ。2016年7 月 22 日閲覧。
- ^ 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日閲覧。
- ^ ab Reynolds, Carl; Jeremy Wyatt (2011 年 2 月). 「オープン ソース、オープン スタンダード、および医療情報システム」. Journal of Medical Internet Research . 13 (1): e24. doi : 10.2196/jmir.1521 . PMC 3221346. PMID 21447469 .
- ^ Landry, John; Rajiv Gupta (2000 年 9 月). 「オープンソースから利益を得る」. Harvard Business Review . doi :10.1225/F00503 (2024 年 9 月 12 日現在非アクティブ).
{{cite journal}}: CS1 maint: DOIは2024年9月時点で非アクティブです（リンク） - ^ abc Nagle, Frank (2019年3月3日). 「政府の技術政策、社会的価値、国家競争力」( PDF) .情報システムジャーナル. 12. doi :10.2139/ssrn.3355486. S2CID 85509685. SSRN 3355486.
- ^ abcdefghijklmnopqrstu vwxyz aa ab ac ad ae af ag ah ai aj Tozzi, Christopher (2017). For Fun and Profit: A History of the Free and Open Source Software Revolution . 米国: MIT Press. ISBN 978-0-262-34118-9。
- ^ Plotkin, Hal (1998 年 12 月)。「オープンソース ソフトウェアについて知っておくべきこと (およびその理由)」Harvard Management Update : 8–9 ページ。
- ^ abc Payne, Christian (2002 年 2 月)。 「オープン ソース ソフトウェアのセキュリティについて」。Information Systems Journal。12 ( 1): 61–78。doi :10.1046/j.1365-2575.2002.00118.x。S2CID 8123076 。
- ^ abcd ゾルキフリ、ナザトゥル・ヌルリサ;ガー、アミール。アジズ・デラマン (2018)。 「バージョン管理システム: レビュー」。プロセディアコンピュータサイエンス。135 : 408–415.土井: 10.1016/j.procs.2018.08.191。
- ^ abcdefghijklmnopqrstu Brasseur, VM (2018).オープンソースで未来を築く: スキルを構築し、ネットワークを構築し、テクノロジーの未来を築く。The pragmatic programmingers。ノースカロライナ州ローリー: The Pragmatic Bookshelf。ISBN 978-1-68050-301-2。
- ^ 「オープンソース」。Open Collective。2022年10月20日。 2024年5月28日閲覧。
- ^ 「テクノロジー」。ソブリン・テック・ファンド。 2024年5月28日閲覧。
- ^ 「NSFがオープンソースプロジェクトに2,600万ドル以上を投資 | NSF - National Science Foundation」new.nsf.gov 2023年10月25日2024年5月28日閲覧。
- ^ abcd Spinellis, Diomidis; Giannikas, Vaggelis (2012). 「オープンソースソフトウェアの組織的導入」.システムおよびソフトウェアジャーナル. 85 (3): 666–682. doi :10.1016/j.jss.2011.09.037.
- ^ 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。
- ^ abcdefghijklmnopqrstu vwxyz ブロック、アマンダ（2023）。オープンソースの法律、ポリシー、実践（第2版）。英国：オックスフォード大学出版局。ISBN 978-0-19-886234-5。
- ^ abcdefghijklmnop Wynants, M., & Cornelis, J. (編). (2005).未来はどれだけオープンか?: フリーおよびオープンソースソフトウェアに触発された経済、社会、文化のシナリオ。ASP。
- ^ abcdefghij パニエ、アリス（2022）。ソフトウェアパワー：オープンソースソフトウェアの経済的および地政学的影響。イフリーの学問。ISBN 979-10-373-0641-8。
- ^ abcd Maracke , Catharina (2019). 「フリーおよびオープンソースソフトウェアとFRANDベースの特許ライセンス：標準必須特許とフリーおよびオープンソースソフトウェアを仲介する方法」。 世界知的所有権ジャーナル。22 (3–4): 78–102。doi : 10.1111 /jwip.12114。ISSN 1422-2213。
- ^ abcdefg Bretthauer, David (2001). 「オープンソースソフトウェア：歴史」.情報技術と図書館. 21 (1).
- ^ ab 「International Authority & Recognition」。Open Source Initiative。2015年4月21日。 2023年12月18日閲覧。
- ^ abc Fogel, Karl (2006).オープンソースソフトウェアの制作: フリーソフトウェアプロジェクトを成功させる方法(第 1 版、[後編] 編). 北京ケルン: O'Reilly. ISBN 978-0-596-00759-1。
- ^ ケルティ、クリストファー (2008)。『2つのビット: フリーソフトウェアの文化的意義』デューク大学出版局。ISBN 978-0-8223-8900-2。
- ^ abc Miller, Keith W .; Voas, Jeffrey; Costello, Tom (2010). 「フリーおよびオープンソースソフトウェア」。ITプロフェッショナル。12 (6): 14–16。doi : 10.1109 / mitp.2010.147。ISSN 1520-9202。S2CID 265508713 。
- ^ abcd Zhu, Kevin Xiaoguo; Zhou, Zach Zhizhong (2012). 「研究ノート - ソフトウェア競争におけるロックイン戦略: オープンソースソフトウェア vs. プロプライエタリソフトウェア」.情報システム研究. 23 (2): 536–545. doi :10.1287/isre.1110.0358. ISSN 1047-7047.
- ^ ab 「オープンソースの定義（注釈付き）」。オープンソース・イニシアティブ。2006年7月24日。 2023年12月18日閲覧。
- ^ abc リチャード・M・ストールマン、ジョシュア・ゲイ（2002年）。フリーソフトウェア、フリー社会。ボストン（マサチューセッツ州）：フリーソフトウェア財団。ISBN 978-1-882114-98-6。
- ^ abcde Fortunato, Laura; Galassi, Mark (2021年5月17日). 「研究と学術におけるフリーソフトウェアとオープンソースソフトウェアの事例」. Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences . 379 (2197). Bibcode :2021RSPTA.37900079F. doi :10.1098/rsta.2020.0079. ISSN 1364-503X. PMID 33775148. S2CID 232387092.
- ^ abcde 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.
- ^ ab Ågerfalk; Fitzgerald (2008). 「未知の労働力へのアウトソーシング：グローバルソーシング戦略としてのオープンソーシングの検討」MIS Quarterly . 32 (2): 385. doi :10.2307/25148845. ISSN 0276-7783. JSTOR 25148845.
- ^ abcd Wachs , Johannes; Nitecki, Mariusz; Schueller, William; Polleres, Axel (2002 年 3 月) 。「オープンソース ソフトウェアの地理: GitHub からの証拠」。技術予測と社会変化。176 : 121478。arXiv : 2107.03200。doi : 10.1016 / j.techfore.2022.121478。
- ^ 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。
- ^ abcde Gonzalez-Barahona, Jesus M.; Robles, Gregorio; Andradas-Izquierdo, Roberto; Ghosh, Rishab Aiyer (2008 年 8 月). 「リブレ ソフトウェア開発者の地理的起源」.情報経済政策. 20 (4): 356–363. doi :10.1016/j.infoecopol.2008.07.001.
- ^ abcd 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。
- ^ Nafus, Dawn (2012 年 6 月)。「『パッチに性別はない』: オープンソース ソフトウェアでオープンではないもの」。New Media & Society。14 ( 4): 669–683。doi : 10.1177 /1461444811422887。ISSN 1461-4448。S2CID 206727320 。
- ^ 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.
- ^ Albusays, Khaled; Bjorn, Pernille; Dabbish, Laura; Ford, Denae; Murphy-Hill, Emerson; Serebrenik, Alexander; Storey, Margaret-Anne (2021年4月). 「ソフトウェア開発における多様性の危機」. IEEE Software . 38 (2): 19–25. doi :10.1109/MS.2020.3045817. ISSN 0740-7459.
- ^ Popp, Karl Michael 編 (2020)。オープンソースソフトウェアの商用利用に関するベストプラクティス: オープンソースソフトウェアを管理するためのビジネスモデル、プロセス、ツール。Synomic Academy。Norderstedt: BoD – Books on Demand。ISBN 978-3-7386-1909-6。
- ^ Powers, Stephen M .; Hampton, Stephanie E. (2019). 「生態学におけるオープンサイエンス、再現性、透明性」。生態学 的応用。29 (1): e01822。Bibcode : 2019EcoAp..29E1822P。doi : 10.1002/ eap.1822。ISSN 1051-0761。PMID 30362295 。
- ^ Cheliotis, Giorgos (2009). 「オープンソースからオープンコンテンツへ: オープン文化制作における組織、ライセンス、意思決定プロセス」.意思決定支援システム. 47 (3): 229–244. doi :10.1016/j.dss.2009.02.006. ISSN 0167-9236.
- ^ バトラー他2022年、1頁。
- ^ バトラーら。 2022、p. 11152.
- ^ ダビラ2015、7ページ。
- ^ 周＆チョードリー2022、731頁。
- ^ オーガストら。 2021 年、1 ～ 2 ページ。
- ^ August et al. 2021、p.1。
- ^ Morin et al. 2012、「互換性、増殖、断片化、方向性」。
さらに読む
- Androutsellis-Theotokis, Stephanos; Spinellis, Diomidis ; Kechagia, Maria; Gousios, Georgios (2010)。「オープンソースソフトウェア: 10,000 フィートからの調査」( PDF)。技術、情報、運用管理の基礎と動向。4 (3–4): 187–347。doi : 10.1561 /0200000026。ISBN 978-1-60198-484-5。
- August, Terrence; Chen, Wei; Zhu , Kevin ( 2021). 「プロプライエタリソフトウェア企業とオープンソースソフトウェア企業間の競争：戦略的貢献におけるライセンスの役割」。マネジメントサイエンス。67 (5): 3041–3066。doi :10.1287/mnsc.2020.3674。
- バーキンバイン、ベンジャミン J. (2020)。デジタルコモンズの組み込み: フリーおよびオープンソースソフトウェアへの企業の関与。ウェストミンスター大学出版局。hdl :20.500.12657/ 37226。ISBN 978-1-912656-43-1。
- バトラー、サイモン。ガマリエルソン、ジョナス。ランデル、ビョルン。ブラックス、クリストファー。マットソン、アンダース。グスタフソン、トーマス。ファイスト、ジョナス。クヴァルンストロム、ベングト。レンロート、エリック (2022)。 「ソフトウェア集約型ビジネスにおけるオープンソース コンポーネントの導入に関する考慮事項と課題」。システムとソフトウェアのジャーナル。186 . Elsevier BV: 111152. doi :10.1016/j.jss.2021.111152. ISSN 0164-1212。
- コールマン、E. ガブリエラ.コーディングの自由: ハッキングの倫理と美学(プリンストン大学出版、2012)
- Davila, Jacinto (2015)。「フリーでオープン ソースのソフトウェアの政治的論理」。自由にアクセスできるテクノロジーと知識リソースの社会的利点。IGI Global。pp. 1–24。ISBN 978-1-4666-8337-2。
- Fadi P. Deek、James AM McHugh (2008)。オープンソース：テクノロジーとポリシー。ケンブリッジ：ケンブリッジ大学出版局。ISBN 978-0-511-36775-5。
- クリス・ディボナ、サム・オックマン、マーク・ストーン編 (1999)。『オープンソース: オープンソース革命の声』オライリー。ISBN 978-1-56592-582-3。
- ジョシュア・ゲイ編 (2002)。フリーソフトウェア、フリー社会: リチャード・M・ストールマン選集。ボストン: GNU プレス、フリーソフトウェア財団。ISBN 978-1-882114-98-6。
- FOSS を理解する | 編集者 = Sampathkumar コインバトール インド
- Benkler, Yochai (2002)、「Coase のペンギン、あるいは Linux と企業の性質」Yale Law Journal 112.3 (2002 年 12 月): p367(78) (Adobe pdf形式)
- v. Engelhardt, Sebastian (2008)。「ソフトウェアの経済的特性」、Jena Economic Research Papers、第 2 巻 (2008)、番号 2008-045 (PDF)。Jena Economics Research Papers。
- Lerner, J. & Tirole, J. (2002):「オープンソースに関する簡単な経済学」、Journal of Industrial Economics 50(2)、p 197–234
- Välimäki, Mikko (2005). オープンソースライセンスの台頭: ソフトウェア業界における知的財産権の利用に対する挑戦(PDF)。Turre Publishing。2009年3月4日時点のオリジナル(PDF)からアーカイブ。
- Morin, Andrew; Urban, Jennifer; Sliz, Piotr (2012). 「科学者プログラマーのためのソフトウェアライセンスのクイックガイド」. PLOS Computational Biology . 8 (7): e1002598. Bibcode :2012PLSCB...8E2598M. doi : 10.1371/journal.pcbi.1002598 . ISSN 1553-7358. PMC 3406002. PMID 22844236 .
- Polley, Barry (2007 年 12 月 11 日)。「オープンソース ディスカッション ペーパー – バージョン 1.0」(PDF)。ニュージーランド オープンソース協会。ニュージーランド法務省。2018年 2 月 23 日時点のオリジナル(PDF)からアーカイブ。2007年12 月 12 日閲覧。
- Rossi, MA (2006): フリー/オープンソース ソフトウェア パズルの解読: 理論的および実証的貢献の調査、J. Bitzer P. Schröder 編、『オープンソース ソフトウェア開発の経済学』、p 15–55。
- オープンソース: オープンソース革命の声 — オープンソースコミュニティの著名なメンバーによるエッセイを収録したオンラインブック
- ベリー、DM（2004）。コードの対立：フリーソフトウェアとオープンソフトウェア運動の言説に関する予備的調査、批判的言説研究、第1巻（1）。
- Schrape, Jan-Felix (2017)。「イノベーションのインキュベーターとしてのオープンソース プロジェクト。ニッチな現象からソフトウェア業界の不可欠な部分へ」(PDF)。シュトゥットガルト: 組織社会学とイノベーション研究への研究貢献 2017-03。
- Sustainable Open Source は、オープンソース エコシステムへの公正な参加に関するガイドラインを提供する Confluence の記事で、Radovan Semancik 著です。
- Zhou, Zach Zhizhong; Choudhary, Vidyanand ( 2022 ). 「オープンソースソフトウェアとの競争がプロプライエタリソフトウェアに与える影響」。生産および運用管理。31 (2): 731–742。doi :10.1111/poms.13575。
外部リンク
ウィキメディア・コモンズには、フリーソフトウェアに関連するメディアがあります。
Wikibooksにはオープンソースに関する本があります
Wikibooksには「ソースの使用」に関する本があります。
Scholia には、オープンソース ソフトウェアのトピックプロファイルがあります。
- オープンソース・イニシアティブによるオープンソースの定義
- フリー/オープンソース研究コミュニティ — オープンソースに関するオンライン研究論文が多数
- ‹ Curlieテンプレートは 削除が検討されています。› Curlie のオープンソースソフトウェア