Loading article…
オープンソースソフトウェア（OSS）とは、ソースコードが公開されているコンピュータソフトウェアのことで、ユーザーはそれを使用、研究、変更、配布することができます。これは、プロプライエタリ（クローズドソース）ソフトウェアとは対照的です。これらの権利は通常、オープンライセンスによって付与されますが、まれにパブリックドメインへの提供によって付与される場合もあります。オープンソースソフトウェアの開発は、分散型の生産モデルであるオープンコラボレーションに基づいて行われることがあります。一般的には、オープンソースイニシアティブのオープンソース定義に従って定義されますが、オープンソースの正確な意味については依然として議論の余地があります。
オープンソースソフトウェアはさまざまな利点を提供する一方で、特有のリスクや課題も抱えています。[ 1 ]低コストで共有できるアクセシビリティの向上、カスタマイズによる適応性の向上、監査可能なコードによる透明性の向上、オープンスタンダードによる相互運用性の向上、ベンダーロックインからの独立性など、多くの利点があります。現代のソフトウェアで広く普及しているため、オープンソースソフトウェアは重大なサイバーセキュリティ上の懸念や、メンテナンス上の大きな課題を引き起こします。
オープンソースソフトウェアは、ウェブサーバー、クラウドコンピューティング、スーパーコンピューター、モバイルデバイス、人工知能、モノのインターネットなどの領域を支える、グローバルなデジタルインフラストラクチャの基盤となっています。2022年の推定では、プロプライエタリソフトウェアを含め、現在市場に出回っているソフトウェアを構成するコードの80～96%がオープンソース由来であるとされています。[ 2 ]サイバーセキュリティ、デジタル主権、プロプライエタリソフトウェアからの独立といった動機に後押しされ、公共機関、民間企業、学術界で着実に普及が進んでおり、地政学的にも大きな意味を持っています。組織は、戦略を管理するためにオープンソースプログラムオフィスを設立するケースが増えています。
オープンソースソフトウェアは、1950年代のコンピュータ黎明期にまで遡るソースコード共有の文化にルーツを持つ。この用語は、 1980年代に始まったフリーソフトウェア運動の後継として、 1998年にオープンソース・イニシアティブが設立されたことで正式に定義され、「自由」と「無償」の両方を意味する「フリー」という言葉の曖昧さを克服し、ビジネス界への訴求力を高めることを目的としていた。
代表的な例としては、LinuxカーネルやFirefoxウェブブラウザが挙げられる。Wikipediaを支えるソフトウェアであるMediaWiki自体も、オープンソースソフトウェアの一例である。
オープンソースソフトウェアは、主にオープンソースイニシアティブ（OSI）が定めたオープンソース定義（OSD）に従って定義されます。このフレームワークの下でオープンソースとして認められるには、ソフトウェアはソースコードを提供し、10のOSD基準を満たすライセンスの下で配布される必要があります。特に、個人、グループ、または活動分野に対する非差別、つまり誰でもあらゆる目的でそれを使用、変更、再配布できるようにすることが含まれます。この定義は、主にブルース・ペレンズとエリック・S・レイモンドによって書かれ、改訂されたDebianフリーソフトウェアガイドラインに基づいています。[ 3 ] [ 4 ] [ 5 ] OSIは、OSDに準拠する承認済みライセンスのリストを維持しています。[ 6 ]
しかし、OSI は「オープンソース」という用語に対して法的権限を持っておらず、その定義は社会慣習の問題です。[ 7 ] OSI の非差別基準は、ソフトウェア コミュニティ内でオープンソースの意味そのものをめぐって数十年にわたり「文化戦争」と呼ばれるものを引き起こしてきました[ 8 ] [ 9 ] — OSI は一部の関係者から抑圧的な教義と見なされることがあります。[ 10 ]これは、開発者がこの歴史について学んだことがないか、気にしないか、あるいは積極的に無関係だと考えているために発生し、世代間の対立の一形態を伴います。[ 11 ]これらの論争は、倫理的および商業的な懸念によって引き起こされます。[ 8 ]その結果、「オープンソース」という用語は、意図しない誤用からその権威の意図的な拒否まで、OSD に準拠しない方法で使用されることがあります。[ 7 ] [ 12 ] [ 13 ]
パブリックドメインのソフトウェアは、正式なライセンスがなく、管轄区域によって権利が大きく異なるため、オープンソースソフトウェアとして認められるかどうかについて意見の相違がある。[ 14 ] [ 15 ] [ 16 ] OSI自身もこの問題に関して相反する見解を示しており、「そのようなソフトウェアは実質的にオープンソースであると言うのは正確である」[ 17 ]と「パブリックドメインのソフトウェアをオープンソースとして扱うのは誤りである」 [ 18 ]の両方を主張している。
オープンソースの意味をめぐる見解の相違や意味論的な対立により、ソース利用可能ソフトウェア、フェアソース、エシカルソース、シェアードソース、ポストオープンソース、フォックスペンソースなどの関連用語が生み出された。[ 19 ] [ 20 ]
フリーでオープンソースのソフトウェア（FOSS）またはフリー/リブレでオープンソースのソフトウェア（FLOSS）は、使用、変更、配布に制限なくライセンスされた、オープンに共有されるソースコードです。この定義については混乱が続いています。「フリー」または「リブレ」は、製品の自由度を指し、価格、費用、コスト、料金を指すものではないからです。たとえば、「自由に発言できること」は「無料のビール」とは異なります。[ 21 ]
逆に、リチャード・ストールマンは、「オープンソース」という用語の「明白な意味」は、ソースコードが公開され、検査のためにアクセス可能であることであり、必ずしも他の権利が付与されるわけではないと主張しているが、この用語の提唱者たちは、オープンソースの定義にある条件が満たされなければならないと述べている。[ 22 ]
「自由でオープン」は、公的所有（国家所有）、民営化解除（国有化）、反民営化（反企業活動）、または透明性のある行動と混同されるべきではない。
Feller et al. (2005) によると、「フリーソフトウェア」および「オープンソースソフトウェア」という用語は、「ユーザーがソフトウェアを、そのソフトウェアの作者にロイヤリティや手数料を支払うことなく、ユーザーが適切と考える方法で使用、変更、再配布することを許可する条件で配布されるソフトウェア製品」に適用されるべきである。[ 23 ]
当初は受け入れていたものの、[ 24 ] FSFのリチャード・ストールマンは、現在では「オープンソース」という用語を、彼らが「フリーソフトウェア」と呼ぶものに適用することに断固反対している。ストールマンは、2つの用語が「ほぼ同じカテゴリのソフトウェア」を表していることには同意するものの、これらの用語を同一視することは不正確で誤解を招くと考えている。 [ 25 ]ストールマンはまた、オープンソース・イニシアティブの主張する実用主義にも反対しており、ソフトウェアの自由に関するFSFの理想主義的な基準を妥協することで、自由とコミュニティというフリーソフトウェアの理想が脅かされることを懸念している。[ 26 ] FSFはフリーソフトウェアをオープンソースソフトウェアのサブセットとみなしており、リチャード・ストールマンは、例えばDRMソフトウェアは、ユーザーに自由を与えず（制限する）、したがってフリーソフトウェアの資格を満たさないにもかかわらず、オープンソースとして開発できると説明した。[ 25 ]
オープンソースソフトウェアは、著作権を保持する作者が所有し、ライセンスの使用を通じてソフトウェアの使用、変更、再配布の権利を付与します。[ 27 ]外部の合意がない場合、貢献は作者が所有し、著作権は貢献者間で共有されます。[ 28 ] [ 29 ]このような法的状況では、プロジェクトの著作権を管理し、異なる条件でソフトウェアを再ライセンスできるようにするために、貢献者ライセンス契約（CLA）または著作権譲渡契約を使用するプロジェクトもあります。[ 30 ]そのため、一部の種類のオープンソースソフトウェアはプロプライエタリソフトウェアと呼ばれます。[ 31 ]
オープンソースの有力貢献者であるエリック・S・レイモンドは、 1997年のエッセイ「大聖堂とバザール」の中で、バザールモデルとして知られるOSS開発モデルを提案している。レイモンドは、従来の方法論によるソフトウェア開発を、個人または小グループによる慎重で孤立した作業を伴う大聖堂の建設に例えている。彼は、すべてのソフトウェアは、異なる目的とアプローチを持つバザールスタイルを使用して開発されるべきだと提案している。[ 32 ]
彼が「大聖堂モデル」と呼んだ従来の開発モデルでは、開発は中央集権的に行われます。役割は明確に定義されています。役割には、設計を担当する人（アーキテクト）、プロジェクト管理を担当する人、実装を担当する人が含まれます。従来のソフトウェアエンジニアリングは、大聖堂モデルに従います。[ 32 ]
しかし、バザールモデルは異なります。このモデルでは、役割は明確に定義されていません。[ 32 ]バザールモデルを使用して開発されたソフトウェアの提案された特性には、次のパターンが現れるはずです。[ 33 ]
オープンソース開発のプロセスは、要件定義から始まります。開発者は、プロジェクトに新機能を追加すべきか、バグを修正する必要があるかを検討します。これは、バグ報告や追跡、メーリングリスト、プロジェクトページなどの手段を通じてOSSコミュニティとコミュニケーションを取ることで確立されます。次に、OSS開発者はタスクを選択または割り当てられ、解決策を特定します。OSSでは解決策のさまざまな方法があることが多いため、最適な解決策は慎重に検討し、場合によってはピアフィードバックも考慮して選択する必要があります。その後、開発者はコードの開発とコミットを開始します。コードはピアによってテストおよびレビューされます。開発者は、継続的インテグレーションからのフィードバックを通じてコードを編集および進化させることができます。リーダーシップとコミュニティがプロジェクト全体に満足したら、部分的にリリースしてユーザー向けの手順を文書化できます。プロジェクトがリリース準備完了になったら、重大なバグ修正またはセキュリティ修復のみが行われるように凍結されます。最後に、プロジェクトは完全にリリースされ、軽微なバグ修正のみによって変更されます。[ 35 ]
標準のオープンソース実装は、その標準の普及と長期的な存続可能性を高めることができる。[ 36 ]貢献者は開発プロセスと最終製品への参加と所有意識をより強く感じるため、開発者の忠誠心を高めることが多い。[ 37 ]
さらに、OSSにはマーケティングおよび物流サービスのコスト削減が必要である。[ 38 ] OSSは、商用製品を含む企業のイメージ向上に役立つツールとなり得る。[ 39 ] OSS開発アプローチは、信頼性が高く高品質なソフトウェアを迅速かつ低コストで開発するのに役立つことが知られている。[ 38 ]
オープンソース開発は、イノベーションを加速させ、社会的価値を生み出す可能性を秘めている。例えばフランスでは、政府がフリーのオープンソースソフトウェアを優遇する政策により、年間約60万件のOSS貢献が増加し、オープンソースソフトウェアの量と質の向上によって社会的価値が生み出された。この政策により、テクノロジー系スタートアップ企業の数は最大18%増加し、ITセクターの雇用者数は14%増加したと推定されている。[ 40 ]
OSSは、何千人もの独立したプログラマーがソフトウェアのテストとバグ修正を行っている場合、非常に信頼性が高くなります。[ 33 ]オープンソースは、それを最初に作成した企業や作者に依存しません。企業が倒産しても、コードは存在し続け、ユーザーによって開発されます。[ 41 ]
OSSはモジュール式のシステムであるため、プログラマーがカスタムインターフェースを構築したり、新しい機能を追加したりできるため、柔軟性があります。多様な視点、企業の目標、個人の目標が混在することでイノベーションが生まれます。[ 42 ]
さらに、フリーソフトウェアは純粋に技術的な要件に従って開発できます。ソフトウェアの品質を低下させることが多い商業的圧力について考える必要はありません。商業的圧力により、従来のソフトウェア開発者はセキュリティ要件よりも顧客の要件に注意を払うようになります。なぜなら、そのような機能は顧客にはある程度見えないからです。[ 43 ]
オープンソースソフトウェア開発では、製品の開発と開発プロセス自体をサポートするためにツールが使用されます。[ 35 ]
中央集中型バージョン管理システム (CVCS) や分散型バージョン管理システム(DVCS)などのバージョン管理システムは、ソフトウェアプロジェクトのソースコードファイルとその変更を管理してコラボレーションを促進するのに役立つツールの例であり、多くの場合オープンソースです。CVCS は中央リポジトリを持つ集中型ですが、DVCS は分散型で、各ユーザーにローカルリポジトリがあります。Concurrent Versions System (CVS) や後にSubversion (SVN) は CVCS の例であり、Git はDVCS であり、最も広く使用されているバージョン管理ソフトウェアです。[ 44 ]リポジトリは、 GitHubやGitLabなどのソースコードホスティング施設でホストされ、公開されます。[ 45 ]
オープンソースプロジェクトでは、課題追跡ツールなどのユーティリティを使用して、オープンソースソフトウェアの開発を整理します。よく使用されるバグ追跡ツールには、 BugzillaやRedmineなどがあります。[ 35 ]
メーリングリストやIRCなどのツールは、開発者間のバグの調整や議論の手段を提供する。プロジェクトのウェブページ、ウィキページ、ロードマップリスト、ニュースグループは、エンドユーザーに焦点を当てたプロジェクト情報の配布を可能にする。[ 35 ]
OSS参加者の基本的な役割は複数のカテゴリーに分類でき、まずプロジェクトの中心で実行を管理するリーダーシップが挙げられます。次に、プロジェクトで豊富な経験と権限を持ち、他の貢献者を指導するコア貢献者がいます。非コア貢献者は経験と権限は少ないものの、定期的に貢献し、プロジェクトの開発に不可欠です。新規貢献者は最も経験が浅いですが、メンターシップと指導を受けることで定期的な貢献者になることができます。[ 46 ]
オープンソースソフトウェアへの貢献方法としては、プログラミング、保守、ユーザーインターフェースの設計とテスト、ウェブデザイン、バグトリアージ、アクセシビリティ設計とテスト、UXデザイン、コードテスト、セキュリティレビューとテストなどが挙げられます。しかし、コーディングスキルがなくてもOSSプロジェクトに貢献できる方法はいくつかあります。例えば、技術的な知識がなくても参加できる方法としては、ドキュメントの作成と編集、翻訳、プロジェクト管理、イベントの企画と調整、マーケティング、リリース管理、コミュニティ管理、広報活動などがあります。[ 46 ]
資金提供は、個人や組織がオープンソース プロジェクトに貢献する方法の 1 つです。Open Collectiveのようなグループは、個人がお気に入りのプロジェクトを支援するために毎月寄付できる手段を提供しています。[ 47 ] Sovereign Tech Fundのような組織は、ドイツ政府が使用するツールを支援するために数百万ドルを拠出することができます。[ 48 ]米国国立科学財団は、オープンソース イノベーションを支援するために、オープンソース エコシステムを可能にするための経路 (POSE) プログラムを設立しました。[ 49 ]
オープンソースソフトウェアの業界における採用は時間とともに増加している。[ 50 ] OSSは、その利点から、電気通信、航空宇宙、ヘルスケア、メディア＆エンターテイメントなどのいくつかの業界で人気がある。 [ 51 ] OSSの採用は、より大規模な組織で起こりやすく、企業のIT利用、運用効率、従業員の生産性に依存する。[ 50 ]
バックオフィス機能、販売サポート、研究開発、ソフトウェア機能、迅速な導入、プラットフォーム間の移植性、商用ライセンス管理の回避といった理由から、産業界はOSSを利用する可能性が高い。さらに、ハードウェアと所有コストの削減も重要な利点である。[ 50 ]
フリーソフトウェアおよびオープンソースソフトウェア運動の開発と拡大に貢献する組織は世界中に存在します。これらの組織は、教育や技術の普及といった目標に専念しています。Open Source Initiativeの元副会長が挙げたアメリカの組織には、Free Software Foundation、Software Freedom Conservancy、Open Source Initiative、Software in the Public Interestなどがあります。ヨーロッパでは、 Free Software Foundation Europe、open-source projects EU (OSP)、OpenForum Europe (OFE) などの注目すべき組織があります。オーストラリアの組織としてはLinux Australiaがあり、アジアには Open source Asia と FOSSAsia があります。Free and open source software for Africa (FOSSFA) と OpenAfrica はアフリカの組織で、中央アジアと南アジアにはFLISOLや GRUP de usuarios de software libre Peru などの組織があります。これら以外にも、オープンソースソフトウェアの発展に専念する組織は数多く存在します。[ 46 ]
FOSS製品は一般的に、許容ライセンスとコピーレフトライセンスの2種類のライセンスでライセンス供与されます。これらのライセンスはどちらも、独自のライセンスとは異なり、より多くのユーザーがソフトウェアにアクセスでき、特定のライセンスの条項に従って派生作品の作成を許可することができます。各ライセンスには独自のルールがあります。許容ライセンスでは、ソフトウェアの受領者は、配布に同じライセンスを使用する必要なく、著作者の著作権を実装できます。このタイプのライセンスの例としては、 BSD、MIT、Apacheライセンスなどがあります。コピーレフトライセンスは、受領者が作品の配布の少なくとも一部に同じライセンスを使用することを要求する点で異なります。強力なコピーレフトライセンスでは、すべての派生作品に同じライセンスの使用が要求されますが、弱いコピーレフトライセンスでは、特定の条件下でのみ同じライセンスの使用が要求されます。このタイプのライセンスの例としては、GNUファミリーライセンス、MPLライセンス、EPLライセンスなどがあります。これら2つのライセンスのカテゴリーの類似点としては、著作権の広範な付与、受領者が著作権表示を保持することの要求、およびライセンスのコピーがコードとともに受領者に提供されることが挙げられる。[ 52 ]
オープンソースソフトウェアに関する重要な法的先例の一つは、2008年にジェイコブソン対カッツァー事件で、帰属表示や改変の特定を含むアーティスティックライセンスの条項が強制されたことで確立されました。この判決は、ライセンスの条件が守られなかった場合に著作権法の下で強制執行されることを確固たるものにしました。アーティスティックライセンスは他のオープンソースソフトウェアライセンスと類似しているため、この判決は広く適用される先例となりました。[ 52 ]
フリーソフトウェアライセンス／オープンソースライセンスの例としては、Apacheライセンス、BSDライセンス、GNU General Public License、GNU Lesser General Public License、MITライセンス、Eclipse Public License、Mozilla Public Licenseなどがある。[ 52 ]
ソフトウェア規制には、ソフトウェアが商品かサービスか、何が改変とみなされるか、契約によるガバナンスとライセンスによるガバナンス、所有権と使用権など、オープンソースソフトウェアに大きな影響を与えるグレーゾーンがいくつか存在します。これらの問題については進展が見られますが、多くの場合、さらに多くの疑問が生じます。規制におけるこれらの不確実性の存在は、テクノロジーに関わる業界全体に悪影響を及ぼします。[ 52 ]
ソフトウェアの法的な歴史全体において、特許法、著作権法、あるいは独自の規制の制定によって知的財産として保護すべきかどうかについて多くの議論がありました。最終的には、著作権法が標準となり、コンピュータプログラムは文学作品の一形態とみなされ、独自の規制に若干の修正が加えられました。[ 52 ]
ソフトウェアは一般的にソースコードとオブジェクトコードから成り、どちらも保護対象とみなされますが、この定義には法的差異があります。一部の法域では、独自の目的のためにこの概念を拡大または縮小しようとしています。たとえば、欧州司法裁判所は、コンピュータプログラムを、プログラムの機能、プログラミング言語、またはデータファイルの形式を含まないものと定義しています。ソフトウェアのさまざまな側面に対する保護を制限することで、法律はソフトウェアの使用に対するオープンソースのアプローチを優遇しています。特に米国はソフトウェアに対してオープンなアプローチをとっており、ほとんどのオープンソースライセンスは米国で生まれています。しかし、これによりこれらのライセンス内の特許権への注目が高まり、他の形態の知的財産保護を好むOSSコミュニティからの反発を受けています。[ 52 ]
もう一つの問題は、1996年の世界知的所有権機関（WIPO）条約で国際的に法的に認められ保護された技術的保護措置（TPM）とデジタル著作権管理（DRM）技術です。オープンソースソフトウェアの支持者は、これらの技術が著作権法を超えてエンドユーザーを制限する可能性があるとして、これらの技術を嫌っていました。ヨーロッパは、TPMを法的規制下に置くことでこうした苦情に対応し、OSS支持者にとって勝利となりました。[ 52 ]
オープンソースコミュニティでは、制作されたソフトウェアを所有するのではなく、制作者は進化するソフトウェアの開発を所有します。このようにして、ソフトウェアの未来はオープンになり、OSS内では所有権や知的財産権が難しくなります。ライセンスとブランディングによって、他者がそれを盗むことを防ぎ、公共財としての地位を維持できます。オープンソースソフトウェアは、誰でも利用でき、1人がダウンロードしても他の人にとっての価値が下がることはないため、公共財とみなすことができます。オープンソースソフトウェアは、リソースが減少するのではなく、使用され貢献されるにつれて価値が高まるという点で独特です。これは、評判への投資やネットワーク効果などの概念によって説明されます。[ 53 ]
オープンソースソフトウェアの経済モデルは、開発者がプロジェクトに作業を提供し、公共の利益を生み出すことで説明できます。開発者は、評判の向上やプロジェクトの価値など、認識されている利益やコストに基づいてプロジェクトを選択します。開発者の動機はさまざまな場所や理由から生じますが、重要な点は、お金が唯一の、あるいは最も重要なインセンティブではないということです。[ 53 ]
経済理論は主に希少資源の消費に焦点を当てているため、OSSのダイナミクスを理解するのは難しい場合があります。OSSでは、生産者はプロジェクトへの貢献による報酬を得ることで消費者になります。たとえば、開発者はOSSプロジェクトへの貢献が成功すれば、同僚から高く評価されます。OSSの社会的利益と相互作用も経済モデルでは説明しにくいです。さらに、技術革新は絶えず変化する価値に関する議論と見通しを生み出し、経済モデルでは社会行動を予測できなくなります。[ 53 ]
OSSは経済モデルにおいては理論的に困難を伴うものの、資源を必要とする持続可能な社会活動として説明できる。これらの資源には、時間、資金、技術、貢献が含まれる。多くの開発者は大学や政府などの組織から資金提供を受けた技術を使用しているが、これらの組織もOSSの活動から恩恵を受けている。OSSが成長するにつれて、OSSとプロプライエタリシステムを含むハイブリッドシステムがより一般的になってきている。[ 53 ]
2000年代半ばにかけて、ますます多くのテクノロジー企業がOSSを利用し始めた。例えば、デルはLinuxがプリインストールされたコンピュータを販売するようになった。マイクロソフト自身も、以前はOSS運動に敵対的だったにもかかわらず、 Linuxベースのオペレーティングシステムをリリースした。こうした進展にもかかわらず、これらの企業は特定の目的にのみOSSを使用する傾向があり、OSSが企業に利用され、見返りに何も得られていないという懸念につながっている。[ 41 ]
Battery Open Source Software Index (BOSS) によると、2017 年の経済的に最も重要なオープンソースプロジェクト 10 件は以下のとおりです。[ 54 ] [ 55 ]
多くの政府は、オープンソースソフトウェアが提供する多くの利点から、その導入と普及に関心を持っています。たとえば、英国政府は2004年にオープンソースとオープンスタンダードを推進する政策を発表し、2009年にその政策を再確認しました。「政府は、プロプライエタリなソリューションと並んで、オープンソースのソリューションを積極的に公平に検討する」。[ 56 ]しかし、考慮すべき問題としてサイバーセキュリティがあります。偶発的な脆弱性も考えられますが、外部のエージェントによる攻撃も考えられます。こうした懸念から、ソフトウェアのガバナンスに貢献することに対する政府の関心が高まっています。しかし、これらは問題の概略であり、各国はオープンソースソフトウェアとの独自の政治的な関わりと、その導入に関する目標を持っています。たとえば、米国は、中国やロシアなどの国々でのオープンソースソフトウェア活動の増加による脅威を認識しているため、オープンソースソフトウェアの導入に関して国家安全保障に重点を置いており、国防総省はOSSの使用に関する複数の基準を検討しています。これらの基準には、信頼できる情報源から入手され、信頼できる情報源によって維持されているか、今後も維持されるか、ソフトウェア内のサブコンポーネントへの依存関係があるか、コンポーネントのセキュリティと整合性、外国政府の影響などが含まれます。[ 2 ] 2014年、韓国政府はフリーソフトウェアとオープンソースソフトウェアの使用を増やしたいと考えていました。[ 57 ]
オープンソースに関して政府にとってのもう1つの問題は、オペレーティングシステム、半導体、クラウド、人工知能などの技術への投資です。これらの技術はすべてグローバルな協力に影響を与え、セキュリティ問題や政治的な影響を引き起こします。多くの国は、これらのパートナーシップにおいて、技術革新と技術依存のバランスを取らなければなりません。たとえば、中国のオープンソース依存企業であるファーウェイは、2019年にGoogleのAndroidシステムの使用を禁止された後、独自の代替オペレーティングシステムであるHarmony OSの開発を開始しました。[ 2 ]
ドイツは最近、自国で使用するソフトウェアのガバナンスとメンテナンスを支援するために、国家技術基金を設立した。
コンピューティングの黎明期、特に1950年代と1960年代には、プログラマーや開発者は互いに学び合い、この分野を発展させるためにソフトウェアを共有するのが一般的でした。Unixのような初期のシステムでは、ユーザーがソースコードにアクセスできるようにすることで、共同作業や修正が可能でした。しかし、1970年代と1980年代に商用ソフトウェア産業が台頭すると、独自のモデルが主流となり、このオープンな共有文化は衰退し始めました。このような変化にもかかわらず、学術機関や研究機関は共同ソフトウェア開発の実践を推進し続けました。[ 58 ]
これに対し、ハッカーまたはハッカー文化として広く知られる熟練したプログラマー愛好家たちの活動からオープンソース運動が生まれた。[ 59 ]これらの愛好家の一人であるリチャード・ストールマンは、後にオープンソース運動を可能にするフリーソフトウェア運動の原動力となった。1984年、彼はMITを辞職し、フリーオペレーティングシステムGNUを作成した。これは、彼の研究室のプログラマー文化が、ソースコードの共有と改良を妨げるプロプライエタリソフトウェアによって抑圧されていたためである。GNUはUNIX互換であったため、プログラマー愛好家たちはその動作方法に慣れていた。しかし、ストールマンが選んだフリーソフトウェアというラベルにはすぐに混乱が生じていることが明らかになった。彼はそれを「フリー」とは「言論の自由」のように「フリー」であり、「フリービール」ではないと説明し、価格ではなく自由という意味でフリーであるとした。彼は後にこの自由の概念を4つの本質的な自由へと拡張した。GNUを通じて、他者のソースコードを取り入れる、コミュニティによるバグ修正、新機能のコード提案といったオープンソースの規範が現れた。 1985年、ストールマンはソフトウェアの変更を促進し、GNU の作成を支援するためにフリーソフトウェア財団(FSF) を設立しました。彼の作品がプロプライエタリソフトウェアで使用されるのを防ぐため、ストールマンはコピーレフトの概念を作成しました。これは、特定の条件の下で誰でも彼の作品を使用することを許可するものです。これを行うために、彼は1989 年にGNU General Public License (GNU GPL) を作成し、1991 年に更新しました。[ 34 ] 1991 年、GNU にはカーネルが欠けていたため、 GNU はLinus Torvaldsによって書かれたLinux カーネルと統合されました。 [ 60 ]現在、このオペレーティングシステムは通常Linuxと呼ばれています。[ 34 ]この期間全体を通して、当時、フリーソフトウェアの概念が何であるか、またプロプライエタリソフトウェアの倫理についてさまざまな考えを持つ他の多くのフリーソフトウェアプロジェクトとライセンスが存在していました。たとえば、Berkeley Software Distribution、TeX、X Window Systemなどです。[ 61 ]
フリーソフトウェアが発展するにつれ、フリーソフトウェア財団は、フリーソフトウェアの理念と認識されている利点を商用ソフトウェア業界にもたらす方法を検討し始めました。FSFの社会活動は企業にとって魅力的ではなく、ソフトウェアソースコードの共有とコラボレーションのビジネス上の可能性を強調するために、フリーソフトウェア運動をリブランディングする方法が必要であると結論付けられました。 [ 61 ]オープンソースという用語は、1998年にフリーソフトウェアの支持者の会議でクリスティン・ピーターソンによって提案されました。グループの多くは、フリーソフトウェアという名称が新規参入者にとって紛らわしく、業界の関心を妨げていると感じており、オープンソースという新しい名称をすぐに受け入れ、オープンソース・イニシアティブ（OSI）と、オープンソースソフトウェアとは何かというOSIの定義を作成しました。[ 34 ]オープンソース・イニシアティブ（OSI）の定義は、現在、国際的にいくつかの政府によって標準または事実上の定義として認識されています。[ 60 ]この定義は、主にブルース・ペレンズによって書かれ、改訂されたDebianフリーソフトウェアガイドラインに基づいています。 [ 62 ] OSI の定義は、プロプライエタリ ソフトウェアの包含を認め、ライセンスに関してより多くの自由を認めている点で、フリー ソフトウェアの定義とは異なっていた。 ストールマンなどの一部の人々は、プロプライエタリ ソフトウェアに対して強い倫理的立場を取っているため、結果としてフリー ソフトウェアの元の概念に賛同しているが、ソフトウェアの動作に関しては、この 2 つの運動には多くの重複がある。[ 34 ]
オープンソース・イニシアティブは、この新しい用語の使用を奨励し、その原則を広めようとしたが、商用ソフトウェアベンダーは、自由に配布されるソフトウェアとアプリケーションのソースコードへの普遍的なアクセスという概念にますます脅威を感じるようになり、2001年にはマイクロソフトの幹部がオープンソースを知的財産の破壊者と呼んだ。しかし、フリー・オープンソース・ソフトウェア（FOSS）は歴史的に主流の民間ソフトウェア開発の外で役割を果たしてきたが、マイクロソフトのような大企業もインターネット上で公式のオープンソースの存在を築き始めている。IBM、Oracle、State Farmは、今日の競争の激しいオープンソース市場に真剣に公的に関与している企業のほんの一例であり、FOSSの開発に関する企業哲学の大きな変化を示している。[ 63 ]
オープンソースソフトウェアコミュニティ、ひいてはフリーソフトウェアコミュニティの未来は、その理念が混乱しているわけではないにしても、成功を収めている。例えば、AndroidとUbuntuは、2000年代初頭に存在した技術革新の傍流から台頭したオープンソースソフトウェアの成功のマイルストーンの例である。しかし、コミュニティの一部では、GoogleとそのパートナーによるAndroidのOSSセンターの軽視、フォークを可能にしたApacheライセンスの使用によるAndroid内でのコラボレーション機会の喪失、Ubuntuにおける自由よりも利便性の優先、マーケティング目的でユーザーを追跡するUbuntuの機能などの問題により、OSSの代表として失敗していると考えている。[ 41 ]
OSS の利用はビジネスにおいてより一般的になり、企業の 78% が業務の全部または一部を FOSS で運用していると報告しています。OSS の人気は高まり、かつて OSS を批判していたMicrosoftでさえ、自社のシステムに OSS を取り入れるようになりました。しかし、この成功は OSS の将来を左右する懸念を引き起こしており、コミュニティは OSS とは何か、あるべき姿とは何か、保護する必要があるのかどうか、保護するために何をすべきかといった疑問に答えなければなりません。総じて、フリーおよびオープンソース革命は市場では均衡状態に達したと認識されていますが、それは革命が終わったことを意味するものではなく、その将来を決定するために多くの理論的な議論が行われる必要があります。[ 41 ]
オープンソースソフトウェアは、一般に公開されていること、ライセンス料が不要であること、ライセンス仕様に基づいて変更や配布が許可されていることなど、プロプライエタリソフトウェアと異なる点があります。これらすべては、プロプライエタリソフトウェアの目標である、あらゆるOSS製品の独占を防ぐのに役立ちます。プロプライエタリソフトウェアは、顧客の選択肢を、そのソフトウェアの使用を継続するか、アップグレードするか、他のソフトウェアに切り替えるかのいずれかに限定し、顧客のソフトウェアの選択が金銭的コストによって影響を受けるように仕向けます。プロプライエタリソフトウェアベンダーにとって理想的なシナリオは、顧客がこれらのコストのためにソフトウェアを切り替えることができない、または切り替えることができず、そのベンダーから製品を購入し続けるというロックインです。 [ 64 ]
独自ソフトウェアでは、バグ修正はベンダーのみが提供でき、プラットフォームの移行には別の購入が必要であり、製品の存在はベンダーに依存しており、ベンダーはいつでも製品の提供を中止することができます。[ 59 ]さらに、独自ソフトウェアはソースコードを提供しておらず、ユーザーが変更することはできません。企業にとっては、製品をニーズに合わせてカスタマイズできないため、セキュリティリスクや不満の原因となる可能性があり、アクセスまたは変更できない隠れた脅威や情報漏洩がソフトウェア内に存在する可能性があります。[ 34 ]
OSIの定義によれば、オープンソースとは、ソースコードを一般に公開し、コードの使用や変更に対する制限を緩和またはなくす広範なソフトウェアライセンスである。オープンソースの明確な特徴は、ソフトウェアの急速な進化を可能にするために、組織やユーザーによる使用や配布に対する制限をほとんど設けないことである。[ 65 ]
フリーソフトウェア運動のリーダーであり、フリーソフトウェア財団のメンバーでもあるリチャード・ストールマンは、彼らがフリーソフトウェアと呼ぶものにオープンソースという用語を適用することに反対している。彼は、この2つの用語がほぼ同じカテゴリのソフトウェアを指していることには同意するものの、これらの用語を同一視することは不適切で誤解を招くと考えている。 [ 25 ] 彼は、主な違いは、一方の用語を選択することで、開発（オープンソース）か社会的立場（フリーソフトウェア）か、自分の目標が何であるかを他人に知らせることができる点にあると考えている。[ 66 ]それにもかかわらず、オープンソースソフトウェアとフリーソフトウェアの間にはかなりの重複がある。[ 25 ]ストールマンはまた、オープンソース・イニシアティブの主張する実用主義にも反対しており、ソフトウェアの自由に関するFSFの理想主義的な基準を妥協することで、自由とコミュニティというフリーソフトウェアの理想が脅かされることを懸念している。[ 66 ] FSFはフリーソフトウェアをオープンソースソフトウェアのサブセットとみなしており、リチャード・ストールマンは、例えばDRMソフトウェアはユーザーを制限するにもかかわらずオープンソースとして開発できるため、フリーソフトウェアには該当しないと説明した。[ 25 ]
FSFは、オープンソースという用語は、ソースの入手可能性と、それを使用、変更、再配布する自由を混同するという、別の種類の曖昧さを助長すると述べた。[ 25 ]一方、フリーソフトウェアという用語は、フリーという言葉の曖昧さがビジネスでの採用を阻害すると考えられていること、およびこの用語の歴史的な曖昧な使用法について批判された。[ 66 ]
開発者は、フリーソフトウェアでもあるオープンソースソフトウェアを説明するために、フリーおよびオープンソースソフトウェア（FOSS）またはフリー/リブレおよびオープンソースソフトウェア（FLOSS）という代替用語 を使用してきました。[ 46 ]
ソフトウェアは、読み取り可能なコードであるソースコードとともに配布できます。このソースコードが閲覧可能な場合、ソフトウェアはソース利用可能となります。ただし、ソース利用可能またはFOSSであるためには、ソースコードはすべての人にアクセスできる必要はなく、そのソフトウェアのユーザーのみがアクセスできる必要があります。すべてのFOSSソフトウェアはオープンソース定義で要求されているためソース利用可能ですが、すべてのソース利用可能ソフトウェアがFOSSであるとは限りません。たとえば、ソフトウェアが許可された変更や再配布などのオープンソース定義の他の側面を満たしていない場合、ソースコードが利用可能であっても、そのソフトウェアはFOSSではありません。[ 67 ]
ソフトウェア企業における最近のトレンドは、オープンソース化、つまり以前の独自ソフトウェアをオープンソースライセンスの下でリリースすることによってオープンソースソフトウェアに移行することです。[ 68 ] [ 69 ]これを行う企業の例としては、Google、Microsoft、Appleなどがあります。[ 68 ]さらに、オープンソース化は、オープンソースソフトウェアのプログラミングやオープンソースソフトウェアのインストールを指す場合もあります。[ 69 ]オープンソース化は、新しい視点や問題解決能力をもたらす外部貢献者をより多く引き付けるなど、さまざまな点で有益です。オープンソース化の欠点としては、新しいコミュニティを維持するために必要な作業、例えば、基本コードを簡単に理解できるようにすること、新しい開発者のためのコミュニケーションチャネルを設定すること、新しい開発者が簡単に参加できるようにドキュメントを作成することなどが挙げられます。しかし、いくつかのオープンソースプロジェクトのレビューでは、新しくオープンソース化されたプロジェクトは多くの新規参加者を引き付けるものの、その多くはすぐにプロジェクトを離れる可能性が高く、彼らのフォークも影響力を持たない可能性が高いことがわかりました。[ 68 ]
オープンソースと類似点を持つ可能性のある他の概念としては、シェアウェア、パブリックドメインソフトウェア、フリーウェア、および無料で利用できるがソースコードを提供しないソフトウェアビューア/リーダーなどがあります。ただし、これらはソースコードへのアクセス、ライセンス、著作権、料金の点でオープンソースソフトウェアとは異なります。 [ 34 ]
国際的に協力できるにもかかわらず、オープンソースソフトウェアの貢献者は、シリコンバレーなどの大規模なクラスターに集中しており、そのクラスター内での協力が中心となっていることがわかった。この現象の考えられる理由としては、OSS貢献者の人口統計が主にソフトウェア関連の仕事に従事していること、つまりOSSの地理的な位置がその分散と密接に関連しており、仕事やソーシャルネットワークを通じて協力が促進される可能性があることが挙げられる。[ 70 ]コードの受け入れは、これらのソーシャルネットワーククラスター内での地位によって影響を受ける可能性があり、場所に基づいてコード受け入れに不公平な先入観が生じる可能性がある。[ 71 ]国際的な協力の障壁には、言語や文化の違いも含まれる。[ 72 ]さらに、インドを除く各国では、自国の貢献者からのコードの受け入れ率が高いことが示されており、文化的に類似した協力者に対する偏りがあることが示唆されている。[ 72 ]
2021年、オープンソースソフトウェアへの貢献が最も多かった国は、米国、中国、ドイツ、インド、英国の順でした。[ 70 ] 2021年の調査によると、1人当たりのOSS開発者数が最も多かった国は、アイスランド、スイス、ノルウェー、スウェーデン、フィンランドの順でしたが、2008年にはSourceForgeへの貢献者数の推定値が最も多かった国は、米国、ドイツ、英国、カナダ、フランスでした。[ 70 ] [ 72 ] OSS開発者の分布と貢献に関する研究はいくつか行われていますが、これはまださまざまな方法で測定できる未開拓の分野です。たとえば、情報通信技術への参加、人口、富、インターネットへのアクセスの割合は、OSSへの貢献と相関関係があることが示されています。[ 72 ]
性別の多様性はチームの生産性を向上させることがわかっていますが、女性は性別が特定できる場合、オープンソースソフトウェアプロジェクトに貢献する際に依然として偏見に直面します。 [ 73 ] 2002年、国際的なオープンソースソフトウェア開発者のうち女性はわずか1.5%でしたが、技術業界の職種では女性が28%を占めており、ソフトウェア分野における女性の代表性の低さを示しています。[ 74 ] OSSへの貢献には前提条件はありませんが、貢献者の間で性別は関係なく、コードの品質だけがコードの受け入れの唯一の考慮事項であるという考えが一般的であるため、この性別による偏見は依然として存在し、コミュニティが女性の代表性における体系的な格差に対処することを妨げています。[ 59 ]しかし、2005年から2021年にかけて国際的に計算された女性のOSS参加のより最近の数値は9.8%であり、そのほとんどが最近の貢献者であるため、女性の参加は増加している可能性があります。[ 75 ]
OSSへの貢献者は、FOSSの理念への信念、個人的な関心、コミュニティへの貢献、プロジェクトや問題解決への関心などによって動機づけられています。さらに、特定のソフトウェアのユーザーは、使用するツールの改善を目的として貢献することもあります。また、オープンソース開発環境の協調的な性質に魅力を感じる人もいます。加えて、OSSへの貢献は、プログラミングやシステムエンジニアリングのスキルを磨く機会にもなります。LinuxやTorのような大規模で広く利用されているオープンソースプロジェクトは、貢献者が分析力、厳密な思考力、プログラミング能力、推論能力を試せる、やりがいのある環境を提供しています。また、活発なプロジェクトに参加することで、貢献者は業界の慣行や最新のトレンドを把握することができます。オープンソースプロジェクトには革新的な技術やトレンドが取り入れられており、技術分野で広く普及しています。OSSへの貢献は、貢献内容が公開され、他のユーザーによるレビューを受けることができるため、コミュニティ内での貢献者の知名度や評判を高めることにもつながります。その結果、毎日何千人もの貢献者がオープンソースプロジェクトに貢献し、一般の人々の生活向上のためにプロジェクトの維持に貢献しています。
プログラミングはもともと女性の職業と見なされていましたが、コンピューティングには大きなギャップが残っています。[ 76 ]社会的アイデンティティは大きな懸念事項となる傾向があり、テクノロジー業界の女性は、望まない男性の注目や嫌がらせを受けたり、テクノロジーの知識が女性らしくないことを心配したりして、自信に大きな影響を与えています。[ 59 ]男性テクノロジー関係者の中には、女性がこの文化に馴染むことは不可能だと考えていることを明確にしている人もおり、女性の不安とテクノロジー業界における女性の地位をさらに不安にさせています。さらに、オープンソースソフトウェアのような自主的な貢献環境であっても、女性と男性がOSSへの貢献において同じ生産性を示しているにもかかわらず、女性は手動テストやドキュメント作成など、プロジェクトの技術的ではない側面を担当する傾向があります。明示的なバイアスには、フィードバックに時間がかかること、コードの精査が厳しいこと、コードの受け入れ率が低いことなどが含まれます。[ 73 ]特にオープンソースソフトウェアコミュニティでは、女性は性的に不快な言葉が一般的であり、OSS貢献者としてよりも女性としてのアイデンティティの方が注目されていると報告しています。性別は関係ないという考え方が根強く、ほとんどの貢献者が女性が特別扱いされるのは不公平であり、成功はスキル次第であるべきだと考えているため、偏見に対処するのは困難であり、より包括的な変化を阻害している。[ 59 ]
オープンソースソフトウェアプロジェクトは、多くの場合ボランティアであるプログラマーのネットワークによって構築および維持され、無料製品だけでなく商用製品にも広く使用されています。[ 77 ]
オープンソースという用語は元々はソフトウェアのソースコードのみに適用されていましたが、現在ではオープンソースエコロジーなど他の多くの分野にも適用されています。オープンソースエコロジーとは、あらゆる人が利用できるように技術を分散化する運動です。[ 25 ] [ 78 ]しかし、オープンソースは、異なる競合する原則を持ち、部分的にしか重ならない他の分野に誤って適用されることがよくあります。[ 59 ]
オープンソースソフトウェアの根底にあるのと同じ原則は、オープンソース、オープンコンテンツ、オープンコラボレーションなど、他の多くの事業にも見られます。[ 79 ] [ 80 ]
この「文化」またはイデオロギーは、商業企業で一般的に使用されているような、より中央集権的な開発モデルとは対照的に、さまざまなアジェンダ、アプローチ、優先事項の同時投入を促進するために、原則がより一般的に適用されるという見解をとっている。[ 32 ]
90%以上の企業が、自社開発ソフトウェアの構成要素としてオープンソースソフトウェアを使用しています。[ 81 ]オープンソースソフトウェアを使用する、あるいは既存のオープンソースソフトウェアを改善するためにオープンソースプロジェクトに参加するという決定は、通常、実用的ビジネス上の決定です。[ 82 ] [ 83 ]自社開発ソフトウェアがオープンソースの代替品と直接競合する場合、競争が自社製品の価格と品質に与える影響については、研究によって相反する結果が出ています。[ 84 ]
数十年にわたり、一部の企業は、企業ユーザー向けのオープンソースソフトウェア製品の保守をビジネスモデルとしてきました。これらの企業はオープンソースソフトウェア製品を管理し、ライセンス料や使用料を請求する代わりに、改良、統合、その他の保守に対して料金を請求します。[ 85 ]オープンソースコンポーネントに基づくサービスとしてのソフトウェア（SaaS）製品はますます一般的になっています。[ 86 ]
オープンソースソフトウェアは、透明性を高め、科学的結果の検証と受容を助けるため、科学アプリケーションで好まれています。[ 87 ]
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）しかし、「オープンソースソフトウェア」という表現の明白な意味、そしてほとんどの人がそう考えていると思われる意味は、「ソースコードを見ることができる」です。[...] 「オープンソース」の明白な意味は、その支持者が意図する意味ではありません[...]
{{cite journal}}: CS1メンテナンス: DOIは2025年7月現在非アクティブです（リンク）