ソースコードにMPLのライセンス通知が記載されていない

[Guest126]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

Mozilla Public License Version 2.0 で定めるライセンス通知 Exhibit A がソースコードファイルに記載されていない。

本プロジェクトにはMPLの対象外となるサードパーティーコンポーネントも含まれるようだが、どのファイルがMPLでライセンスされているのかが区別不能。

解決策についてお書きください / Describe the solution you'd like

Exhibit A - Source Code Form License Notice

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

をすべてのソースコードのヘッダ部分に加える。

例:
https://github.com/mozilla-mobile/firefox-ios/blob/main/Providers/SyncStatusResolver.swift
https://github.com/mozilla-mobile/fenix/blob/master/buildSrc/src/main/java/AndroidComponents.kt

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

ライセンス通知を特定のファイルに入れることが不可能または望ましくない場合に限り LICENSE ファイル等に通知を含めても構わないとされており、Markdown(.MD)ファイルやXMLファイル等にまで通知を記載する必要はないと考えられる。

その他 / Additional context

[keiji]

ありがとうございます。Androidのソースコードとかでもファイルごとに上部にApache 2 Licenseとかライセンスが記載されていますね。

ぼくもXamarin.Formsの内部処理クラスをそのままコピーするPRを出したことがあるので、そういったときに混乱を生まないように、手当てしておくのが良いですね。

ちなみになんですが、今のCOCOAでMPLの対象外になるサードパーティコンポーネント、ソースコードの状態で取り込んでいる箇所はどこかありますでしょうか。ライブラリとして利用しているのはたくさんあるんですが、コードやスニペットが使われているところは把握して居らず、もし知っていたら教えてもらえると助かります。

[Guest126]

ちなみになんですが、今のCOCOAでMPLの対象外になるサードパーティコンポーネント、ソースコードの状態で取り込んでいる箇所はどこかありますでしょうか。ライブラリとして利用しているのはたくさんあるんですが、コードやスニペットが使われているところは把握して居らず、もし知っていたら教えてもらえると助かります。

私の方で把握しているものはありません。

[keiji]

#78 から転記

ご指摘のライセンス通知の添付については、"Exhibit A" には続きがありまして、

If it is not possible or desirable to put the notice in a particular file, then You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice.

これはリポジトリ管理者が、そちらのほうが望ましいと判断すれば各ソースコードに記載せず、LICENSEに記載するだけも認められていると言う意味であるとぼくは理解しています。

[Guest126]

ご指摘のライセンス通知の添付については、"Exhibit A" には続きがありまして、

If it is not possible or desirable to put the notice in a particular file, then You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice.

これはリポジトリ管理者が、そちらのほうが望ましいと判断すれば各ソースコードに記載せず、LICENSEに記載するだけも認められていると言う意味であるとぼくは理解しています。

これについては

ライセンス通知を特定のファイルに入れることが不可能または望ましくない場合に限り LICENSE ファイル等に通知を含めても構わないとされており、Markdown(.MD)ファイルやXMLファイル等にまで通知を記載する必要はないと考えられる。

とはじめに記載している通りです。MozillaによるFAQのQ22もご覧ください。

なお、「リポジトリ管理者が、そちらのほうが望ましいと判断すれば」に対応する原文は存在しませんので、そのような好意的な解釈を採用することはできません。

また、そのような好意的な解釈を採用した場合でも、COCOAのLICENSEファイルにはMPL 2.0が全文ママ記載されているのみで、Exhibit Aのライセンス通知は記載されていません（MPL 2.0の全文にはExhibit Aの例文も含まれていますが、ライセンス通知として記載されたものではありません）。

[keiji]

ありがとうございます。

ということはfork元のプロジェクトがソースコードに記載するのが望ましくないと判断したのかもしれませんね。
その当たりの経緯を確認してみます。

[Guest126]

Markdown(.MD)ファイルやXMLファイル等にまで通知を記載する必要はないと考えられる。

補足です。ここで言うMarkdown(.MD)ファイルやXMLファイルというのは、CONTRIBUTING.md や COPYRIGHT_THIRD_PARTY_SOFTWARE_NOTICES.md、 Covid19Radar.csproj といったものを想定しています。

[keiji]

Markdownには仕様上、コメントがありませんからね。
この場合、XMLで対象になるのは他言語対応の言語リソースのあたりですね。

[keiji]

実際にPRを作って試行した結果、Xamlや一部のXMLファイルには、コメント形式であってもライセンスを付けるとアプリのビルドに失敗することがわかりました。

https://github.com/cocoa-mhlw/cocoa/runs/2213349019

「ライセンスを付けるファイル」と「付けられないファイル」「仕様上は付けられるはずだが実際には制約があって付けられないファイル」を判別しながら開発することはことは建設的ではないと考えます。

おそらく、fork元のCovid19Radarがすべてのファイルにライセンス通知を付けることが不可能または望ましくないと判断したのは、これが理由かと推測します。

Covid19Radarの廣瀬さんにはPRの中で確認中です。
Covid19Radarから、すべてのファイルにライセンスを表記する要望があればもちろん対応しますが、要望がないようであれば「すべてのファイルにライセンス通知を付けることが不可能または望ましくない」として、PRと本Issueはcloseの方向で進めます。

[Guest126]

実際にPRを作って試行した結果、Xamlや一部のXMLファイルには、コメント形式であってもライセンスを付けるとアプリのビルドに失敗することがわかりました。

一般的にxaml/xlf/xmlの一行目はXML宣言でなければなりません(例)が、一行目にライセンスヘッダーを挿入してないでしょうか。

「ライセンスを付けるファイル」と「付けられないファイル」「仕様上は付けられるはずだが実際には制約があって付けられないファイル」を判別しながら開発することはことは建設的ではないと考えます。

新規ファイルを追加する際に一度記載してしまえば後は気にする必要もないですし、きちんとしたOSSプロジェクトはそうしています。まあ、私が開発するわけではないので、COCOAの開発チームにはその判別が重荷だと言われればそれまでですが、それは開発チームの総意なんですか？ それともkeijiさんが close したいだけなんですか？ #19 や #78 もそうですが、コミュニティを無視して一方的に close に持ち込んだり、勘違いのまま突っ走る傾向が目に余ります。

Covid19Radarの廣瀬さんにはPRの中で確認中です。
Covid19Radarから、すべてのファイルにライセンスを表記する要望があればもちろん対応しますが、要望がないようであれば「すべてのファイルにライセンス通知を付けることが不可能または望ましくない」として、PRと本Issueはcloseの方向で進めます。

Covid19Radarの廣瀬さんに確認したところで、最終的には厚生労働省の責任で判断するしかないので、聞かれた方も困るんじゃないでしょうか。Original Authors の名前を入れるか入れないか、という話なら意思を最大限に尊重するのも分かりますが、これはライセンスの話なので。最悪、責任を押し付けてるように見えると思いますが。

[keiji]

一般的にxaml/xlf/xmlの一行目はXML宣言でなければなりません(例)が、一行目にライセンスヘッダーを挿入してないでしょうか。

ご指摘ありがとうございます。コメントをXML宣言後に差し替えたらビルド確かに通りました。

新規ファイルを追加する際に一度記載してしまえば後は気にする必要もないですし、きちんとしたOSSプロジェクトはそうしています。まあ、私が開発するわけではないので、COCOAの開発チームにはその判別が重荷だと言われればそれまでですが、それは開発チームの総意なんですか？ それともkeijiさんが close したいだけなんですか？ 19 や 78 もそうですが、コミュニティを無視して一方的に close に持ち込んだり、勘違いのまま突っ走る傾向が目に余ります。

率直なお気持ちを伝えてくださって、ありがとうございます。
ぼくもCollaboratorになってそろそろ2週間が過ぎようとしていますので、襟を正して、より信頼してもらえる活動ができるように改善したいと考えています。

例えばなのですが、今回の場合、どのように進めるのが良かったとお考えでしょうか。

ぼくがなにもしないで「なんかできなさそうだから、問題が起きそうだからcloseした」と言うのであれば、Guest126さんの批判はもっともなことだと思います。

しかしながら、ぼくは実際に手を動かして、各ファイルにライセンス通知を記載したPull Requestを作成していることをまずはご理解ください。
各ファイルにライセンス通知を追加する作業そのものは、そのファイルが数千、数万あろうと、プログラマーにとって大きな負荷がかかるものではありませんが、時間をまったく使わないというわけではありません。

そして、実際に作業をしてみて問題点らしきものを発見したので（実際には的外れだったわけですが）、これが解決できずCovid19Radarチームからの要望がなければcloseしたい意向を示したのです。もし決定であればすぐにcloseしています。

現在時点での認識を元に方向性を示すことは、そんなにいけないことでしょうか。
どのようにしたら、Guest126さんのご期待に添えるような活動ができますか？

Guest126さん、他の皆様も、ご意見をお聞かせ願えればと思います。

Covid19Radarの廣瀬さんに確認したところで、最終的には厚生労働省の責任で判断するしかないので、聞かれた方も困るんじゃないでしょうか。Original Authors の名前を入れるか入れないか、という話なら意思を最大限に尊重するのも分かりますが、これはライセンスの話なので。最悪、責任を押し付けてるように見えると思いますが。

こちらについてはぼくの意図とは完全に異なりますので、この場で明確に否定します。

まず前提としてCOCOAはCovid19Radarからforkしたプロジェクトです。
次に、MPLはCovid19Radarチームが選択したライセンスで、COCOAはCovid19Radarの採用したライセンスに則って開発しています。

Guest126さんが仰っている「各ファイルにライセンス通知を記載しなければMPLとみなされない」は、Covid19Radarからforkした段階で現在のような状態であったとぼくは認識しています（もし認識違いがあればご指摘をお願いします）。

Covid19RadarとCOCOAでは、悲しいかなコミュニティは断絶しており、当時のことを聞いてすぐに答えが返ってくる状態ではありません。ぼくたちにはCovid19Radar時代のことは、コミットログという轍が見えているに過ぎず、その道を選んだ意図まではわかりません。なぜライセンス通知を各ファイルに記載していないのか。確認をすることは自然なことだと思います。

確認をして、理由がなければPull Requestはマージする。記載できない（記載するのが適当でない）理由があったのなら破棄をする。
その場合、ぼくが使った時間は無駄になりますが、どちらのケースでも対応できるように最善の道を選んでいると自負しています。

[keiji]

（実質ただ一人）Issue をコントロールする権限が有ることもあり、幾つかの内容では代表意見を主張しているようには感じます。
また、精力的に活動されていることは素晴らしいですが、他のコミュニティーメンバーがそのスピードに付いて行けていない様にも感じて居ます。

ありがとうございます。より改善するために具体的にどうしたらいいかを考えていきたいと思います。

GitHubでの対応スピードの遅さについてはTwitterなどで批判されていることの一つだと認識していたので気をつけていたのですが、それが裏目に出ているのかもしれませんね。もっと対応スピードを落とした方がいいと言う意見が多いならそれ有りだと思います。

代表意見は…については、基本的にGitHubの内容はすべて自動的に共有されるようになっていて、開発チームや関係者全員が目を通せる状況になっています。ぼくが特定の意見とフィルタリングして伝えないとか、そういったことはできない仕組みになっているのでご安心ください（そもそもこのリポジトリ自体が public なので、誰でも見られるわけですが）

この時点でCOCOAはMPLで作られた物の派生物でしか無く、MPL と自身で決めた方向性以外に縛られる理由は無いと考えます。
COCOA プロジェクトとしてMPLライセンスに従えない理由があるならそれを明記すれば良く、fork 元のプロジェクトの事情は関係無いと考えます。

これについてはぼくの見解は異なります。

本Issueと #78 (comment) の課題は「ライセンス通知を添付したコードをMPLの適用対象とみなす」とされていて、COCOAにはそれ（ライセンス通知）がないのでMPLの適用対象とみなされないという趣旨であると認識しています。

MPL 2.0では「保護対象ソフトウェア」の定義を「初期開発者が別紙Aの通知を添付した「ソースコード形式」、当該「ソースコード形式」の「実行可能形式」、及び当該「ソースコード形式」の「修正」を指し、いずれの場合もその一部を含みます。」と定めています。

https://github.com/opensource-jp/licenses/blob/main/MPL-2.0/MPL-2.0.md

つまり、MPL 2.0の保護対象ソフトウェアとするためにソースコード形式にライセンス通知を添付しなければいけないのは、初期開発者であるCovid19Radarであるとぼくは理解しています。

しかし引き継ぎ時点ではライセンス通知の添付は実施されておらず、最新（archived）のCovid19Radarのリポジトリを見ても同様です。

ここでぼくが言いたいのは、初期開発者がライセンス通知を添付しなかったソースコードにはMPL 2.0が適用されないというものではありません。ライセンスについてはLICENSEにも記載があります。少なくとも、ソースコードに関してMPL 2.0が適用されることについて合理的な疑いはないと考えています。

その上でライセンスはOSSにとって非常に重要な要素であるので、きちんと確認しておこうとしたのです。

@b-wind さんの仰るとおりCOCOAはCovid19Radarの派生物に過ぎません。しかし派生物であるからこそ、初期開発者のCovid19Radar がMPLを適用している範囲 の意図を確認する必要があると考えます。

実際に廣瀬さんからも「単に時間の余裕がなかった」という返答を頂いています。ビルドも通って技術的な問題もないことがわかり、ぼくとしては安心してPull Requestを進めていけるなと言う気持ちです。

一般論としてOSSライセンスを付けた場合、派生物をどのように扱うかは「ライセンスを読んでくれ」の一言で済むはずで、
私が自分のプロダクトにOSSライセンスを付けるならそれを期待し、派生物に対してわざわざ方針を聞かれるのは迷惑でしか無いです。

ライセンスについて確認すべきと判断した理由については前に述べたとおりです。また、オリジナルの作成者が居て、GitHubで連絡が取れるなら、疑問に思ったことがあれば教えを請うのはそれほどおかしな事ではないと思います。

[keiji]

開発チームが見ていると言う情報はもう少し早く明らかにして欲しかったです。一部追加で情報を伝えたいケースも有ったりするので。

ありがとうございます。開発チームが見ていないなら情報を出さないでおこうと言う判断に至ったのであれば、すべてぼくの不徳の致すところです。

もっとみなさんに協力していこうと思ってもらえるように、改善をしていきたいと思います。

まずMPLを採用した（MPLプロダクトをベースとして採用した）時点でその負荷は追うべき物だと認識しています。
その上で、他のContributorの意見を聞いて、自動化するなり他の手を探すという道もあったと思います。

まず、ぼくはライセンスに関する課題は非常に重要であると考えています。

#78 (comment) を受けて、まずは各ファイルにライセンス通知を添付するPull Requestを作成しました。そして次に、各ファイルにライセンス通知を添付していない初期開発者の意図を確認するのが適切と考えた理由は前に述べたとおりです。

PRを作る上で技術的な課題（実際には間違いだったのですが）が見つかったので方針を示した（提案した）に過ぎず、実際に反対意見もあり、また技術的な課題もぼくのミスであったことが判明したので、事実としてIssueは継続しています。

実際にcloseしたり、反対意見を無視してcloseしたなら批判されるのも無理からぬ事かと思いますが、今回の対応で「どうしたらいいですか？」と聞いても、対応できる（してもらえる）コントリビューターがいるかはわかりませんし、繰り返しになりますがライセンスのことなので、速やかに一定の方針を定めることが必要と考えました。

ご指摘のライセンス通知の添付の自動化についてはとても良いと思うので、是非、提案いただければと思います。

現状の流れを見ますと、 @keiji さんが心配した部分が問題無いので @keiji の判断でOKと見なしているように見えますが、厚労省の承諾は得なくて良いのでしょうか？

みなさんがPull Requestを出せるのと同様に、ぼくがPull Requestを作成するのに厚生労働省やIT室の承諾は必要ないという認識です。

Covid19Radar から引き継ぎ時のライセンス確認が十分でなかったと言う結果も含めて確認の必要があるように思えます。

こちらも繰り返しになりますが、ライセンスについてはLICENSEにも記載があり、少なくともソースコードに関してMPL 2.0が適用されることについて合理的な疑いはないとぼくは考えていますが、いかがでしょうか。

UPDATE
「Issueの提出を受けて」と記載しましたが、「コメントを受けて」に訂正しました。

[Meiryo7743]

まずは，当該の PR #83 の統合を最優先するべきでしょう。今は MPL のライセンスが適用されたプロジェクトであるものの実際には則っていない，という中々の状態ですから。

本 issue は MPL ライセンスの通知が記載されていないことを指摘するものであり，その対処を施した PR #83 で完結します。直近で話題に上っている内容のお話については，爾後に（ここで書き込まれた内容を含めた）別 issue を建ててみてはいかがでしょうか。タイトルと内容の乖離・情報の錯綜が進むと，ここを見る人達に混乱を招いてしまいます……。

---

ところで，CONTRIBUTING.md によると，このリポジトリは「内閣官房情報通信技術（IT）総合戦略室」が運用・管理なさっているようですね。したがって，このリポジトリのライセンスに対する見解というのは，「内閣官房情報通信技術（IT）総合戦略室」が示すものと思われます。

[keiji]

直近で話題に上っている内容のお話については，爾後に（ここで書き込まれた内容を含めた）別 issue を建ててみてはいかがでしょうか。
ありがとうございます。仰るとおりです。

別Issueについては、ちょっとぼくにはタイトルが思い浮かばないので @b-wind さん。よろしければお願いできますか（今度は「スピードについて行けない」とならないように気をつけますので。

ソースコードに限らず、MPL が適用される物・されないものの分類、ライセンス表記を加えるべきファイルの種類について、指摘がある毎に変更するよりは一度纏めて整理した方が良いと思うのですが、如何でしょうか。

現在の #83 で対応した.xml .xlf .cs .xaml に合わせて.sh .featureくらいかなと思っていますが、他に何かあればご指摘ください。

[ghost]

「スピードについていけない」という話じゃないと思うのでミスリーディングなのではと思いますが。。

それはそうとして、#83 では少なくとも src/ と infrastructure/ も対応がいるのではと思います

[keiji]

ほんとうですね。従来の拡張子に追加して .bat .tf を入れます。

[ghost]

@keiji
拡張子の問題もあるかもしれないですが、src/ 以下には別の .csproj があるので
そちらも見ないといけないという意図でした (蛇足)

[keiji]

@zipperpull
はい。src以下にある.csなど従来拡張子も対象にします。

@b-wind
手戻りについては、たとえばGitHubに関して言えば @zipperpull さんのPRがコンフリクトしますね。
開発チームとの調整についてはもちろんです。COCOAのバイナリが配布されているからにはやりましょうと進言するのがぼくの役割でもあります。

[keiji]

Pull Request更新しました！

[Guest126]

第三者を交えて前向きな意見交換が進んでいるところ蒸し返すようで恐縮ですが、遅まきながらコメント返します。

例えばなのですが、今回の場合、どのように進めるのが良かったとお考えでしょうか。
どのようにしたら、Guest126さんのご期待に添えるような活動ができますか？

例え XMLファイルにコメントを入れるのが不可能だったとしても、(1) その他のソースファイルに可能な限りコメントを入れ、(2) LICENSE または Readme に Exhibit A のライセンス通知を入れる、という次善の策を検討すべきだったと考えます。

それをせずにオール・オア・ナッシングで結論を急いだのは、手間と時間が掛かるのでやりたくないというのが本音で、「やらない理由探し」をしていたように見えます。XMLの一行目にコメントを入れるというあまりに初歩的なミスでビルドができないと結論付けてしまったのも、わざとやったとまでは言いませんが、そういう本音が雑な仕事ぶりとして表れたのかなと思ってしまいます。

その他はおおむね @b-wind さんが代弁しているので、多くを言うのは差し控えます。Issue を立てた私が言うのも何ですが、@keiji さんにはこんな雑事より EN API やバックグラウンド動作の調査に時間を割けるようになることを期待しています。

[Guest126]

ひとつ確認しておきたいのですが、この先もCOCOAの引き継いだコードについて不明な点があれば都度 Covid-19Radar の廣瀬さんを頼ることになるのでしょうか。極端な話、人命が懸かってるアプリなので聞かれたら断るわけにもいきませんが、廣瀬さんが韜晦した経緯を考えると、傷口に塩を塗るも同然の行為じゃないですか。実社会でも、不具合や仕様の不明な箇所が見つかったからといって退職した人にそれを聞くのは非常識ですよね。何かそういう契約が続いているとか、あるいは個人的に懇意にしている関係者がいるとか、向こうが納得済みならいいのですが。

これは廣瀬さんに何を確認したかったのか、本当にそれを聞く必要があったのかにもよると思うのですが、@keiji さんの発言を順に追ってみると

ということはfork元のプロジェクトがソースコードに記載するのが望ましくないと判断したのかもしれませんね。
その当たりの経緯を確認してみます。

と最初は「経緯を確認する」という話だったのですが、PR #83で

これについては判断した理由を聞きたいわけではありません。Original Authorsの意思を最大限に尊重すべく、COCOAではどうすることを望むか。ご意見をお聞かせ願えますと幸いです。

Covid19Radarから、すべてのファイルにライセンスを表記する要望があればもちろん対応しますが、要望がないようであれば「すべてのファイルにライセンス通知を付けることが不可能または望ましくない」として、PRと本Issueはcloseの方向で進めます。

と理由は問わず、要望をヒアリングする話に変わっており、かと思えば、

なぜライセンス通知を各ファイルに記載していないのか。確認をすることは自然なことだと思います。
確認をして、理由がなければPull Requestはマージする。記載できない（記載するのが適当でない）理由があったのなら破棄をする。

と理由を確認したのだと言い、

@b-wind さんの仰るとおりCOCOAはCovid19Radarの派生物に過ぎません。しかし派生物であるからこそ、初期開発者のCovid19Radar がMPLを適用している範囲 の意図を確認する必要があると考えます。

とまるで一貫性がなく、突っ込まれる度に説明が二転三転していることに、私は不信感を抱いています。申し訳ないですが、これ以降、真意を説明されても素直に信じる気にはなれません。

[ghost]

@Guest126 さん
お気持ち理解しますし経緯はともかく、以降信じる気になれないみたいなことは
わざわざおっしゃられないほうがよいかと思います。

ライセンスの話なので微妙なのですが、

• fork 元のファイルは必要がない限り commit ログに残したくない
• original の意図があるならできる限り反映する
• 重要な問題については fork 元で反映されたものをマージする形で取り込む

というような原則論は一応理解できるとは思っています。

@Guest126 さんもおっしゃられているように過去の経緯はなかったことにするという
配慮のしかたもあるとは思いますが、契約上発言不可とかではない前提であれば、
fork 元の意向やもとの設計意図などを聞ける範囲で聞きたいというのは自然な話ではあると思います。

現実にはそれを聞かないと何も直せない、みたいなことではないと思いますし、
仮に回答がなかったとしても先に進めるだけの話かとは思いますが。

むしろ問題なのは、#80 (comment) では close するという判断の早さのわりに
理由が軽かったということなんではないかと思っています。
不要な issue は close したいのもわかりますが、不要であるかどうかの判断理由なり判断プロセスなりが
不明確なままで、さらには、現状は正直なところライセンスとかドキュメントとか本質的ではないもので、
かつ内輪のひとのPRしかマージされずに進んでいて、他人が口出ししてきたものはとりあえず
排除して close したいのだという邪推を受けてもしかたないのではというふうにも見えますね？

そういう意図ではないとは一応思いますが、外部からみて、見ようと思えばそう見えるのでは
とは思っています。

追記: close するというのは意向であって決定ではない、というスタンスのようなのを見落としていましたが、
まぁ結果として close してはいなくて継続だとしても、close する権限があるひとが "close する方向で"
と書いてしまったらその段階での判断ではある、ということでご理解ください。たとえば
"本件は対応不要でもよいのではと考えています" とか "意見をお待ちしています" くらいの書き方で
保留するような話だったら、そこまでの不信感とかには至らなかったのではと想像します。

[Guest126]

@Guest126 さん
お気持ち理解しますし経緯はともかく、以降信じる気になれないみたいなことは
わざわざおっしゃられないほうがよいかと思います。

言い過ぎました、ごめんなさい。GitHubコミュニティフォーラムの行動規範の遵守を心掛けます。

[Takym]

もう既に閉じられている様ですが、最近知ったので書きます。

.editorconfig ファイルに下記の様に書くと、新規ファイルにライセンス通知を自動的に挿入してくれます。

file_header_template = "<ライセンス通知>"

https://docs.microsoft.com/ja-jp/visualstudio/ide/reference/add-file-header?view=vs-2019