私は私のオープンソースプロジェクトに使用できるさまざまなライセンスを探していましたが、私が見たすべてのプロジェクトは、あらゆる種類のライセンスで、巨大で不愉快です（私の意見では）ファイルが特定のライセンスの下にリストされていることを示す各ソースファイルに注意してください。私はそのような通知を持たないパブリックドメインではない単一のソースプロジェクトを見つけたとは思わない。

これは時間とファイルスペースの無駄のようです。私は自分のプロジェクトにタグを付け@licenseたり@authorタグを付けたりする予定ですが、コードをパブリックドメインにしたくない場合、個々のファイルにそのような巨大な通知をリストする必要がある理由がわかりません。

私は私のプロジェクトでは、このような通知を含めるしたい、または単にで予告を含むなぜ任意の理由があるREADMEと@licenseタグは十分に良いことは？これは、ほとんどのライセンスの「明確に述べられた」ルールに影響を与えますか、それとも人々が議論しないように過剰になっていますか？

私の理解では、GPLv3はすべてのソースファイルに著作権表示を強く提案します（少なくとも、「新しいプログラムにこれらの条件を適用する方法」というテキストをどのように理解するかを要求します）。それは言います

そのためには、プログラムに次の通知を添付してください。保証の除外を最も効果的に述べるには、各ソースファイルの先頭にそれらを添付するのが最も安全です。各ファイルには、少なくとも「著作権」の行と、完全な通知が見つかった場所へのポインターが必要です。

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

また、GCCのようにFSFが所有するGNUプロジェクトでは、すべてのファイルにそのような通知があります。

また、すべてのファイルにそのような通知がないため、フリーソフトウェアコミュニティのWebサイトで拒否されたプログラム（J.PitratのCAIAシステム）も知っています。

私は弁護士ではありませんが、そのような通知はGPLv3プログラムのすべてのソースファイルで実質的に必須であると考えています。

^{（他のライセンス、特に非FSFライセンスを使用する場合は、その適用方法について注意深くお読みください; YMMV;ただし、すべてのファイルに通知を書き込んでも問題はありません。）}

私はREADMEまたはLICENSEまたはCOPYINGファイルでのみライセンスに言及している多くのプロジェクトを見てきました。

ソフトウェアは、国際法で合意されているように、著作権で自動的に保護されます。（米国政府または著作権が適用されない他の組織で働いている場合を除きます。）

誰かがあなたのソフトウェアを使用する場合、彼らは必ずライセンス契約に従うか、彼らができることに関する公正使用制限に従う必要があります。

その人があなたのコード配布でファイルの1つを使用したいとし、それはもちろんコピーを必要とし、したがって著作権法が適用されるとします。デフォルトでは、著作権法に基づいてソフトウェアを使用する権利はありません。彼らがそれを使用することを許可されているのは、彼らがライセンス制限を知っていてそれに従うときだけです。

したがって、ソフトウェアライセンスなしでファイルを使用する場合、著作権法に違反しています。すべてのライセンスは「上記の著作権表示とこの許可通知はソフトウェアのすべてのコピーまたは実質的な部分に含まれる」と言っているため、ライセンスをどこかに配置する義務があります。

それはファイル自体にある場合もありますし、ライブラリとしてコードを使用した場合、関連する部分を独自のディレクトリに配置し、そのサブディレクトリに「README」または「LICENSE」を追加しました。

要するに、各ファイルにライセンスを入れる必要はありません。やり過ぎだと思います。そうすることで追加の法的保護はありません。ダウンストリームユーザーの助けにはなりますが、あまり役に立ちません。

多くのコメントベースのメタデータ（ライセンス、各機能の作成日、変更ログなど）の伝統は、非常に古い伝統であり、実行が容易であり、有用というよりはお守りです。

たとえば、デフォルトのEclipseテンプレートは、各機能の前に、役に立たないメタデータと思われるものを追加します。これは、バージョン管理によってはるかによくキャプチャされると思います。しかし、その慣行は多くの店で一般的です。

問題は、完全な著作権を含む残りのファイルなしで、チェックアウト、メール送信、1つのファイルのダウンロードなど、より大きなプロジェクトから単一のソースコードファイルを簡単に分解できることです。そして、そのファイルは、ファイルの起源を知らない可能性のあるN番目のパーティに、無限に渡されます。

上部の著作権表示は、その孤立したファイルに出くわした人に、パブリックドメインではなく、実際に著作権で保護されていることを思い出させます。ファインダーに独自のランダムな仮定をさせることに対して。

地下バンカーには、各ソースファイルに何を入れなければならないかを伝える秘密の超大国会議はありません。

このファイルがどんなライセンスの下にあることをユーザーに明確にします。実際、ほとんどのGPLソフトウェアには、license.txtを読むという短い前文が含まれています。プロジェクトが分割され、ファイルが再利用されることを忘れないでください。そのため、メッセージを1つのファイルに入れるだけでは良い考えとは言えません。

万が一、法廷に出かけた場合、各ファイルをあなたの作品として明確にマークし、どのライセンスの下にあったかをもっと主張するかもしれません-この特定のファイルがカバーされていないと考えた人は誰も主張できませんでした

私はほとんど同様の質問を投稿しました。迷惑については少なく、技術についてはもっと。TL; DR：答えは著者の優先順位の問題だと思います。たぶん、意図は優先順位よりも正確だろう...

「大丈夫」の定義に応じて、ソースでライセンスを参照してもかまいません。「無伴奏」という用語は、愛情のこもったコードベースから無慈悲に分離されたプロジェクトの一部であるソースファイルを示すことに同意しましょう。このファイルには次のような行が含まれています。

# This file is covered by the LICENSING file in the root of this project.

または、このようなはるかにクールな行：

* @license OMGBBQ <http://goodlics.com/bbq>

"ちょっと待って！" 、「そのファイルはプロジェクトから分離されたと言ったばかりです！そしてgoodlics.comはドメイン不法占拠者にリダイレクトします！あなたは正しい、私はそれを言ったが、それは大丈夫かもしれず、私に怒鳴るのをやめる。ここに私の弁護士ではない推論があります：

• ほぼすべての国が、ベルン条約に同意しています。これは、何かを作成する場合、その期間、つまり著作権があることを意味します。あなたはそれが簡単にするために作るん（c）の行または任意のがらくたような、しかし、その原料（プラスGitHubのようなサードパーティ製のVCS）を必要としないことを証明あなたはそれを作成していることをするとき、あなたがそれを作成しました。
• したがって、作成したジューシーな1337コードをオンラインで投稿する場合、著作権があります。誰も（合法的に）コピーすることはできません。まれで衝撃的なことは知っていますが、人々は時々法律を破ると聞いています。それはまだ可能です。
• nyancat-bcminer-algo.qbasicあなたがLiveJournalに書いて投稿した素晴らしいファイルは、信じられないかもしれませんが、パブリックドメインではありません。あなたがそれがパブリックドメインであると言わない限りではありません。デフォルトでは、あなたとあなただけです。それは... 貴重です。（少なくとも25〜50年は、ディズニーでない限り。）
• 人々は通常、ライセンスを介してこの意図を伝えます（あなた自身とあなただけのものではない一部またはすべての権利を作ります）が、その意図を発表する必要があります。オプトインオプトアウトです（HAHA GET IT？著作権のオプトアウトを選択しますか？すばらしい）。チケットを手に入れてください、もうすぐです！
• それは大丈夫であれば、前述の無伴奏ファイルはプライベートドメインであることを-つまり、合法的にコピー可能ではない、そして潜在的に壊れた参照を使用すると、完全に罰金です。ただし、問題がなければ、すべてのソースファイルにライセンステキストを含める必要があると思います。こうすることで、付属していないファイルは、あなたが優先的に意図した方法でライセンスされます。ええ、それはましです。

この推論は、2つの壮大でおそらく無効な仮定を作ります：

• 「壊れた」ライセンス参照は、デフォルト（著作権）の動作にフォールバックしますが、これは有効な仮定ではない場合があります。
• 投稿したサイトには、すべてをパブリックドメインにする何らかの種類の投稿ポリシー（StackExchangeなど）がありません。

猿脳気道に乗ってくれてありがとう。

免責事項：これは私にとっては論理的に思えますが、私は90％が100％間違っていると確信しています。

ライセンスとプリアンブルには違いがあります。

私のプロジェクトのいくつかでは、GNU General Public Licenseバージョン3.0を使用しています。GNU GPLでは、すべてのソースコードファイルにプリアンブルを含める必要があります。

前文と指示はGNU GPLの不可欠な部分であり、省略できません。

ソース：http : //www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

だからここに私がやることがあります：

1. License.txtを追加します

ルールに従うために、LICENSE.txtをプロジェクトのリポジトリのルートに配置しました。これはGitHubによっても提案されています（「ライセンスはどこにありますか」を参照）。

2.自動折りたたみを使用してプリアンブルを追加する

次の私は、すべてのソースコードファイルの先頭にGPLプリアンブルを含んしかし、私はIDEでそれを隠すことがほとんど妨害にします。ほとんどのIDEには、コードブロックを自動的に折りたたむ機能があります。NetBeansはカスタムコードの折りたたみをサポートしており、WebStormはコメントの折りたたみもサポートしています。

そのため、次のようになります。

//<editor-fold desc="Preamble">
/*
 * Company Name
 * Copyright (C) 2016 Company Name
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * ...
 */
//</editor-fold>

console.log('Here is my licensed JavaScript code.');

これは、快適性と法的安全性の間の非常に良い妥協点だと思います。

ライセンスを追加する必要があるプロジェクトが多数ある場合は、http： //www.addalicense.com/が役立つ場合があります。

注：私のアドバイスはGPLv3に言及しています。他のライセンスタイプでは、プリアンブルは不要です。

ここでまだ言及されていない別の実用的な方法があります。

SPDX-License-Identifier鬼ごっこ。https://spdx.org/using-spdx

これを使用すると、すべてのソースファイルヘッダーの「合法的な定型文」が2行に減少します。

/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */

さらに、ソフトウェアサプライチェーン分析を自動化する人々は、機械可読なライセンス記述の一般的な標準に固執していることに感謝します。