20

ファイルを変更するのではなく、新しいファイルを提供するときに GPL 著作権通知を書くにはどうすればよいですか? プロジェクトでは、すべてのファイルは次で始まります。

/**
 * Some open source application
 * Component Foo
 * (C) 20?? by Scruffy H. Hacker (scruffy@foo.bar)
 * Released under the GPL
 *
 * Awesome description here.
 */

次のように、著作権表示に自分の名前だけを表示する必要があります。

/**
 * Some open source application
 * Component Bar
 * (C) 20?? by Tobier Hackerson <tobier@foo.bar)
 * Released under the GPL
 *
 * Awesome description here.
 */

または、プロジェクトの元の作成者を含める必要があります。

/**
 * Some open source application
 * Component Bar
 * (C) 20?? by Scruffy H. Hacker (scruffy@foo.bar)
 * (C) 20?? by Tobier Hackerson (tobier@foo.bar)
 * Released under the GPL
 *
 * Awesome description here.
 */
4

2 に答える 2

22

GPL はファイル単位のコピーレフト ライセンスではなく、パッケージ全体のライセンスです。

したがって、新しいファイルも GPL の下でライセンスされる必要があります。元のライセンス ヘッダーには GPL バージョンが指定されていないため、任意の GPL バージョンを選択できます。GPL に複数のバージョンがある理由と、GPL がライセンス バージョンのアップグレードでどのように機能するかについて詳しく知りたい場合は、以下を参照してください。

したがって、ライセンスのバージョンを明確にした後、著作権表示と名前をどこに配置するかについて尋ねます。私はあなたの弁護士ではなく、ここでソフトウェア開発者として話しています。その質問にあらゆる角度から完全に答えることは容易ではありません。

著作権ごとに、複数の著者による複数の作品をまとめています。組み合わせた作品を制作しています。著作権という意味での各作品には、作者と著作権所有者がいます。

結合された作品については、この著作権も結合されます。

したがって、単一のファイルの場合、それを独自に作成した場合、たとえば 2012 年であるとしましょう。あなたが作成者であるため、独自の著作権ヘッダーを作成できます。

/**
 * My Extension to some open source application
 *
 *  Copyright 2012 by Tobias Eriksson <author@tobier.se>
 */

そのファイルがハードドライブにある場合、それはまったく問題ありません。それを配布したいので、ライセンスを明確にするのが賢明です。GPL-3.0+ を選択したとしましょう。ガイドラインに従う

およびいくつかのコメント/ドキュメントブロックのタグ付けガイドライン:

次の例のように、ナンバー プレートを使用してこれを拡張することができます。

/**
 * My Extension to some open source application
 *
 *  Copyright 2012 by Tobias Eriksson <author@tobier.se>
 *
 * This file is part of some open source application.
 * 
 * Some open source application 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.
 * 
 * Some open source application 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 Foobar.  If not, see <http://www.gnu.org/licenses/>.
 *
 * @license GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+>
 */

このライセンス プレートにより、ファイルを受け取る人は、このファイルがどのライセンスの下にあり、コードに対してどの権利を持っているかを確認できます。また、彼らはあなたの著作権表示で元の作者を見ることができます。ここで私の目に最も重要な部分は、明確にすることです: a) 誰が作者/著作権所有者であるか、b) ライセンスは何か。この情報が失われないように、表示されます。あなた次第の推奨事項に従いたい場合。あなた自身の著者の権利をカットしないために、私は少なくともあなたの名前のクレジットを残すことを強くお勧めします.これは法律で義務付けられていません.そこに名前)。

したがって、このファイルを上流に追加することを提案できます。ソフトウェアのオリジナルの作成者と連絡を取るのはこれが初めてです。彼らは独自のやり方を持っているかもしれませんし、独自のヘッダーを好むかもしれません.

これがプロジェクト内でどのように管理されているかを事前に尋ねることができます。一般に、複数の方法があります。一般的な方法は次の 2 つです。

  • ライセンスと著作権をファイルごとに管理
  • ライセンスと著作権を一元管理します。

ファイルごとのアプローチは、プロジェクトの開始時に便利です。中央アプローチは、プロジェクトが大きくなる場合に便利です。

ファイルごとのアプローチについては上で少し概説しましたが、各ファイルごとにライセンスと著作権/作成者情報の変更を追跡する必要があります。

中心的なアプローチとして受け入れられている手順は、いわゆる AUTHORS (およびおそらく追加で CONTRIBUTORS) ファイルを作成してソフトウェアの作成者をリストし、ライセンスを含む COPYING ファイルを作成することです (ライセンスがパッケージ全体に対して 1 つだけの場合は、それ以外の場合は、メインのライセンスと追加のライセンス)。

また、両方の概念が混在している場合もあります。たとえば、パッケージ全体が GPL の下にありますが、コードベース内には MIT または BSD タイプのライセンスの下にあるコードもあります。次に、これらのパーツのライセンス情報を保持して、これらのパーツの変更をアップストリームに戻すことができるようにする必要があります。また、これらの部分に貢献する作成者は、その部分のライセンスを維持するために、MIT / BSD の下でも変更のライセンスを取得する必要があることを認識しておく必要があります。それについての詳細と、ライセンスを文書化する方法と場所の詳細について知りたい場合は、以下をお読みください。

次に、中央のアプローチにより、各ファイルの上部にある著作権ヘッダーとライセンス プレートを減らすことができます。

/**
 * Some open source application
 *
 *  Copyright 2010, 2012 by it's authors. 
 *  Some rights reserved. See COPYING, AUTHORS.
 */

情報の圧縮を探していて、作成者が各ファイルに自分の名前が表示されなくても構わない場合。スーパースターではそれはできません、本当です。だから、誰の名前が最初に来るかなどのソーシャルランキングがあるかもしれません. ただし、だまされてはいけません。著者は、自分の名前を見る権利があります。誰かがあなたにその権利を否定した場合、あなたはだまされています。ご想像のとおり、これは (フリー) ソフトウェア プロジェクトにおける敬意についても多くを物語っています。

技術的には、最新の変更を行ったのはあなたであるため、著作権行を一番上に追加してもまったく問題ありません。ライセンスは、元の著作権を保持する必要があることを示しているだけで、それを上に置く必要があることを示しているわけではありません。

/**
 * Some open source application
 *
 *  Copyright 2012 by Tobias Eriksson <author@tobier.se>
 *  Copyright 2010, 2011 by Scruffy H. Hacker <scruffy@foo.bar>
 *
 *  Licensed under GNU General Public License 3.0 or later. 
 *  Some rights reserved. See COPYING, AUTHORS.
 *
 * @license GPL-3.0+ <http://spdx.org/licenses/GPL-3.0+>
 */

そのようなライセンス/著作権ヘッダー docblock のより一般的/実際の例かもしれません。また、自分の著者と同じように、他の著者にも常に同じ敬意を持って接することを忘れないでください。これは通常、法的な側面はさておき、共同プロジェクトで最もうまく機能します。物事がもはやインライン化されていないときだけ、法律が必要です。

同様に参照してください:

于 2012-08-05T10:16:57.817 に答える
6

イアナル

元の作成者がこのファイルのいずれかのコードに貢献した場合 (たとえば、彼のファイルの 1 つをコピーして変更した場合)、両方をクレジットする必要があります。すべてのコードを作成した場合、必要なのは名前だけです。

プロジェクト テンプレートに準拠する必要がありますが、通常は次のようなものを含めます。

* Released under the GNU General Public License

「GPL」は本来あるべきほど正確ではありません。バージョンも指定する必要がある場合があります。詳細については、ライセンス (バージョン 2またはバージョン 3 ) 自体を参照してください。現状では、理論的には GPL バージョン 1 の下でリリースされる可能性がありますが、それは誰も考えていなかった可能性があります (ただし、弁護士はそれを仮定することに何の問題も見いだしません)。

GNU GPL バージョン 2 は次のように提案しています (最後に、「これらの条件を新しいプログラムに適用する方法」の下):

one line to give the program's name and an idea of what it does.
Copyright (C) yyyy  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 2
of the License, or (at your option) any later version.

(さらに 2 つの段落)。

于 2012-07-26T13:37:42.527 に答える