Develop and Download Open Source Software

OpenSource Downloads

7-Zip  (4,014)  
HandBrake Japanese Language Version  (2,964)  
CrystalDiskInfo  (1,714)  
Boookends  (1,269)  
CrystalDiskMark  (874)  
Tera Term  (825)  
CotEditor  (626)  
FFFTP  (593)  
えこでこツール  (532)  
10  ffdshow  (524)  
11  SMPlayer  (503)  
12  Cabos  (492)  
13  ギコナビ  (475)  
14  Rappelz Server  (471)  
15  MergeDoc  (457)  
More >>

最近ブックマークされた記事

ASPを想定したGPLの拡張

2006年08月16日 11:04 Joe-'Zonker'-Brockmeier(2006年0月14日(月))
本日、FunambolのCEO、Fabrizio Capobiancoは、次の条項を付加した修正GPL(GNU General Public License)のドラフトを発表することになっている。その条項とは、サービスプロバイダに対して、たとえプロバイダの所有するサーバーの域外にコードを“頒布”しなくても、コードの変更を頒布することを義務づけるものである。これをCapobiancoはHPL(Honest Public License)と呼ぶ。この追加条項はフリーソフトウェアの新たな機軸となる可能性がある。

ソフトウェアをめぐる状況が変化しつつあることに殆ど疑問の余地はない。15年以上前にGPLv2が書かれた当時には思いも寄らなかった方法で企業はフリー/オープンソースソフトウェアを使用している。だからこそFSF(Free Software Foundation)はGPLv3に向けて改訂作業を進めているわけだが、アプリケーションサービスプロバイダ(ASP)がGPLedソフトウェアを用いてSaaS(Software as a Service)を提供しているという問題に対しても結局GPLv3で本格的な取り組みが行われることになるのだろう。

さらに別のライセンス

だが、金曜にCapobiancoと話したとき、彼は、GPLv3を待てないので、差し当たりHPLを推進するつもりだ述べた。Capobiancoは、FSFにおいてこの問題が「十分討議されていない」ので、これが切っ掛けとなって、SaaSコードの変更を共有しないASPの問題に「もっと関心が向けられる」ことになればよいとも述べた。

しかし、別のオープンソースライセンスが本当に必要なのだろうか?「ライセンスの拡散」がオープンソースにとって多少問題であることは、ここしばらくを振り返っても衆目の認めるところである。Open Source Definitionに準拠する多くのライセンスの間に両立性がないために、それらのライセンスの表向きの目的であったコードの積極的な共有そのものが封じられているからだ。

JBossの前副社長(戦略・法人開発担当)Bob Bickelは必要性ありと言う。(Capobiancoと相談してきた)Bickelとしては、一般的には新しいライセンスを使うよう勧めたくはないが、「Funambolの現在の状況はまさに拡大状況にある.... ソフトウェアをサービスと見なす新モデルは企業によるコードの利用を促すが、必ずしもコミュニティへの還元を促進しない」というのである。

Capobiancoによれば、このライセンスは変更の頒布を義務化する追加条項をGPLv2に付加したもので、企業が変更後のHPLedコードを用いてサービスを提供する際に変更の頒布が義務づけられる。また、GPLv3と上位互換であるため、後日FunambolのソフトウェアライセンスをGPLv3に切り替えることも可能という。

問題は、ASPがGPLedコード(例えば、Funambolのソフトウェア)を手に入れて変更し、当該ソフトウェアベースのサービスを売る際、ASPはコードをGPLの定義に従って“頒布”しないのでコミュニティへの還元が必要ない点にあるという。Capobiancoはこの問題をここしばらく考えており、どう考えたらよいか人々と話し合ってきた。Capobiancoによれば、「誰かが何かすべきときだ」との意見が散見されたという。

代替配布の問題が取り上げられたのはこれが初めてでない。例えば、Affero General Public License(AGPL)というライセンスは、ネットワーク上で実行されるユーザー対面ソフトウェアの問題に対処するために作られたものである。ウェブログソフトウェアのようなプログラムでは、HTTPを介してユーザーがコードをダウンロードでき、AGPLはそのダウンロード機能を保持するよう義務づける。AGPLedコードに変更を加えた場合は、その変更もダウンロードできるようにしなければならないのである。

頒布とライセンス遵守

HPLに従った場合の問題は、オープンソースソフトウェアの利用に水を差す可能性があることだ。GPLの“ウィルス的”側面を過度に強調しようとする人々がいる一方、コードの共有は頒布によって初めて引き起こされる。つまり、ユーザーや企業はGPLedコードを変更する自由があり、社内で使う限りコードを共有しなくてよいのである。これはGoogleやYahoo!のような企業が採用する際の重要な条件となっている。

Mark Radcliffe(GPLv3ドラフト作成工程でCommittee Cの議長を務め、FunambolのHPL作成を支援する)によれば、「契約上の拘束を受けるのはネットワークを通じて第三者と相互作用することが意図されたサービスに限られ、会計などの事務管理機能」はライセンスに制約されないというのである。

HPLはライセンス遵守の問題も引き起こす。コード頒布の際のGPL遵守の執行は簡単でない。ソフトウェアがどこかほかのネットワークで排他的に実行されているとするなら、違反の事実を発見して証明するのは一層困難になる。Radcliffeはこれが問題であることを認めているが、「ライセンサーは常に規則を破る可能性がある」とも指摘する。

「自分の製品をGPLのもとで頒布するライセンサーがオブジェクトコードを変更付きで提供しても頒布するソースコードに変更を含めないことがあり得る。コミュニティは最終的にそれを発見するかもしれないが、契約で倫理的行動が保証されるわけではない」

HPLedコードの場合、Radcliffeによれば、「SaaSベンダから元コードに存在しない機能が提供された場合にライセンシーはソースコードをぜひ入手したいと考える」という。

プログラムに新しい機能ありと判明した場合、その著作権所有者はソースコードのコピーを要求する権利を有する。「ソースコードを提供しなければ、HPLに違反し、SaaSベンダは元コードのライセンスを失うことになる」というのである。

NewsForge.com 原文

最終更新:2007年07月01日 19:05