[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

ちょっと硬派なコンピュータフリークのBlogです。

カスタム検索

2010-06-10

受託開発とGPL ー 補足事項

前回は受託開発をする際にGPLライブラリを用いた場合のライセンスの扱い、主にソースコードの開示義務について説明した。今日はさらにもっと掘り下げて、受託開発でGPLが使える場合、使えない場合、使いたい場合などについて考察してみたい。なお、今回のエントリは前回の続きであるため、まだ前回のエントリを読まれていない方は先にそちらを読んで頂きたい。

おさらい: ライセンシーへソースコードを開示する

前回のエントリにおいて解説したことまとめると次の2点となる。
  • 受託開発でGPLを使うときは、発注者=ライセンシーに対してGPLに基づいてソースコードを開示する必要がある。
  • ライセンシーがソフトウェアを再配布するかはあくまでもライセンシーの自由。
後者について補足すると、GPLではライセンシーに対してNDAなどでソフトウェアの再配布を禁止することを認めていない。発注者側が「GPLソフトウェアとして一般公開しよう」と思えば、それはライセンス的に何ら問題はないということだ。受託側はそのように一般公開されることも考慮に入れておくべきだろう。(発注者からワンオフでお金を頂ければ問題ないということで。)

SaaSは頒布にあたらないのか?

GPLv2およびGPLv3でライセンスされたソフトウェアをSaaSとしてWeb経由で提供する場合、これは頒布には当たらない。何故なら、ソフトウェアのコピーが第3者に渡ったわけではないからである。従って、自社だけで運営するSaaSにおいては、GPLのことを気にせずGPLなソフトウェアが使い放題ということになる。

ただし、このような状況は「自由なソフトウェア」を標榜するGNUプロジェクトにとっては好ましいものではない。そもそも、自由でないソフトウェアが横行するのは、ユーザーにとっても開発者にとってもよくない状況である。(ユーザーにとってはWebシステムの中身がまったく見えない=ブラックボックスとなってしまうし、開発者にとっては転職時=別のWebサイト構築時には全てのソースコードを書き直す必要があるという、即ち生産性が低下するという問題があるだろう。)

そこで登場したのがAGPLだ!AGPLを適用したソフトウェアは、SaaSの利用でもソースコードを開示しなければいけない。利用するソフトウェアのライセンスが、通常のGPLなのか、それともAGPLなのかということはよく確認しておこう。

なお、自分が開発したソフトウェアを頒布したい場合はAGPLがオススメであると言っておこう。

GPL非互換のライブラリ

受託開発においてGPLを用いる際、もっとも問題になるのはこの点であろう。ライブラリなどでGPLソフトウェアを利用する場合、頒布時にはソフトウェア全体をGPLにしなければならない。すると問題になるのが「GPL非互換のライブラリ」を他に用いているような場合だ。GPL非互換のソフトウェアは、ライセンスをGPLに変更することができない。即ち、AというGPLライブラリとBというGPL非互換のライブラリを用いてひとつのソフトウェアを構築するというのは不可能なのである。どちらか一方を選択しなければならないだろう。

パッケージの受託開発

受託開発と言っても、何も基幹系システムの構築といったような案件だけではなく、実際にはパッケージ製品の受託という形態もある。このような形態の場合、発注者側は不特定多数の人にパッケージを販売することを前提としているが、内部でGPLソフトウェアを利用している場合、パッケージのライセンスをGPLにしなければならない。パッケージの販売でライセンスをGPLにして商業的に成功するのは正直難しい。従って、パッケージの受託開発でGPLが利用されることはあまりないだろう。

GPLを指定するのはユーザー!

GPLなソフトウェアを使うことで得をするのは一体誰か?本ブログを読んで下さっている方にはすぐ分かることだろうが、それはユーザーである。ユーザーはGPLソフトウェアの利用に際して如何なる制限も受けない。再配布すら自由であるし、いざとなれば誰にでも開示可能名ソースコードがあるため第3者にソフトウェアのメンテナンスを依頼することも可能だ。万が一、受託開発業者が潰れた場合でもサポートを受けるチャンスがあるわけだ。

プロプラエタリなライセンスは、ソフトウェアを提供する側に自由がある。即ち、自由に「ユーザーを制限できる」ということである。逆に、GPLはソフトウェアを提供する側にちょっとだけ制限がある代わりに、ユーザーにとっては最大の自由が保障されたライセンスなのである。読者諸君よ。自分がもしソフトウェアを発注する立場であったなら、割増料金を払ってでもライセンスにGPLを指定することを検討してみてはいかがだろうか。

SIerにとってのメリット

会社の利益はさておき、自分がSIerのいち社員、すなわち開発者の立場であったなら、GPLの利用は歓迎すべきである。何故なら、GPLソフトウェアで培った知識というのは会社を変わっても引き継げるからだ。このようなご時世であるから、汎用性の高いスキルを磨いて腰を軽くしておくのは賢い選択ではないだろうか。自分が積み上げてきたものが無駄にならない(たとえ転職しても!)というのは、何者にも代え難い大きなメリットである。

一方で、会社としてSIerの利益を考えた場合はどうだろうか。もし仮にユーザーのリテラシーが向上し、「割り増し料金を払ってもいいからGPLでお願いしたい」という案件が増えれば、短期的には確実な収入増が見込めるだろう。短期的であれ何であれ、実入りが増えるのはいいことである。長期的にはどうか?この点については、次回壮大に語ってみようと思う。

4 コメント:

Unknown さんのコメント...

>なお、自分が開発したソフトウェアを頒布したい場合はAGPLがオススメ

AGPLv1はGPLv2,v3と非互換
AGPLv3はGPLv3互換だけどGPLv2非互換
なので、フルスクラッチならいいけど既存GPLコード(ライブラリ)使うとき注意

ssdc0246 さんのコメント...

「GPL非互換のライブラリ」セクションの
> 即ち、AというGPLライブラリとBというGPL非互換の
> ライブラリを用いてひとつのソフトウェアを構築
> するというのは不可能なのである。
> どちらか一方を選択しなければならないだろう。

とのことですが、下記のGPLのFAQによると
できなくもなさそうな気がします。
よろしければご意見をお聞かせください。

-----

フリーではないライブラリを利用するフリーソフトウェアを書いているのですが、GPLを適用した場合どのような法的問題が発生するでしょうか?
http://www.gnu.org/licenses/gpl-faq.ja.html#WritingFSWithNFLibs

Mikiya Okuno さんのコメント...

例外規定の話ですね。例外規定を設けると、そのソフトウェアのライセンスは「例外付きのGPL」という位置づけになってしまいますが、確かにGPLソフトウェアに組み入れることが可能です。GPL非互換のOSS系ライセンスでも同じことが言えます。以前EPLについて考察したエントリがありますので、そちらを読んでみてください。

参照
http://nippondanji.blogspot.jp/2010/05/eclipsegpl.html

ssdc0246 さんのコメント...

貴重なご意見ありがとうございました。
EPLの記事は最後のくだりが大変参考になりました。

> たとえプロプラエタリなライブラリであっても、
> そのライセンスがGPLソフトウェアへのリンクを
> 明確に禁じているようなものでなければ問題は
> ないのである。

禁止が明文化されていると厄介と言うことですね。

単純にGPLの普及促進もそうですが、ライセンス混在の
煩雑さを回避するためにもGPL(のライブラリ)には
がんばって頂きたいものです。
(他力本願と言うわけではなくて、単純に今は
 ライブラリを利用した「ソフトウェア」をGPLに
 しようと目論んでいるだけです。)

コメントを投稿