可知豊の『 わかっておきたい、オープンソースライセンス』: 第3回 オープンソースライセンスの使い方をわかっておきたい

情報システムの構築・運用で不可欠な存在となったオープンソースソフトウェア(OSS)。連載第3回では、OSSを使う場合、ライセンスを実用する上でのポイントを解説します。

OSSの使い方チェック

みなさんは、どのようにOSSを使っているでしょうか。OSSを使うといっても用途は色々ですし、その用途によってライセンスの対応方法も違ってきます。ここでは、次のような代表的な用途について、考えてみたいと思います。

• OSSを使用する
• 既存のOSSを実行形式で提供する
• 既存のOSSをWebサービスとして提供する
• 既存のOSSのソースコードを改変なしで提供する
• 既存のOSSのソースコードを改変して提供する
• 自分の開発したソースコードをオープンソースで提供する

ただし、実際に使うときには、必ずライセンスを確認してください。

OSSを使用する

ユーザーとして、OSSを使用するケースです。ネットからダウンロードしたOSSを、自社の環境にインストールして実行します。

実行形式になっているOSSが、オープンソースとして特殊なものでない限り、ライセンスについては、あまり心配する点はありません。オープンソースライセンスがエンドユーザーの使用を制限することはありません。オープンソースの定義で説明したように、個人やグループ・利用分野によって制限しないからです。

既存のOSSを実行形式で提供する

システムインテグレーターとして、OSSを利用するケースです。ネットからダウンロードしたOSSを、お客様の環境に導入して、システムの一部として提供します。

実行形式になっているOSSを提供する場合、つまり複製したり配布したり販売したりするのも、ライセンスについては、あまり心配する点はありません。改変していない実行形式のOSSは、自由に利用できるからです。

ただし、GPL/LGPLが適用されたOSSは、「著作権表示・本ライセンス文書・免責条項」を同梱する必要があり、さらに、次のいずれかを満たす必要があります。

• ソースコードを添付する
• ソースコードを入手する方法を提供する
• 再配布者が実行形式のコードしか入手していない場合、再配布者が入手した一切の情報を引き渡す(ただし、あなたがソースコードを配布しておらず、非営利目的の配布の場合に限る)

なお、OSSの名前や開発者の名前を、勝手に広告などに使ってはいけないとするライセンスがあるので注意してください。

既存のOSSをWebサービスとして提供する

クラウド環境にOSSを導入して、その実行結果をサービスとして提供するケースです。Webホスティングサービスに、ApacheやMySQL・WordPressなどを導入して、ブログサービスを提供するといった場合が該当します。

このような場合、OSSを改変していなくても改変していても、一部のライセンスのOSSを除いて、自由にサービスとして提供できます。この場合、提供しているのはサービスの実行結果で、プログラム自体は配布していないからです。

ただし、AGPLというライセンスのOSSは、ソースコードを入手可能にする必要があるので注意してください。

また、このようなWebサービスを利用する、ユーザーの立場もありますね。この場合、ユーザーは、OSSを入手しておらず、OSSの実行結果を使っているだけなので、そのサービスの利用規約に従う必要があります。

既存のOSSのソースコードを改変なしで提供する

RubyやPythonなどスクリプト言語で作られたOSSをお客様のシステムに導入するといったケースです。

このような場合も、ライセンスについては、あまり心配する点はありません。改変していないOSSのソースコードも、自由に利用できるからです。

なお、この場合も、OSSの名前や開発者の名前を、勝手に広告などに使ってはいけないとするライセンスがあるので注意してください。

既存のOSSのソースコードを改変して提供する

では、インターネットなどから入手したOSSのソースコードを改変する場合には、ライセンスをどのようにすればいいでしょうか。

これは、適用されているライセンスと利用方法によって変わってきます。

MITライセンスやApacheライセンスが適用されている場合は、著作権表示・免責条項・ライセンス文書といった 3点セットを同梱すれば、かなり自由に提供できます。一方で、Mozilla Public ライセンスやGPL/LGPLが適用されたOSSは、利用方法に合わせて対応が違ってきます。

例えば、OSSを利用していて不具合を発見し、それを修正して顧客に納品するといった場合はどうでしょうか。

このような場合、GPLを適用しているOSSでは、修正したソースコードを納入顧客に提供可能にする必要があります。その際には、元のソースコードと同じライセンスで引き渡すことになります。守秘契約などで再利用の限定はできません。納入顧客側は、受け取ったソースコードファイルを自由に再利用できることになります。

ただし、修正したソースコードを顧客に納入したからといって、ソースコードをインターネットで公開する必要はありません。ソースコードを渡す相手は、納入顧客だけで構いません。

自分の開発したソースコードをオープンソースで提供する

自分で開発したソフトウェアは、著作権者として自由にライセンスを選ぶことができます。オープンソースでも、オープンソースでなくても、どちらでも構いません。

もしも、オープンソースにしたいなら、次はライセンスを選択しましょう。このとき、次の項目について検討します。

1.  連携するソフトウェアがあれば、それがどのライセンスを選択しているか
2.  他の企業の製品などに取り込まれても良いか
3.  用途・目的に適したライセンスか
4.  そのライセンスが、幅広く使われているか

なお、独自のオープンソースライセンスを作成することはお薦めできません。なぜなら、ほかのオープンソースライセンスとの互換性が不明確だからです。作成したライセンスが、法的な要件を十分に備えていない場合も考えられます。

また、面倒だからと、何もライセンスを付けずにソースコードを公開することもやめましょう。何もライセンスがないと、自由に利用できることが保証されていないため、自由に利用できなくなってしまうのです。Githubで、ソースコードを公開する場合、何らかのオープンソースライセンスを選ぶよう勧めてくれます。こちらに方法を整理していますので、参考にしてください(Githubによる、オープンソースライセンスの選び方 )。

マーケティングキャンペーンとして始まったオープンソース

実は、たとえオープンソースと名乗っていても、実はオープンソースでなく「オープンソースの定義」に従っていない場合があります(参考 https://www.catch.jp/wiki/index.php?opensource_like)。

もともと、オープンソースは、1998年にネットスケープ社がWebブラウザのソースコードを公開したのをきっかけにスタートしました(参考 https://www.catch.jp/wiki/index.php?OSI_History)。同時に、オープンソースという言葉の乱用を防止するために、LinuxディストリビューションのひとつであったDebianの社会契約をベースに、オープンソースの定義が策定されました。ですので、オープンソースという名前を活用するときは、その由来も理解しておくと良いでしょう(参考 https://www.catch.jp/oss-license/2012/01/25/why_opensource_under_osd/)。

以上、オープンソースのライセンスについて、実用上のポイントを解説してきました。オープンソースの理解を一層深めて、ビジネスに活用して頂ければと思います。この記事がお役に立てば幸いです。

• 第1回：著作権とライセンスをわかっておきたい
• 第2回：色々なオープンソースライセンスをわかっておきたい
• 第3回：オープンソースライセンスの使い方をわかっておきたい

About AM 213 Articles

プロフェッショナルサービスチームの中の人。

Twitter YouTube