logo

オープンソースを使えば自社の運命をコントロールできる--グーグルとオープンソースの関係 - (page 2)

文:Chris Duckett(Builder AU) 翻訳校正:石橋啓一郎2008年12月09日 08時00分
  • このエントリーをはてなブックマークに追加

--このライセンスの追跡の問題は、Googleにとってどの程度重要なのでしょうか。基調講演で触れられたとおり、Googleが相互的ライセンス契約を好まない理由はここにあるのでしょうか。

 GPLやLGPLの適用された製品を出荷した場合、自分のサイトのどこかでミラーを維持しなくてはなりません。

 Googleはこのミラーを維持しており、オープンソースソフトウェアの利用を追跡するためのソフトウェアを利用しています。そのため、追跡の作業はさほど難しくないですが、時間のかかる作業ではあります。

 商用ソフトウェアでは、これは何をやる時にも当てはまり、しかもその後時間が経つに連れて作業は何倍にもなるのです。

 われわれは相互的な(オープンソース)ライセンス契約を好んでいないわけではありません。われわれは相互的ライセンスの下で大量のソフトウェアをリリースしています。ただ、ApacheやBSDスタイルのライセンスでソフトウェアをリリースする方が、より簡単だというだけのことです。みなさんに「持っていってください。とにかく、持っていって構いません」と言えること。これは素晴らしいことです。

--Googleのソフトウェアがオープンソースとしてリリースされる段階に達すると、どういう手順が発生するのですか。

 まず担当部署の人たちがわれわれのところに、「このGoogleソフトウェアをリリースしたい」と言いに来ます。その際、彼らが開発サイクルのどの段階にいるかによって、作業が簡単になるか大変になるかが決まります。

 「これをリリースしたい」と言われても、そのソフトウェアに当人たちが把握していない依存関係が存在する場合があります。この場合は、「リリースは可能だけど、そのためにはこんな手順を踏むことになる」と提示することになります。

 ほとんどのケースで、特に小さいものの場合、リリースの許可を出すまでにかかる時間は3〜4日です。われわれはその間に法的な検討やその他の作業を行います。ですから、Googleでのソフトウェアのリリースは非常に簡単です。

 パッチはさらに簡単です。通常、パッチについては1時間以内にリリースの許可を出しています。

 また、新しいプロジェクトについては、だいたい2日か3日で承認します。

 AndroidやChromeのような大きなプロジェクトとなると、話は複雑です。プロジェクトが巨大で、多くの下位コンポーネントなどを持っているからです。彼らに対しては、一定のインフラを提供する必要があります。

 Androidについて言えば、われわれは150のGitリポジトリを管理しています。われわれは、それらのリポジトリなどを管理するための多くのソフトウェアを利用しています。

 他にも作業がありますが、あまりここでの話とは関係がありません。とにかく、製品の寿命がかなり長いのに対し、作業の期間は日数で数えることができる程度のものです。

--GoogleがGoogle Codeを作ったのはなぜですか。なぜSourceForgeではいけないのですか。

 1つだけ問題があると感じている箇所があったのですが、誰もその問題を解決しようとしていませんでした。

 私はSourceForgeはかなり素晴らしいものだと思っていますし、SourceForgeが始まった時、私はVA Linux Systemで働いていました。

 しかし、企業1社だけがあれだけ大きなオープンソースのインフラを持っているということは、権力でもあります。

 そこで私は、自分たちがバックアップの役割を果たしてもよいのではないかと考えました。人々はSourceForgeなり何なりで開発を続けることができます。私はともかく、このように非常に重大な機能をもつオープンソースのインフラを、1社の企業だけが維持している状態を避けたいと思っているのです。

CNET Japanの記事を毎朝メールでまとめ読み(無料)

-PR-企画特集

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]