「自社の成果物をOSSとして公開しよう」――何に気を付けるべき？：いまさら聞けないOSSの基礎知識（3）

自社の成果物をOSSとして公開する場合、どのようなことに気を付けなければいけないでしょうか？　OSS利用の変遷を振り返りつつ解説します。

[吉田行男，ワイズプランニング]

ベンダーロックインからの解放、そして企業ブランディングへ――OSS利用の変遷を振り返る

　2000年代初めからオープンソースソフトウェア（OSS）はさまざまな目的で活用されるようになりましたが、企業における最も大きな目的は「コスト削減」や「ベンダーロックインからの解放」でした。もちろん、インターネットでダウンロードすればすぐに利用できるため、導入費用ゼロのOSSはそうした点でも注目されました。当時は開発元の戦略で、稼働するOSやミドルウェアを限定したり、垂直統合型の構成にしたりすることでユーザーをロックインしていた商用ソフトウェアのベンダーが多く存在していたため、そうした制約から逃れたいというユーザー企業の要望にも合致していました。

　2010年代に入ると、コンピュータの性能向上やインターネット環境の普及により、クラウドやビッグデータといったキーワードが広まり始めました。ソフトウェアに求められる機能要件は年々増え、1社だけのソフトウェア開発は現実的ではなくなりました。

　本連載の初回で解説したように、MozillaがWebブラウザの開発にコミュニティーの力を借りてより良いものにしようとしたことが、ITのさまざまな分野で起こるようになったのです。筆者の記憶では、当時盛り上がっていたのが分散処理フレームワークの「Apache Hadoop」やクラウド構築基盤の「OpenStack」でした。

　OpenStack関連のセミナーに登壇するベンダーの担当者は、いかに自社がOpenStackに貢献しているかを競うように講演していました。現在でも多くのOSSは、会社に所属する複数の開発者がインターネットを介して知恵を出し合い、共有しながら開発をしています。そうした状況は、「Stackalytics」を見ることで容易に知ることができます。

　参考までにOpenStackとコンテナオーケストレーションプラットフォームの「Kubernetes」の会社別コミット数を紹介します（2020年9月30日現在）。OpenStackは「independent」という個人開発者の比率が少ないことが分かります。一方でKubernetesは個人開発者の比率が高く、ビジネスとして積極的に取り組んでいるRed Hatのコミット数が多いのも興味深いです。

OpenStackとKubernetesの会社別コミット数比率（2020年9月30日時点）

#	OpenStack		Kubernetes
1	Red Hat	21.4%	Google	40.7%
2	Rackspace	7.8%	independent	17.6%
3	Mirantis	6.2%	Red Hat	15.8%
4	IBM	5.7%	Huawei	3.3%
5	independent	5.6%	ZTE Corporation	2.2%
6	Canonical	4.7%	VMware	1.9%
7	HP	4.4%	Microsoft	1.8%
8	NEC	2.7%	IBM	1.3%
9	SUSE	2.6%	FathomDB	1.1%
10	Others	39.8%	Others	14.3%

　OSSの活用は企業のコスト削減やベンダーロックインからの解放が目的でしたが、現在ではOSS活用はもちろんOSSそのものに貢献する個人、企業も現れているというわけです。こうした潮流の中で、社内の技術や成果物をOSSとして公開するケースも複数出てきています。

「成果物をOSSで公開することにした」場合、注意すべきことは？

　一般的に日本の企業では「ソフトウェアそのものが他社との差別化要因であり、それを公開したら自社の優位性が失われてしまう」と考えるケースが珍しくありません。とはいえ前述したように社外の知恵を享受したり、企業のブランディングを図ったりする観点で「OSSプロジェクトに貢献する」「成果物をOSSとして公開する」といったケースは今後増えていくでしょう。

　では、成果物をOSSとして公開する場合、どのような点に気を付けるべきでしょうか。

　まず、公開するソフトウェアに他社の権利を侵害していないかどうかを確認することが不可欠です。手作業で確認することは難しいため、他社の著作物を取り込んでいないかどうかを確認する手段として、さまざまなベンダーから提供されているツールやサービスが役立ちます。これ以外にも、業務で知る個人情報や独自のノウハウが含まれていないことを確認する必要があるでしょう。

ライセンスを決める

　第2回で紹介したように、OSSのライセンスは多岐にわたっていて、どのライセンスにすればよいか悩むと思います。「Choose an open source license」のようなWebサイトを参考に決めてもいいですが、ライセンス選びの考え方を紹介します。

ごくシンプルに自由な利用を認めたい場合

　ごくシンプルに自由な利用を認める場合は「MIT License」がオススメです。著作権表示のみで商用利用、再配布、改変などが許されているという利点があります。

特許の懸念がある場合

　企業の特許に関する懸念がある場合は「Apache License 2.0」がオススメです。著作権表示を条件に2次利用を認める点では、上記の「MIT License」と同じですが、特許条項が用意されており条件付きで特許の使用を許諾できるためです。

シェアによる改善を期待する場合

　公開により多くのユーザーの貢献を期待する場合は「GNU GPL」がオススメです。2次利用する場合も同じライセンスを要求するところが、上記のライセンスと異なる点です。改善や要望を常にフィードバックしてもらいたい場合は、このライセンスにすべきです。ただし、派生物に自社開発のソフトを含むことを嫌うケースが多いため、他人の成果物のライセンスを確認する方法、それを使って自身の成果物を作った場合のライセンスはどうなるか確認する必要があります。

ライセンス情報を探すには？

　すでに存在するOSSが含まれている場合は、まず、そのOSSのライセンスを確認する必要があります。GitHubを使用している場合は、ルートディレクトリに「LICENSE」「LICENSE.txt」もしくは「LICENSE.md」というファイルがあり、このファイルにライセンスが記述されています。

　そのようなファイルが見つからない場合は、ソースファイルのヘッダ部分に記述されていることもあります。しかし、これらを手作業で探し出すことは時間と労力がかかります。ベンダーが提供しているサービスもありますが、そのようなサービスを活用せず、ライセンス情報を集めてくるOSSツールをご紹介したいと思います。

　The Linux Foundationの傘下で開発が進められている「FOSSology」は、それ自身もOSSで公開されています。FOSSologyは、ソフトウェアを構成するソースコードを分析し、その中に含まれているライセンス情報を抽出してリストアップするツールです。2003年にHewlett-Packardで「Nomos」というライセンススキャナーが開発されたのがこのFOSSologyの始まりで、2007年にGPLv2ライセンスでOSSとして公開され、2015年にThe Linux Foundationにオーナーが移管されました。2019年にはREST API対応などの新機能も追加され、さらに進化を続けています。

　GitHubは、OSSライブラリのライセンスをチェックする「licensed」というツールを提供しています。このツールの特徴は、npm（*1）やgem（*2）といったパッケージ管理ツールでインストールしたOSSライブラリのライセンスを収集し、リストを作成します。そのリストには、直接使用しているライブラリだけではなく、依存しているライブラリに関する情報も収集できます。従って、使用したくないライセンスのOSSが含まれていることをチェックできるというわけです。

(*1) npm(Node Package Manager)：Node.jsのパッケージ管理ツール
(*2) gem：Rubyのライブラリ管理ツール

派生物（二次的著作物）の考え方

　本連載の初回でOSSの使い方として以下の4種類があることを解説しました。

1. ソフトウェア製品の一部にOSSを取り込む場合。
2. OSSを改変してソフトウェア製品を開発する場合
3. ソフトウェア製品とOSSをリンクする場合
4. OSSをシステム構築のコンポーネントとして使用する場合

　この中で、第2回で紹介した「伝搬性」が起きるのは、1〜3の3つのパターンです。「伝搬性」とは、OSSと一体化したソフトウェア全体（OSSの派生物）に対して、ソースコードの公開など、 OSSライセンス（許諾条件）が適用されると紹介しました。「非コピーレフト型」のOSSなら問題ありませんが、「コピーレフト型」のOSSの場合は、ライセンスが伝搬します。特に?については「静的リンク」も「動的リンク」も同様に考える必要があるため、注意が必要です。

まとめ

　成果物をOSSとして公開する場合、何に気を付けなければならないのかを紹介しました。今後、ますますこのような機会が増えていくと思いますので、個別具体的な問題は専門家に相談することをお勧めします。

　次回は、リスクを減らしてOSSを賢く活用する方法と題して、社内でのOSSの管理方法を紹介します。

筆者紹介

吉田行男

2000年ごろからメーカー系SIerにて、Linux／OSSのビジネス推進、技術検証、OSS全般の活用を目指したビジネスの立ち上げに従事。社内外でOSS活用に関する講演、執筆活動を行ってきた。2019年から独立し、さまざまな会社や団体の顧問として活動。OSSの活用やコンプライアンス管理などを支援している。

特集：AI、クラウドネイティブ時代の必須知識、「オープンソース活用」のマナーとリスク

SaaSやWebサービスを通じて利用者に価値を提供する中で、もはや必要不可欠となっているOSS（オープンソースソフトウェア）。近年はクラウド事業者が提供するAI（人工知能）やデータ分析系サービスと、OSSを組み合わせた活用事例も出ているなど、実ビジネスを支える存在となっている。実ビジネスである以上、安全・信頼を保証することが前提条件だが、果たしてOSSを本当に安全に使いこなせているだろうか。社会的信頼失墜のリスクをしっかりと認識した上で扱えているだろうか。本特集では、企業や開発者がOSSを活用するに当たってどのようなリスクとチャンスがあるのか、AI、クラウドネイティブ時代のオープンソースのマナーとリスクを徹底解説する。

特集：AI、クラウドネイティブ時代の必須知識、「オープンソース活用」のマナーとリスク