敬遠されるソースコードライセンス（2/2 ページ）

[Andy-Singleton，IT Manager's Journal]

　コードがオープンソース／フリーになる：ベンダーにソースコード・ライセンスの打診をするとよく返ってくる答えは、「うちの製品をオープンソースにしたり無料にしたりしたくない」というものだ。多くのベンダーは、長い間、限定的なライセンスを使用してきているために、ライセンスにも幅広い選択肢があること、そしてそうした選択肢を利用すれば自由も収益も大きくできることをあまり認識していない。顧客と契約者に限定したソースコード・ライセンス（従来のOEMライセンス）や、使用権（オブジェクトコードとも呼ばれる）と開発権（ソースコードと修正コード）を分離したライセンスを検討したことがないのである。このようなベンダーにとっては、シェアードソースモデルが一つのいい踏み台になる。これは、使用権は標準の価格と条件でライセンス供与し、開発用には制限の少ない条件でソースコードをライセンス供与するモデルだ。

　GPL汚染：顧客とパートナーがコードを入手できれば、彼らも製品の改訂に貢献できる。主に法律家から持ち出されている懸念として、部外者がGPLなどのウイルス性オープンソース・ライセンスの対象コードを組み入れることで、コードが"汚染"されるというものがある。この問題を調査したところ、2つのことが分かった。

1）そうした不測のGPL汚染で知的財産の価値は破壊されない。一部の法律家は"汚染"製品全体をGPLの対象とする必要があるといっているが、そんなことをしなくても、GPLコードを置き換えることで対処できるからだ。

2）この問題に対処するよい方法の1つは、Black Duck社やPalamida社の製品のようなコードスキャナを利用することである。これらは、ライセンスに抵触するコードを識別する。この方法は、少量の寄贈コードだけでなく、社内由来の大量のコードにも適用できる。

　このように、ソースコードをライセンス供与して寄贈コードを採用しても、GPL汚染回避のコストは大幅には増加しない。

　バージョン管理：顧客がアプリケーションの改訂バージョンを作成した場合、ベンダーはそうした新しいバージョンのテストとサポートをどのように行うか。これまで述べたどのリスクもたいした経済費用を伴わなかったが、それとは対照的に、アプリケーションの複数バージョンを管理することは、複雑でコストもかかるものになる可能性がある。

　ベンダーがカスタムバージョンをサポートするには、ツールと戦術の改善が必要だ。オープンソースの世界から転用できる戦術もある。例えば、修正コードをメインラインに組み込む明確なポリシーを設ければ、複数バージョンにフォークしないようにすることができる。この方法は実際にオープンソース・プロジェクトで使われている。顧客やパートナーが責任を持ってカスタムバージョンを管理できるように、より高度なサポートを提供するという方法もある。例えば、コード、請負業者、プロジェクトポータル、ビルドスクリプト、ビルドファームなども、多少保守費用を追加すれば提供できる。また、ベンダー自身の側でも、コンフィギュレーション管理、ソースコード管理、分散チーム管理の整備を検討する必要があるだろう。

　このような投資は、顧客やパートナーと協力し合う新たなチャンスにつながると考えれば無駄にはならない。

Andy Singleton――マサチューセッツ州ニーダムにあるAssembla社の社長。同社はオープンソースシステムとビジネスソフトウェアの導入を支援するコンサルティング/開発サービスを企業等に提供している。

原文へのリンク