ユーティリティライブラリに最適なライセンスですか？

Javaで書かれた有用なものの小さなユーティリティライブラリがあり、オープンソースのリリースを計画しています。どのライセンスを使用するか迷っています。私はBSDライセンスをとても気に入っています。これは短くて理解しやすいものですが、製品のドキュメントに免責事項を含めることに関する条項は必要ありません。そのビットをドロップアウトすることを検討してください。

それでは、MITライセンスのほうが適していますか？BSDのような推奨禁止条項はありません。これは、私がBSDについて気に入っていることです。また、ソフトウェアの大部分の著作権表示を保持するというMITの条項は、ソースコードのみを参照しており、バイナリ形式やドキュメントが生成するものを参照していませんか？

このトピックに関する他のSO質問を調査したところ、Apacheライセンスを推奨する人が数人いることがわかりました。簡単にスキャンしてみると、実際に私が望むもののほとんどがうまくいくかもしれませんが、その量の法的なものでさえ頭を痛めます（特にSOではなくベッドに寝る必要がある午前2時30分）。

基本的に私は何かが欲しい：

• 分かりやすい、
• 好きなようにコードを使用できますが、ソースコードに私の著作権と許可の通知を保管してください、
• 作成するドキュメント、マニュアルなどに私や私の製品の名前、著作権表示などを入れる必要はありません。
• 私や私の製品をあなたの製品のセールスポイントとして使用しようとしないでください（私の支持がとにかく重要になるとは限りません！）
• そして、合理的な方法で私のお尻をカバーします。:-)

編集：うわー、30分、すでにいくつかの良い応答！に応じて：

私は、できる限り「ミックスアンドマッチ」を避け、さらに別のオープンソースライセンスを作成したいと思います。標準ライセンスを使用すると、私たち全員にとって簡単になります。

コメントをカバーするお尻は頬に少し舌です。言及されているすべてのライセンスに含まれている保証の免責事項は、実際に私が話しているすべてです。

編集：MITライセンスのWikipediaページを読んで、ncursesがFSFによって承認された修正版を使用していることを発見しました。それが彼らにとって十分であるかどうか、私にとっては十分であると考えています。

Apacheライセンスを検討していましたが、GPLv2との互換性の問題は紹介したくなかった問題です。

ブーストライセンスルックスはそれは、あなたが望むものはありません好きですか？

Boostソフトウェアライセンス-バージョン1.0-2003年8月17日

これにより、ソフトウェアの使用、複製、表示、配布、実行、および送信を行うために、このライセンス（「ソフトウェア」）の対象となるソフトウェアおよび付随文書のコピーを取得する個人または組織に許可が無料で付与されます。ソフトウェアの二次的著作物を準備し、ソフトウェアの提供先である第三者にそのようにすることを許可すること。

ソフトウェアの著作権表示および上記のライセンス許可、この制限、および以下の免責事項を含むこの声明全体は、ソフトウェアのすべてまたはすべてのコピー、およびソフトウェアのすべての派生物に含まれなければなりません。コピーまたは二次的著作物は、ソース言語プロセッサによって生成されたマシン実行可能オブジェクトコードの形式のみです。

本ソフトウェアは、商品性、特定の目的への適合性、タイトルおよび権利の非侵害の保証を含むが、明示または黙示を問わず、いかなる種類の保証もなしに「現状のまま」提供されます。いかなる場合においても、著作権者またはソフトウェアを配布する人は、契約、不法行為、その他のいずれにおいても、ソフトウェアまたはソフトウェアの使用または他の取引に起因または関連する責任を負いません。

• ソフトウェアの大部分の著作権表示を保持することに関するMITの条項は、ソースコードのみを参照しており、バイナリ形式やドキュメントが生成するものを参照していませんか？

ライセンスに関する私の解釈では、ソフトウェアの著作権表示のみが必要です（最初の文でライセンスとして定義されています）。これはソースコードとドキュメントのみを参照します-バイナリ形式にはライセンスが含まれず、コンパイラはすべてのコメントを破棄します。言うまでもなく、人間が読める形式ではありません。

MITライセンスにこの条項を自由に追加してください（組み合わせることができます）。

事前の書面による許可なしに、このソフトウェアから派生した製品を推奨または宣伝するために、その名前もその貢献者の名前も使用することはできません。

Apacheライセンスはより負債に強いですが、プログラマーにとっては、すべての「合法的な」ものはおそらくそれを使用することを恐れます。私の意見では（これは法的助言ではありません）、承認の禁止を含めるためにMITライセンスを変更することが最善の方法です。最も理解しやすく、保証の免除は、直接または間接的な請求をカバーするものです。

作成者の編集に編集： ライセンスを混在させたくない場合は、Apacheライセンスを使用します。それはあなたが望むすべてとそれ以上を行います（いくつかの素晴らしい特許条項を含む）。コードのライセンスブロックは、Webサイトにリンクし、十分に文書化されているため、単純です。

プロジェクトにはApacheライセンスを使用しています。これは、オープンソースJavaの世界ではデフォルトのライセンス選択のようです（主にJakartaプロジェクトの初期の作業のおかげです）。異なるライブラリがすべて同じライセンスを持っている場合、1つのプロジェクトで異なるライブラリを組み合わせるのは簡単です。

MITライセンスには常に禁止条項を追加できます。ライセンスの一部のバージョンには、既存の条項の直後にライセンスが含まれています。著作権表示に関しては、MITライセンスは「ソフトウェア」を「このソフトウェアおよび関連するドキュメントファイル」と定義しています。これには間違いなくドキュメントが含まれており、プログラムのバイナリ形式も含まれていると思います。

自分で書いてください。または、CCライセンスをご覧ください：ウィキペディア

そして、お尻を「覆う」ことさえ考えないでください。あなたが訴えられたら、誰かがあなたを責めたいので、最大のハードルは法的たわごとに資金を供給することです。いかなる角度からも覆われないこと。

ノベルでない限り;）

zlib / libpngライセンスを使用しています。私はあなたが望む特性を持っていると思います。それは短くてシンプルで、特に帰属は認められるが必須ではないことを明記し、ソースコードから著作権表示を削除することを禁止し、言語の免責責任を最小限に抑えています。

支持を拒否することについては何も具体的には述べていませんが、IANALの間、それは大したことではないと感じています。

• ありそうもない。
• 私のコードがセールスポイントになった場合、おそらくお世辞になります。
• 私のコードが私が承認しない方法で使用されている場合、他の手段があると思います。「jamesdlinがこの製品にコードを書いた」と宣伝することで製品を販売しようとする場合、それは技術的にも客観的にも真実です。「jamesdlinがこの製品を推奨している」と彼らが主張するなら、それは名誉 '損です。さらに、私の名前が何らかの形で銀行に適している状況では、とにかく間違った支持を簡単に異議を唱えることができる十分なフォローがありそうです。