サードパーティのコードを変更した後、著者として自分を含めるべきですか？

サードパーティのコードにいくつかの微調整や修正を加えるのが一般的な方法です（単純な要点でも、ライブラリ全体でも）。しかし、これらのコードの多くには独自のライセンスルールがあり、最終的には著作権情報を含むすべてのファイルにヘッダーが付いていることもよくあります。

これらの変更を行った後、次に行うべきことは何ですか？ライセンス情報を変更できないようにする@authorか、自分自身や@revisionタグなどで更新しようとしますか？

もう1つの一般的な問題は、サードパーティの名前空間/パッケージをプロジェクトの規則に合わせて変更することです。一部のライセンスタイプでは、ライセンスブロックにこの種の情報が含まれていますが、自由に変更できますか？

私はこれらの質問に対する答えが各ライセンスの種類に依存することを知っているので、私の質問をより具体的にするため...

一般的なライセンスルールを考慮すると（通常、それらはマイナーな側面で異なりますよね？）、倫理上の（または少なくとも許可されている）私の変更に関する情報をライセンスブロックに自由に追加し、おそらくコードでそれを参照する方法も変更します（例：YACorp.YALibとして使用Utils.YALib）？

これらの変更を行った後、次にすべきことは何ですか？ライセンス情報を変更できないようにするか、@ authorタグや@revisionタグなどで自分自身を含めて更新してみてください。

ソフトウェアライセンスとソフトウェアの一部である可能性のあるプロローグを混同していると思います。

ライセンスは、プログラムの著作権の所有者が他の人の使用条件（ライセンス）を指定する場所です。一部のライセンスは非常に寛容ですが、他のライセンスはより制限的です。

プロローグは、ソースコードへの変更を追跡する方法を提供するために、作成者が挿入@authorおよび@revisionタグ付けする場所です。場合によっては、コードへの重要でない追加の作成者になると、コードのそのセクションの著作権を主張できる場合があります。著作権の問題を解きほぐすことは厄介な場合があり、弁護士が対処するのが最適です。ただし、その側面には関心がないと具体的に述べているので、次に進みます。

もう1つの一般的な問題は、サードパーティの名前空間/パッケージをプロジェクトの規則に合わせて変更することです。一部のライセンスタイプでは、ライセンスブロックにこの種の情報が含まれていますが、自由に変更できますか？

これは、プロジェクトの規則に本当に依存します。

プロジェクトをフォークすると、何でもできます。

変更をプロジェクトに貢献することを計画している場合は、確立された規約に従う必要があります。名前空間を変更する説得力のある理由がある場合は、アプリケーションのコミュニティにそれを提示する必要があります。

一般的なライセンスルールを考慮します（通常、それらはマイナーな面で異なりますよね？）、

私は自分の変更についてライセンスブロックに情報を自由に追加し、おそらくコードでそれをどのように参照するかを変更することは倫理的（または少なくとも許可されています）ですか？

ライセンスを変更しないでください！

まず、ライセンスを変更する法的権利を持っていない可能性があります。第二に、変更を加えると、ライセンスが台無しになる可能性があります。ライセンスの変更は弁護士に任せてください。

プロローグを更新する限り、プロジェクトの標準に依存します。一部のプロジェクトは、ソース管理を使用して追跡するため、プロローグを必要としません。他のプロジェクトが行います。プロジェクトの規則に従ってください。

実際、私の懸念は法的側面よりも「コミュニティへの敬意」に関するものであり、私たちのプロジェクトが個人的または個人的であるとみなされる場合、どれだけ倫理的であり続けることができるかについて私はもっと尋ねています。

自分の変更を保持している場合、他の人がどう思うか気にするのはなぜですか？自分だけのために使用し、他人に決して配布しないものは、元のプロジェクトに影響を与えません。だから彼らはあなたが何をするか気にしません。

変更を配布したり、プロジェクトに貢献することを計画している場合は、そのプロジェクトの規則を評価する必要があります。分岐することを望まないプロジェクトもあり、それを防ぐためのライセンスがあります。他の人は「あなたがしたいことをする」と言って、あなたが適当と思うようにあなたがするべきカルトブランシュを与えられます。最終的に、ここでの答えはあなたが見ている特定のプロジェクトに依存します。

ファイルを「バニラ」ではないことを読者に知らせるために、関連するドキュメントまたは問題追跡システムへのリンクを含むコメントを追加します。

編集：だからこの状況は、Linuxディストリビューションがライブラリなどをパッケージ化するときを思い出させます。Debianには、パッケージのビルド方法と命名方法に関するガイドラインと標準があります。これは、ライブラリが通常ビルド前に配布される方法とは大きく異なる可能性があります。

ライブラリの命名/構築/変更について恥ずかしがり屋ではないと思います。結果をより広い世界に配布することはないだろうと思うので。この場合、私はあなたが行った変更とその理由を説明するソースとともにREADMEを含めます。例：README。$ {companyName} .changes

コードのライセンスルールを参照する必要があります。

一般に、多くのオープンソースフロントエンドアプリケーション（Firefox、OpenOfficeなど）は、アプリケーション名とロゴを商標と見なしています。そのため、アプリの修正版をリリースする場合、元の商標/トレードドレス（IceWeasel、Torbrowser、LibreOffice）を使用することはできません。

ただし、ほとんどのプログラミングライブラリは、誰が何をするかが明確である限り、多くの場合、商標についてあまり関心を持ちません（通常、これはバージョン管理メタデータから見つけることができます）。

著者情報には2つの目的があります。

1. 期限が来たらクレジットを与える
2. 値する場所に責任を与える

変更が大きくなると、後者がより重要になります。通常、実際の著者情報はバージョン管理で確認できますが、一部のプロジェクトでは、著者のセットを別のファイルに正式に登録しています。人々が正式にクレジットされるカットオフポイントはプロジェクトごとに異なります。疑わしい場合は元の著者に連絡してください。