stanford-oval/wikipedia huggingface dataset:
イスタンブール地下鉄
路線 > M1号線

M1号線（英語版）は、1989年に完成した最初の路線であり、ハフィフ・メトロと呼ばれている。ハフィフとはトルコ語で「軽い」を意味し、英語のLight Metro（ライトメトロ）を直訳したものである。従って、その規格は路面電車に近く、地上区間が大半であることから地下鉄ではなくライトレールに含める事が多い。しかし、近年に路線番号がM1とされ地下鉄一号線として分類されるようになった。2014年に完成したマルマライやトラム、地下鉄2号線への乗換駅であるイェニカプ駅を基点に旧アタテュルク国際空港にまで延びているヨーロッパ側を走る。Esenler駅からKirazlı駅までの区間が2013年に開通した。Kirazlı駅でM3号線に接続する。長年、空港連絡鉄道として重要な地位を占めていてが、2019年に旧アタテュルク国際空港は旅客営業を終えた。Kirazlı駅からトルコ国鉄高速鉄道ターミナル駅のハルカル駅までの区間が建設中である。
M1本線。支線のM1A、M1B線と直通運転をしている。
Yenikapı: (M2) (Marmaray) (İDO)
Aksaray: (T1)
Emniyet-Fatih
Topkapı-Ulubatlı: (T4)
Bayrampaşa-Maltepe
Sağmalcılar
Kocatepe
Otogar / Coach Station
支線のM1A線
Terazidere
Davutpaşa-YTÜ
Merter: (Metrobus)
Zeytinburnu: (T1) (Metrobus)
Bakırköy-İncirli
Bahçelievler: (Metrobus)
Ataköy-Şirinevler: (Metrobus)
Yenibosna
DTM-İstanbul Fuar Merkezi / Expo Center
Atatürk Havalimanı
支線のM1B線
Esenler
Menderes
Üçyüzlü
Bağcılar Meydan: (T1)
Kirazlı: (M3)
Barbaros(建設中)
Malazgirt(建設中)
Mimar Sinan(建設中) (M9)
Fatih(建設中)
Halkalı Üniversite(建設中)
Mehmet Akif Ersoy(建設中)
Yenidoğan(建設中)
Bezirganbahçe(建設中)
ハルカル駅(建設中) (M11、M34)
路線 > M2号線

M2号線（英語版）は、1992年に着工し、2000年にイスタンブール初の本格的な地下鉄として新市街側のイスティクラル通りの北の終点であるタクスィム広場から北の住宅街に向けて開通した路線である。また、トルコ・テレコム・アリーナとサナイ・マハーレシィ駅（トルコ語版）を結ぶシャトル路線が支線として運行されている。この新市街の地下鉄は金角湾を金角湾メトロ橋（トルコ語版、英語版）で渡って旧市街に達し、M1号線やマルマライ線、トラムと接続するイェニカプ駅までの区間が2014年2月15日に開通した。
Hacıosman
Darüşşafaka
Atatürk Oto Sanayi
İTÜ-Ayazağa
Sanayi Mahallesi,
4. Levent
Levent
Gayrettepe: (Metrobüs)
Şişli-Mecidiyeköy: (M7) (Metrobüs)
Osmanbey
Taksim: (F1) (T2)
Şişhane: (F2) (T2)
Haliç / Golden Horn
Vezneciler: (T1)
Yenikapı: (M1A) (M1B) (Marmaray) (İDO)
Sanayi Mahallesi:
Seyrantepe
路線 > M3号線

M3号線（英語版）は、バシャクシェヒル＝メトロケント（トルコ語版）とキラズル（トルコ語版）間、支線のオリンピヤト（トルコ語版）とイキテッリ・サナイ（トルコ語版）間が2013年6月14日に開通。Kirazlı駅ではM1B号線に接続する。イスタンブールが立候補していた2020年夏季オリンピックの会場予定であったオリンピック公園への交通手段路線として整備された。キラズル駅から先、バクルキョイIDO駅（トルコ語版）までの延伸計画もある。
Başakşehir-Metrokent
Başak Konutları
Siteler
Turgut Özal
İkitelli Sanayi,
İstoç
Mahmutbey: (M7)
Yenimahalle
Kirazlı: (M1B)
İkitelli Sanayi:
Ziya Gökalp Mahallesi
Olimpiyat
路線 > M4号線

M4号線は、2008年に着工し、2012年に8月17日にアジア側のカドゥキョイ（トルコ語版） からカルタル（トルコ語版）までの区間が完成したアジア側最初の地下鉄路線である。2016年10月10日にはタヴシャンテペ（トルコ語版）まで延伸された。全線が地下を走る。さらにその先はサビハ・ギョクチェン国際空港まで延伸部分が2022年10月2日に開通した。カドゥキョイ（トルコ語版）, アイルルク・チェスメシ, ユナラン（トルコ語版）、ギョズテペ（トルコ語版）の各駅は海面下の標高に位置している。
Kadıköy: (T3) (İDO)
Ayrılık Çeşmesi: (Marmaray)
Acıbadem
Ünalan: (Metrobüs)
Göztepe
Yenisahra
Kozyatağı
Bostancı
Küçükyalı
Maltepe
Huzurevi
Gülsuyu
Cevizli
Hastane-Adliye
Soğanlık
Kartal
Yakacık
Pendik
Tavşantepe
Hastane
Şeyhli
Kurtköy
Sabiha Gökçen Havalimanı
路線 > M5号線

M5号線（英語版）はアジア側ではM4号線につぐ2番目の地下鉄路線として2017年12月15日にユスキュダル～ヤマネブラー間が開通した。その後、2018年10月21日にはチェキメキョイ（トルコ語版）までの区間が延伸開業している。トルコで最初の全自動運転の鉄道路線となっており、全駅にホームドアが設置されている。
Üsküdar: (Marmaray)
Fıstıkağacı
Bağlarbaşı
Altunizade: (Metrobüs)
Kısıklı
Bulgurlu
Ümraniye
Çarşı
Yamanevler
Çakmak
Ihlamurkuyu
Altınşehir
İmam Hatip
Dudullu
Necip Fazıl
Çekmeköy
路線 > M6号線

M6号線（英語版）はライトレール・メトロ路線。2号線のレヴェント駅とボアジチ大学＝ヒサリュステュ駅（トルコ語版）間の3.3kmが2015年4月19日に開通。
Levent (M2)
Nispetiye
Etiler
Boğaziçi Üniversitesi
路線 > M7号線

M7号線（英語版）は計画ではカバタシュ駅とマフムットベイ駅（トルコ語版）を結ぶが、メジデイェキョイ - マフムットベイ間の18km、15駅が2020年10月28日に開通、ユルドゥズ（トルコ語版）-メジデイェキョイ間が2023年1月2日に開通している。ユルドゥズ-メジデイェキョイ間は暫定的にシャトル運用となっている。2029年に全線が開通予定となっている。
Kabataş(T1) (F1)(建設中)
Beşiktaş(建設中)
Yıldız
Fulya
Mecidiyeköy: (M2) (Metrobüs)
Çağlayan
Kâğıthane
Nurtepe
Alibeyköy
Yeşilpınar
Veysel Karani
Akşemsettin
Kâzım Karabekir
Yenimahalle
Karadeniz Mahallesi: (T4)
Tekstilkent
Yüzyıl
Göztepe
Mahmutbey: (M3)
路線 > M8号線

M8号線（英語版）。2023年1月6日開通。総延長14.2 km。Bostancı駅とParseller駅を結ぶ。
路線 > M9号線

M9号線（英語版）。2021年5月29日部分開通。総延長13 km。Ataköy駅と Olimpiyat駅を結ぶ予定。
路線 > M10号線

M10号線（英語版）。Pendik Merkez駅からサビハ・ギョクチェン国際空港までを結ぶ建設中の路線。2025年開通予定
路線 > M11号線

M11号線（英語版）。イスタンブール空港までを結ぶ路線。新空港開港に合わせて建設されていたが2023年1月23日に開通。M7号線のキャウトハーネ駅から路線が空港まで開通済みで空港～キャウトハーネ駅間所要時間26分で結ぶ。残りの空港からトルコ国鉄のハルカル駅までの区間は建設中である。ハルカル駅までの区間が完成するとマルマライ線を経由する高速鉄道に乗り換えてアンカラ方面へ行くことが可能となる。
路線 > M12号線

M12号線（英語版）。建設中。
路線 > M13号線

M13号線（英語版）。計画中。
路線 > M14号線

M14号線（トルコ語版）。建設中。
路線 > M34号線

M34号線（トルコ語版）。計画中。
その他

上記の地下鉄路線以外にも、ライレールのT4号線（トルコ語版、英語版）は半数が地下を走り、ケーブルカーの2路線（F1、F2）も地下を走る。そのうち、F2号線はテュネルと呼ばれ、ロンドンに次いで世界第二に古い地下鉄と言われることもある。また、マルマライ線も地下を走る。
ギャラリー

1号線のイェニカプ駅
1号線の車両
1号線のゼイティンブルヌ駅
1号線のオトガル駅（トルコ語版）
M1、M2号線のイェニカプ駅
イェニカプ駅のM2号線ホーム
M2号線のレヴェント駅
M2号線の車内
2号線のハリッチ駅
2号線のハリッチ駅プラットホーム
2号線のハジュオズマン駅（トルコ語版）入口
2号線のオスマンベイ駅（トルコ語版）
M4号線のユナラン駅（トルコ語版）
M5号線の案内板
M5号線のフストゥカージュ駅（トルコ語版）
M5号線のアルトゥニザデ駅（トルコ語版）
6号線のニスペティエ駅
M6号線のレヴェント駅
6号線のレヴェント駅構内
7号線のアリベイキョイ駅（トルコ語版）構内
イェニカプ駅構内
金閣湾に架かるM2号線の橋（金角湾メトロ橋（トルコ語版、英語版））
M5号線Huzurevi駅の駅名表示板
M1A/M1B号線の路線図
地上を走るM1号線のハフィフ・メトロ
M1号線のDavutpaşa—YTÜ駅
M1号線のアタテュルク空港駅
M2号線の路線図
金角湾を渡るM2号線
M2号線のハリッチ駅
M3号線の路線図
M3号線のMahmutbey駅
M4号線の路線図
M4号線の車両
M4号線のアジバデム駅（トルコ語版）
M4号線のアイルルク・チェスメシ駅
M5号線の路線図
M5号線の自動運転を行う車両
M5号線のÜsküdar駅
M6号線路線図。
6号線のNispetiye駅構内
M7号線の路線図
全面ホームドアのある7号線Mecidiyeköy駅
全面ホームドアのあるM8号線の駅
M11号線のイスタンブール空港駅
オープンソースソフトウェア

Fedoraのデスクトップアプリケーションリスト
Linux MintのアプリケーションXfce・VLC・GIMP・電卓・カレンダー・Firefox
オープンソースソフトウェアの組み込みOS Android
オープンソースソフトウェアのウェブサービス構成例 LAMP
オープンソースソフトウェア（英: Open Source Software、略称: OSS）とは、利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称である。
解説

1950年代のコンピュータ上でソフトウェアが稼働するようになった頃、学術機関・研究機関の間でソフトウェアのソースコードはパブリックドメインで共有されていた。1970年代前後よりソフトウェア開発は徐々に商業となり、ソフトウェアの再頒布を禁止するプロプライエタリソフトウェア、ソースコードを非公開とするクローズドソースの文化ができあがった。1980年代より利用者がソフトウェアのソースコードを自由に利用できないことをストレスに感じた人たちはフリーソフトウェア財団やオープンソース・イニシアティブを立ち上げ、ソースコードを一般に公開してソフトウェアの利用者による利用・修正・再頒布を許すことによるソフトウェア開発の発展を提唱し、オープンソースソフトウェアの文化ができあがった。
一般に使われている基準として、オープンソース・イニシアティブの提唱するオープンソースおよびフリーソフトウェア財団の提唱する自由ソフトウェアのカテゴリに含まれるソフトウェアがオープンソースソフトウェアである。ソフトウェアのソースコードが公開されていても、その利用・修正・再頒布が有償である、商用利用は禁止されるなどの制限がある場合は、オープンソースソフトウェアではなくプロプライエタリソフトウェアやシェアードソース・ソフトウェアと呼ばれる。オープンソースソフトウェアに課すソフトウェアライセンスはオープンソースライセンスと呼ばれ、管理団体やコミュニティによってある程度精査されており、GNU GPL・Apache-2.0・MITなどの既存の汎用的なライセンスを利用することが推奨されている。
類似した概念にオープンソースハードウェア・オープンシステム・オープンコンテントなどがある。
歴史

→詳細は「オープンソースソフトウェアの歴史」を参照
1950年代のコンピュータ上でソフトウェアが稼働するようになった頃、学術機関・研究機関の間でソフトウェアとソースコードはパブリックドメインで共有され、ソフトウェアのソースコードを利用者が共有・修正・再頒布する文化は存在していた。1970年代以降、ソフトウェア開発は徐々に商業となり、ソフトウェアの頒布に制約を付与するプロプライエタリソフトウェア、ソースコードを非公開とするクローズドソースの文化ができあがった。
1980年代序盤、リチャード・ストールマンは利用者がソフトウェアのソースコードを自由に利用できないことは非道徳であると考えて自由ソフトウェアを提唱した。リチャード・ストールマンは自由ソフトウェアだけで構成されたオペレーティングシステムを開発するGNUプロジェクトを立ち上げ、自由ソフトウェア運動を促進するフリーソフトウェア財団を設立した。自由ソフトウェアはソフトウェア利用者のソフトウェアを実行・複製・配布・研究・変更・改良する自由を守るためソースコードの公開を求め、コピーレフト・ライセンスを用いてソースコード共有文化のコモンズ（ローカル・コモンズ）の輪を広げた。
1990年代末、ネットスケープ・コミュニケーションズはエリック・レイモンドの著書The Cathedral and the Bazaarに感化されてクローズドソースで開発していたMozilla Application Suiteを自由ソフトウェアとしてソースコードを公開した。エリック・レイモンドやブルース・ペレンズ、リーナス・トーバルズたちはソースコードの共有は望ましいが、自由ソフトウェア運動のプロプライエタリソフトウェアへの攻撃的姿勢とコピーレフトの閉鎖性は企業には受け入れられ辛いと考えた。そこでソースコードの共有文化の再ブランドを検討し、ソースコードを公開・共有したソフトウェア開発の実利的なメリットを主観にしたオープンソースを提唱し、オープンソース・イニシアティブを設立した。オープンソースの開発手法はホビイストやハッカーの非商用ソフトウェアだけでなく企業・商用のプロプライエタリソフトウェアにも利用され、ソフトウェア開発の分野で広く利用されるようになった。
2000年代以降、オープンソースは一般的な用語となり、オープンソースソフトウェアとして様々なソフトウェア、例えばLAMP・Ruby on Railsなどのウェブプラットフォーム、Linux・FreeBSD・Androidなどのオペレーティングシステム、OpenCVなどのライブラリ、といったものが開発された。Javaのソフトウェア開発キットであるOpenJDKや、.NET仕様のオープン実装であるMonoや.NET Coreなど、もともとクローズドソースやプロプライエタリだったソフトウェアがオープンソース化されたり、オープンソース版の実装がサードパーティの企業やコミュニティによって別途開発されたりしているものもある。TypeScriptやGoなど、公式の処理系（コンパイラやプログラミングツール）がオープンソースとなっているプログラミング言語も存在する。マイクロソフトによる従来のC#/Visual Basic .NETのコンパイラ (csc/vbc) はプロプライエタリだったが、のちにオープンソース版のRoslynコンパイラ（英語版）が開発された。処理系がオープンソース化されるプログラミング言語は、言語仕様がオープン標準になっていたり、ISOやEcmaといった団体によって標準化されていたりするものも多い。
定義

オープンソースソフトウェアは、ソフトウェアのソースコードが一般に公開され、商用および非商用の目的を問わずソースコードの利用・修正・再頒布が可能なソフトウェアと定義される。オープンソースライセンスが課せられたソフトウェアやパブリックドメインに置かれたソースコードとそのソフトウェアなどがそれに当たる。
アメリカ国防総省はオープンソースソフトウェアを「可読性のあるコードが利用・学習・再利用・修正・改善・再頒布が可能であるソフトウェア」と定義している。ソースコードが開示されていても商用を目的として提供されるソフトウェアはオープンソースソフトウェアとは区分せず、プロプライエタリソフトウェアやクローズドソース・ソフトウェアに区分している。
オープンソース・イニシアティブは「オープンソースの定義」に従ったソフトウェアをオープンソースのソフトウェアと定義している。オープンソースの定義は単純にソースコードへのアクセスが開かれていることを定義するものではなく、オープンソースのソフトウェアは利用者がそのソースコードを商用および非商用の目的を問わず利用・修正・頒布することを許し、それを利用する個人や団体の努力や利益を遮ることがないことを定義している。オープンソース・イニシアティブはオープンソースライセンスというライセンスカテゴリを管理しており、そのオープンソースの定義に準拠したライセンスのみをオープンソースライセンスとして承認している。オープンソースソフトウェアはオープンソースライセンスが課せられたソフトウェアであると言い換えることが出来る。
フリーソフトウェア財団はオープンソースソフトウェアという単語についての定義は行なっていないが、類似した概念として自由ソフトウェアという単語を「自由ソフトウェアの定義」において定義している。自由ソフトウェアは利用者の自由とコミュニティに敬意を払い、利用者にソフトウェアを実行・複製・配布・学習・改善する自由を提供する。その自由を提供するために、自由ソフトウェアのソースコードは一般に公開され、利用者はソフトウェアのソースコードを自由に利用・修正・再配布することが可能である。フリーソフトウェア財団の代表であるリチャード・ストールマンはオープンソース・イニシアティブの定義するオープンソースという単語およびその活動を否定的に発言しており、同財団ではオープンソースソフトウェアという単語の定義および意義については消極的である。
日本の総務省はオープンソース・イニシアティブのオープンソースの定義を満たすソフトウェアをオープンソースソフトウェアを定義するものとして参照している。
まとめると、以下の条件がOSSとして備わっていなければならない。
1.自由な再頒布ができること
2.ソースコードを入手できること
3.派生物が存在でき、派生物に同じライセンスを適用できること
4.差分情報の配布を認める場合には、同一性の保持を要求してもかまわない
5.個人やグループを差別しないこと
6.利用する分野を差別しないこと
7.再配布において追加ライセンスを必要としないこと
8.特定製品に依存しないこと
9.同じ媒体で配布される他のソフトウェアを制限しないこと
10.技術的な中立を保っていること
標準化団体

広義のオープンソースソフトウェア（オープンソースのソフトウェアや自由ソフトウェア）の分野における標準化団体はオープンソース・イニシアティブとフリーソフトウェア財団が主要な団体である。それに加えて各専門分野において、 Linux分野ではLinux Foundation、デスクトップ環境分野ではfreedesktop.org、携帯機器分野ではOpen Handset Allianceなどの組織がある。
標準化団体 > オープンソース・イニシアティブ

→詳細は「オープンソース・イニシアティブ」を参照
オープンソース・イニシアティブは、1998年2月にブルース・ペレンズとエリック・レイモンドにより設立されたオープンソースのソフトウェア（英: open-source software）の発展・促進を目的に活動している非営利団体である。
オープンソース・イニシアティブは、ソースコードの利用・修正・再頒布を可能とするソースコードの共有文化によるソフトウェア開発の発展のため、オープンソースのソフトウェアをオープンソースの定義において定義し、オープンソースのソフトウェアを利用者の商用・非商用などの目的を問わず利用しやすい文化の構築に貢献している。オープンソースのソフトウェアに適したソフトウェアライセンスをライセンスレビューを通して選定し、オープンソースのライセンスとして承認している。オープンソースのライセンスのリストを逐次更新し、より新しく適切なライセンスの推奨や、時代遅れとなり不適切となったライセンスの非推奨など、オープンソースライセンスの管理をしている。
オープンソース・イニシアティブはオープンソースの用語を用いる際はオープンソースの定義に準拠することを求めている。オープンソースの商標については、アメリカでは1999年6月に「Open Source」の商標登録を求めたが、Open Sourceは一般的な用語であり特定団体が権利を持つ商標にはならないと判断されている。これについて、オープンソース・イニシアティブはOpen Sourceが一般的な用語として周知されたことを歓迎する立場を取っている。なお、日本では2002年3月にオープンソースグループ・ジャパンが「オープンソース・OPENSOURCE」を商標登録（第4553488号）している。日本での用語の利用に際しては特に許諾や制限は求められないが、オープンソースの定義に準拠した扱いで利用されることが望まれている。
オープンソース・イニシアティブは、2006年にSugarCRMが自社のことを「Commercial Open Source」と表現し、オープンソースのライセンスとして承認していないライセンスをソフトウェアに課していたことを非難した。後に、SugarCRMはライセンスをオープンソースのライセンスとして承認されているGPLv3に切り替えている。
標準化団体 > フリーソフトウェア財団

→詳細は「フリーソフトウェア財団」を参照
フリーソフトウェア財団は、1985年10月4日にリチャード・ストールマンにより設立された自由ソフトウェア（英: free software）の発展・促進を目的に活動している非営利団体である。
フリーソフトウェア財団はソフトウェアの利用者の作成、頒布、改変する自由をユーザーに広く遍く推し進めることを狙い、自由ソフトウェアを自由ソフトウェアの定義において定義し、コピーレフトを基本とする社会運動の支援を目標に掲げている。コピーレフトは利用者がソフトウェアを実行・複製・配布・研究・変更・改良する自由を守り、その利用者の自由を派生ソフトウェアに展開して自由ソフトウェアのコモンズの輪を広げる概念である。フリーソフトウェア財団はコピーレフトの概念をGPLやAGPLなどのソフトウェアライセンスとして実装し、同ライセンスの利用を推進している。
フリーソフトウェア財団は利用者がソフトウェアを実行・複製・配布・研究・変更・改良する自由を尊重し、その自由であるソフトウェアを啓蒙する社会運動として自由ソフトウェア運動を行っている。自由ソフトウェア運動では自由を尊重するソフトウェアやファイルフォーマットをGNU宣言・自由ソフトウェアの歌・PlayOggなどを通して啓蒙している。利用者の自由を妨げるDRMやソフトウェア特許についてはDefective by DesignやTiVo化と表現して批判している。また、フリーソフトウェア財団は自由ソフトウェアとオープンソースのソフトウェアは異なるものであり、オープンソースは自由ソフトウェアの理念の的を外しているとして、広義のオープンソースソフトウェアのような表現ではなく、自由ソフトウェアとオープンソースソフトウェア、FLOSS (Free/Libre and Open Source Software) などの表現をすることを求めている。
フリーソフトウェア財団は自由ソフトウェアのみで構成されるオペレーティングシステムの開発、および自由ソフトウェアライセンスの実装とレビューをするプロジェクトとしてGNUプロジェクトを遂行している。
標準化団体 > その他の団体

freedesktop.orgは、2000年にハヴォック・ペニントンにより設立されたUnix系システムのデスクトップ環境の相互運用性の向上と共通基盤技術の整備を目指した非営利団体である。GNOME・KDE・XfceなどのX11上のデスクトップ環境のユーザビリティの差異の問題を明確化し、共通化の方向性を模索・助力をしている。また、X.Org Server・D-BUS・HALなどの基礎基盤のリファレンス実装を開発し、各ソフトウェアでの実装の差異の削減を図っている。
Linux Foundationは、2007年1月にOpen Source Development LabsとFree Standards Groupを統合する形で設立されたLinuxオペレーティングシステムの普及をサポートする非営利のコンソーシアムである。Linuxのカーネルを含む開発とそのオペレーティングシステムの成長と普及のための活動を実施している。Linuxの原作者であり開発の第一人者であるリーナス・トーバルズは2018年現在、Linux Foundationにフルタイムで勤務している。
Open Handset Allianceは、2007年11月にGoogleを中心として設立された携帯機器の共通環境の開発を推進するために組織されたアライアンス（コンソーシアム）である。通信キャリア・半導体メーカー・携帯電話メーカー・ソフトウェアベンダーなど携帯機器分野全般の企業・団体が参画している。Open Handset Allianceはオープンソースの携帯電話のフラグシップ・ソフトウェアとしてAndroidを開発し、Android SDKをオープンソースソフトウェアとして公開している。参画組織はアライアンスが開発したAndroidをフォークして試験的なクローズドソースのバージョンで試験実装をしたり、独自のAndroidディストリビューションを用いた携帯電話の開発・販売している。
クリエイティブ・コモンズは、2001年に著作物の適正な再利用の促進を目的として設立された非営利団体である。クリエイティブ・コモンズはクリエイティブ・コモンズ・ライセンスという著作物全般に適用可能なライセンスをリリースしている。ただし、クリエイティブ・コモンズはソフトウェア分野の著作物には既に適したライセンス（ソフトウェアライセンス）が多数存在しており、クリエイティブ・コモンズ・ライセンスを利用する必要性はないとして、ソフトウェアとソースコードにクリエイティブ・コモンズ・ライセンスを適用することは推奨していない。
ライセンス

→詳細は「オープンソースライセンス」を参照
→「Category:オープンソースライセンス」も参照
オープンソースライセンスは、オープンソースソフトウェアの定義に従い利用者の利用目的に問わずソフトウェアのソースコードの利用・修正・再頒布を認めるソフトウェアライセンスである。オープンソースライセンスの多くはソフトウェアのソースコードを公開したパーミッシブ・ライセンスもしくはコピーレフト・ライセンスである。パーミッシブ・ライセンスはソフトウェアの利用に最低限の制約のみを課し、コピーレフト・ライセンスはソフトウェアの利用に利用者の自由を制約として義務付ける。ソフトウェアに課せられたライセンスが本当にオープンソースソフトウェアであることを認めるソフトウェアライセンスであるかについて慎重な法的レビューをするべきである。
2018年2月現在、広く使われている、もしくは、著名なコミュニティが採用しているパーミッシブ・ライセンスとしてApache-2.0・BSD-3-Clause・BSD-2-Clause・MIT、コピーレフト・ライセンスのGPLv3・LGPLv3、原作者特権条項のあるMPL-2.0・CDDL-1.0・EPL-2.0が挙げられる。
ライセンス > 誓約

オープンソースライセンスは、ライセンサー（作者）の定めた誓約に従う範囲でライセンシー（利用者）にソフトウェアとソースコードの自由な利用を認める。オープンソースソフトウェアの性質上、ソフトウェアやその二次著作物は元の作者でも制御しきれない形で頒布されるため、多くのライセンスでソフトウェアおよびソースコードの利用に際して「無保証 (NO WARRANTY)」と宣言した誓約を記す。それに加えてライセンス毎に異なる誓約（条項・条文）が記す。
著作権表示条項および広告表示条項は、適切な形でソースコードや付属文書に含まれる著作権表示を保持し、つまり二次的著作物を作った者が自分で0から作ったように偽らないことを定める。著作権表示は改変していないソースコードファイルのヘッダのコピーライトを残した上で、ソフトウェアを利用するエンドユーザーに作品元を表示することを求めるApache-2.0や、ソフトウェアのソースコードツリーのCOPYRIGHTファイルに作品元を記すことを要求するMITなどがある。
コピーレフト条項ないし継承条項は、そのライセンスで公開されたソフトウェアを修正して二次創作物として公開する場合に、同じライセンスもしくはそれと同等条件の利用許可を要求するライセンスで公開することを定める。同等ライセンスを派生ソフトウェアに課すことで、ライセンスが規程するソースコードの共有文化のコモンズを展開する。派生ソフトウェアに同一ライセンスを要求するGPL・MPL-2.0・CDDL-1.0がある。
原作者特権条項は、原則的には利用者にその事項を許可もしくは禁止するが、原作者が利用する場合にはその限りではないことを定める。原作者は利用者にソフトウェアのソースコードを開示することを要求するMPL-2.0・CDDL-1.0がある。
ライセンス > ガイドライン

オープンソースライセンスは多数のライセンスが存在しているが、オープンソース・イニシアティブ・GNUプロジェクト・Fedoraプロジェクト・Debianプロジェクトなどは対象のソフトウェアライセンスがオープンソースソフトウェアに課すライセンスとして適切であるかの法的レビューを個々に実施している。特にオープンソース・イニシアティブとGNUプロジェクトのライセンスレビューは重要であり、それらの団体のレビューを通ったライセンスをオープンソースライセンスとして用いることが推奨される。
オープンソース・イニシアティブはオープンソースの定義に基づいたライセンスレビューの実施とライセンスの一覧を管理をしている。オープンソースのライセンスの中でも主要なライセンスを選定しており、オープンソースソフトウェアにはその主要なライセンスの中からライセンス選択することを推奨している。オープンソースのライセンスと主要ライセンスの一覧は適宜更新されており、過去に承認・推奨されていたライセンスでも現在は非推奨となったライセンスなどもある。
GNUプロジェクトは自由ソフトウェアの定義に基づいた自由ソフトウェアライセンスの一覧を管理している。一覧には自由ソフトウェアの定義に適合しているか、コピーレフト条項を含むか、GPLと互換性があるか、および特記事項を記載している。自由ソフトウェアはそれに応じた異なるライセンスを選択するべきとし、ライセンス選択時の推奨ガイドラインを出している。一般的なソフトウェアではコピーレフト特性をもつGPL、小さなプログラムではコピーレフト特性を持たないApache-2.0、ライブラリではLGPL、サーバソフトウェアではAGPLを推奨している。
Fedoraプロジェクトは同プロジェクトのソフトウェアに課せられるべきソフトウェアライセンスの一覧を管理している。Fedoraの公式パッケージに含まれるソフトウェアはこの一覧にあるソフトウェアライセンスが課せられたものであり、これらのライセンスはフリーソフトウェア財団、オープンソース・イニシアティブおよびRed Hat法務担当が公認したものである。ライセンスの検証はFedoraのメーリングリストで公に検証されている。ただし、コンフィデンシャルな情報を送ることや、ソースコードについての法的な助言を求めるために利用してはならないし、メーリングリストの参加者が法律家や弁護士であることを仮定するべきではない。
DebianプロジェクトはDebianフリーソフトウェアガイドライン (DFSG) に基づいたソフトウェアライセンスの一覧を管理している。Debianの公式パッケージに含まれるソフトウェアは原則としてDebianフリーソフトウェアガイドラインに準拠したソフトウェアライセンスが課せられたものである。Debianフリーソフトウェアガイドラインはオープンソースソフトウェアの定義に符号するものであり、DFSG準拠ライセンスはオープンソースソフトウェアに課すソフトウェアライセンスの一例として参考にできる。
ライセンス > 検討課題

ソフトウェアライセンスにはライセンスの互換性がある。異なるライセンスはそれぞれが定める誓約の下にソフトウェアとソースコードを利用することが出来るが、ライセンスによっては自身のソフトウェアの利用に対する誓約だけではなく併用するソフトウェアに対して求める誓約を含む場合があり、その際に複数のソフトウェアのライセンスに互換性がない場合はソフトウェアを併用することが不可能となる。例えば、GNU General Public Licenseは併用するソフトウェアに同一のライセンスを適用することを求めているため、同ライセンスと商用ソフトウェアのクローズドソースを求めるライセンスは併用出来ない。フリーソフトウェア財団はGPLのコピーレフト誓約違反に対して幾度も訴訟を起こしている。
2000年代前半、オープンソースソフトウェアのライセンスは多数の独自ライセンスが策定され、よく似た条文で一部分だけ異なるという有象無象のライセンスがいたずらに作られていったことを問題視し、その事象はライセンスの氾濫と呼ばれ批判の対象となった。ライセンスの氾濫はライセンス製作者の虚栄心を満たすだけの無害なものではなく、オープンソースソフトウェアに課せられたライセンスの内容を精査しなければならない利用者を疲弊させる有害なものであった。オープンソース・イニシアティブは2006年にこの問題を解決するためライセンス氾濫問題プロジェクト (License Proliferation Project) を立ち上げ、ライセンスレビューを通して承認ライセンスを選定することでライセンスの氾濫を抑えた歴史がある。ライセンスの氾濫を再発させないため、オープンソースソフトウェアのライセンスは既存のオープンソースライセンスを採用することが推奨される。ライセンスの作成者は新規ライセンスの必要性について慎重な検討を経て策定に至り、ライセンスを承認する団体は新規のライセンスが既存のライセンスと本質的な差異がない場合は承認しない判断を下している。
ライセンスの継承条文を伴うオープンソースライセンスが課せられたソフトウェアは、その継承条文に基づき、ソフトウェアのソースコードを利用、修正したソフトウェアのソフトウェアライセンスを同等条件のものとするよう縛る。このライセンスの縛りはソースコードの二次利用、三次利用と伝播し、ライセンスがウイルスのように感染していくことからウイルス性ライセンス（ライセンス感染）と呼ばれる。ライセンス感染するライセンスの例としては、GPL (コピーレフト条文)やCC BY-SA (SA条項)がある。ライセンス感染の影響は元となったソフトウェアライセンスの内容に依るが、GNU GPLのコピーレフト条項のようにソースコードの公開を義務とするものや、CC BY-SAのSA条項ように同等条件のライセンスを強制するだけ（ソースコードの公開を求めるかどうかは別条文に依る）のものがある。
パブリックドメインによる著作権の放棄は著作権法の下に完全に認められたという実績（判決）は存在しておらず、法的な判断が不明瞭である。ソースコード作成者が著作権を放棄する意図でパブリックドメイン以下で公開していたソースコードに対して、ソースコード作成者が考えを変えて著作権の保持を主張してソースコードの二次利用者を訴えた場合に、サブマリン特許のように見解を翻して権利を行使することの是非という道徳的な観点は別として、著作権の放棄の有効性について著作権法の下にどのような判断がなされるのか明確になっていない。つまり、パブリックドメインはソースコード作成者の当初の意図に反して著作権の放棄はできておらず、著作権の保持を根拠にしたソースコードの二次利用者に対する訴えは有効であるとされる可能性がある。そのような不確定性のため、オープンソース・イニシアティブはパブリックドメインに相当するCC0を有効なオープンソースライセンスとして承認していない。一方で、フリーソフトウェア財団はCC0を有効な自由ソフトウェアライセンスとして承認している。
OSS開発 > 開発手法

→詳細は「オープンソースソフトウェア開発」を参照
オープンソースソフトウェアの利用者は共同開発者のように扱われる。利用者はソフトウェアのソースコードにアクセスすることができ、ソフトウェアへの機能追加、ソースコードの修正、バグの報告、ドキュメントの提出が可能である。利用者はそれらをソフトウェア開発のメインストリームに反映することができるし、利用者が望むのであれば自身の製品として頒布することもできる。オープンソースソフトウェアで複数の共同開発者を持つことは、ソフトウェアの発展を手助けする。リーナスの法則では、「十分な目玉を与えられることで、全てのバグは浅くなる」と述べている。このことは、多くの利用者がソースコードを眺めれば、結局は全てのバグを発見しそれらの修正方法が提案される、ということを意味している。
オープンソースソフトウェア開発に使われる開発ツールはそれもまたオープンソースソフトウェアであることがある。オープンソースソフトウェア開発でオープンソースソフトウェアの開発ツールである利点は、オープンソースソフトウェアのライブラリの一部にオープンソースソフトウェアを利用する利点と同じく、その開発ツールがオープンソースソフトウェアであることによる利便性、安全性、信頼性を享受できることである。
OSS開発 > 開発手法 > モジュール分解

オープンソースソフトウェアの機能は幾つもの細分化されたモジュールで構成されている。例えばコンパイラでは、字句解析、構文解析、意味解析（英語版）、最適化、コード生成などの機能を持ち、それらはモジュールとして一つのソフトウェアに内包される。LAMPのようなSaaSでは、Linux、Apache、MySQL、PHPなどの複数のオープンソースソフトウェアの組み合わせで、一つのサービスを提供している。細分化されたモジュールはそれぞれの機能を得意とする利用者および開発者により改善がもたらされ、より良いソフトウェアへの発展を手助けする。
オープンソースソフトウェアのアーキテクチャは利用者および開発者により決定され、その戦略的決定を利用者の意見や他の多くの要因に依存する。長期に渡って固定された具体的な仕様や開発計画に依らず、複数の要因による柔軟なアーキテクチャ決定を通して仕様や開発計画を決定する。オープンソースソフトウェアの利用者は各個により良いアーキテクチャを決定する権利を持ち、メインストリームのソフトウェアおよび派生したソフトウェアのアーキテクチャとしてそれを採用することができる。
OSS開発 > 開発手法 > ソースコード管理

→「OSSホスティングサービスの比較」も参照
ソフトウェアの開発者が複数名からなり、修正が頻繁になされるオープンソースソフトウェア開発では、ソースコードの修正内容、修正履歴の閲覧、そして修正の差し戻しを助けるためソースコードリポジトリにバージョン管理システムが用いられる。
ソースコードリポジトリはソフトウェアのソースコード一式を保存し、ソースコードの変更者、変更時刻、変更時コメントを残す。ソースコードの変更はユニークなID（連番の数字やハッシュ値）が割り当てられ、変更の記録を遡って特定して変更内容を確認することができる。ソースコードリポジトリはローカルファイルシステムに置くものや、インターネットを介したネットワーク上に置くものもある。オープンソースソフトウェアの利用者はソースコードリポジトリをフォークして独自のソースコードリポジトリを構築し、そのソースコードリポジトリ上でオープンソースソフトウェアを利用、修正、再頒布してより良いオープンソースソフトウェアを提供することができる。
ソースコードリポジトリをホスティングサービスとして提供するウェブサービスには、SourceForge、GitHub、Bitbucketなどがある。それらのウェブサービスは一般にソースコードが公開されるバージョン管理されたソースコードリポジトリを提供し、オープンソースソフトウェアの開発を支援している。それらのリポジトリはソースコードの閲覧、フォークは二次開発者が自由に行えるが、メインストリームのソースコードリポジトリに置かれたソースコード修正は主管開発者やその権限が与えられた開発者のみに許されており、不適切なソースコード修正がメインストリームのソースコードリポジトリに反映されて品質を損なうことを防いでいる。
オープンソースソフトウェアの開発者間のコミュニケーションはメーリングリスト、IRC、インスタントメッセージ、バグトラッキングシステムなどのインターネットコミュニケーションが用いられる。これらのコミュニケーションツールはオープンソースソフトウェアのソースコードの実装についてだけではなく、オープンソースソフトウェアの開発に関わるプロジェクトの方針、設計の検討、テストの実施、不具合の報告などの多岐に渡った話題のためのコミュニケーションに利用される。
コミュニケーションツールはプロジェクトの話題に限定したIRC、Skype、Slackなどのチャット、ソースコードリポジトリ、バグトラッキングシステム、ウィキを統合したGitHub、Bitbucketなどのホスティングサービス、プロジェクトやソフトウェアを限定しない雑多なStack Overflow、redditなどのコミュニティサイトが存在する。
OSS開発 > 開発手法 > ブランチとフォーク

→「ブランチ (ソフトウェア)」および「フォーク (ソフトウェア開発)」も参照
オープンソースソフトウェアのリリースは複数の公式バージョンを配布している。一つは「安定版」で、機能が安定している、致命的なバグがない、実行環境への最適化がなされているなどの、利用者がそのソフトウェアを定常的に利用しても大きな問題が発生することが想定されていないバージョンである。一つは「検証版」で、試験的な機能が実装されている、バグが存在している、幾つかの環境でのみ動作するなどの、利用者がソフトウェアの開発および検証を目的として用いるバージョンである。安定版は検証版より長い間隔でリリースされることもあり、幾つかの検証版のリリースを経て安定版がリリースされることがある。検証版はアルファ版、ベータ版、RC（Release Candidate、リリース候補）版などの名称を持つ。オープンソースソフトウェアの特性上、安定版ですべての機能が完成して開発が終了するものを示すものではなく、安定版もまた継続してリリースされる。
オープンソースソフトウェアのリリースサイクルは短い間隔でリリースされる。ソフトウェアのソースコードが公開されていることにより、利用者はスナップショットのソースコードでソフトウェアをビルドすることが可能で、そのソフトウェアを非公式リリースとして頒布することもできる。短い間隔でのリリースを実現するため、継続的インテグレーションツールを用いてナイトリー版のビルドをリリースするソフトウェアもある。
OSS開発 > プロジェクト

→「Category:オープンソースソフトウェア」も参照
多くのプロジェクト・ソフトウェアがオープンソースソフトウェアのソフトウェアを開発している。1980年代にプロプライエタリソフトウェア、クローズドソースに移行したオペレーティングシステム・プログラミング言語コンパイラも2000年代移行にオープンソースソフトウェアとして開発・普及している。
GNUプロジェクトは自由ソフトウェアのGNUユーティリティとしてLinux・Windows・macOS・その他OSで動作するユーティリティソフトウェアを開発している。
リーナス・トーバルズが1980年代から開発しているLinuxはオープンソースソフトウェアのオペレーティングシステムとして広く使われている。Linuxは様々なベンダー・ユーザーにより派生したソフトウェアが開発されLinuxディストリビューションの総称で呼ばれている。2007年以降、LinuxはLinux Foundationが開発主体となった。
Apacheソフトウェア財団はApache HTTP Serverを代表にC/C++のソフトウェア・ライブラリ、Javaのソフトウェア・ライブラリを開発している。また、Sun Microsystemsが開発していたオフィスソフトウェアの後継Apache OpenOfficeや、Adobeが開発していたFlashビルドツールの後継Apache Flex、HTML5アプリケーションプラットフォームの後継Apache Cordovaなど、企業が開発していたソフトウェアの後継メンテナンスも行っている。
カノニカルは2004年にユーザビリティの高いLinuxディストリビューションとなることを目標としてDebianから派生してUbuntuを開発した。Googleは2009年にウェブブラウザChromeをベースにしたChrome OSを開発した。
Googleは2012年3月にマルチコアのマシンでプログラマが意識することなくマルチスレッドを最適化して実行するGo言語を発表した。Mozilla Foundationは2012年1月に速度、安全性、平行性を言語仕様特徴として謳うシステムプログラミング向けのRust言語を発表した。Appleは2014年6月にiOS、macOS用プログラミング言語のObjective-Cの文法をモダンにリフォーマットしたSwiftを発表した。
OSS開発 > ビジネスモデル

→詳細は「オープンソースソフトウェアのビジネスモデル」を参照
多くのソフトウェアベンダー・ハードウェアベンダー・ソフトウェアライセンサーはオープンソースソフトウェアのフレームワーク・モジュール・ライブラリを彼らの製品に利用している。一方で、オープンソースソフトウェア開発はソフトウェアのソースコードを共有・利用・修正・再頒布を認めるという特性から収益を得るビジネスモデルを成立させることが難しく、様々な手法でのビジネスモデルの確立が試行されている。
オープンソースソフトウェアをビジネスで利用するメリットは、開発者にとってはソフトウェアのソースコードを公開し、利用者を増やすことで市場シェアを伸ばすことができる。利用者にとっては無償で利用できる、目的に併せて改変できる、コミュニティによって新しいバグが即座に修正されるという利点がある。
ビジネスモデルの例として、デュアルライセンスやサポートサービスは、ソフトウェアのライセンスに複数の選択肢を与え、基本機能のソフトウェアや過去のバージョンのソフトウェアのソースコードはオープンソースライセンスで開示し、より良い機能（英語版）のソフトウェアやテクニカルサポートを有償で提供する。クラウドファンディングや投資組織は、ソフトウェア開発の前に開発資金を確保して、その資金をもってソフトウェア開発プロジェクトの運営を行い、完成したソフトウェアの販売やプロダクトの権利譲渡、先行投資アドバンテージなどにより資金援助元へ還元する。有償コンテンツ・拡張機能の販売は、ソフトウェア本体は無償のオープンソースソフトウェアとして利用者にリリースし、ソフトウェアを利用するためのコンテンツやより便利にするための拡張機能を有償販売する。ドネーションウェア・アドウェアは、ソフトウェアは完全に無償で全ての機能を利用可能とした上で、寄付や広告による収益を得る。
オープンソース文化・運動 > OSS啓発本・映画

The Cathedral and the Bazaar（1999年、O'Reilly Media、ISBN 978-1565927247）は、エリック・レイモンドによるオープンソースソフトウェア開発のエッセイである。同著書ではGNUプロジェクトのトップダウン開発手法をカテドラル方式、Linux・Fetchmailのボトムアップ開発手法をバザール方式と評して、バザール方式のソースコードを公開・共有したソフトウェア開発の有効性について述べている。エッセイの主題はバザール方式におけるエリック・レイモンドが提起したリーナスの法則「十分な目玉があれば、全てのバグは洗い出される」という点で、オープンソースソフトウェアでは利用者を共同開発者と捉えて、利用者と共にソフトウェア開発を進めることでより良いソフトウェアを開発することができると述べている。
Open Sources: Voices from the Open Source Revolution（英語版）（1999年、O'Reilly Media、ISBN 1-56592-582-3）、Open Sources 2.0（英語版）（2005年、O'Reilly Media、ISBN 0-596-00802-3）は、オープンソースソフトウェア分野の著名人のエッセイをまとめた書籍である。マーシャル・カーク・マキュージック、マイケル・ティーマン、リーナス・トーバルズ、ポール・ヴィクシー、ラリー・ウォール、イアン・マードック、ラリー・サンガー、ティム・オライリーなどが寄稿している。
Revolution OS（2001年）は、1970年代末から約20年間のGNUプロジェクト・Linux・自由ソフトウェア・オープンソースの歴史をまとめたドキュメンタリー映画である。オープンソースソフトウェア分野の著名人のリチャード・ストールマン、リーナス・トーバルズ、エリック・レイモンド、ブルース・ペレンズが特別出演している。
オープンソース文化・運動 > 自由ソフトウェア運動

→詳細は「自由ソフトウェア運動」を参照
自由ソフトウェア運動（英: Free Software Movement）は、フリーソフトウェア財団を主体にした自由ソフトウェアの利用者の自由を尊重する思想を啓蒙する社会運動である。自由ソフトウェア運動はGNU宣言を代表として、自由ソフトウェアの定義・コピーレフト・Defective by Design・BadVista・TiVo化批判・自由ソフトウェアの歌など、理念的なものから他者批判的なもの、ユーモラス的なものまで多種多様である。
自由ソフトウェア運動の理念の1つとして、自由ソフトウェアとオープンソースは別物でありオープンソースソフトウェアの名の基に自由ソフトウェアを用いるのは不適切であるという考えがあり、自由ソフトウェア運動家はフリーソフトウェアとオープンソースのソフトウェアの総称を「OSS（オープンソースソフトウェア）」ではなく「FLOSS（Free/Libre and Open Source Software）」もしくは「自由ソフトウェアとオープンソースソフトウェア」と明確に別けて呼称する。
他のソフトウェアモデルとの比較 > 自由ソフトウェア

→詳細は「自由ソフトウェア」を参照
自由ソフトウェアは、広義のオープンソースソフトウェアの定義においてオープンソースソフトウェアの部分集合であるが、オープンソースソフトウェアと自由ソフトウェアは根源的なコンセプトが異なる。オープンソースソフトウェア（オープンソース）がソフトウェアのソースコードを公開・共有する「開発の方法論」である一方で、自由ソフトウェアは利用者の自由（実行・研究・変更・コピーを変更ありまたはなしで再配布するという自由）を尊重する「社会運動」である。コンセプトが開発の方法論と社会運動と異なるため、本来は並列に比較するようなものではない。
その上で、自由ソフトウェアという社会運動のための一つのツールとしてオープンソースソフトウェアという開発の方法論を用いようとした場合、オープンソースソフトウェアは利用者の自由を尊重するのに機能不十分なツールである。この機能不十分な点を比較した場合、オープンソースソフトウェアが許容する幾つかのライセンスは不適切であり、自由ソフトウェアはコピーレフトに代表されるような利用者の自由を尊重するための条項が含まれたライセンスを推奨している。
機能不十分な例としては、オープンソース・イニシアティブがオープンソースライセンスとして承認しているSybase Open Watcom Public License（英語版）は利用者が修正したソースコードから作られたソフトウェアを個人的な用途で公開した場合にはソースコードの公開を必要としていない。これは修正されたソフトウェアは一般に公開されているにもかかわらず、そのソフトウェアのソースコードは非公開となっており、二次利用者の自由を妨げている。もう一つの例としては、オープンソースソフトウェアは利用者がソフトウェアもしくはそのソフトウェアが動作するハードウェアをTiVo化 (tivoization) することを許容するライセンスの存在を許し、二次利用者の自由を妨げることを否定していない。
他のソフトウェアモデルとの比較 > ソースアベイラブル・ソフトウェア

→詳細は「ソースアベイラブル・ソフトウェア」を参照
ソースコードは開示しているという条件だけを満たしている物をソースアベイラブル・ソフトウェアと呼ぶ。ソフトウェアの範囲はオープンソースソフトウェアよりも広い。営利利用に制限がかかっていたり、改変禁止だったりするとソースアベイラブルとなる。