コピーレフト

大文字の C が垂直軸を中心に反転し、円を形成する 1 本の線で囲まれています。
コピーレフトシンボル
知的財産
関連トピック
上位カテゴリ：
財産および財産法
コピーレフト
コピーレフトライセンスに関する記事
トピック

上位カテゴリ: ソフトウェア、自由

コピーレフトとは、著作物の複製に対して一定の自由を認める法的手法であり、派生作品においても同様の権利が保持されることが求められます。この意味での自由とは、著作物をあらゆる目的で利用すること、また、有償・無償を問わず、著作物を改変、複製、共有、再配布できることを指します。コピーレフトを実装したライセンスは、コンピュータソフトウェアから文書、芸術作品、科学的発見に至るまで、幅広い著作物の著作権条件を維持するために使用することができ、同様のアプローチは特定の特許にも適用されています。[1]

コピーレフト型ソフトウェアライセンスは、保護的または相互的なライセンス（寛容型フリーソフトウェアライセンスとは対照的）であると考えられています。 [2]著作権保護型ライセンスでは、ソフトウェアプログラムの受領者が、著作物の複製および改変に必要な情報を入手できるようにする必要があります。[要出典]この情報は、通常、ソースコードファイルの形で提供され、ライセンス条項のコピーとコードの作成者への謝辞が含まれています。コピーレフトは、誰もが製品を自由に使用できる権利を保証するのに役立ちますが、著作権の所有、登録、および著作権使用料の受け取りを禁止しています。

著名なコピーレフトライセンスには、リチャード・ストールマンによって最初に書かれたGNU一般公衆利用許諾書（GPL）があり、これは広く利用された最初のソフトウェアコピーレフトライセンスでした。[3] [非一次ソースが必要] Mozillaパブリックライセンス、フリーアートライセンス、[4] [非一次ソースが必要]、クリエイティブコモンズの継承ライセンス条件[5] [非一次ソースが必要]があります。最後の2つは、文書や画像など、学術的または芸術的な性質の非ソフトウェア作品を対象としています。Wikipediaはクリエイティブコモンズの表示-継承ライセンスの下でコピーレフトです。 [6]

歴史

Li-Chen WangによるIntel 8080用Palo Alto Tiny BASICは、 1976年5月にDr. Dobb's Journalに掲載されました。リストはタイトル、著者名、日付で始まり、「@COPYLEFT ALL WRONGS RESERVED」と記載されています。[7]

コピーレフトの概念は、 1985 年のリチャード ストールマンのGNU 宣言で説明されており、次のように書かれています。

GNUはパブリックドメインではありません。GNUの改変および再配布は誰でも許可されますが、いかなる配布者もその再配布を制限することはできません。つまり、プロプライエタリな改変は許可されません。私は、GNUのすべてのバージョンがフリーであり続けることを確実にしたいと考えています。

ストールマンの動機は、数年前にLispインタプリタの開発に携わっていたことだった。シンボリックスはそのLispインタプリタの使用を依頼し、ストールマンは自身の成果物のパブリックドメイン版を提供することに同意した。シンボリックスはLispインタプリタを拡張・改良したが、ストールマンがシンボリックスが自身のインタプリタに加えた改良点へのアクセスを求めたところ、シンボリックスは拒否した。その後、1984年、ストールマンはプロプライエタリソフトウェアという、この台頭しつつあった行動と文化を根絶するための活動を開始した。彼はこれを「ソフトウェア・ホーディング」と名付けた。ストールマンがプロプライエタリソフトウェアに取り組んだのはこれが初めてではなかったが、この経験が「転換点」となった。彼はソフトウェア共有を正当化し、共有すればオンライン上のソフトウェアは元の作品を失うことなく複製できると主張した。ソフトウェアは損傷したり摩耗したりすることなく、何度も使用できるのだ。[8] [9]

ストールマンは、短期的には現行の著作権法とそれが永続させると彼が考える不正を廃止するのは非現実的だと考えたため、既存の法律の枠組みの中で取り組むことを決意し、1985年[10]に、独自の著作権ライセンスであるEmacs一般公衆利用許諾書[11]を作成しました。これは最初のコピーレフトライセンスでした。これは後にGNU一般公衆利用許諾書へと発展し、今では最も人気のあるフリーソフトウェアライセンスの1つとなっています。著作権者が、その後誰が元のプログラムにどのような修正を加えたかに関係なく、最大限の権利が永続的にプログラムのユーザーに譲渡されることを保証するための措置を講じたのは初めてでした。この最初のGPLは公衆全体に権利を与えたわけではなく、既にプログラムを受け取った人だけに権利を与えていましたが、それは既存の法律の下でできる最善のことでした。

新しいライセンスには、この時点ではコピーレフトのラベルは付与されていませんでした。[12]リチャード・ストールマンは、「コピーレフト」という言葉の使用は、ドン・ホプキンスが1984年か1985年に彼に送った手紙に由来すると述べています。その手紙には「コピーレフト -すべての権利は逆転する」と書かれており、これは一般的な著作権放棄の「すべての権利を留保する」という表現をもじったものです。[12]

フランスでは、2000年に「コピーレフトへの姿勢」と題して行われた一連の会議からフリーアートライセンス（FAL）[13]が誕生しました。これはベルヌ条約に拘束されるあらゆる管轄区域で理論的に有効であり、ストールマン自身のフリーソフトウェア財団によって推奨されています。[14]その後まもなく、米国で別の無関係な取り組みからクリエイティブコモンズライセンスが誕生し、2001年からパーミッシブ（BY）とコピーレフト（BY-SA）の両方のバリエーションで利用可能になり、より米国法に合わせて調整されています。

コピーレフトの原則

自由

著作権法はソフトウェア作者に著作物の複製、頒布、改変に関する権限を与えていますが、コピーレフトの目的は、著作物のすべての利用者にこれらの活動を行う自由を与えることです。これらの自由（フリーソフトウェアの定義より）には以下が含まれます。[8] [15]

自由0
作品を使用する自由
自由1
作品を研究する自由
フリーダム2
作品をコピーし、他の人と共有する自由
フリーダム3
作品を変更する自由、および変更された二次的著作物を配布する自由

オープンソース定義にも同様の用語が存在します。これは同様の自由を含む別の定義です。コピーレフトライセンスの大部分は、フリーソフトウェア定義とオープンソース定義の両方の定義を満たしています。[8]コピーレフトライセンスは、作品の閲覧者と利用者に複製、改変、または配布の自由と許可を保証する点で、そのような自由を制限する他の種類の著作権ライセンスとは異なります。

相互関係

コピーレフトは、著作物が著作権を主張しないパブリックドメインに完全に収まるのを許容するのではなく、著作者が作品の利用に制限を課すことを許可します。コピーレフトによって課される主な制限の一つは、派生作品も互換性のあるコピーレフトライセンスの下でリリースされなければならないことです。[8]

これは、コピーレフトの根底にある原則によるものです。つまり、誰もが他者の過去の著作物から自由に利益を得ることができる一方で、その著作物への改変は他のすべての人にも利益をもたらすべきであり、したがって同様の条件でリリースされなければならないということです。このため、コピーレフトライセンスは相互ライセンスとも呼ばれます。コピーレフトライセンスの著作物を改変する者は、著作者がソフトウェアをコピーレフトライセンスでライセンスした行為に対し、自らが作成した派生作品にもコピーレフトライセンスを適用することで報いることが期待されます。この要件により、コピーレフトライセンスは、その自己永続的な条件から「バイラル」とも呼ばれています。[16]

コピーレフトライセンスは、コピーの制限に加えて、他の潜在的な障害にも対処します。著作権が後から取り消されないことを保証し、著作物とその派生作品は、さらなる改変が可能な形式で提供されることを義務付けます。ソフトウェアにおいては、派生作品のソースコードをソフトウェア本体と共に提供することを義務付けることを意味します。 [8]

経済的インセンティブ

コピーレフトコンテンツに取り組む経済的インセンティブは様々です。従来の著作権法は、クリエイターに経済的利益を提供することで進歩を促進するように設計されています。作品をコピーレフト化することを選択するコンテンツクリエイターは、同業者からの認知といった相乗効果を求める場合があります。

コンピュータプログラミングの世界では、コピーレフトライセンスのコンピュータプログラムは、プログラマーが自らのニーズを満たすために作成することがよくあります。このようなプログラムは、後続のユーザーがそのプログラムの改変版を自由に使用できるようにするために、コピーレフトライセンスで公開されることがよくあります。これは特に、「オープンソースハイジャック」、つまりオープンソースコードを再利用して追加の制限を加える行為を防ぎたいクリエイターにとって当てはまります。コピーレフトライセンスは、この行為をソフトウェアに防ぎます。Elastic [17] などの一部のクリエイターは、営利企業が自社の製品を独自ライセンスで使用し、販売することを防ぐこともインセンティブになると考えています。

さらに、オープンソースプログラミング文化は贈与経済として説明されており、社会的な力は個人の貢献によって決まります。[18]オープンソースでコピーレフトライセンスの高品質なソフトウェアに貢献したり作成したりすることは、貢献者に貴重な経験をもたらし、将来のキャリアの機会につながる可能性があります。[19]

コピーレフト・ソフトウェアは、個々のクリエイターにとどまらず、経済効果をもたらします。質の高いコピーレフト・ソフトウェアの存在は、プロプライエタリ・ソフトウェア開発者に、フリーソフトウェアとの競争のためにソフトウェアの品質向上を迫る可能性があります。[20]これは、プロプライエタリ・ソフトウェアが支配的な分野における独占を阻止する効果も持つ可能性があります。しかし、プロプライエタリ・ソフトウェアとの競争は、コピーレフトを放棄する理由にもなり得ます。フリーソフトウェア財団は、「コードの広範な利用がフリーソフトウェアの理念の推進に不可欠である」場合、[21]コードを自由にコピーして利用できるようにすることが、コピーレフトよりも重要であると推奨しています。

コピーレフト申請

コピーレフトを利用する一般的な方法は、作品の複製条件をライセンスで成文化することです。このようなライセンスには通常、コピーレフトの条項と原則がすべて含まれています。これには、作品の利用、研究、複製、他者との共有、改変、そして作品の完全版または改変版を有償または無償で頒布する自由が含まれます。[22] [23]

これらの自由を付与する類似の許容ライセンスとは異なり、コピーレフトライセンスは、コピーレフトライセンスの対象となる作品の改変版にもこれらの自由を付与することを保証します。したがって、コピーレフトライセンスには条件があります。コピーレフトライセンスの下でライセンスされた作品の改変版は、互換性のあるコピーレフトスキームの下で配布されなければならず、配布された改変版には作品の改変手段が含まれていなければなりません。しかし、フェアユースの下では、コピーレフトライセンスは通常の著作権と同様に置き換えられる可能性があります。したがって、コピーレフトライセンスの下でライセンスされたソースを自らの創作作品に利用する者は、フェアユース基準を満たす限り、他​​のライセンス（またはライセンスを全く選択しないこと）を自由に選択できます。[24]

コピーレフトライセンスは、その条項を強制執行するために、関連する規則や法律を必然的に創造的に活用します。例えば、著作権法を適用する場合、コピーレフトの対象となっている作品に貢献する者は通常、著作権者の地位を取得、延期、または譲渡する必要があります。[要出典]貢献物の著作権をコピーレフトライセンスに委ねることで、彼らは通常著作権から生じる権利の一部を意図的に放棄することになります。これには、作品のコピーの唯一の配布者となる権利も含まれます。

コピーレフトライセンスに用いられる法律は国によって異なり、また国ごとに異なる条件で付与されることもあります。例えば、一部の国では標準的なGNU一般公衆利用許諾書のスタイルでソフトウェア製品を保証なしで販売することが認められていますが、ほとんどのヨーロッパ諸国では​​ソフトウェア配布者が販売した製品に関するすべての保証を放棄することは認められていません。 [要出典]このため、そのような保証の範囲はほとんどのヨーロッパのコピーレフトライセンス、例えば欧州連合公衆利用許諾書(EUPL) [25]やCeCILLライセンス[26] ( GNU GPLを限定的保証と組み合わせて使用​​できるライセンス)で指定されています。

ネットワーク上で実行されるプロジェクトの場合、GNU GPL のバリエーションであるAffero General Public License (GNU AGPL) により、ネットワーク上のソフトウェア ユーザーがソース コードを確実に利用できるようになります。

種類と他のライセンスとの関係

無料非フリー
パブリックドメイン および同等のもの許容ライセンスコピーレフト（保護ライセンス）非商用ライセンス独自のライセンス企業秘密
説明すべての権利を付与する再ライセンス権を含む使用権を付与します（独占化、ライセンスの互換性を許可）使用権を付与し、所有権の取得を禁止する非営利目的のみに権利を付与します。継承ライセンスと組み合わせることもできます。著作権の伝統的な使用。特定の権利が付与される場合と付与されない場合がある。情報は公開されていない
ソフトウェアの場合PD、無許可、CC0BSD、MIT、ApacheGPL、AGPLJRL、AFPLプロプライエタリソフトウェア、パブリックライセンスなしプライベートな社内ソフトウェア
その他の創作作品PD、CC0CC BYCC BY-SA , FALCC BY-NC著作権、パブリックライセンスなし、CC BY-ND
クリエイティブ・コモンズのアイコンは、コピーレフトシンボルの変形であり、Share-Alike を表します。

コピーレフトは一部のフリーソフトウェアライセンスの特徴的な特徴ですが、一方で、ライセンシーに派生作品を同じライセンスの下で配布することを義務付けていないため、コピーレフトではないフリーソフトウェアライセンスもあります。どちらのライセンスがより自由度が高いかについては、現在も議論が続いています。この議論は、自由の定義や、誰の自由がより重要か（作品の将来の潜在的な受領者（独占化からの自由）か、それとも最初の受領者（独占化の自由）か）といった複雑な問題に左右されます。しかしながら、現在の著作権法と、コピーレフトとパーミッシブの2種類のライセンスが存在することで、著作者は創作した作品にどのライセンスを適用するかを選択できます。

ソフトウェアやコード以外の文書、アート、その他の作品については、クリエイティブ・コモンズの共有ライセンスシステムとGNUフリー・ドキュメンテーション・ライセンス（GFDL）により、著作者は作品の特定のセクションに制限を適用し、作品の一部を完全なコピーレフトのメカニズムから除外することができます。GFDLの場合、これらの制限には、将来の編集者によって変更されない不変セクションの使用が含まれます。GFDLの当初の意図は、コピーレフトが適用されるソフトウェアのドキュメンテーションを支援するための手段でした。しかし、結果として、あらゆる種類の文書に使用できるようになっています。

強いコピーレフトと弱いコピーレフト

ある作品に適用されるコピーレフトライセンスの強さは、その規定があらゆる種類の派生作品にどの程度適用できるかによって決まります。したがって、「弱いコピーレフト」という用語は、すべての派生作品がコピーレフトライセンスを継承するわけではないライセンスを指します。派生作品がコピーレフトライセンスを継承するかどうかは、多くの場合、その派生方法によって決まります。

「弱いコピーレフト」ライセンスは、ソフトウェアライブラリに適用されやすい。このライセンスでは、他のソフトウェアをライブラリにリンクし、リンク元のソフトウェアに同じライセンスを付与することなく再配布することができる。「弱いコピーレフト」ライセンスでライセンスされたソフトウェアへの変更のみが、このライセンスのコピーレフト条項の適用対象となる。このライセンスでは、あらゆるライセンスのプログラムをglibcなどのコピーレフトライブラリにコンパイル・リンクし、再ライセンスを必要とせずに再配布することができる。強いコピーレフトと弱いコピーレフトの具体的な効果は、法廷でまだ検証されていない。[27]「弱い」コピーレフトを採用しているフリーソフトウェアライセンスには、GNU Lesser General Public LicenseやMozilla Public Licenseなどがある。

GNU一般公衆利用許諾書（GPL）は、強力なコピーレフトを実装したライセンスの一例です。さらに強力なコピーレフトライセンスはAGPLであり、 SaaS（Software as a Service）のユースケースではソースコードの公開を義務付けています。[28] [29] [30] [31]

Sybase Open Watcom Public Licenseは、GPLのいわゆる「私的利用」の抜け穴を塞ぎ、いかなる使用例においてもソースコードの公開を義務付けているため、最も強力なコピーレフトライセンスの一つです。このため、フリーソフトウェア財団、GNUプロジェクト、Debianプロジェクトでは非フリーとみなされています。[32]しかしながら、 OSIではオープンソースとして認められています。

デザインサイエンスライセンス（DSL）は、ソフトウェアや文書だけでなく、文学、芸術作品、音楽、写真、ビデオなど、あらゆる作品に適用される強力なコピーレフトライセンスです。DSLは、マイケル・スタッツがGNUスタイルのコピーレフトを非ソフトウェア作品（後に自由作品と呼ばれるようになった作品）に適用することに興味を持った後に作成されました。1990年代には、音楽録音、視覚芸術、さらには小説にも使用されました。フリーソフトウェア財団は、DSLをGNU GPLと互換性がないとみなしています。[33]

完全および部分的なコピーレフト

「完全」コピーレフトと「部分的」コピーレフトは、別の問題に関連しています。完全コピーレフトとは、作品のすべての部分（ライセンス自体を除く）が、その作品のコピーレフトライセンスの条件に従ってのみ改変および頒布できる場合を指します。一方、部分的コピーレフトとは、作品の一部をコピーレフト規定から除外し、コピーレフトライセンスとは異なる条件で改変した部分の頒布を許可する、あるいはその他の方法で、作品にコピーレフトの原則のすべてを課さないことを意味します。部分的コピーレフトの例としては、一部のソフトウェアパッケージに適用されるGPLのリンク例外が挙げられます。

シェアアライク

一部のライセンスの「継承」条件では、元の作品に関して付与される自由は、派生作品でもまったく同じ条件または互換性のある条件で付与されなければならないという要件が課せられます。

これは、コピーレフトライセンスは自動的に共有ライセンスになるが、その逆はあり得ないことを意味します。共有ライセンスの中には、商用利用の禁止など、さらなる制限が含まれているものもあります。また、誰もが自分の作品を共有したいわけではないという制限もあり、共有契約の中には、たとえ作者が特定の部分のみを共有したい場合でも、作品全体の共有を要求するものもあります。ソースコードの作成者にとってのプラス面は、コードに変更を加えることで元の作者が利益を得られるだけでなく、作者が認められ、変更されたコードにも同じ、あるいは互換性のあるライセンス条項が適用されることを保証できることです。[34]クリエイティブ・コモンズ・ライセンスの中には、共有コピーレフト・ライセンスの例がいくつかあります。

許容ライセンス

これらのライセンスは、ソフトウェアのユーザーにコピーレフトライセンスと同様の自由を付与しますが、ソフトウェアの改変版にもそれらの自由を付与する必要はありません。ソフトウェアの使用、改変、再配布方法に対する制限は最小限であるため、コピーレフトライセンスではありません。この種のライセンスの例としては、X11ライセンス、Apacheライセンス、Expatライセンス、各種BSDライセンスなどが挙げられます。

議論と論争

コピーレフトはオープンソース・イニシアティブとフリーソフトウェア運動の間のイデオロギー的争いの中で分裂の原因となっていると指摘されてきた。[35]しかし、コピーレフトが両派によって受け入れられ、提案されているという証拠がある。

  • OSIとFSFは、それぞれが受け入れ可能なライセンスのリストにコピーレフトと非コピーレフトのライセンスを掲載しています。[36] [33]
  • OSI の元法律顧問Lawrence Rosen 氏は、コピーレフト ライセンスであるOpen Software Licenseを作成しました。
  • OSIのライセンスガイドではGPLを「ベストプラクティス」ライセンスとして認めています。[37]
  • GNUプロジェクトのソフトウェアプログラムの一部は、非コピーレフトライセンスの下で公開されています。[38]
  • ストールマンは、 Ogg Vorbisの 再ライセンスの場合など、特定の状況下では非コピーレフトライセンスの使用を支持している。[39]

「バイラル」ライセンス

「ウイルスライセンス」は、コピーレフトライセンスに対する軽蔑的な呼び名です。[40] [41] [42] [43] [44]これは、「一般公衆ウイルス」または「GNU公衆ウイルス」（GPV）という用語に由来し、GPLv1がリリースされた翌年の1990年にさかのぼります。[45] [46] [47]「ウイルスライセンス」という名前は、コピーレフト作品から派生したすべての作品は、配布時にコピーレフトの許可を保持しなければならないという事実を指しています。

様々なBSDライセンスの支持者の中には、GPLがBSDライセンスのコードを吸収する傾向があり、元のBSDの成果物にその恩恵を与えない一方で、他のライセンスよりも「自由」であると自らを宣伝していることを嘲笑的に「GPL」という言葉で表現した者もいた。[48] [49] [50] マイクロソフト副社長のクレイグ・マンディーは2001年に、「GPLのこのウイルス的側面は、それを利用するあらゆる組織の知的財産権に脅威をもたらす」と述べた。[51]別の文脈では、スティーブ・バルマーは、GPLでリリースされたコードは、その周囲のコードがGPL互換ライセンスでライセンスされている場合にのみ使用できるため、商業部門には役に立たないと宣言し、GPLを「知的財産権の意味で、触れるものすべてに付着する癌」と表現した。[52]

マイクロソフトによるGPLへの攻撃に対し、著名なフリーソフトウェア開発者や擁護者数名が、このライセンスを支持する共同声明を発表しました。[53] [54] FSFのコンプライアンスエンジニアであるデイビッド・ターナー氏によると、「バイラルライセンス」という用語は、コピーレフトが適用されたフリーソフトウェアの使用に対する誤解と不安を生じさせるとのことです。[55]人は積極的に行動しなくてもウイルスに感染する可能性がありますが、ライセンス条件は有効な使用または採用によって発効します。[56]デイビッド・マクゴーワン氏も、GPLがプロプライエタリソフトウェアをフリーソフトウェアに強制できると考える理由はないが、「GPLのコードと組み合わせて派生作品を形成するプログラムを商業的に配布することを企業に禁じ、侵害に対する損害賠償を請求しようとする」ことはできると書いています。もし企業が「実際にGPLのプログラムからコードをコピーした場合、そのような訴訟はごく一般的な著作権の主張であり、ほとんどの民間企業は立場が逆であればこれを擁護するだろう」としています。[57]リチャード・ストールマンはこの見解を例えで説明し、「GPLの領域は近接や接触によって広がるのではなく、プログラムにGPLで保護されたコードを意図的に組み込むことによってのみ広がります。それはウイルスではなく、クモの巣植物のように広がります。」と述べています。[58]

GPLなどの一般的なコピーレフトライセンスには、通信が抽象的である限り、コンポーネントが非コピーレフトコンポーネントと通信することを許可する条項があります。[検証失敗]例えば、一連のスイッチを使ってコマンドラインツールを実行したり、ウェブサーバーとやり取りしたりすることです。[59]その結果、非コピーレフト製品のモジュールの一つがGPLの下にある場合でも、他のコンポーネントがこのような方法でそのモジュールと通信することは合法となる可能性があります。[明確化が必要]この許可された通信には、動的リンクによるライブラリやルーチンの再利用が含まれる場合と含まれない場合があります。 一部のコメンテーターはこれが含まれると主張していますが、[60] FSFはこれが含まれていないと主張し、 JavaライブラリのGNU Classpath再実装のライセンスに明示的に例外を追加してこれを許可するとしています。この曖昧さはGPLとLGPLの重要な違いであり、LGPLはLGPLと互換性のない条件でライセンスされた作品をLGPLの対象となる作品とリンクまたはコンパイルすることを明確に許可しています。[61]

シンボル

<?>
このセクションの珍しいUnicode文字を正しく表示するには、レンダリング サポートが必要になる場合があります。
© 🄯
コピーレフトシンボル
ユニコード ​U+1F12F 🄯 COPYLEFT SYMBOL
代替記号: (ɔ)
異なる
異なるU+00A9 © 著作権表示

コピーレフトシンボルは著作権シンボル©の反転バージョンで、円の中に逆さまのCが描かれています。[62] 2016年にこのシンボルを将来のUnicodeバージョンに追加する提案がUnicode技術委員会に承認されました。[63] [64]コードポイントU+1F12F 🄯コピーレフトシンボルはUnicode 11で追加されました。[64] [65]コピーレフトシンボルには法的地位はありません。[66]

2024年現在、この記号は、ほとんどの現行オペレーティングシステムのシステムフォントで標準として提供されていますが[引用が必要] 、必要に応じて、括弧(ɔ)で囲んだ文字U+2184 ↄ LATIN SMALL LETTER REVERSED Cで近似することもできます。

文字を入力する

現代のコンピュータ システムでは、文字U+1F12F 🄯 COPYLEFT SYMBOL は、次のいずれかの方法 (キーボード ショートカット)を使用して生成できます。

  • ChromeOS : Ctrl++ ⇧ Shift、、または。u[ 67 ]1F12F↵ EnterSpace
  • HTML :&#127279 or &#x1F12F
  • Linux : ++ 、、または​​Ctrl⇧ Shiftu1F12F↵ EnterSpace
  • Mac : コードポイント: U+1F12F
  • ウィンドウズ: +Alt1F12F

参照

参考文献

  1. ^ Newman, John (2011年12月29日). 「ベッドサイドにおける著作権とオープンアクセス」. NEJM . 365 (26): 2447–2449 . doi :10.1056/NEJMp1110652. PMID  22204721.
  2. ^ Troan, Larry (2006). Open Source from a Proprietary Perspective (PDF) . Red Hat Summit. ナッシュビル: Red Hat . 2014年1月22日時点のオリジナル(PDF)からのアーカイブ。
  3. ^ Stallman, Richard (2007年6月29日). 「GNU General Public License」. GNUプロジェクト. 2017年5月1日閲覧。
  4. ^ 「Free Art License 1.3」。Copyleft Attitude . 2021年10月6日閲覧。
  5. ^ “Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)”. Creative Commons . 2015年8月14日閲覧。
  6. ^ 「WikipediaがGNUライセンスを廃止し、クリエイティブ・コモンズ・ライセンスを採用」PC world . 2009年5月21日. 2025年7月4日閲覧。
  7. ^ Wang, Li-Chen (1976年5月). 「Palo Alto Tiny BASIC」. Dr. Dobb's Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte . 1 (5): 12– 25.ソースコードは次の6行で始まります。
    INTEL 8080用TINY BASICバージョン 1.0リーチェン・ワン1976年6月10日@コピーレフトすべての権利は留保されています
    5月号の6月の日付は正しいです。雑誌はスケジュールに遅れており、遅れを取り戻すために6月号と7月号を統合しました。
  8. ^ abcde Carver, Brian W. (2005年4月5日). 「Share and Share Alike: Understanding and Enforcing Open Source and Free Software Licenses」. Berkeley Technology Law Journal . 20 (1): 443. doi :10.15779/Z388T19. S2CID  153900462. SSRN  1586574. 2023年6月27日閲覧。
  9. ^ ウィリアムズ、サム（2002年3月）「7」『自由とは自由であること ― リチャード・ストールマンのフリーソフトウェアへの闘い』オライリーメディア. ISBN 978-0-596-00287-9。
  10. ^ ムーディー、グリン（2002年）『反逆の法則』26頁。
  11. ^ 「Emacs General Public License」. 2001年7月5日. 2008年8月23日閲覧。
  12. ^ ab Stallman, Richard (2008年1月21日). 「GNUプロジェクトについて」.フリーソフトウェア財団. 2017年5月1日閲覧。
  13. ^ 「フリーアートライセンス – よくある質問」。Copyleft Attitude . 2021年10月6日閲覧。
  14. ^ 「ライセンス」. GNUプロジェクト. 2021年10月6日閲覧。: 「芸術作品や娯楽作品は必ず無料であるべきだという立場はとりませんが、もし無料で公開したいのであれば、Free Art License をお勧めします。」
  15. ^ 「フリーソフトウェアとは何か？」GNU 2019年7月30日. 2020年7月22日閲覧。
  16. ^ Mundie, Craig (2001年5月3日). 「マイクロソフト上級副社長クレイグ・マンディー氏の発言原稿 - 商用ソフトウェアモデル」.ニューヨーク大学スターン経営大学院. 2005年6月21日時点のオリジナルよりアーカイブ。 2009年10月1日閲覧。
  17. ^ ニューヨーク・タイムズ。2022年4月23日閲覧。
  18. ^ Maher, Marcus (2000). 「オープンソースソフトウェア：代替知的財産インセンティブパラダイムの成功」(PDF) . Fordham Intellectual Property, Media & Entertainment Law Journal . 2014年5月2日時点のオリジナル(PDF)からアーカイブ。 2014年5月1日閲覧。
  19. ^ Sarmah, Harshajit (2019年9月23日). 「オープンソースプロジェクトへの貢献が就職に役立つ5つの理由」. Analytics India Magazine . 2020年7月22日閲覧。
  20. ^ Mustonen, Mikko. 「Copyleft - The Economics of Linux and Other Open Source Software」（PDF） . Information Economics and Policy. 2014年5月2日時点のオリジナル（PDF）からアーカイブ。 2014年5月1日閲覧。
  21. ^ 「自分の作品に適したライセンスの選び方」フリーソフトウェア財団のライセンス・コンプライアンスラボ。 2017年5月1日閲覧。
  22. ^ 「コピーレフトとは何か?」GNU プロジェクト。
  23. ^ 「Scheibner, James – 「ソフトウェアの自由の代償は何か？ オープンソースライセンスに関するオーストラリアの法律専門家向けガイド」[2017] PrecedentAULA 23; (2017) 139 Precedent 39」. classic.austlii.edu.au . 2021年11月27日閲覧。
  24. ^ カーク・セント・アマント＆ブライアン・スティル（2008年）「クリエイティブ・コモンズ・ライセンスモデルによるオープンソースソフトウェアライセンスの検証」『オープンソースソフトウェア研究ハンドブック：技術的、経済的、社会的視点』情報科学参考文献、全728ページ中382ページ。ISBN 978-1-59140-999-1。
  25. ^ 「EUPL – 欧州連合パブリックライセンス」。欧州委員会。 2007年1月9日閲覧。
  26. ^ 「フリーソフトウェアライセンス契約 CeCILL」(PDF) 。INRIA。 2010年8月8日時点のオリジナル(PDF)からアーカイブ。 2010年8月24日閲覧。
  27. ^ Patrice-Emmanuel Schmitz (2015年4月3日). 「EUPLにおける「コピーレフト」の意味」Joinup .
  28. ^ 「SaaSS」という用語の背景にある考え方については、「自分の作品のためのライセンスの選び方」の「サーバーソフトウェア」セクションを参照してください。GNUプロジェクト。2015年12月20日。 2017年5月1日閲覧。
  29. ^ リチャード・ストールマン（2016年11月18日）「そのサーバーは一体誰にサービスを提供しているのか？」GNUプロジェクト。 2017年5月1日閲覧。
  30. ^ 「なぜAffero GPLなのか」GNUプロジェクト、2015年5月10日。 2017年5月1日閲覧。
  31. ^ GNU ウェブサイト上のフリーソフトウェア ライセンスのリスト: 「開発者は、ネットワーク上で一般的に実行されるソフトウェアには GNU AGPL の使用を検討することをお勧めします」。
  32. ^ 「各種ライセンスとそれらに関するコメント - Sybase Open Watcom Public License バージョン 1.0 (#Watcom)」。GNU . 2015年12月23日閲覧。これはフリーソフトウェアライセンスではありません。対象となるソフトウェアを「展開」するたびにソースコードを公開することが義務付けられており、「展開」には様々な私的利用が含まれると定義されています。
  33. ^ ab 「さまざまなライセンスとそれらについてのコメント」。GNUプロジェクト。
  34. ^ Engelfriet, Arnoud (2010). 「オープンソースライセンスの選択」. IEEEソフトウェア. 27.アテネ経済経営大学: 48–49 . doi :10.1109/MS.2010.5. S2CID  36712745.
  35. ^ Biancuzzi, Federico (2005年6月30日). 「ESR: 「GPLはもう必要ない」」ONLamp.com. 2018年3月6日時点のオリジナルよりアーカイブ。2008年8月23日閲覧。
  36. ^ マイケル、ティーマン(2006 年 9 月 18 日)。 「名前によるライセンス」。2008 年8 月 23 日に取得。
  37. ^ Raymond, Eric Steven (2002年11月9日). 「ライセンスHOWTO」 . 2008年8月23日閲覧。
  38. ^ 「GPLv3がMS-Novell契約に及ぼす影響」Yro.slashdot.org、2007年3月8日。 2014年5月14日閲覧。
  39. ^ Stallman, Richard (2001年2月26日). 「LWN.net: RMS on the Ogg Vorbis license」. 2008年8月23日閲覧。この特殊なケースにおいて、緩い[Ogg/Vorbis]ライセンスの考え方に私が賛成するのは、ほとんどの場合にGPLを好むのと同じくらい実利的な理由からです。どちらの場合も、いかにして自由を獲得するかが問題なのです。
  40. ^ 「マイクロソフトのライセンスがオープンソースを軽視」CNET、CBS Interactive。
  41. ^ 「一部の権利は留保されています：著作権に代わる選択肢」Wired UK。
  42. ^ “用語集”. a2knetwork.org . 2009年4月26日時点のオリジナルよりアーカイブ。
  43. ^ ジェイソン・グリーンバーグ、ダニエル・グレイザー（2013年3月）「購入時の予防接種：M&A取引におけるウイルスライセンスからの契約上の保護」（PDF）フリード・フランク、企業法務協会。 2016年6月10日閲覧。
  44. ^ Philip Wood、Amy Ryburn、Allan Yeoman、Andrew Matangi、Steve Nightingale (2013年7月1日). “Legal update on Information and Communication Technology – July 2013”​​. 2013年9月21日時点のオリジナルよりアーカイブ。 2016年6月10日閲覧。
  45. ^ Vixie, Paul (2006年3月6日). 「Re: TAKロールオーバー要件草案第5.2項（IPRエンクンバランス）について」IETF Namedroppersメーリングリスト. 2007年9月27日時点のオリジナルよりアーカイブ。 2007年4月29日閲覧。
  46. ^ 「一般大衆ウイルス」Jargon File 2.2.1 1990年12月15日2007年4月29日閲覧。
  47. ^ Hackvän, Stig (1999年9月). 「GNUパブリックウイルスのリバースエンジニアリング - コピーレフトはやり過ぎか？」Linux Journal . 2011年7月18日時点のオリジナルよりアーカイブ。2007年4月29日閲覧。
  48. ^ Stewart, Bill (1998年10月8日). 「Re: propose: 'cypherpunks license' (Re: Wanted: Twofish source code)」. Cypherpunksメーリングリスト. 2007年5月29日時点のオリジナルよりアーカイブ。 2007年4月29日閲覧。
  49. ^ Buck, Joe (2000年10月10日). 「Re: 構文解析ツリーの外部使用について」GCCメーリングリスト. 2007年4月29日閲覧。
  50. ^ Griffis, L. Adrian (2000年7月15日). 「GNU Public Virus」. 2017年11月9日時点のオリジナルよりアーカイブ。2007年4月29日閲覧。
  51. ^ クレイグ・マンディー（2001年5月3日）「スピーチ・トランスクリプト – クレイグ・マンディー」ニューヨーク大学スターン経営大学院。2005年6月21日時点のオリジナルよりアーカイブ。 2008年8月23日閲覧。
  52. ^ ニューバート、デイブ (2001年6月1日). 「Microsoft CEO takes launch break with the Sun-Times」シカゴ・サンタイムズ. 2001年6月15日時点のオリジナルよりアーカイブ。（インターネットアーカイブリンク）
  53. ^ フリーソフトウェアのリーダーたちが団結 – Wikisource経由。
  54. ^ MacCrisken, Jack. 「オープンソース：ある不可知論者の視点」CNET . 2025年7月5日閲覧。
  55. ^ Byfield, Bruce (2006年8月29日). 「IT Manager's Journal: GPLに関する10のよくある誤解」 . 2008年8月23日閲覧。
  56. ^ 「ライセンス用語のスモーガスボード：コピーレフト、シェアアライク、相互、ウイルス、それとも遺伝性？」ルイス・ヴィラ著『Open Law and Strategy』2012年2月3日。 2018年8月22日閲覧。
  57. ^ マクゴーワン、デイビッド (2005). 「フリーソフトウェアとオープンソースソフトウェアの法的側面」ジョセフ・フェラー、ブライアン・フィッツジェラルド、スコット・A・ヒッサム、カリム・R・ラカハニ編著『フリーソフトウェアとオープンソースソフトウェアの展望』MITプレス、382ページ。ISBN 978-0-262-06246-6。
  58. ^ Poynder, Richard (2006年3月21日). 「The Basement Interviews: Freeing the Code」 . 2010年2月5日閲覧。
  59. ^ 「GNUライセンスに関するよくある質問」フリーソフトウェア財団、2008年6月24日。 2017年5月1日閲覧。
  60. ^ Raymond, Eric Steven (2002年11月9日). 「ライセンスHOWTO」 . 2010年3月21日閲覧。
  61. ^ リチャード・ストールマン、「なぜ次のライブラリに劣等GPLを使うべきではないのか」GNUプロジェクト。
  62. ^ 「Unicode 標準バージョン 15.0: 添付の英数字補足」(PDF) . unicode.org .
  63. ^ 「Unicode にコピーレフトシンボルを追加する提案」(PDF)。
  64. ^ ab 「提案された新文字：パイプラインテーブル」。Unicode文字提案。Unicodeコンソーシアム。 2017年4月18日閲覧。
  65. ^ 「Unicode標準バージョン11.0の発表」Unicodeブログ。 2018年6月6日閲覧。
  66. ^ Hall, G. Brent (2008). 空間データ処理におけるオープンソースアプローチ. Springer. p. 29.書誌コード:2008osas.book.....H. ISBN 9783540748311。
  67. ^ 「Unicode文字 "🄯" (U+1F12F)」。www.compart.com . 2024年9月12日閲覧。
  • ウィキメディア・コモンズにおけるコピーレフト関連メディア
  • ウィクショナリーにおけるコピーレフトの辞書的定義
「https://en.wikipedia.org/w/index.php?title=Copyleft&oldid=1320710739」より取得