オープンソース、著作権、および些細なバグ修正

開発者がクローズドソースの商用アプリケーション用のライブラリを開発したとしましょう。彼らはオープンソースコミュニティに還元したいので、たとえばGPLの下でこのライブラリを公開しますが、独自のアプリケーションで引き続き使用します。彼らは著作権を保持しているので、それは問題ありません。

これで、GPLバージョンのユーザーがバグを見つけて修正し、元の開発者にパッチを提出します。私が理解しているように、このバグ修正をクローズドソースアプリケーションで使用するには、開発者が送信者からの許可を持っている必要があります。提出者が拒否した場合、開発者はクローズドソースバージョンのバグを修正する別の方法を見つける必要があります。

しかし、バグ修正自体が本当に簡単な場合はどうでしょうか？変数を適切に初期化したり、nullポインターをチェックしたりしますか？エラーの説明が与えられれば、半分の有能なプログラマーがほんの数分で見つけて修正できる何か？このパッチはまだ著作権で保護されていますか？または、元の開発者が提出者の同意なしに、クローズドソースアプリケーションに同じ修正を実装できますか？

注：これは実際には架空のシナリオであり、「私の「友人」がこの問題を抱えている」質問の1つではありません

警告：私は弁護士ではありません！

更新：些細なバグ修正は著作権の対象ではない可能性があります。詳細については、Michael Shawの回答を参照してください。これは、私が最初に言ったものよりも正確であると思います。

ただし、それでも、この状況は理想的とは言えません。

• これは、重要な機能を追加するのではなく、ささいな変更であるという、あなたの不自然な例についてはかなり明白かもしれません。ただし、実際には、それがいつ当てはまるかについての判断が求められます。あなたは著作権のグレーの領域に残されます。
• 理想的には、更新されたファイルをプログラムに組み込むだけです。たとえ些細なことであっても、独自のコードを追加する必要はありません。不必要に作業を複製するだけです。
• これで、ファイルには2つのバージョンがあります。あなたのものとオープンソースのものです。コードの更新されたバージョンを後でコミュニティにリリースする場合、これは混乱を招くだけです。

結論： Gnu Public Licenseは、クローズドソースプログラムでのコードの使用を具体的に制限します。したがって、GPLの下でコードをリリースすることは、元のプログラムに組み込むことのできないコードのフォークを意図的に作成することになります。これはあまり意味がありません。

BSDライセンスやArtistic Licenseなど、より寛容なライセンスの下でコードをリリースするほうがよいでしょう。これらのライセンスにより、追加の許可なしにコードをクローズドソースソフトウェアに含めることができます。通常、コミュニティによるそれ以降の開発は、使用したのと同じライセンスの下で行われるため、加えられた変更（マイナーまたは重要）をソフトウェアに組み込むことができます。

技術的には、誰かがコードを更新してGPLでリリースすることを決定する可能性がありますが、積極的に選択する必要があります。デフォルトの位置ではありません。そしてそうすることで、彼らはあなたが行った更新からリリースを断ち切るので、それはおそらく彼らにとって有益ではないでしょう（それがあなたのソフトウェアであるならば、あなたはおそらく他の誰よりも多くの開発をするでしょう）。

バグ修正が非常に簡単な場合、特にコードを書く方法が他にない場合は、著作権で保護されていない可能性があります。愛の詩やビデオゲームを書く方法は何億もの方法がありますが、実際に書く方法は1つか2つしかありませんif (*p == NULL)。著作権はアイデアの表現に基づいているため、アイデアの表現方法に本当に選択肢がない場合、著作権は存在できません。

ただし、バグ修正がまだかなり簡単な場合は、それを表現する方法が数十通りある可能性があるため、著作権で保護されている可能性があります。そして、かなり些細なことでも、ほとんど著作権で保護されているのか、ほとんど著作権で保護されていないのかを見分けるのは簡単ではないかもしれません。

著作権で保護されている可能性もありますが、それを使用するとフェアユースになります。フェアユースは、いくつかの要因の重み付けに依存するため、やや複雑であり、フェアユースが適用されるかどうかは裁判所によって決定されるため、役に立たない可能性があります-理想的には、裁判ではないことを望みます。 、あなたのケースがどんなに強くても。フェアユースの要因の1つは、使用された作品の割合です（これは、すべてを取り上げたため、これはあなたに反します）。もう1つは、作品の商業的可能性です（これは、あなたにとって、商業的価値があるため、些細なバグ修正自体はゼロです）。したがって、裁判所がどちらの方法で判断するかを推測するとエラーが発生しやすくなります。

おそらくこれに対処する最良の方法は、バグの正確な説明とその正確な場所を、パッチを見たことのない開発者に渡すことです。その後、彼らは独立してバグを修正でき（このバグは些細なものなので非常に時間がかかりません）、著作権で保護されている場合は著作権を所有しているため、潜在的な著作権の問題がすべて解消されます。本質的にそれを書く方法は1つしかないため、開発者はパッチとほぼまったく同じコードになる可能性がありますが、この場合は著作権で保護されていません。

http://www.ifosslr.org/ifosslr/article/view/30/64を読んだ後の私の専門家の意見はこれです：

元の作品は唯一の著作者であり、その人物は著作権を所有しており、希望どおりの作品のライセンスを選択することができます。

現在、開発者はバグを見つけて修正に貢献しています。これは著作権で保護されていない（貢献が少なすぎる）と見なすことができますが、相当な貢献でした。両方の個人がマージに同意しているので、元の作者は貢献を受け入れ、それによって作品を集合作品にします。

共同作品では、各作者がそれぞれの部分を所有しますが、それぞれが全体の作品に分割されない関心を所有しているため、それぞれが希望する条件で作品全体をリリースできます。

これが妥当な解釈である場合、論争は、元の作者が商用リリースでバグ修正を使用できるかどうかではなく、IMOが使用できます。潜在的な競合は、バグフィクサーが、全体として作業に独自の分割されていない所有権を持っていると信じるかどうかです。その場合、オリジナルの作者がバグフィクサーからリリースを入手して、その著作物の所有権を受け入れないことを明確に示すことをお勧めします。