nDiki : 著作権

契約 The Artistic License 開発 ソフトウェア WiKicker Creative Commons 製品 MySQL Perl モジュール Perl 見積もり フリーソフトウェア ソフトウェア開発 現場 GPL 使用許諾契約書 Apache License, Version 2.0 バグ 書評 フロー

■ 自分が個人で開発したフリーソフトウェアを自社製品に組み込むとき

tito 氏より、記事「WiKicker と GNU GPL」にコメントをいただいた。

ご承知とは思いますが「本体が GNU GPL だから、配布する場合はその部分も GNU GPL を適用」というのはGPLの条件で配布を受けた人がさらに別の人に配布する場合です。著作者本人はGPLに縛られずに別の条件でライセンスできます。 MySQLではGPLとコマーシャルライセンスの二つのライセンスを顧客の要求に応じて選べるようにしています。だからWiKicker の場合どうしようか? というのが「MySQLとGPL」のお話ですよね。

コメントをいただいた通りである。 WiKicker は(バグレポート等ありがたいコメントをいただだきつつも)コーディングは一人で行ってきている状態なので、幸いライセンスの設定は自由がきく状態である。

今回いろいろ気にしているのは、自分がフリーソフトウェアの作者であると同時に、(組織の一員として)利用の判断、およびもし利用したとしてそれをベースに製品開発を行う立場にあるということ。

@ フリーソフトウェア作者として

• GNU GPL のまま
  • 理念を貫いて作者としてはちょっと満足。
• Perl と同じライセンスにする
  • 評判の良くない The Artistic License がからむのがちょっと嫌。しかしながら Perl モジュールは Perl と同じライセンスの方が望ましい点が多いので、これを機会にかえてしまうのも手。
• 組織に対して独占的ライセンス契約を結ぶ (売る)
  • 嫌。ありえない。
• 組織に対して非独占的ライセンス契約を結ぶ
  • 面倒。ただし個別契約時に引き換え条件として、業務時間内にフリーソフトウェア部分のメンテ作業に対する「著作権放棄声明(copyright disclaimer)」がとれるならばちょっといいかも。
  • その場合、ソースファイルのライセンス表示ってどうするの? ソースファイルを複製して、ライセンス表示2パターン作るべき?

@ 組織の一員として

• GNU GPL のまま
  • 組織の一員という立場からは困る。
• Perl と同じライセンスにする
  • 製品に組み込めるので吉。
• 組織に対して独占的ライセンス契約を結ぶ (売る)
  • ないでしょう。
• 組織に対して非独占的ライセンス契約を結ぶ
  • 面倒。

@ どれにする?

「Perl と同じライセンス」にして、かつ「業務時間内にフリーソフトウェア部分のメンテ作業に対する『著作権放棄声明』獲得」がベストか?

フリーソフトウェアを個人で開発しつつ、それを商用ソフトウェアに組む込んでいる他の方々はどうされているのかぜひ知りたいところ。

• WiKicker と GNU GPL (2005-05-10)
• Perl プログラムと必要なモジュールの配布 (2005-05-16)
• 私的10大ニュース2003 (2003-12-31)
• Perlプログラムのコードカバレッジ解析 (2004-06-03)
• PAR + ActivePerl で実行形式ファイルを作った時のライセンスは? (2004-07-21)

■ ソフト契約と見積りの基本がよ～くわかる本

最近契約的な視点での決め事にかかわる事が多くなってきたので先日買ってみた。 見積もりの部分はおまけ程度で、契約・契約書の作り方が中心。 ソフトウェア取引の契約について

• ソフトウェア開発委託契約
• ソフトウェア使用許諾契約
• ソフトウェア保守契約
• 情報処理委託契約

などがあることやそれらの概要を確認できるという点でなかなか良い。

権利的には

• 著作権
• 所有権
• 使用権
• 特許権・実用新案権

などかからんでくるのだが、ソフトウェア特有の複雑さがありすぐ混乱してくる。 やっかい。

面倒な世界であるな。

書籍はわかりやすいが、契約(書)例が少ないのが残念。 著作権等がどちらの権利になるかなどについてもう少し解説があると嬉しい。 第三者ソフトウェアがからんできた時の説明も欲しい。

またソフトウェア開発委託契約例はウォーターフォール的なモデルにもとづいており、現場としてアジャイル的なモデルで進めたいと思っても相容れない部分が多い。

それと「図解入門」シリーズということで図がふんだんに使われている。 図があった方がわかりやすいのだが、わざわざ図にする必要のないものを無理やり図にしたり図が間違っていたりするものがあったりする。ちょっと注意。

• ソフト契約と見積りの基本がよ～くわかる本

委託・受託双方にハッピーな結果(と権利関係)が得られる契約が作れるのが一番いいんだけれど、実際のところ

• 力関係
• 雛型がある場合、組織の方針・風潮として(全く/あまり)変えられない事が往々にしてある
• 面倒。時間がかかる。

などなかなか思うようにいかないものである。

この辺りについてカバーされている書籍があれば、ぜひ読んでみたい。

[ 書評 ]

• Joel on Software - 必読書 (2008-08-14)
• 開発の現場 Vol.004 「上流脳」をつくろう! (2006-04-14)
• コミットメント・リスト vs ガントチャート (2005-10-19)
• ドキュメンテーション大全 (2006-02-15)
• 自分が個人で開発したフリーソフトウェアを自社製品に組み込むとき (2005-05-16)