この投稿では、著作権と無料ライセンスに関するメタ情報を提供します。 つまり、フリーソフトウェアを作成するすべての人が知っておくべきことです。 このようなライセンスの特定の例については触れませんが、インターネット上の他の場所で見つけることができます。 また、GPLについても少しお話します。 私は弁護士ではなく、どこかで間違えられた可能性があるとすぐに言わなければなりません。 この投稿全体は、ロシアとアメリカを含むほぼすべての先進国に適用されます（ただし、残念ながら、GPLのロシア語への承認された翻訳はないため、ロシアでは有効ではありません）。 私がGPLについて話すときはいつでも、私は第3バージョンのGPLを意味しますが、この情報のほとんどすべてはGPL 2に適用され、おそらく将来のバージョンにも適用されるでしょう。 （もう一度言います：私はこのトピックに精通していません。記事の最後にある2016-11-10のUPDを参照してください。）

著作権

知的著作物はすべて自動的に著作権の対象になります。 あらゆる種類の「著作権」、「すべての権利」、「©」などは必要ありません。 著作権の登録は必要ありませんが、たとえば法廷で著作権を本当に所有していることを後で証明するのに役立ちます。 つまり、たとえば、プログラムを書いたり、インターネットに投稿したり、購読しなかったり、「著作権」を書いたりしなかった場合、あなたはその著作権を所有しています。 しかし、ここであなたが成功するという事実からはほど遠い、その場合、それを証明します。



著作権とはどういう意味ですか？ 誰かが作品を使用するためにお金を請求する権利であると考えるかもしれません。 はい、そうですが、著作権にはそれ以上のものが含まれています。 著作権は、著作権使用料を要求する権利を含む、作品の使用に関する制限および条件（つまり、実際にはライセンス）を確立する権利です。 たとえば、プログラマーは、片足で立っている間だけ自分のプログラムを使用することを要求する場合があります。 そして彼は正しいでしょう。 そして、この条件に従わない人は誰でも法律に違反します。



作成者が製品の使用条件を指定しない場合、つまりライセンスを確立しない場合、すべてが自動的に禁止されます。 つまり、著者の同意なしに使用を禁止します。 ここにある。 たとえば、利用規約を指定せずにインターネットに投稿すると、著作権を申し込んでいない場合でも、作品の使用を禁止していることがわかります。 「インターネットにアップロードしたという事実は、私がだれでもその製品で何かをすることを許可している、または少なくとも何かを許可していると言っているのですか？」いいえ、彼はしていません。



まあ、おそらくいくつかの最小限の使用が許可されています。 たとえば、インターネットに写真を投稿した場合、おそらく、人々はそれを見ることができます。 しかし、人々はそれをお互いに移転する権利を持っていません。



しかし、楽しい些細なこともあります。 一部の国では、いずれの場合でも許可されているものの固定リストがあり、著者が禁止することはできません。 アメリカでは、これはいわゆる「公正使用」、ロシアでは-「作品の無料使用」、 Wikipediaの詳細を参照してください 。



著作権の期間は制限されています。 終了すると、コンテンツはいわゆるパブリックドメインになります。 コンテンツがパブリックドメインにある場合、いわゆる所有権のない著作権は依然として著者に残ります。 基本的に、これは名前に対する権利です。つまり、この作品を自分のものと呼ぶ権利は誰にもありません。



ベルヌ条約の下では、著作権は著者の生涯を通じて、そして彼の死後50年間保持されます。 一部の国ではこの期間が延長され、ロシアでは70年です。 著者が不明な場合、期間は作品の公開時点からカウントされます。



著者自身が資料をパブリックドメインに移すことができます。 しかし、残念ながら、これを行うための標準的な法的方法はないため、特別な法的ツールCC0を使用することをお勧めします。



そのため、著作物は著作権の対象となるもの（使用するライセンスで既に分割できます：GPL、BSDなど）とそうでないもの、つまりパブリックドメインです。



したがって、一般的な使用のためにインターネット上に何かを投稿する場合は、必ずライセンスを示すか、パブリックドメインにあることを示す必要があります。そうでない場合、デフォルトではすべてが禁止されます。

無料ライセンス

次に、無料ライセンス（GPL、BSDなど）について詳しく説明します。



無料、オープン、無料、非営利。 フリーソフトウェアは、フリーライセンス（またはパブリックドメイン）の下で配布されるソフトウェアであり、フリーライセンスはユーザーに次の権利を付与するものです。

• プログラムを使用
• ソースコードを変更する
• プログラムを配布する
• 変更されたバージョンを配布する

より具体的には、無料ライセンスは、 Free Software Definitionを満たすライセンスです。 FSFは、無料と見なすライセンスのリストを保持しています。



どんなに奇妙に聞こえても、人がプログラムを書いてそれをだれにも渡さない場合、これはフリーソフトウェアです。 このソフトウェアには1人のユーザーがいて、上記の4つの権利があります。 ストールマンは、「オペレーターがそれらを開発し、コピーを配布せずに使用する場合、すべてのユーザー（1人のみ）には4つの自由があるため、些細な意味で無料です。 」



オープンソースソフトウェアは、オープンライセンス（またはパブリックドメイン）で配布されるソフトウェアであり、オープンライセンスはオープンソース定義に準拠しています。 OSIは、オープンと見なしているライセンスのリストを保持しています。



実際、オープンソースの定義はフリーソフトウェアの定義と変わらないため、例外はありますが、「フリー」と「オープン」は同義語であると想定できます。 OSIはArtistic License 1.0をオープンライセンスとして認識しましたが 、FSFはそれを無料として認識しませんでした。



フリーでオープンソースのソフトウェアは、フリーソフトウェアとまったく同じではありません。 Red Hat Enterprise Linuxは無料のソフトウェアですが、有料でもあります。 Skypeはフリーソフトウェアですが、無料ではありません。



無料でオープンソースのソフトウェアは、非営利団体と同じではありません。 ほとんどすべての大規模な無料プロジェクト（Linux、gcc、glibc、Gnome、FreeBSD、clang、および他の多く） は 、これらのプロジェクトをさまざまな方法で支援するこれらのプロジェクトの存在に興味がある企業があるという意味で商業的です（これらのプロジェクトへの転送お金、これらのプロジェクトの開発者を雇い、コードを提供します）。 そしてもちろん、ソースコードなしでインターネットに投稿された非営利および非フリーのソフトウェア、たとえば小さなソフトウェアがたくさんあります。



無料ライセンスで資料を公開する場合、以下を示すことをお勧めします。

• 英語の「著作権」という単語と著作権記号©（これはオプションですが、それでも望ましい）
• 作品の出版年（著作権の有効期限の計算に使用）
• 作者の名前（作者がいないと著作権はありません。作者がいないとライセンスです）
• 実際には、ライセンス自体

著作権は一次であり、ライセンスは二次です。 これは、著作権なしにはライセンスが存在できないことを意味します。 著作権の期限が切れると、ライセンスも無効になります。 たとえば、誰かがGPLでプログラムをインターネットに投稿した場合、ある時点で著作権が失効し、プログラムはパブリックドメインになります。つまり、GPLが失効します。



素材を無料ライセンスで公開する場合、著作権を放棄しません（著作権の一部を放棄したと言える場合を除く）。 それどころか、あなたは著作権を保持し、これがあなたのコンテンツにこの無料ライセンスをインストールする権利を与えるものです。 ライセンスは、著者とユーザーの間の契約です。 著者自身の権利を持つ著者のみがライセンスを確立して変更できます。 インターネット上にコンテンツを置くことは、各ユーザーに個人的に転送することから、基本的に他の配信方法と変わりません。 インターネットに素材を投稿する場合、各ユーザーに個別に提供し、ユーザーとの契約、つまりライセンスを締結すると言うことができます。



特に明記しない限り、無料ライセンスは取り消せません。 例で説明します。 著者がプログラムをインターネットに投稿し、一部のユーザーがそれをダウンロードしたとします。 その後、彼はインターネットで示されたライセンスを変更しました（私が言ったように、彼は著者としてこれを行う権利を持っています）。 次に、新しいユーザーが新しいライセンスでこのプログラムをダウンロードします。 ただし、古いユーザーは古いライセンスでこのプログラムを使用する権利を保持します。



プログラムの新しいバージョンはそれぞれ新しい著作権です。 プログラムの異なるバージョンの著作権条件は、互いに独立して期限切れになる場合があります。 Linuxカーネルが1000年存在する場合、新しいパッチはそれぞれ新しい著作権であるため、この期間の後、その時点のカーネルの現在のバージョンは依然として著作権の対象となります。 しかし、それまでの古いバージョンのカーネルの著作権期間は簡単に切れる可能性があります。



コピーレフトは著作権の特別なケースであり、その逆はありません。 コピーレフトライセンス、たとえばGPLは、作者が著作権を保持しているという事実（著作権）により機能します。 したがって、GPLまたはその他のライセンスの条件に基づいてコンテンツを公開する場合は、「Copyleft」ではなく「Copyright」を記述する必要があります。



Free Software Foundation（FSF）は、他の組織と同様に通常の組織です。 法的に何も区別されていません。 私はインターネットのどこかで「GPLの下でプログラムを公開するには、2つの方法があります。著作権を保持するか、FSFに転送するか」です。 まあ、はい、他の組織のように。 しかし、FSFに警告することなく、FSFに権利を譲渡することは愚かです。 公式のGNUパッケージに貢献した場合（そしてそれでもすべてのGNUパッケージに当てはまるわけではありません）、唯一のケースでFSFの権利を譲渡する必要があります。 この場合、特別な文書に署名してFSFに送信する必要があります。



さらに、GPLの下でコンテンツを公開すると、著作権は自動的にFSFに、またはストールマンにさえ個人的に譲渡されることをインターネットで読みました。 これはそうではないことを明確にする必要はないと思います。 はい、GPLテキスト（たとえばGPL 3）には「Copyright©2007 Free Software Foundation」と書かれていますが、この著作権はあなたの著作物ではなくライセンス自体のテキストに言及しています。



ライセンステキストのすべての禁止事項は絶対的なものではありません。 何かが禁止されている場合、それは単に著者の同意がある場合にのみ許可されることを意味します。 著者は、彼の要求に応じて、誰にでも適切と思われるものなら何でも許可し、一般的には、異なるライセンスの下でコンテンツを異なる人々に配布できます。 著者自身は、一般的に自分の素材を好きなように使用でき、自分のライセンスに縛られることはありません。 たとえば、商用利用を禁止するライセンス（ CC BY-NCなど ）は、1つの場合にのみ使用することをお勧めします：自分で作品を商業的に使用する場合、または個人（または組織）が金銭のために使用することを許可する場合。 CC BY-NCに基づいて公開し、同時にこの資料で自分自身で収益を得ていない場合、あなたは意地の悪い行為をします（自分自身にも人にも）。



または例を見てみましょう。たとえば、 Qtの所有者であるDigiaなどの会社は、いわゆるGPL例外で利益を上げています。 これは、彼らがGPLの条件の下でコードを公開することを意味しますが、同時に、より制限の少ない別のライセンスの条件の下でお金のためにあなたにコードを与えることができます。



次の非常に成功した比較がQt Webサイトに書き込まれましたが、今は見つけることができません。 著者は自分の作品のコピーを無限に持っていると言えます。 彼は誰かにコンテンツを提供するたびに、その瞬間に彼がどのような条件でそれを与えるかを選択します（デフォルトでは、ユーザーは著作権が終了するまでこれらの条件でこのコンテンツを破棄する権利を取得し、著者はそれをキャンセルすることはできませんそして、著作権の終了後、ユーザーは通常このコンテンツで何でもできます）。 しかし、この後、著者は作品のコピーを無限に持っており、自分が望む条件で好きな人に渡すことができます。



まあ、著作権の移転自体は、この無限の腕一杯の移転です。 つまり、誰にどのように使用するかを決定する権利の移転です。 同時に、元の作者には著作権がありません（非財産を除く）。



ダブルライセンスは、（特に明記しない限り）「または」ユニオンで接続された2つのライセンスです（トリプルライセンスなども同様です）。 つまり、ユーザーはこれらのライセンスのいずれでマテリアルを使用するかを選択できます。 無限のコピーとの類推に戻りましょう。作者はユーザーに作品のコピーを一度に2つ与え、それぞれが独自のライセンスの下にあります。 ユーザーはこれらのインスタンスのいずれかを選択できます。 両方のライセンスでさらに配布が許可されている場合、ユーザーはさらに二重ライセンスで製品を配布できます（つまり、両方のコピーを配布します）。



このようなデュアルライセンスでは（後述の「and」ユニオンを使用したデュアルライセンスとは対照的に）、どのライセンスも他のライセンスと互換性があります。 つまり、「ライセンスA または Bの下での二重ライセンス」は不可能です。たとえば、ライセンスAはこれを禁止しているためです。 なぜなら、二重ライセンスでは、著者は実際には1つのライセンスの下で資料を配布するだけであり、これに加えて、別のライセンスの下でもそれを配布するからです。 そして、もちろん、最初のライセンスで2番目のライセンスを禁止することはできません。



また、ユニオン「and」とのデュアルライセンスがあります。 つまり、作成者が作業をユーザーに渡すとき、両方のライセンスを同時に遵守する必要があります。 そして、ここでライセンスの互換性の概念がすでに生じています。 たとえば、BSDライセンスは、他のライセンスとの共有を禁止していません。 したがって、BSDライセンスおよびその他のライセンスの下での配布が可能です（ただし、これが2番目のライセンスで禁止されていない場合）。 しかし、GPLは、GPLに対する重大な追加の制限を課すことを禁止しています。 許可される制限のリストは、セクション「7。 追加条件»GPLライセンス3.実際、このリストはGPLをBSDライクな無料ライセンスとのみ互換性があるものにします。 したがって、GPLおよびBSDライセンスは可能です（BSDはGPLを超える重要な制限を課しません）が、GPL 2およびGPL 3ライセンスは（GPL 2 または GPL 3とは異なり）GPL 3が課すため不可能ですGPL 2を超える重大な制限、およびその逆。



言い換えれば、「GPL互換」ライセンス、つまり「and」結合によってGPLに接続できるライセンスという概念があります。 このようなライセンスには、CC0、BSDライクライセンス、および同じバージョンのGPL自体が含まれます。



したがって、プログラムが「バージョン3以上のGPL条件」の下で配布されることを書くときは、「and」ではなく「or」を書くようにしてください。



著者の同意なしに他人の作品のライセンスを変更することは可能ですか？ もちろん違います。 ただし、元のライセンスで許可されている場合は、追加の制限を課し（「and」ユニオンによって元のライセンスと関連付けられます）、さらに（変更の有無にかかわらず）作業を配布する権利があります。 すべての無料ライセンスでは、変更と追加配布が可能です（無料です）。 そして同時に、私が言ったように、それらのいくつか（BSD）は追加の制限をぶら下げることを許可し、一部（GPL）-一部のみです。 これは、BSDライセンスの下で作品がある場合、「BSDおよびGPL」ライセンスの下でそれをさらに配布できることを意味します（実質的にはGPLと同等です。つまり、ライセンスを効果的に変更したことがわかります）。 つまり、GPL互換ライセンスをGPL自体にいつでも「変更」することができます（ただし、元のライセンス[たとえば、BSDの場合]はどこにも行きません）。 しかし、もちろん、ライセンスをGPLからBSDに「変更」することはできません。



異なるライセンスの下で異なるプロジェクトのコードを混合します。 一部のライセンス（BSD）は、他のライセンスとの共有に制限を課していません。 つまり、プロジェクトの1つのファイル（または1つのコード）がBSDライセンスを持っている場合、これは別のコードのライセンスを制限しません（これらのライセンスがBSDで使用できる場合）。 ただし、GPLでは、GPLコードに静的または動的にリンクするすべてのコードにもGPLライセンスが必要です。 この他のコードに元々GPL以外のライセンスがあった場合、可能であれば（つまり、元のライセンスがGPL互換であれば）、このライセンスは和集合「and」でGPLに接続されます。 これが不可能な場合、そのようなプロジェクトは配布できません。



たとえば、私たちのプロジェクトは、BSDライセンスとGPLライセンスの2つのファイルで構成されており、これらのファイルはリンクされています。 その後、プロジェクト全体がGPLライセンスを取得します。 BSDの下にあったファイルは、「BSD and GPL」、つまり基本的にGPLになります（ただし、通知自体がこれを禁止しているため、BSDライセンス通知を削除することはできません）。



別の例：プロジェクトは、ライセンスGPL 2（「GPL 2のみ」、つまり「新しいバージョン」）およびGPL 3（同じ）の2つのファイルで構成され、リンクされています。 次に、GPL 2は2番目のファイルに「感染」し、GPL 2ライセンスを取得し、「GPL 2 and GPL 3」になります。 同じことが逆方向にも起こります。 しかし、「GPL 2およびGPL 3」というライセンスが不可能であることは誰もが知っています。 これは、ライセンスの非互換性のため、そのようなプロジェクトの配布が禁止されていることを意味します。



無料プロジェクトの一般的な慣行。 無料のプロジェクトには、配布される固定ライセンスがあります。 また、プロジェクトには2つのタイプがあります。コード全体に対する権利が任意の1つの組織に譲渡されるプロジェクトと、すべての参加者が権利を留保するプロジェクトです。 最初のケースは条件付きでさらに2つに分けることができます。

• これはGNUパッケージであり、コードに対するすべての権利はFSFに移転されます（すべてのGNUパッケージがFSF権利の移転を受け入れるわけではないことを思い出してください）。 パッケージが常に無料であることを保証するため、つまり、参加者がパッケージのGPL以外のライセンスを選択したり、GPLに例外を与えたりするのを防ぐために、権利が譲渡されます
• これは営利企業のプロジェクトであり、ライセンスの例外を販売するため、またはライセンスを変更する権利を留保するために、著作権を収集します。

私はすぐに商業プロジェクトがそれ自体で悪いものを運ばないことに注意したいです。 上で書いたように、多くの無料プロジェクトは商用です。 そして、すべての商業プロジェクトから遠く離れて、1つの組織のコードへの権利の移転を受け入れています。 しかし、そのような譲渡が受け入れられるプロジェクトでは、フリーソフトウェアコミュニティでの態度は否定的です（FSFでない場合）。 たとえば、sysvinit vs upstart vs systemd紛争では、upstartに対する重要な議論の1つは、Canonicalがこのプロジェクトで譲渡されたことであり、これはフリーソフトウェアコミュニティでは受け入れられません。



（2016年5月19日、UPD：FSFの権利を譲渡することは、他の組織に権利を譲渡することと大きな違いはありません。GNUプロジェクトのメイン作成者であるとしても、FSFに権利を譲渡する前によく考えてください。 GnuTLS開発者はプロジェクトをGNUから撤回し、著作権をFSFに譲渡したことを後悔しました： www.opennet.ru/opennews/art.shtml?num=35681 ）



誰かが権利の譲渡が受け入れられないプロジェクトに貢献する場合、彼は著作権を留保し、プロジェクトで採用されたライセンスの条件の下でコードを譲渡します。 そして、これはデフォルトで暗示されています。つまり、参加者がコメントなしでコードを送信した場合でも、それは真実です。



たとえば、Linuxカーネルに貢献したほとんどの人（1つの組織の権利の譲渡はこのプロジェクトでは受け入れられませんでした）は、最初に名前で著作権を入力しなかったとしても（デフォルトで想定されているため）権利を残しました任意のファイル。 そして、彼らは全員、GPL 2ライセンスの条件の下でコードをプロジェクトに転送しましたが、このライセンスを変更するには、すべての参加者の同意が必要になります。 いずれかの会社がGPLから例外を購入したい場合、これらすべての人々に賄briを贈る必要があり、同時に、それらすべてを見つけることでさえ別の問題になります。 したがって、「カーネルの購入」はほとんど不可能です。 これについては、「 カーネルの購入」の記事を参照してください。



特定の組織の権利の譲渡が受け入れられるプロジェクトに誰かが貢献した場合、通常、彼は特別な文書に署名してこの組織に送信します。 その後、そのコードはプロジェクトライセンスの条件の下でこのプロジェクトのフレームワーク内で使用可能になりますが、組織は将来このライセンスを変更できます。



また、参加者が権利を保持しているが、送信されたコードに対する権利を本当に所有していることを確認する文書に署名して送信するプロジェクトも可能です。 これらのドキュメントを送信することにより、たとえば、どこかでこのコードを盗んでいないことを確認します。



無料のコードを書いていると同時に会社で働いている人について。 従業員が雇用主の指示にコードを書いた場合、ほとんどの場合、受け取ったコードの著作権は雇用主に帰属します。 誰が仕事で書かれたコードの権利を所有しますが、割り当てではなく、または仕事からの自由時間に、雇用契約に依存します。 特に、私の雇用契約書には、雇用主が職場を使用して書かれたコードの権利を所有していることが書かれていました（契約条件を開示する権利はないが、私にはイチジク:)） まあ、その場合（たとえば、法廷で）、従業員が職場で、または勤務時間中にコードを書いたかどうかを調べることは非常に難しいので、この従業員によって書かれたすべてのコードは、この会社に属する主題について疑っています。



したがって、1つの組織の権利の譲渡が認められているプロジェクトでは、この譲渡を確認する文書には、コードの作成者だけでなく、雇用者（存在する場合）の署名も必要です。 そして、この著者が大学で勉強または働いている場合、この大学の代表者の署名。

GPL

簡単に言うと、GPLの本質は次のように表現できます。このライセンスは何でも許可しますが、同時に：

• さらに配布する場合、ライセンスを保持する必要があります。
• ソースコードはバイナリとともに配布する必要があります（または、オンデマンドで提供するためにプロミスを配布する必要があります。これについてはこれ以上言及しません）
• （静的または動的に）GPLコードにリンクされているものもすべてGPLに該当します

実際、GPLによって課せられている唯一の制限は、バイナリを配布するとき、ソースも配布する必要があるということです。 他の制限はありません、と言うかもしれません。 インターネットまたは他の場所でソースまたはバイナリを公開する必要はありません。 必要に応じてソースコードとバイナリを提供する必要はありません（既にバイナリを受け取った人にソースコードを提供する必要がない限り）。 プログラムを無料で配布する必要はありません。 これについては、後で詳しく説明します。



それでは、GPLは誰のためのものですか？ Aliceがプログラムを作成し、GPLの条件に基づいてBobに転送したとします。 その後、このライセンスに従ってボブは、さらに配布する権利を受け取ります。 彼がプログラムをキャロルに移すことに決めたとしよう。 それから彼はGPLの条件の下でのみそれを転送する義務があります。 また、バイナリを転送する場合、コードの転送とソース化も義務付けられています。 これらの義務は、2番目のギア（ボブからキャロルへ）でのみ発生し、最初のギア（アリスからボブへ）では発生しないことに注意してください。 なんで？ はい、アリスが著者だからです。 そして、著者として、彼女は何でもすることができて、誰にも負いません。 著者はいつでも彼自身のライセンスに違反することができます、私はすでにこれについて上で書きました。 特に、著者は、GPLの条件の下で特定のプログラムを配布していると同時に、ソーステキストを配布していないことを宣言でき、法律に違反しません。 しかし、これらのバイナリをさらに配布する人はそうなります。



たとえば、ある日、facepalmとしか呼べないケースがありました。GNUEmacsのGPL違反が発見されました。 長い間、ソースコードのないコンピューター生成ファイルがEmacsで配布されていました。 詳細はこちらをご覧ください： GNU EmacsがGPLライセンスの違反を発見しました 。 ここで私はこれに注意したい：EmacsとFSFの作者は、Emacsに対する権利を所有しているが、GPLに違反していない。 著作権者は何でもできるからです。 しかし、Emacsをさらに配布した人々（たとえば、GNU / Linuxディストリビューション）はこれに違反しました。 これは、ストールマンの手紙で 「これらのバージョンを再配布する人はGPLに違反している」と確認されました 。ストールマンはその後、完全なソースコードなしでEmacsのこれらのバージョンの配布を許可する特別な文書を発行しました。



したがって、GPLによって課せられた制限、そして実際、ライセンスの実際の効果は、2回目のコード転送からのみ生じます。つまり、ライセンスは、少なくとも3人の俳優（著者（アリス）、送信者（ボブ）、および受信者（キャロル））が現れたときにのみ開始されます。



, , , «you» . . , , GPL . , , «you» , . , (, ) (, ). . , , . . , . , . (, ), GPL — («» « », , « »).



そしてもちろん、実際には、物事はこの例よりも複雑になる可能性があります。プロジェクトには多くの作者がいる可能性があり、流通チェーンは長くなる可能性があります。



GPLでは、インターネットまたは他の場所でソースコードまたはバイナリを公開する必要はありません。 GPLテキストには「インターネット」という言葉はありません。 GPLでは、ソースまたはバイナリオンデマンドの提供は必要ありません。つまり、GPLの条件に基づいてコードを受け取り、場合によっては何らかの変更を加えた人は、変更したコードを必要だと思う人に渡すことができます。唯一の要件は、既にバイナリを提供した人にソースコードを提供する義務があることです。



ロシアのある秘密のサービスが内部使用のために独自のGNU / Linuxディストリビューションを作成し、それを公開していないと聞きました。もしそうなら、これはGPLの違反ではありません。彼らはこの配布を誰にでも与える義務がないからです。しかし、この配布キットが何らかの形でサービスの外に漏れた場合、それを受け取った人は配布キットのソースコードを要求し、GPL条件の下でソースコードをさらに配布する権利を持ちます（私はGPLライセンスを持っている配布パッケージの部分について話している）



プログラム（バイナリまたはソース形式）を無料で配布する必要はありません。 — ( ), , , .



. . , « ?» , .



PS GPL . . GPL .



UPD 2014-12-22. ? , . , , , GPL ( , — GPL) . . , , contributor () contribution () . ( ), , , . , , GPL ( GPL) . , , :

• contributor'
• , « ?» , «» BSD GPL (, BSD ), GPL BSD —

UPD 2016-11-10. , .この記事の公開後、私はすぐに2人の弁護士（実際の弁護士、私とは違います！）からそのような事実（ロシアの法律に関する）を学びました。どちらがまだ私の頭に収まらないか、そして、それは私には上記の世界の私のイメージと矛盾しています。ある会社が独自のコード（非フリー）を別の会社にライセンスしたとします。ライセンス契約で、彼女は受信者の会社がコードを変更する権利を持っていると書いた（そしてこの変更されたコードのさらなる運命の制限に関する追加の説明はない）。次に、受信者の会社はコードを変更でき、この新しいコードの著作権は自動的に完全に受信者の会社に帰属し、このコードで何でもできます。また、このライセンス契約に拘束されることはありません。



私は2人目の弁護士に尋ねました：「Linuxカーネルはどうですか？何千人もの人々がそれに変更を加えます。そして、次の人が変更を加えたとき、彼は修正されたコピーの著作権の唯一の所有者になりません。このコピーは、これまでに変更を加えたすべての人の著作権の対象です。」彼は言った：「はい、そうです。これは、Linuxが特別なオープンライセンスの下で配布されているため、実際にはこれらのルールが設定されているためです。



, ? . , . . . . .



UPD 2017-08-26. The GPL Is a License, not a Contract .