論点は、
・glibライセンスであり、glibライセンスであることを明記しさえすれば良いのか、
・glibライセンスであり、glibライセンスであることを明記するのに加えて、glibライセンスの説明も書かなければならないのか
ということです。自分は前者で十分だと考えております。

自分的には、可能であれば以下のような形を考えております。どうでしょうか。

/*! @file
@brief ファイル説明

@author kobake
*/
/*
Copyright (C) 2008, kobake

Distributed under the zlib/libpng license.
See http://www.nk2.org/d/amzip/LICENSE.html for the license information.
*/

あと、申し訳ないのですけど、この件に関しては匿名でのコメントを控えていただけませんでしょうか。
あくまでもプロジェクトメンバーの見解をお聞きしたい次第です。
一般論としての突っ込み的な情報は歓迎しますが、プロジェクト固有の話の本質的なことに触れられてしまうと、情報源が匿名の場合、その情報の扱いに非常に困ります。

▼ ラスティブさん
> ▼ kobake さん
> > ファイル毎にライセンスが異なる可能性のあるプロジェクトであれば、
> > それを明示する意味で、ファイル毎に説明文が必要かもしれませんが、
> > サクラエディタの場合はすべて glib ということで認識が合って
> > いる（はず）ので、簡易的な表示（詳細は参照先でも書いとけば
> > 良い）で良いと思うのですが、どうでしょうか。
>
>
> http://sakura.qp.land.to/?Develop%2FLicenses
>
> 　僭越ながら anonymous さんの仰ることを代弁させていただきます。
> 上記のページで、◎、○、●　印が付いている方のソース以外の著名が
> 含まれるソースは、zlib/libpng ライセンスを適応せず、以前の制限の
> きつい方のライセンスを適応することにしてくださいませんか。
> 確かに、以前のライセンスに著名を消すなとは書かれてないですし、
> 著名を勝手に消せば済むんですけれど…そのへん良心的に
> お願いできれば＾＾；

「以前の制限のきついほうの」とはどれを指すのでしょうか。

>ライセンスをどう書くかについては理解しました。
>ご助言ありがとうございました。
>
>ただ、それを実行に移すにあたっては、
>代表者（またはそれにあたる権限を委譲された別の方）のゴーサイン、
>またはそれに替わる正式なソース（プロジェクト方針が記されたドキュメント等）が必要かと思います。
>
>というわけで、上記のいずれかを待ちます。
>ラスティブさんやなすこじさんが、その役割にあたる方であれば、
>そう言っていただければそれをゴーサインとみなします。
他の人が留保しているライセンスを侵害してはいけないという基本を押さえていれば，表記方法はある程度自由にしても良いかとは思います．ラスティブさんやなすこじさんは，サクラエディタにライセンスが留保された部分と明確になった部分の混在についてkobakeさんが誤解されているのではないかと心配されたのだと思います．

ライセンスの話が2回目に出たとき(1回目のGPL移行作戦に失敗したので2回目)，サクラエディタ以外への転用をどのように考えるかどうかという点を議論しました．提供されたパッチのサクラエディタでの「使用権」は暗黙のうちに認められたと考えて良いのではないかということで「This source code is designed for sakura editor. Please contact the copyright holders to use this code for other purpose. 」という表現にしてあります．

※著作権者不明等の場合の裁定制度 http://www.bunka.go.jp/1tyosaku/c-l/ でも得られるのは「使用権」だけですね．

anonymousさんがライセンスは各コードに記載すべきと述べられていますが，ソースの一部分のみを別のソフトへ転用することを想定するのであれば，それぞれのコードに全文を記載するか，一部のファイルからライセンスにたどり着けるURLが必要でしょう．

どのみちコピペするだけであれば，長くても短くても大差ない気はしますけど...短い方が好きですか？と言っても，全文を入れているのも多数派に見習っただけではありますけど．プログラム先頭のコメントが長くなることを嫌って，更新履歴を末尾にコメントで入れているソースは見たことがありますが，ライセンスを末尾に入れるのはあんまり一般的ではないですよねぇ．

▼ kobakeさん
> ▼ なすこじさん
> > こんにちは。
> > kobakeさんの精力的な活動には頭が下がります m(_ _)m
> > さて、本件については、kobakeさんが追加されたファイルはもちろんのことzlib/libpngにOKを表明されていない方のコードが無いソースファイルは簡略化した記述で良いと思います。
> > しかし、OKを表明されていない方のコードが残っているソースファイルへの記述は旧来のままとしておくべきと思います。
> > 該当部分が再設計されていればzlib/libpngに移行可能でしようが、その確認は時間的にもなかなか難しいんじゃないでしょうか？
> > あと、ライセンス文書へのリンクは下記の所の日本語か英語の所でどうでしょうか？
> > 　http://sourceforge.jp/projects/opensource/wiki/licenses
> > 稀にしか出てこない上にこの程度のことしか言えなくてすみません。
>
> 情報ありがとうございます。
> sourceforgeサーバ上のリソースであれば、（なんとなくですが）ちょっと安心できます。
> そちらを使わせていただきます。

sourceforge上のzlib/libpngライセンスを拝見しましたが、これには <年> と<著作権者>を書き込まなければライセンス文書としては完成しない（使えるものにはならない）様に見えます。
dskobaさんの指摘のように、これを元に作成したlicense.txtを同梱するようにした方が良いとおもいます。
日本語訳は、『法的に有効な形で述べたものではありません。』だそうなので、英語版をベースに作成し、日本語訳を参考資料として添付またはリンクを付ける当りが妥当と思います。

▼ Uchiさん
> ▼ kobakeさん
> > ・そもそも統合して良い時期なのか（安定度的な観点など）
>
> 試用してみた感じで言うと、もうちょっと という感じです。
> 安定度という観点から見ると、
> あれおかしいな？でも具体的にどこがおかしいのかな？
> 見たいなものが１日に何回か発生しています。
> ただ、これは統合して、多くの人に見てもらうということでの解決も考えられるので、
> 考え方次第ともいえると思います。

形式はどうあれ、使用者（試用者？）が増えてくれると非常に助かります。
一般掲示板のほうへ、UNICODE 版最新版更新のお知らせをちょくちょく流していますが、
掲示板って、ユーザのうち、どれだけの割合の人が見てくれているのでしょうかね？

サクラエディタ本家サイトのパッケージダウンロードのページに
UNICODE版ダウンロードのリンクを張っていただくことは可能でしょうか？＞gentaさん
そうすると、ユーザ人口にもけっこう影響を与えられそうな気がします。
http://sakura_editor.at.infoseek.co.jp/snapshot.html

本家統合にしても、本家からダウンロードリンクにしても、
ある程度の基準（安定度的な？）を満たす必要はあると思いますが…。


> kobakeさんが精力的に行っているソースのリファクタリングについては、
> いくつか疑問に思うことがあります。
> ① StdAfx.cpp に関数が書き込まれている。
> ② プロジェクトのフォルダ構成と、実ファイルのフォルダ構成が一致しない。
> 作用途中であれば、当然のことなのですが、統合ということであれば、リファクタリングは完了していないとまずいと思いますので、
> あえて指摘させていただきます。

一時スペースとして、ファイルやプロジェクトの変な使い方をしてしまっている所はあります。ちょくちょく直していきます。自分以外でも気づいた方のほうで（直せれば）直すこともしていただけると助かります。


ところで、Uchiさんのほうでもリポジトリへのコミット権限を取得いただき（管理掲示板に申請すると良いです）、開発に力をお貸しいただくことは可能でしょうか。

何度かパッチ作成やソースコードへの具体的なご指摘をいただいていることもありますし、掲示板等を経由して修正箇所のご指摘→権限保有者の実作業、とするよりは、直接リポジトリにアクセスできたほうが（時間的に、また、意図の正確な反映のために）好都合である気がします。

可能であれば、の話ですが。
ご検討いただければ幸いです。

▼ げんたさん
> >本当にお聞きしたいのは実用に直結する課題としての、
> >・本家とどう統合するのか
> 単純に 2.x 版ってことで良いと思います．
>
> パッケージなど: 2.xとして公開
> ブランチ: trunkを1.0, ansi等にrenameして，unicode版をtrunkにする．

方式は了解しました。

ただ、ブランチの間は本家版に影響を与えないので、自分のほうで、ある程度勝手にやらせてもらいましたが、本家への統合（trunk化）となると、サクラエディタプロジェクトのコアに影響するところです。
「思います」ではなく、「決定」をいただきたいです…。

お手数ですが、ライセンスに関する話 (>>376) についてもご回答お願い致します。

具体的に決めておきたい点を挙げます。
・どのタイミングでtrunkにするか（開発者視点の正式版）
・どのタイミングで新しいtrunkバイナリを公式版として公開するか（ユーザ視点の正式版）
　（Uchiさんから、まだイマイチ、との評価をいただいておりますし、自分としても、
　たしかに、評価期間はもうちょっと設けたほうが良いかも、と思ってはいます）
・新しいtrunkでのコミット方式はどうするか
　（従来通り、「パッチ→レビュー→コミット」式にするか？
　リファクタリング存続を考慮して、「コミット→レビュー」式にするか？）