既存のLGPLのオープンソースのソースコードを改造して、新たなLGPLのオープンソースプロジェクトを始める際に、特にやらなければならないこと、注意しなければならないことを教えてください。

以下のルールをまもれば、何もすることはない。

http://ja.wikipedia.org/wiki/GNU_Lesser_General_Public_License

必要ないかとは思いますが和訳へのリンクを張っておきます。

LGPL2.1

http://sourceforge.jp/projects/opensource/wiki/licenses%2FGNU_Li...

ただし、法的に有効なのはWikiPediaでも和訳でもなく、LGPLの原文である点に注意してください。

元のソースはおそらくLGPL2.1ではないかと思われますが、今後LGPL3.0で配布したい場合には、「複製、頒布、改変に関する条件と制約」の13.に従う必要があります。

元のソースでそのようなライセンス変更を許可していない場合、勝手にLGPL3.0を適用することはできないようなので、単に新しいバージョンだからと乗り換えてしまわないように注意する必要があります。

ライセンスと原作者の名誉でしょうか．前者は，実社会で身を守るために必要ですし，後者は OSS 界で(自身の)評判を守るために必要です．

ライセンスに関しては，LGPL であればライセンス条件を変更せずにソース公開をする限り，常識的な範囲で作業していればそんなに気をつかう必要はないのかな，と思います．(L)GPL は，ライセンス条件の維持+ソース公開をする限り，派生物の作成に対してとても「ゆるやかな」ライセンスですので (元々が派生物に対してライセンス条件の維持とソース公開を求めることが目的のライセンスなので当然ですが)．

原作者の名誉については，上記で言及されている「ノウアスフィアの開墾」にありますように，OSS 界における経済上の利益 (≠金銭上の利益) の第一に相当します．「プロジェクトを乗っ取って原作者が得られるべき名誉をかすめ取った」ように見られないようにするために，ある程度のお作法が必要になると思われます．

「英語圏のもの」「数年前から休止状態」以上に情報がないので答えにくいですが，一般的には，

1. ML ないし Web forum が残っているなら「こういう改善パッチがあるけどニーズはあるか」と呼び掛ける．なければ原作者に直メール．
2. 反応があれば，数年ぶりの公式アップデートに結びつくかもしれない．その場合，新たなプロジェクトをフォーク (分岐) させる必要もないし，大抵の場合はフォークさせるべきではない．
3. 「プロジェクトは死んでいるから自分でやってくれ」というネガティブな反応が来たり，もしくは反応がないかもしれない．このときは，自分で「改造」プロジェクトを運営する正当な理由ができた．
4. 改造したものを公開する．

という手順でしょうか．

あと，公開するときの名前をどうするべきかが思案のしどころだと思います．「<元の名称>-<あなたの名前>-patch kit」など，コードのベースは原作者の方 (プロジェクト) の成果物であり，そこに対するあなたの貢献をマージしたものを公開する，ということを明示するのが，おそらく最も「上品」なやり方でしょうか．名前を全く変えてしまうのは，たとえば私の感覚だとちょっと品がないかな，と思います．また，同じ名前でバージョン番号だけを上げるのは，原作者の方から明示的に了解が得られたときだけにしておいたほうが無難と思います．

以上，ご参考になりましたら．