├── CONTRIBUTORS.md ├── LICENSE.md ├── README.md ├── pdf └── 東京都オープンソース公開ガイドライン.pdf └── 東京都オープン・ソース・ソフトウェア公開ガイドライン.md /CONTRIBUTORS.md: -------------------------------------------------------------------------------- 1 | 東京都オープン・ソース・ソフトウェア公開ガイドラインのコントリビューター 2 | ============================================ 3 | 4 | ## 編集を行ったメンバー（更新時点所属） 5 | 6 | | 名前 | 所属 | 7 | | --- | --- | 8 | | 荻原 聡 | 東京都 デジタルサービス局 戦略部 サービス開発担当部長 | 9 | | 小澤 洋之 | 東京都 デジタルサービス局 戦略部 戦略課長 | 10 | | 松野 友雄 | 東京都 デジタルサービス局 戦略部 デジタルシフト推進担当課長 | 11 | | 松居 和広 | 東京都 デジタルサービス局 戦略部 デジタル推進課 課長代理（デジタルシフト推進担当） | 12 | | 田村 正典 | 東京都 デジタルサービス局 戦略部 デジタル推進課 課長代理（デジタルシフト推進担当） | 13 | | 猪ノ口 渉 | 東京都 デジタルサービス局 戦略部 戦略課主事 | 14 | | 山田 篤彦 | 東京都 デジタルサービス局 戦略部 戦略課主事 | 15 | | 大石 晴日 | 東京都 デジタルサービス局 デジタルサービス推進部 ネットワーク推進課主事 | 16 | 17 | 18 | ## 謝辞 19 | 編集にあたりましては、下記の皆様にご協力いたただきましたことを、改めて感謝申し上げます。 20 | 21 | | お名前 | ご所属 | 22 | | --- | --- | 23 | | 遠藤 雅人 | The Linux Foundation OpenChain Project Automotive Chair / Japan Work Group Promotion Sub Group Leader | 24 | | 大崎 雅行 | The Linux Foundation OpenChain Project | 25 | | 小保田 規生 | The Linux Foundation OpenChain Project | 26 | | 高須 正和 | 開源社（China Open Source Alliance) / 早稲田大学リサーチイノベーションセンター | 27 | | 福安 徳晃 | Linux Foundation Japan 代表 | 28 | | 八田 真行 | 駿河台大学経済経営学部准教授 | 29 | 30 | 31 | ## ガイドラインの更新にご協力いただいた皆様 32 | ガイドラインの更新にあたり、下記の皆様にご協力いただきましたことをお礼申し上げます。 33 | | Name (link) | GitHub | Link | 34 | | --- | --- | --- | 35 | | | | | 36 | 37 | 38 | お名前の掲載をご希望の方は，[#11](https://github.com/Tokyo-Metro-Gov/tokyo-oss-guideline/issues/11)にコメントをお願いします。 39 | 40 | If you want to add your name, please comment on [#11](https://github.com/Tokyo-Metro-Gov/tokyo-oss-guideline/issues/11). 41 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | ## License 2 | 3 | This guideline is licensed under CC0. 4 | [![CC0](http://i.creativecommons.org/p/zero/1.0/88x31.png "CC0")](http://creativecommons.org/publicdomain/zero/1.0/deed.ja) 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 東京都オープン・ソース・ソフトウェア公開ガイドライン 2 | 3 | ## リソース 4 | - [マークダウン形式](./東京都オープン・ソース・ソフトウェア公開ガイドライン.md) 5 | - [pdf形式](./pdf/東京都オープンソース公開ガイドライン.pdf) 6 | 7 | ## 本ガイドラインの目的と意義について 8 | 東京都OSS公開ガイドラインは、今回の感染症対策の経験を踏まえつつ、OSS化がもたらす社会的効果を、 9 | - 都が保有する知的資産（ソースコード）を公共財として、都民や他の自治体と共有することで、国内外から幅広く意見（修正改善意見）を聞くことが可能となり、これによりOSS自体が自律的に発展し、都民にその利益を還元することが可能となる。 10 | - この動きを全国に波及させることで、行政などが類似するシステムを構築する際の開発時間とコストの縮減にも寄与することができる。 11 | 12 | と捉え、その効果を最大限に活かし、都政のQOS（クオリティ・オブ・サービス）の向上を推進していくため、このガイドラインを策定し、都全体でOSSに取り組んでいくために策定しました。 13 | 本ガイドラインは、都庁内部向けのもので、OSSの定義や公開から廃棄までの手順、注意点などを明記しています。 14 | 15 | ## 本ガイドラインを Github での公開を行った趣旨について 16 | ガイドラインを、自由に他自治体で派生利用されることを目的とし、本ガイドラインを公開しているほか、多くのシビックテック・エンジニアの方々に見ていただき、改善点の把握に努めていくなどのフォローアップを実施し、継続的に必要な見直しを行っていくため、Githubでの公開を行っています。 17 | 18 | ## いただいたご意見（ Issue や Pull Request ）への対応方針 19 | ガイドラインの修正は、いただいたご意見にその都度対応するものではなく、定期的な修正の機会を設け、修正しバージョンアップして参ります。 20 | 21 | ## License 22 | 23 | This guideline is licensed under CC0. 24 | [![CC0](http://i.creativecommons.org/p/zero/1.0/88x31.png "CC0")](http://creativecommons.org/publicdomain/zero/1.0/deed.ja) 25 | -------------------------------------------------------------------------------- /pdf/東京都オープンソース公開ガイドライン.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Tokyo-Metro-Gov/tokyo-oss-guideline/20ae9b0a2d7489571482ba921fcbeb22e3f54fe7/pdf/東京都オープンソース公開ガイドライン.pdf -------------------------------------------------------------------------------- /東京都オープン・ソース・ソフトウェア公開ガイドライン.md: -------------------------------------------------------------------------------- 1 | # **東京都オープン・ソース・ソフトウェア公開ガイドライン（β版（0.1.0版））** 2 | 3 | ## 第１ オープンソース・ソフトウェア公開ガイドライン策定の背景と目的 4 | 5 | ### 1 新型コロナウイルス感染症対策サイト構築から見えてきた世界 6 | 　新型コロナウイルス感染症が拡大の傾向を見せるなか、都では、今までに経験したことのない状況下で、正確な情報を都民に迅速に届けるため、「東京都新型コロナウイルス感染症対策サイト」を開設した。 7 | 　このサイトは、日々変わる感染状況をワンストップで閲覧できるサイトとして立上げ、運用にあたっては、都だけではなくシビックテックと協働し、順次、その精度を高め、行政のクオリティ・オブ・サービス（以下「QOS」という。）の向上につなげていった。 8 | 　具体的には、このサイトのソースコードを、GitHub※を活用して公開することで、世界中から大小合わせて2,000件以上の改善要求が寄せられ、それらに対応することで、使いやすさを高めていった。この改善提案の中には台湾のデジタル担当大臣・唐鳳（オードリー・タン）氏からのものもあり、誰もが行政が提供するウェブサイトに対して貢献できることが示された好事例となった。 9 | 　また、GitHub上で公開したソースコードはオープンソースソフトウェア（以下「OSS」という。）として他の自治体でも利活用され、各地域における独自のコロナ対策サイトの構築にも貢献することとなった。令和3年4月20日現在、54の地域において本サイトのソースコードを活用したサイトが構築されており、その総数は63件となっている。 10 | 　さらには、そのうち、13府県市が当該自治体の公式サイトとして運用するなど、日本全体の課題に対する地方自治体の連携強化にも資するものとなった。 11 | 　このように、今までに経験したことのない状況下で、正確な情報を都民に迅速に届けることが求められる場面で、OSSという仕組みによってサービスを提供できたことは、都民のみならず国民に対しても大きな効果（貢献）があったものと考えられる。 12 | 　※「第３　OSSの管理」内の「コラム：GitHubの仕組み」参照 13 | ### 2 都政の構造改革の推進 14 | 　長期化するコロナ禍で、社会のデジタルシフトが加速している。こうした、社会の大きな変化、変革は、より良い社会を実現する好機ととらえることもできる。 15 | 　このため、都は、DX(デジタル・トランスフォーメーション)の推進を梃子として、都政のQOSを向上させることで、都民のQOL（クオリティ・オブ・ライフ）を高め、誰もが安全・安心で幸せを享受できる社会の実現を目指していくこととしている。 16 | 　これを受け、令和3年3月には、「シン・トセイ　都政の構造改革QOSアップグレード戦略」を策定し、都庁自らがイノベーティブな存在になるとともに、市民、企業、大学、NPOなど多様なプレイヤーとのコラボレーションにより社会課題を解決し、明るい未来の東京をつくり上げることを目標に掲げた。 17 | 　この目標を実現するための一つの選択肢として、OSSの活用がある。都は、このOSSを積極的に活用し、シビックテック等との協働を実践し、成功事例を積み上げ、OSSに対する職員の意識改革を進めて行くこととしている。（OSSとは、機械ではなく人間にとって解釈や編集がしやすい形式のプログラムコードを無償で公開し、利用や改変、再配布が自由に許可されているソフトウェアのことを指す。） 18 | ### 3 ガイドライン策定の目的 19 | 　今回の感染症対策の経験を踏まえつつ、OSS化がもたらす社会的効果を以下の2点と捉え、その効果を最大限に活かし、都政のQOSの向上を推進していくため、本ガイドラインを策定し、都全体でOSS化に取り組んでいくものとする。 20 | * 　都が保有する知的資産（ソースコード）を公共財として、都民や他の自治体と共有することで、国内外から幅広く意見（修正改善意見）を聞くことが可能となり、これによりOSS自体が自律的に発展し、都民にその利益を還元することが可能 21 | * 　また、この動きを全国に波及させることで、行政などが類似するシステムを構築する際の開発時間とコストの縮減にも寄与 22 | 23 | ## 第２ OSSの定義 24 | 　都は前述したOSS化がもたらす社会的効果を最大限活用していくことを目指し、 都が公開するOSS（以下「“東京都OSS”」という。）が持つべき要素について以下のとおり定義する。 25 | ### 1 OSSに求められる要素※ 26 | ”東京都OSS”として公開するものについては、以下の要素を持つものとする。 27 | ※OSSに求められる要素の記載内容は、OSI(Open Source Initiative)のオープンソースの定義（The Open Source Definition）に準拠した内容となります。 28 | 29 | **(1)　再配布の自由** 30 | 　都が開発したソースコードを公開することは、都民に対する行政サービス向上の可能性を引き上げることに対し多くのメリットがある。そのため、都が公開したソースコードの再配布の自由を確保するものであること。 31 | **(2)　ソースコード** 32 | 　「オープンソース」であるプログラムは、コンパイル済形式と同様にソースコードでの配布も許可されていること。また、公開されるソースコードは、プログラマがプログラムを変更しやすいものであること。 33 | **(3)　派生ソフトウェアの配布が可能** 34 | 　ソフトウェアの変更と派生ソフトウェアの作成を可能とする。ただし、ライセンスの適用については、「第5 公開時のライセンス」を参照するものとする。 35 | **(4)　作者のソースコードの完全性(integrity)** 36 | 　プログラム変更により派生したソフトウェアが、オリジナルのソースコードと区別できるものであること。また、“東京都OSS”として公開されたソースコードから派生されたソフトウェアにおいては、その旨を明示するよう求めるものとする。 37 | **(5)　個人やグループ、使用する分野によってのプログラムの利用用途限定の禁止** 38 | 　可能な限り多くの人々やグループに、平等に公開したソースコードを使用・利用することが認められているものであること。 39 | **(6)　利用分野に対する利用制限の禁止** 40 | 　ライセンスはある特定の分野でプログラムを使うことを制限しないものであること。 41 | **(7)　ライセンスの配布** 42 | 　プログラムに付随する権利は、そのプログラムが再配布した者全てに等しく認められるものとし、使用者・利用者が何らかの追加的ライセンスに同意することを必要としないものであること。 43 | **(8)　特定製品でのみ有効なライセンスの禁止** 44 | 　プログラムに付与された権利は、それがある特定の私有（Proprietary）ソフトウェア配布物の一部であるということに依存するものであってはならない。プログラムをその配布物から取り出したとしても、そのプログラム自身のライセンスの範囲内で使用あるいは配布される限り、プログラムが再配布される全ての人々が、元のソフトウェア配布物において与えられていた権利と同等の権利を有することを保証するものであること。 45 | **(9)　他のソフトウェアを制限するライセンスの禁止** 46 | 　ライセンスは、そのソフトウェアと共に配布される他のソフトウェアに制限を設けないものであること。 47 | **(10)　ライセンスの技術的中立性の保持** 48 | 　ライセンス中に、自由な開発を阻害するような特定の技術やインターフェース等の様式に強く依存するような規定を設けないものであること。 49 | 50 | 51 | --- 52 | 53 | ***【コラム：ローコード・ツールやノーコード・ツールを使ったアプリの公開】*** 54 | 　“東京都OSS”として公開する場合は、OSSとしての汎用性・拡張性を確保する必要があり、特定の私有（Proprietary）ソフトウェア配布物の一部であるということに依存するものであってはならない。そのため、特定製品でのみ有効なライセンスの利用を禁止する。 55 | 　しかしながら、膨大な行政手続や行政サービスを、迅速かつ効率よくデジタル化していくうえで、簡易なソフトウェアについては、ローコード・ツールやノーコード・ツールといった開発ツールの活用が欠かせないものとなりつつある。 56 | 　また、ローコード・ツールで開発されたアプリについても、本ガイドラインの策定趣旨の一つである、行政などが類似するシステムを構築する際の開発時間とコストの縮減にも寄与できるものでもある。 57 | 　これらのことから、ローコード・ツールを活用したアプリについては、“東京都OSS”として公開はしないが、開発した各局は積極的に、各ローコード・ツールが提供しているコミュニティサイトなどにおいて、テンプレートなどとして公開していくことを推奨していくものとする。 58 | 59 | 60 | --- 61 | 62 | ### 2 OSS公開条件 63 | 　OSSとして公開することは、実運用しているサービス及び機能、並びに、処理に対応するソースコード及び内部仕様が、外部からも入手することができ、また、他のサービスやシステム開発の検討や再利用なども可能となる。このため、“東京都OSS”として公開する場合には、以下の条件を課すものとする。 64 | 65 | **(1)　OSS化の検討** 66 | 　前記の“OSSに求められる要素”を満たすソースコードは、原則OSS化することを前提に、行政サービスの提供等の事業目的をもってシステムを開発し運用する各局（以下「OSS所管局」という。）は、開発案件発足時において、第１の3に記載されている“社会的効果及びOSSとして公開することの価値の有無”を検討すること。（検討の結果、OSSとしない決定をした際は、その理由についてデジタルサービス局に通知をすること。） 67 | 　検討にあたっては、開発や公開そのものが目的ではなく、OSSとして流通することによる価値（効果）を明確にするとともに、流通後の運用フェーズにおける保守や改修を想定した体制や維持経費等についても、検討しておかなければならないことに留意すること。 68 | 　また、公開する範囲を設定のうえ、既存のプロジェクトの特定機能のみを切り出すことも可能とし、他方、ソースコードそのものに開発者独自の技術ノウハウがあり、そのため公開ができない場合は、OSS化の対象外と判断しても良い。 69 | 　なお、検討の対象として、都が開発するソースコードのすべてがOSSの対象となるわけではなく、既に開発が完了しているソースコードについては、当面は、改めてOSSとするか否かの検討は必要ないものとする。 70 | **(2)　OSSにおける権利の記載** 71 | 　OSSとして公開するためには、その開発を実施した各組織・個人が、OSSの著作権を保有し、その権利をプロジェクトのオープンソースソフトウェア・ライセンスの下で有効化する必要がある。このため、OSS化にあたっては、ソースコードの複製・配布・改良の範囲を検討のうえ、開発したコードを一般に公開するために必要なライセンスを決め、これに応じて著作物の権利をあらかじめ確保しておくこと。 72 | 　なお、都が公開するOSSは、多くの人々にその利益を享受してもらうことのできる、広く流通しやすいものにするべきであり、例えば、ライセンス形式が非コピーレフト等を選択するのが望ましいが、行政として、OSSから派生していく“アプリ”等（以下、「派生製作物」という。）の質を、サービスの目的の公共性が高く信頼性が求められ、特に監理していくことが必要な場合は、準コピーレフトにより公開していくこともあることから、OSS所管局は、事前にデジタルサービス局と協議のうえ、ライセンスを選定していくものとする。(「第５　公開時のライセンス」参照） 73 | **(3)　関連資料の公開** 74 | 　実装を容易にするための開発プロセス全体を通じて開発者が開発したコード、ドキュメント及びその他の関連資料等の知見を配信すること。 75 | 　例えば、依存関係（該当する場合）を含む、ソフトウェアの構築、作成、インストール、取り扱うデータの形式やそのフォーマット、または使用方法に関するその他の関連する技術的詳細がそれに該当する。 76 | **(4)　OSS公開後の評価** 77 | 　都のOSS開発・公開をより良いものにするため、OSS公開後、運用フェーズにおいてOSS化したことの意義を、評価するための効果検証を行うこと。 78 | 79 | ## 第３ OSSの管理 80 | 　”東京都OSS”として公開する場合は、そのOSSは以下のとおり管理する。 81 | ### 1 OSSの管理基盤 82 | 　OSSは自由な使用・利用を可能とすることを目指し、ソースコードを配信するものであるため、都においても、ソフトウェア開発プラットフォームであるGitにて管理するものとする。 83 | 　なお、Gitを用いた共通基盤を提供する代表的なサービスとしては、GitHubが挙げられる。このため、当面は、デジタルサービス局が、本サービスを活用し、都OSS管理基盤を構築のうえ、各局担当者に適切なアクセス権限を付与しつつ、運用していくものとする。 84 | 85 | 表１.GitHubにおける都公式アカウント表記等 86 | |
都公式アカウント
|
プロフィール
| 87 | | :--------| :-------- | 88 | |Tokyo-Metro-Gov|都のアイコンを使用し
“Tokyo Metropolitan Government”と表記| 89 | 90 | ### 2 管理体制 91 | 　都のOSS管理基盤で管理する対象は、都が開発したものとする。 92 | 　公開のタイミングや期間等、その他OSSの公開に関する取り決めなど、管理にあたって必要となる事項は、デジタルサービス局と、OSSの開発主体となるOSS所管局、開発事業者及び保守運用事業者（以下「開発保守業者」という。）が連携し、協議のうえ決定する。 93 | 　また、各組織の具体的な役割は以下のとおりとする。 94 | 95 | 96 | 表2　各組織とその主な役割 97 | |
組織
|
役割
| 98 | | :--------| :-------- | 99 | | 各局（OSS所管局） |開発予定アプリケーションをOSS化対象とするかの検討、OSSの改善管理| 100 | | 開発保守業者 |OSSの開発、OSSのマージ、OSSの維持管理 | 101 | | デジタルサービス局 |OSSの管理環境の維持・管理、各局からのOSS化に関する相談、開発後のOSSの公開判断、OSSの公開・非公開の設定 | 102 | 103 | 　なお、OSS開発・公開に関する運用の詳細については「第５　公開及び保守運用に関する手順」に記載する。 104 | 105 | 106 | --- 107 | 108 | ***【コラム：GitHubの仕組み】*** 109 | 　GitHubとは、ソフトウェア開発者のため、Git（ソースコードのバージョンを管理するツール）をWebサービス上で利用できるようにした開発プラットフォーム。GitHub上でソースコードを管理することで、世界中の開発者と一緒にソースコードのレビューやソフトウェアの開発を行うことができる。 110 | 　一般的には、GitHub上で管理されているソースコード群（以下「リポジトリ」という。）を、開発者が自身の開発環境にダウンロード（フォーク＆プル）し、改変（コミット）を加え、GitHub上のリポジトリを更新（プッシュ）し、おおもとのソフトウェアのリポジトリの取込依頼（プルリクエスト）をしていくことでソフトウェアが完成していく。 111 | 　都では、GitHub上に都公式のGitHubアカウントを準備し、そこに完成したリポジトリをアップロードすることでOSSを公開していく。これにより行政サービス構築に係る開発保守業者がそれにアクセスし、自身の環境にダウンロードすることで、それを活用した行政サービスの開発・提供に係るコスト削減が可能となるなどのメリットも生まれる。 112 | 113 | 図1　GitHub開発のイメージ 114 | 115 | ![](https://i.imgur.com/RL5RkVg.jpg) 116 | 117 | 118 | --- 119 | 120 | 121 | ## 第４ 公開及び保守運用に関する手順 122 | ### 1 公開等作業にあたっての留意事項 123 | 　都がOSSを公開する際、開発保守業者の納品物を都公式のものとして公開するという特殊な手順を取るため、公開時のほか、開発保守業者との契約時や公開後の保守運用、開発保守終了時にも留意が必要となる。 124 | 　特に、OSS化は、一般的なシステム開発以上に、保守運用が重要となるため、発注時の仕様書や経費積算には注意する必要がある。また、公開するソースコードについては、開発保守事業者が開発したソースコードを事業者内でソースコードレビューを確実に行うほか、外部からPull request等でパッチ提供があったものをマージする際もソースコードレビューを行うこと。 125 | ### 2 公開手順 126 | 　OSS所管局は、そのソースコードをOSSとして公開を希望する際、デジタルサービス局は対象のサービスを確認・審査したのち、そのサービス毎に公開場所を準備する。 127 | 　公開するソースコードについては、開発保守業者自身の保有するGitHubアカウント上のリモートリポジトリにコミットされているものを、都側アカウントでプッシュする方式、もしくは、プルリクエストを受けてマージする方式とする。 128 | 　開発完了前、修正中のソースコードは、都としての認証は行わないものとし、OSS所管局が修正等を確認した納品物のみ、都側アカウント公認のOSS（“東京都OSS”）とする。 129 | 130 | 図2　アカウントと各組織の関係 131 | 132 | ![](https://i.imgur.com/z2aN0l7.jpg) 133 | 134 | 135 | |
用語
|
意味
| 136 | | -------- | -------- | 137 | | フォーク | 複製元に、開発や援助の貢献を前提に、都のリモートリポジトリを開発者のリモートリポジトリとして複製すること。 | 138 | | プル | 開発者のリモートリポジトリから開発環境のローカルリポジトリにダウンロードすること。 | 139 | | クローン | 開発環境のローカルリポジトリから開発担当者自身の環境にリポジトリをダウンロードすること。 | 140 | | プルリクエスト| 修正・変更を、他の開発者やリポジトリ管理者に通知すること。 | 141 | | マージ | 他で変更を加えたファイル、フォルダをリポジトリに取り込むこと。 | 142 | | プッシュ | 開発環境のローカルリポジトリの変更内容を、リモートリポジトリ取り込むこと。 | 143 | 144 | 　以下に、OSS開発案件の発足から一般公開するまでの手順及び各組織の役割について明記する。 145 | 146 | 図3　OSS開発から公開までの手順 147 | 148 |
149 | 150 | ![](https://i.imgur.com/pTKTcYF.png) 151 | 152 |
153 | 154 | 表3　OSS公開までの役割分担 155 | 156 | | ＃ |
組織
|
役割
| 157 | | -------- | -------- | -------- | 158 | |1| 各局（OSS所管局）|案件発足時に開発予定アプリケーションをOSS化対象とするか判断
OSSの開発する旨をデジタルサービス局担当窓口に連絡
開発対象のOSSの公開判断| 159 | |2|デジタルサービス局|OSSの開発を予定している組織に対して、OSS管理基盤（GitHub）の情報（アクセス、アカウント）を各局に対して連絡
開発対象の納品物連絡を受け、OSS公開の準備（開発保守業者公開から取得）を行い、OSSを公開
OSSの管理| 160 | |3|開発保守業者|OSSの開発| 161 | |4|一般| ー | 162 | 163 | ### 3 開発保守業者との契約締結時における留意点 164 | 165 | **(1) 仕様書に明記すべき事項** 166 | 　開発保守業者との契約では、納品物の著作権を都に譲渡することを前提とした調達仕様とする必要がある。 167 | また、OSSの性質上、都で使用する際の動作保証と契約不適合責任は、通常では対外的に無保証となるが、下記の要件を盛り込む必要がある。 168 | * 都に対して、動作の保証と契約不適合責任条項に従うこと。 169 | * 契約不適合状態になったことにより、納品物の更新を行う際は、公開対象のソースコードに対しても更新を行うものとする。 170 | * 外部公開用のGitをベースにしたソースコード変更管理ツールを用いることで、都民等に対して、対外的な公開とバージョン管理を行えるよう開発、納品すること。 171 | * コード作成時に利用したライブラリに脆弱性がないか定期的に確認し、脆弱性が発覚等した場合には、脆弱性を解消するよう、保守すること。 172 | * 契約終了後も、都がOSSとして公開を継続することを了承すること。 173 | * 外部公開を行うべきでない性質の記述やファイル（データベース接続用のホスト名やパスワード、アクセスキー等）は、外部公開用のソースコード変更管理ツールの公開リポジトリを用いてはならない。 174 | 175 | **(2) 担当者が注意すべき事項** 176 | 　開発工程上、納品がなされていないソースコードも開発保守業者のリポジトリに置かれる場合があるため、OSS所管局はこれを許容する必要がある。 177 | 178 | ### 4 公開後の保守運用 179 | 　外部からの個別改善リクエストや課題についての受付は、OSS所管局にて行うものとし、また、都度対応とはせず、定期的なソースコードの修正の機会を設け対応し、バージョン管理を行うものとする。 180 | 　修正・改善等を行ったバージョンのOSSの公開は、OSS所管局がデジタルサービス局に対し、修正完了報告を行い、前記 “２　公開手順”の方式で公開するものとする。 181 | 　ただし、重大なソースコードの誤りや欠陥等が発見され、行政サービスに影響が甚大なものに関してはこの限りではなく、直ちに対処するものとする。また、ソースコード作成時に利用したライブラリ等に脆弱性が発見され、情報漏洩等の恐れがある場合も同様の対応とする。 182 | 　なお、都は公的な機関として信頼できるOSSを公開することが求められる。このため、改善報告に対する対応状況を外部へ明確に示す必要がある。 183 | 　また、改善に向けた対応については段階分けを行い、各々に対して初動（GitHub内で対応開始を通知）及び進捗報告までの時間を定めることが重要である。 184 | 　このため、例えば、緊急対応では1日以内の初動及び日毎の進捗報告、機能改善では3営業日以内の初動及び5営業日以内の進捗報告等、都民にわかりやすい表現で示していくものとする。 185 | 186 | 図4　OSSの保守フロー 187 | 188 |
189 | 190 | ![](https://i.imgur.com/HRujf0P.jpg) 191 | 192 |
193 | 194 | 表4　OSS保守における役割分担 195 | 196 | | ＃ |
組織
|
役割
| 197 | | -------- | -------- | -------- | 198 | |1|各局（OSS所管局）|OSSの改善管理
リリース計画の策定と連絡
改修内容確認
OSSのリリース判断
OSSのリリース完了のアナウンス| 199 | |2|デジタルサービス局|リリース計画の受付
改修納品物の取得、OSSの更新| 200 | |3|開発保守業者|改修
OSSのリリース作業| 201 | |4|一般|改善連絡| 202 | 203 | ### 5 開発保守の終了 204 | 　OSSは永続的に公開するものとせず、一定の期間経過後、OSS所管局は、開発保守を継続するかの判断を行うこと。 205 | 　上記「一定の期間経過後」とは、原則として都のサービス終了時点から、その後の１年間を保守期間として定めるものとし、本保守期間においては改善（脆弱性対応、機能改善等）を実施するものとする。　 206 | 　また、サービス終了後の本保守期間については、１年経過後、1年毎に、OSS所管局において延長するか否かの判断を行うものとする。見直しの結果、開発保守終了が妥当と判断した場合は、以下の手順に従って、開発保守及び公開を終了する。 207 | 208 | 図５　OSS開発保守案件の終了 209 | 210 |
211 | 212 | 　 ![](https://i.imgur.com/OpDDvn8.jpg) 213 | 214 |
215 | 216 | 表5　OSS開発終了時における役割分担 217 | 218 | | ＃ |
組織
|
役割
| 219 | | -------- | -------- | -------- | 220 | |1| 各局（OSS所管局）|GitHubアカウントの返却の受付
OSSの非公開判定| 221 | |2|デジタルサービス局|GitHubアカウントの返却の受付
OSSの非公開判定
OSSの非公開設定| 222 | |3|開発保守業者|GitHubアカウント返却| 223 | |4|一般|　－　| 224 | 225 | ※公開が終了したものに関しては別途Archive化することを検討 226 | 227 | ### 6 その他 228 | 　ソフトウェアが暗号化機能や、ニューラルネットワーク駆動の地理空間分析訓練機能等、輸出規制に該当する機能を有する場合は、輸出規制に留意する必要があるため、デジタルサービス局に事前に相談を行うこと。 229 | 　開発保守業者が作成したソフトウェアを元に、都が新たなソフトウェアとして異なる開発保守業者に対して依頼を行う可能性がある場合は、作成の可否を仕様に明記すること。 230 | 231 | ## 第５ 公開時のライセンス 232 | 233 | ### 1 OSSの体系と注意すべき点 234 | 　OSSの公開にあたっては、適切な形式選定を行う必要がある。 235 | OSSのライセンスの種類については大きく分けて「コピーレフト」、「準コピーレフト」、「非コピーレフト」の3つの形式に分類される。 236 | 　また、各分類において、複数のライセンスが存在するが、形式毎にそのライセンスの特性が大きく異なり、また、個々のライセンスにも差異があり、ライセンスを付与する対象によってもそのあり方が変わってくる。 237 | 　さらには、同じライセンス名称であっても、ライセンスのバージョンによって大きく条件が異なることもあるため、名称のみで判断することなく、ライセンスのバージョンについても注意をしなければならない。 238 | 239 | ### 2 OSSの形式 240 | **(1) コピーレフト** 241 | 　プログラムの実行、プログラムのリバースエンジニアリングの許可、プログラムの改変の許可、改造をしたものを含む複製物の配布の際のソースコード再配布の強制、また、組み合わせて新たに作成したプログラムを同一のライセンス下で許可されるようにしなければならない。 242 | 　すべての派生製作物は誰もがソースコードにアクセス権を持ち、自由に加工し、さらに公開をして再々加工を誰もができなければならないという考え方のライセンスである。従って、このライセンスのソフトウェアを利用し配布したプログラムは、全てソースコードを開示する義務が生じ、ソースコードの改変に、派生物含めて同じライセンスを引きつぐものである。このプログラムの関係部分にもコピーレフトが適用されるので、他のライセンスのプログラムと組み合わせる場合は注意が必要となる。 243 | **(2) 準コピーレフト** 244 | 　基本的な考え方はコピーレフト型と同様であるが、準コピーレフト型のソフトウェアを組み合わせて利用した場合は、対応するソースコードの開示を要求しないものとなる。 245 | 　しかしながら、リバースエンジニアリングの許可と、ライセンスにより許諾したライブラリを利用する著作物のバイナリーコード（実行ファイル）の開示が必要となる等、一定の条件が定められていることもあるため、個別にライセンスの内容を、関連して利用すべきソフトウェアのライセンスとの整合性を精査したうえで、選定する必要がある。 246 | **(3) 非コピーレフト** 247 | 　非コピーレフト型ライセンスを適用して公開したソースコードは、利用者が、改変して利用・再配布する際、OSSであるか否にかかわらず、利用・改造・再配布を認めることとなるライセンスである。 248 | 　コピーレフト型と比して、複製物のソースコードの再配布義務がないことから、JavaScript等のフロントエンドで、表示の微調整レベルでソースコードの変更を伴うサイトなどでは、ソースコード公開の義務に伴う負担を軽減するために、この形式をとることも多い。 249 | 　コロナ対策サイトはこの中のMIT Licenseの形態を取った。ただし、コピーレフト型のライセンスと互換性がないこともあるため、ライセンスの整合性に注意する必要がある。 250 | **(4) 型式分類表** 251 | 　代表的なライセンスをこれらの３つの型式に分類すると下記の表となる。 252 | 253 | 表6　3つの型式 254 | 255 | |
型式
|
特徴
|
主なOSSライセンス
| 256 | | -------- | -------- | -------- | 257 | | コピーレフト | ・ライセンステキストの添付が必要
・改変した（コピー＆ペーストも含む）ソースコードの開示
・組み合わせて利用した場合、対応する部分のソースコードの開示|・GNU General Public License（GPL） Version 3
・Affero General Public License （AGPL） Version 3| 258 | | 準コピーレフト | ・ライセンステキストの添付が必要
・改変した（コピー＆ペーストも含む）ソースコードの開示| ・GNU Lesser General Public License (LGPL) Version 3
・Mozilla Public License (MPL) 2.0| 259 | | 非コピーレフト | ・ライセンステキストの添付が必要
・ソースコードを変更したとしても、ソースコードを開示する必要はない|・BSD 2-clause License
・BSD 3-clause License
・BSD 4-clause License
・Apache License 1.1
・Apache License 2.0
・MIT License| 260 | 261 | 262 | --- 263 | 264 | ***【コラム：MITライセンスの課題】*** 265 | 　新型コロナウイルス感染症の感染拡大のなかで、「東京都新型コロナウイルス感染症対策サイト」同様に、Code for Japanが感染患者の健康管理を目的とした「自宅療養者モニタリングシステム」をOSSとして、GitHub上に公開した。 266 | 　このOSSについては、様々な主体に活用され、感染症対策に貢献している。 267 | 　一方で、本OSSが「症状の報告」に特化したシステムとなっており、再利用する先も症状報告が多くミッションクリティカルであることから、本システムの利用ユーザは運用体制のしっかりした企業が多いと思われた。結果、OSSの特徴でもあるシビックテックなどコミュニティへの参加者は限られてしまい、フィードバック量も少なくなる恐れが出た。 268 | 　このため、Code for Japanでは、企業等の利用を想定し、当初、非コピーレフトのMITライセンスで公開していたものを、準コピーレフトであるMPLライセンスへと変更した。準コピーレフトのライセンスを選択することで、企業が営利目的で改変利用する場合でも改変後のコードを公開することが求められるため、派生系ソフトウェアが独占的な状態へ移行することを防ぐことができる。 269 | 　このように、OSSは、営利、非営利に関わらず、再利用を可能とするものであるが、OSSは、社会に開かれたものであり、公共性を有するものでもあり、“東京都OSS”においては、利用状況に応じて、公開時のライセンス規定についても、柔軟に見直していく必要がある。 270 | 271 | 272 | --- 273 | 274 | ### 3 ライセンス 275 | **(1) ライセンスの選定** 276 | 　ライセンス選定の際には、ライセンスを付与する対象となるものについて、指定するライセンスに基づき二次利用を許諾することとなる。 277 | 　このため、OSS化の趣旨や運用の際の実態と適合するものの中から、都として必要な権利を確保できるライセンスを選定するか、ライセンスの選定を開発保守業者に委ねる場合にもその選定方針を明確にし、その内容を調達仕様書で示す必要がある。 278 | 　都としてOSSを公開する際は、特にライセンス選定対象ソフトウェアの展開において戦略的な手法をとる必要がない場合においては、非コピーレフト型のライセンスを選定することを推奨する。 279 | 　なお、都として公開するOSSのそれぞれのライセンスで配布されるソフトウェアは、都の著作権及び特許・実用新案等の知的財産権の利用許諾を、当該ライセンスで定義される条件に基づき配布することとなる点に留意すること。 280 | **(2) マルチライセンス** 281 | 　関連して利用するソフトウェアとのライセンス不整合を解消する方法や、利用方法の多様化などへの対応方法の一つとして、複数のライセンスでの配布をすることがある。これをマルチライセンスという。 282 | 　ライセンスの選定にあたって、特定の１つのライセンスでは、OSS化の趣旨や運用の際の実態と適合できない場合には、複数のライセンスを組み合わせたマルチライセンスも視野に入れながら選定すること。 283 | 　例として、GPLと不整合となるライセンスを選定した際に、GPLを用いる関連ソースコードとの連携が必要な際に、GPLの対象バージョンと互換するライセンスをマルチライセンスとして付与することが挙げられる。 284 | 285 | ### 4 ライセンス選定プロセス 286 | 　ソフトウェアを利用するにあたっては、動作させるために必要な関連ソフトウェアとのライセンスの整合性に関する課題があり、例えばコピーレフトのライセンスを選定したことで、実際の動作に必要なソフトウェアとのライセンスが整合せず使えない状況に陥るケースもある。この状態のまま使用してしまうと、ライセンス違反となる。 287 | 　このことから、利用したい関連ソフトウェアのライセンスとの整合性に留意のうえ、ライセンス選定をする必要がある。 288 | 　ライセンスを選定するにあたり基本的な考え方を下記に図示する。 289 | 290 | 図6　ライセンスの選定フローイメージ 291 | 292 |
293 | 294 | ![](https://i.imgur.com/qqLEMet.png) 295 | 296 |
297 | 298 | 図7　マルチライセンスの選定フローイメージ 299 | 300 |
301 | 302 | 　 ![](https://i.imgur.com/GNZKtiZ.jpg) 303 | 304 |
305 | 306 | 　都としては、上記のフローで単一のライセンスを決定し、ライセンスを付与することを基本とするが、当初想定していた状況との変化があった場合や、利用方法の多様化に対応していく必要がある場合には、マルチライセンスにより対応するか、または、OSSのバージョンを改め別ライセンスで配布をするかを検討のうえ、配布する。 307 | 　ただし、派生元のOSSが存在する場合は、その派生元のライセンスとの整合性に留意し、ライセンス違反を起こさないよう注意すること。 308 | 　なお、本ガイドラインにおけるライセンスとは、OSIがライセンスレビューを行い承認しているものを指す。 309 | 310 | ## 第６ 公開・運用にあたっての注意事項 311 | 312 | 　都がOSSを公開する上では、セキュリティやコンプライアンス、事業内容やサービス内容に対して留意する必要があり、それらの内容も可能な限り都民に開示していく必要がある。このことから、公開にあたっては、所謂“README”ファイルに、以下の事項を参考に必要事項を明記するものとする。 313 | 　なお、記載内容に関しては、公開するソースコードに関係する事業の性格や、公開することによる社会的波及効果等を考慮の上、事前に各局の法務担当と連携のうえ、確定していくようにすること。 314 | 　また、注意事項として、既存のソフトウェアの改変等による公開の場合は、「第5 公開時のライセンス」に記載しているよう、コピーレフトでは同一のライセンスを継承する必要があることから、当該ソフトウェアのライセンスを事前に精査し、そのライセンス条件に適合するよう検討する必要がある。 315 | 316 | 317 | **(READMEファイルへの記載事項例)** 318 | **１ コンプライアンス情報** 319 | (1) ソフトウェアを利用する際にプライバシーに関連する内容（個人情報保護法やGDPR等）が含まれる場合は、利用者に責任があるものとし、都は一切の責任を負わないものとします。 320 | (2) コンプライアンス等の問題によって、公開の継続が困難又は利用不可となる可能性がありますので、あらかじめご了承願います。 321 | **2 損害賠償等** 322 | (1) 本ソフトウェアの利用に関する責任は利用者にあるものとし、使用・不使用から生ずるいかなる損害や、利用者（及び第三者）が被った損害について、一切責任を負わないものとします。また、損害の可能性について事前に知らされていた場合にも同様とします。 323 | (2) 本ソフトウェアの脆弱性に関する瑕疵について、一切責任を負わないものとします。 324 | (3) 一切の紛争は、東京地方裁判所を第一審の所轄裁判所とし、本ソフトウェアの使用については日本国法に準拠するものとします。 325 | **3 ご利用にあたってのお願い** 326 | 　本ソフトウェアのご利用にあたっては、今後の東京都の施策に活かしていくため、可能な限り東京都にお知らせください。 327 | 328 | 　また、公開に伴い、様々なユーザからの貢献が寄せられることが想定されるため、行動規範、開発者貢献記録、貢献者ライセンス同意書等を合わせて記載することが望ましい。 329 | |
用語
|
意味
| 330 | | -------- | -------- | 331 | | 行動規範（Code of Conduction）| オープンソフトを提供する上で、その提供理念等を明確にし、参加者や貢献者に対して期待する振る舞い等を定めたもの| 332 | | 開発者貢献記録（Developer’s Certificate of Origin）| 適切なオープンソースライセンスに基づき貢献することを宣誓し、その貢献と派生的な作業が誰の手によるものかを特定可能としたもの | 333 | | 貢献者ライセンス同意書（Contributor License Agreement）| オープンソフトの開発プロジェクト等において、個人が行った貢献に対して、知的財産権の許諾を得ていることを明確にするもの | 334 | 335 | ## 第７ フォローアップと見直し 336 | 337 | 　本ガイドラインは、OSSとして公開することによる効果（貢献）に視点を置き、β版として策定している。 338 | 　このため、今後、本ガイドラインを運用していくなかで、OSSとして都のソースコードを公開することによる効果（市民、企業、大学、NPOなど多様なプレイヤーとのコラボレーション）を幅広く普及していくとともに、個別のプロジェクトでガイドラインの実効性を検証していく。 339 | 　あわせて、都として、他自治体等が公開するOSSを利活用するという観点での必要なルール等についても、引き続き検討を行っていく。 340 | 　また、本ガイドラインを、GitHubに公開することで、さらに多くのエンジニアの方々にもご覧いただき、改善点の把握に努めていくなどのフォローアップを実施し、継続的に必要な見直しを行っていくものとする。 341 | 342 | --------------------------------------------------------------------------------