オープンソースソフトウェア
ソースコードの使用権を保証するためにライセンスされたソフトウェア

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]ストールマンはまた、オープンソース・イニシアチブ（OSI）が公言するプラグマティズムにも反対している。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]国立科学財団は、オープンソースのイノベーションを支援するために、オープンソースエコシステム実現のためのパスウェイ（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]

Several gray areas exist within software regulation that have great impact on open-source software, such as if software is a good or service, what can be considered a modification, governance through contract vs license, ownership and right of use. While there have been developments on these issues, they often lead to even more questions. The existence of these uncertainties in regulation has a negative impact on industries involved in technologies as a whole.[35]

Within the legal history of software as a whole, there was much debate on whether to protect it as intellectual property under patent law, copyright law or establishing a unique regulation. Ultimately, copyright law became the standard with computer programs being considered a form of literary work, with some tweaks of unique regulation.[35]

Software is generally considered source code and object code, with both being protectable, though there is legal variety in this definition. Some jurisdictions attempt to expand or reduce this conceptualization for their own purposes. For example, The European Court of Justice defines a computer program as not including the functionality of a program, the programing language, or the format of data files. By limiting protections of the different aspects of software, the law favors an open-source approach to software use. The US especially has an open approach to software, with most open-source licenses originating there. However, this has increased the focus on patent rights within these licenses, which has seen backlash from the OSS community, who prefer other forms of IP protection.[35]

Another issue includes technological protection measures (TPM) and digital rights management (DRM) techniques which were internationally legally recognized and protected in the 1996 World Intellectual Property Organization (WIPO) Treaty. Open source software proponents disliked these technologies as they constrained end-users potentially beyond copyright law. Europe responded to such complaints by putting TPM under legal controls, representing a victory for OSS supporters.[35]

Economic/business implications

Participants in the Free Knowledge Game Jam 2015, an open source and open data oriented game jam

オープンソースコミュニティでは、制作者は制作したソフトウェアを所有するのではなく、進化するソフトウェアの開発そのものを所有する。このように、ソフトウェアの将来はオープンであり、OSS内での所有権や知的財産権の確保は困難である。ライセンスとブランディングによって他者による盗用を防ぎ、公共財としての地位を維持することができる。オープンソースソフトウェアは誰もが利用可能であり、誰かがダウンロードしたとしても他者にとっての価値が下がらないため、公共財とみなすことができる。オープンソースソフトウェアは、リソースを減少させるのではなく、使用され、貢献されるにつれて価値が高まるという点で独特である。これは、評判への投資やネットワーク効果などの概念によって説明される。[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]これらの熱狂者の一人、リチャード・ストールマンは、後のオープンソース運動を可能にするフリーソフトウェア運動の原動力でした。1984年、研究室のプログラマー文化がプロプライエタリソフトウェアによってソースコードの共有や改良が妨げられたことを受けて、彼はMITを辞職し、フリーオペレーティングシステムであるGNUを作成しました。GNUはUNIXと互換性があり、プログラマーの熱狂者たちはGNUの動作に慣れていました。しかし、ストールマンがフリーソフトウェアに付けたラベルに混乱があることがすぐに明らかになりました。彼はフリーをビールの自由ではなく、言論の自由の意味で「フリー」と表現し、価格ではなく自由という意味に言及しました。彼は後にこの自由の概念を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を置き換えるだけでなく、より高度な技術力を備えた優れたバージョンを作ることでした。GNUは、フリーオープンソースソフトウェア革命の理念が真に定義される前にリリースされました。著名な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. ^ ab 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. ^ “International Authority & Recognition”. 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. ^ abcdefg ストールマン、リチャード (2007). 「オープンソースがフリーソフトウェアの本質を見失う理由」
  14. ^ リチャード・ストールマン（2007年6月19日）「なぜ『フリーソフトウェア』は『オープンソース』よりも優れているのか」GNUプロジェクトの哲学。フリーソフトウェア財団。2021年3月27日時点のオリジナルよりアーカイブ。 2007年7月23日閲覧。
  15. ^ abcd レイモンド、エリック (2005). 「大聖堂とバザール（初版第3巻第3号、1998年3月）」. First Monday . doi : 10.5210/fm.v0i0.1472 . ISSN  1396-0466.
  16. ^ abcdefghijk Robles, Gregorio (2006). 「フリー/リブレ/オープンソースソフトウェアに関する実証的ソフトウェアエンジニアリング研究」2006年第22回IEEE国際ソフトウェアメンテナンス会議. pp.  347– 350. doi :10.1109/icsm.2006.25. ISBN 0-7695-2354-4. S2CID  6589566。
  17. ^ abcdefg 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. ^ abcde 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. ^ ab Reynolds, Carl; Jeremy Wyatt (2011年2月). 「オープンソース、オープンスタンダード、そして医療情報システム」. Journal of Medical Internet Research . 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. ^ abcdefghi 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。
  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. ^ abcde 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. ^ abc 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. ^ abcdefg ブロック、アマンダ（2023年）『オープンソースの法律、ポリシー、実践』（第2版）英国：オックスフォード大学出版局。ISBN 978-0-19-886234-5。
  36. ^ abcd Wynants, M., & Cornelis, J. (編). (2005).未来はどれほど開かれているのか？：フリーソフトウェアおよびオープンソースソフトウェアが示唆する経済、社会、文化のシナリオ. ASP.
  37. ^ 内閣府、「オープンソースのすべて：政府ITのためのオープンソースソフトウェア入門」バージョン2.0、8ページ、2012年4月発行、2025年10月1日にアクセス
  38. ^ ab パニエ、アリス（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. ^ abcdef Bretthauer, David (2001). 「オープンソースソフトウェア：歴史」.情報技術と図書館. 21 (1).
  41. ^ ab 「International Authority & Recognition」. Open Source Initiative . 2015年4月21日. 2023年12月18日閲覧。
  42. ^ ab カール・フォーゲル (2006). 『オープンソースソフトウェアの制作：フリーソフトウェアプロジェクトを成功させる方法』（第1巻、後編）. 北京ケルン: 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. ^ abc リチャード・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. ^ abc 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. ^ ab Ågerfalk; Fitzgerald (2008). 「未知の労働力へのアウトソーシング：グローバルソーシング戦略としてのオープンソーシングの探究」MIS Quarterly . 32 (2): 385. doi :10.2307/25148845. ISSN  0276-7783. JSTOR  25148845.
  51. ^ abc 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における開発者の貢献に対する地理的位置と評価の関係」. Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ACM. pp.  1– 8. doi :10.1145/3239235.3240504. ISBN 978-1-4503-5823-1. S2CID  215822439。
  53. ^ abcd ゴンザレス＝バラオナ、ジーザス M.;ロブレス、グレゴリオ。アンドラダス・イスキエルド、ロベルト。ゴーシュ、リシャブ・アイイヤー (2008 年 8 月)。「リブレ ソフトウェア開発者の地理的起源」。情報経済と政策。20 (4): 356–363。土井:10.1016/j.infoecopol.2008.07.001。
  54. ^ ab 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、「互換性、増殖、断片化、方向性」。

さらに読む

  • アンドルーツェリス＝テオトキス（ステファノス）、スピネリス（ディオミディス）、ケチャギア（マリア）、グシオス（ゲオルギオス）（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). 「プロプライエタリソフトウェア企業とオープンソースソフトウェア企業の競争：戦略的貢献におけるライセンスの役割」. Management Science . 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 111152。エルゼビア BV。土井：10.1016/j.jss.2021.111152。ISSN  0164-1212。
  • コールマン、E. ガブリエラ著『コーディングの自由：ハッキングの倫理と美学』（プリンストン大学出版、2012年）
  • ダビラ、ジャシント (2015). 「フリー、リブレ、オープンソースソフトウェアの政治的論理」.自由にアクセス可能な技術と知識資源の社会的利益. IGI Global. pp.  1– 24. ISBN 978-1-4666-8337-2。
  • ファディ・P・ディーク、ジェームズ・A・M・マクヒュー（2008年）『オープンソース：テクノロジーとポリシー』ケンブリッジ大学出版局、ISBN 978-0-511-36775-5。
  • クリス・ディボナ、サム・オックマン、マーク・ストーン編（1999年）『オープンソース：オープンソース革命の声』オライリー社、ISBN 978-1-56592-582-3。
  • ジョシュア・ゲイ編（2002年）『フリーソフトウェア、フリー社会：リチャード・M・ストールマン選集』ボストン：GNU Press、フリーソフトウェア財団。ISBN 978-1-882114-98-6。
  • FOSSを理解する | 編集者 = Sampathkumar コインバトール（インド）
  • ベンクラー、ヨチャイ（2002年）「コースのペンギン、あるいは、Linuxと企業の本質」イェール・ロー・ジャーナル112.3（2002年12月）：p367(78)（Adobe PDF形式）
  • v. エンゲルハート、セバスチャン (2008). 「ソフトウェアの経済的特性」、イエナ経済研究論文、第2巻 (2008年)、番号2008-045 (PDF) .イエナ経済研究論文.
  • 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)からのアーカイブ。
  • モーリン, アンドリュー; アーバン, ジェニファー; スリス, ピオトル (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）。
  • シュラペ、ヤン＝フェリックス (2017). 「イノベーションのインキュベーターとしてのオープンソースプロジェクト：ニッチな現象からソフトウェア産業の不可欠な一部へ」(PDF) . シュトゥットガルト: 組織社会学とイノベーション研究への研究貢献 2017-03.
  • Sustainable Open Source は、オープンソースエコシステムへの公正な参加のためのガイドラインを提供する Confluence の記事で、Radovan Semancik 著によるものです。
  • Zhou, Zach Zhizhong; Choudhary, Vidyanand (2022). 「オープンソースソフトウェアからの競争がプロプライエタリソフトウェアに与える影響」. Production and Operations Management . 31 (2): 731– 742. doi :10.1111/poms.13575.
ウィキメディア コモンズには、フリー ソフトウェアに関連するメディアがあります。
Wikibooksにはオープンソースに関する書籍があります
ウィキブックスには「ソースの使用」に関する書籍があります。
ロゴ
Scholia には、オープンソース ソフトウェアに関するトピックプロファイルがあります。
  • オープンソース・イニシアティブによるオープンソースの定義
  • フリー/オープンソース研究コミュニティ — オープンソースに関する多くのオンライン研究論文
Retrieved from "https://en.wikipedia.org/w/index.php?title=Open-source_software&oldid=1331648085"