【最重要】元のコードから「どのファイルを」「どのように」「どんな風に変更したか」という具体的な変更内容および履歴を、第三者が容易に確認できる形で明示（表示）すること。

この条件がある限りGPLよりハードルが低くなってるとは少しも感じませんね

LGPLみたいなライセンスを作りたかったのかな？
この内容ならそもそもLGPLでいい気がする
よほど特殊なケースを除いて既知のライセンスより自作のライセンスを作らなきゃならない理由は低いと思われます

@amate さん、回答していただきありがとうございます。

【最重要】元のコードから「どのファイルを」「どのように」「どんな風に変更しか」という具体的な変更内容および履歴を、第三者が容易に確認できる形で明示（表示）すること。

とは、CC-L がついている ソフトウェアを改変した 場合に、適応されものとして書いています。わかっていたらすいません。

なぜGPLやLGPLがソース変更や追加の差分の公開を必要とするのかと言えば
変更や追加された機能なり改良なりをオリジナルのソフトウェアに還元させるためです
つまりただ乗り、フリーライドは許しませんよってことです

CC-L がついている ソフトウェアを改変した

これはどこまでがソフトウェアの改変にあたるんですか？
オリジナルにはないソースファイルを追加して、そこに機能追加や改良を全部付け加えた場合に、そのソースファイルは公開しなくていいんですか？

これを公開しなければならないとなるとGPLと同じ位厳しい
公開しなくていいとなると、MIT LicenseやApache License 2.0と何が違うんですか？ってなります

複数のプロジェクト (それぞれが異なるライセンス) を組み合わせた新しいプロジェクトのライセンスがどうなるべきなのかというのは難しい問題で、互換性のないライセンスだと組み合わせられないということも起こりますし、組み合わせが可能なのかどうか解釈が難しい場合もあります。

主要なライセンスについてはフリーソフトウェア財団などが見解を発表していてある程度は安心できるのですが……新しいライセンスはそういった細部の法的見解が確立していないので利用が忌避されがちです。 ひとつのライセンスとしての出来の良し悪しとは別にただ新しいライセンスであるということが望ましくないのです。

CC-L は組合わせについて考えて作っていますか？ 主要なライセンスと組み合わせが可能なつもりで作っていますか？

●前提定義
「利用者」「貢献」「著作者」がMarkdownの太字（アスタリスク二つで囲む）になっています。Markdown用の文章でしょうか。

●条項 2. （免責事項）
「「著作者」および「貢献者」」とありますが、著作者と貢献者を別に書くことの論理的意義はありますでしょうか。
貢献の定義はありますが、貢献者の定義はありません。著作者は「「貢献」を行ったすべての者」となっており、著作者に包含するように読めます。

著作者と別に貢献者を考える場合、貢献者の免責を定める必然性はありますでしょうか。貢献者が、本ソフトウェアを組み込んだ貢献者の著作物で意図して損害を与えたような場合まで免責を宣言することは妥当でしょうか（そのような権限はありますでしょうか）。

これは単にEULAに近いものです。
とくに

【最重要】元のコードから「どのファイルを」「どのように」「どんな風に変更したか」という具体的な変更内容および履歴を、第三者が容易に確認できる形で明示（表示）すること。

これがとてつもなく面倒で

私たちは 1、GPL（General Public License）のように後続のコードへ制約を伝染させるライセンスは利用のハードルを高くし、逆に MIT License や Apache License 2.0 のように、あらゆる利用を無条件に完全解放することもまた、開発者の意図に沿わない場合があると考えます。

これと矛盾する。ライセンスに私論を足されたことによって「自由とは何だ」と言うことを考えさせられますね。
この独自ライセンスと他者が改変までして使いたいと言う価値が釣り合うなら成立するかも知れませんが、大抵このような条件を足した独自構想は破綻します。

中身が無く、ただ単に独自ライセンスを作りたかっただけという魂胆がうかがえます。

あとこれを読むべきでしょう：なぜライセンスを改造しちゃいけないの？

@STSynthe さん、

中身が無く、ただ単に独自ライセンスを作りたかっただけという魂胆がうかがえます。

　申し訳ありません。ただ単に独自ライセンスを作り、自作のソフトウェアに付与させてみたいと考えていました。

　今回、私は前回の質問(で作ったライセンス)の改良版としてこの質問を開けさせてもらいました。

回答していただきありがとうございます。

@SaitoAtsushi さん、ありがとうざいます。

CC-L は、一応GPlのように「改造したら、改造してないオリジナルもCC-Lを受け継いでね」というわけではありません。ただ、CC-Lがつけられたソフトウェアを改造したら表示と改造したところの表示が必要なだけであって、C でいう include のような形だと表示はいらないとしていますので、 MIT / Apache などでも併用可能です

改変部分を明示することを求める OSS ライセンスとして著名なものに zlib ライセンスがあります。

• zlib ライセンス本文 https://www.zlib.net/zlib_license.html
• GitHub 上の zlib ライセンスを含むリポジトリ https://github.com/search?q=license%3Azlib&type=repositories

ライセンスの同梱を求める点も CC-L と共通しますが、 zlib ライセンスには加えてソフトウェアの著者や出自を偽ってはいけないという条項もあります。

zlib ライセンスと比べた CC-L のメリットにはどんなものがあるでしょうか？

@usai さん、ご回答ありがとうございます。

申し訳ないのですが、zlib ライセンスのことを知らずにこの質問をオープンしてしまいました。

その zlib ライセンスとは明確にCC-L を使うメリットはないと思います。

個人で、「こんなライセンスがあればいいな」と考えて作らさせていただきました。

とりあえず、 CC-L って名前が、クリエイティブ・コモンズ・ライセンス と紛らわしいので、名前を変えた方がいいかと。

@oh_jig さん、ありがとうございます。

CC-L から center software license に変えたいと思います。