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


なお条件として、改造元のオープンソースプロジェクトは英語圏のもので、数年前から休止状態になっています。
また新たなプロジェクトで行う改造は、既存の機能を壊さずに新機能を追加したり、コードの最適化を進めたりする程度のものになります。

回答の条件
  • 1人2回まで
  • 登録:2009/05/30 22:48:38
  • 終了:2009/06/04 15:53:08

ベストアンサー

id:miyamuko No.3

miyamuko回答回数29ベストアンサー獲得回数112009/05/31 21:40:27

ポイント27pt

ライセンス周りで他に気をつける必要があるのは、LGPL と互換性のないライセンスのソースコードを

取り込んでしまわないように気をつける必要があります。

たとえば GPL のソースをコピペしたら、GPL にする必要があり LGPL は維持できなくなります。

また、MPL (Mozilla Public License) や CPL (Common Public License) とも互換性がありません。





ライセンス以外の OSS プロジェクトの政治的な話としては以下の記事が参考になると思います。


id:innfog

詳細な情報ありがとうございます。

また後半の運営にかかわる情報も非常に勉強になります。

2009/05/31 23:22:49

その他の回答(3件)

id:QuestR2 No.1

QuestR2回答回数435ベストアンサー獲得回数132009/05/31 00:26:54

ポイント10pt

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

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

id:innfog

情報ありがとうございます。

2009/05/31 23:18:09
id:ratbeta No.2

ratbeta回答回数132ベストアンサー獲得回数92009/05/31 10:30:06

ポイント26pt

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

LGPL2.1

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

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

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

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

id:innfog

指摘の方ありがとうございます。なるほどバージョンの問題があるのですね。

2009/05/31 23:20:37
id:miyamuko No.3

miyamuko回答回数29ベストアンサー獲得回数112009/05/31 21:40:27ここでベストアンサー

ポイント27pt

ライセンス周りで他に気をつける必要があるのは、LGPL と互換性のないライセンスのソースコードを

取り込んでしまわないように気をつける必要があります。

たとえば GPL のソースをコピペしたら、GPL にする必要があり LGPL は維持できなくなります。

また、MPL (Mozilla Public License) や CPL (Common Public License) とも互換性がありません。





ライセンス以外の OSS プロジェクトの政治的な話としては以下の記事が参考になると思います。


id:innfog

詳細な情報ありがとうございます。

また後半の運営にかかわる情報も非常に勉強になります。

2009/05/31 23:22:49
id:tera-p No.4

tera-p回答回数92ベストアンサー獲得回数212009/06/01 04:28:38

ポイント27pt

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

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

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

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

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

という手順でしょうか.

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

以上,ご参考になりましたら.

id:innfog

アドバイスありがとうございます。まさに自分が求めていた回答の1つです。

非常に勉強になります。

2009/06/01 22:26:51
  • id:b-wind
    基本的にはLGPLライセンスに従うこと、以外の制限は無い。
    「しなければならないこと」が何らかの手続きや連絡を指しているなら、そうしたことは一切必要ない。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません