私のオープンソースプロジェクトに使用できるさまざまなライセンスを探していましたが、私が見たすべてのプロジェクトは、すべての種類のライセンスで、巨大で不愉快なように見えます(私の意見では)ファイルが特定のライセンスに基づいてリストされていることを示す各ソースファイルに注意してください。私は、パブリックドメインではない単一のソースプロジェクトを見つけたとは思いませんしないそのような通知があります。
これは、時間とファイルスペースの無駄遣いのようです。プロジェクトに@license
タグと@author
タグを配置する予定ですが、コードを公開したくないのに、なぜこのような巨大な通知を各ファイルにリストする必要があるのかわかりません。ドメイン。
このような通知をプロジェクトに含めたい、または単にREADME
と@license
タグに通知を含めれば十分な理由はありますか?これは、ほとんどのライセンスの「明確に述べられた」規則に影響を与えますか、それとも、人々が主張しないように過剰すぎますか?
READMEまたはLICENSEまたはCOPYINGファイルでライセンスのみを言及している多くのプロジェクトを見てきました。
国際法で合意されているように、ソフトウェアは自動的に著作権の対象となります。 (米国政府または著作権が適用されないその他の組織で働いている場合を除きます。)
誰かがあなたのソフトウェアを使用する場合、彼らはライセンス契約に従うか、何ができるかについてのフェアユース制限に従うことを確認する必要があります。
コード配布でファイルの1つを使用したいとします。もちろん、これにはコピーが必要なので、著作権法が適用されます。デフォルトでは、著作権法に基づいてソフトウェアを使用する権利はありません。彼らがそれを使用することを許可されているのは、彼らがライセンスの制限を知っていてそれに従ったときだけです。
したがって、ソフトウェアライセンスのないファイルを使用すると、著作権法に違反することになります。すべてのライセンスは「上記の著作権表示とこの許可通知はソフトウェアのすべてのコピーまたは実質的な部分に含まれるものとします」のようなものを言うので、それらはどこかにそのライセンスを置く義務があります。
それはファイル自体にあるか、ライブラリとしてコードを使用した場合、関連する部分を独自のディレクトリに配置し、そのサブディレクトリに「README」または「LICENSE」を追加しました。
つまり、各ファイルにライセンスを配置する必要はありません。やり過ぎだと思います。そうすることで追加の法的保護はありません。それは下流のユーザーを幾分助けますが、それほどではありません。
多くのコメントベースのメタデータ(ライセンス、各関数の作成日、変更ログなど)の伝統は、非常に古い伝統であり、実行が簡単であり、お守りよりも有用であると考えています。
たとえば、デフォルトのEclipseテンプレートは、私が役に立たないと考えるメタデータを各関数の前に追加します。これは、バージョン管理でキャプチャした方がはるかに良いと思います。しかし、その習慣は多くの店で一般的です。
私の理解では、 GPLv は、テキストを理解する方法を強く示唆します(またはおそらく必要とさえするかもしれません)。これらの条件を新しいプログラムに適用する方法 、そのセクション17)の後、すべてのソースファイル内の著作権表示。それは言う
これを行うには、プログラムに次の通知を添付します。保証の除外を最も効果的に示すために、各ソースファイルの先頭に添付するのが最も安全です。また、各ファイルには少なくとも「著作権」行と完全な通知が見つかる場所へのポインタが必要です。
<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/>.
また、GNU GCCのようにFSFが所有するプロジェクトは、すべてのファイルにそのような通知があります。
また、すべてのファイルにそのような通知がなかったため、フリーソフトウェアコミュニティのWebサイトで拒否されたプログラム(J.PitratのCAIAシステム)も知っています。
私は弁護士ではありませんが、そのような通知はGPLv3プログラムのすべてのソースファイルで事実上必須であると信じています。
(他のライセンス、特にFSF以外のライセンスを使用する場合は、その適用方法について注意深く読んでください。YMMV。ただし、AFAIKがすべてのファイルに通知を書き込んでも害はありません。)
問題は、大規模なプロジェクトから単一のソースコードファイルを簡単に分解できることです。たとえば、誰かがチェックアウトし、電子メールで送信し、1つのファイルをダウンロードするだけで、残りのファイルには完全な著作権が含まれていません。そして、そのファイルは、ファイルの出所がわからないN番目のパーティに、時間内に渡されます。
上部の著作権表示は、その単一のファイルを実行するすべての人に、実際には著作権で保護されており、パブリックドメインではないことを思い出させます。 Finderに独自のランダムな仮定を行わせることと比較して。
ここではまだ言及されていない別の実用的な方法があります。
SPDX-License-Identifier
鬼ごっこ。 https://spdx.org/idsこれを使用すると、すべてのソースファイルヘッダーの「法的な定型文」が2行だけに減ります。
/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */
ソフトウェアサプライチェーン分析を自動化する人は、機械読み取り可能なライセンスの説明という共通の基準を守ることに感謝します。
各ソースファイルに何を入れなければならないかを明かす地下のバンカーには、秘密の超大国会議はありません。
これは、このファイルがどのようなライセンスの下にあることをユーザーに明確にします。実際、ほとんどのGPLソフトウェアには、license.txtを読むように言う短いプリアンブルが含まれています。プロジェクトは分割され、ファイルは再利用されるので、メッセージを1つのファイルに入れるだけでは良い考えではないかもしれないことを覚えておいてください。
万が一の場合に法廷に出廷した場合、各ファイルを自分の作品として明確にマークし、どのライセンスの下にあったかについて、より多くの請求をする可能性があります。
licenseとpreambleの間には違いがあります。
一部のプロジェクトではGNU General Public License、Version 3.を使用しています。 GNU GPLでは、すべてのソースコードファイルにプリアンブルを付ける必要があります。
プリアンブルと命令はGNU GPLの不可欠な部分であり、省略できません。
ソース: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble
だからここに私がやっていることがあります:
1。 License.txtを追加
ルールに従うために、プロジェクトのリポジトリのルートに LICENSE.txt を置きます。これはGitHubでも提案されています(「 ライセンスはどこにありますか」 を参照)。
2。自動折りたたみを使用してプリアンブルを追加
次に、すべてのソースコードファイルの上にGPLプリアンブルを追加します[〜#〜] but [〜#〜]邪魔にならないように、IDEで非表示にします。ほとんどのIDEには、コードブロックを自動的に折りたたむ機能があります。 NetBeansは Custom Code Folding をサポートし、WebStormは foldingコメント もサポートします。
したがって、次のようになります。
//<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に言及しています。他のライセンスタイプでは、プリアンブルが不要な場合があります。
私はほとんど同じような質問を投稿しました。煩わしさについての詳細ではなく、専門性についての詳細。 TL; DR:答えは著者の優先順位の問題であると私は信じています。意図は優先順位よりも正確かもしれません...
「大丈夫」の定義によっては、ソースでライセンスを参照しても問題ないと思います。 「同梱されていない」という用語が、愛情のあるコードベースから容赦なく分離されたプロジェクトの一部であるソースファイルを示すことに同意します。このファイルには、次のような行が含まれています。
# This file is covered by the LICENSING file in the root of this project.
または、次のようなはるかにクールな行:
* @license OMGBBQ <http://goodlics.com/bbq>
"But wait!"、あなたは「そのファイルはプロジェクトから分離されたと言いました!そしてgoodlics.comはドメイン不法占拠者にリダイレクトします!trixyになるのをやめてください!」あなたは正しい、私はそれを言ったが、それは可能性がある大丈夫だ、そして私に怒鳴るのをやめる。ここに私の弁護士ではない推論があります:
nyancat-bcminer-algo.qbasic
あなたが書いてLiveJournalに投稿したファイルは、信じられないかもしれませんが、notパブリックドメインです。 sayでない限り、パブリックドメインです。 デフォルトそれはあなたのものであり、あなたのものだけです。それは...Preciousです。 (あなたがディズニーでない限り、少なくとも25-50年以上の間。)この推論は、2つの壮大でおそらく無効な仮定を行います。
モンキーブレインエアウェイに乗っていただきありがとうございます。
免責事項:これは私には論理的に思えますが、私は100%間違いであることが90%確信しています。