OSSライブラリのライセンスが変わるのでライブラリを乗り換えた

はじめに

こんにちは！BABY JOB 開発部です！

この記事では、「誰でも決済」で利用していたOSSライブラリのライセンスが変更になったため、別のOSSライブラリへと乗り換えたときのことをご紹介したいと思います。

ライセンスが変わったOSSライブラリ

ユーザーエージェント（User-Agent）文字列を解析し、ユーザーが利用しているブラウザ、OS、デバイスの種類といった情報を特定するためのJavaScriptライブラリである、UAParser.jsを利用していました。

こちらのライブラリがv2系からライセンスが変更になりました。

UAParser.js をv2系にバージョンアップすると何が問題なのか？

v2.0.0からはライセンスがMITではなく、AGPLに変更されました。
※参考リンク
これにより、以下のような問題が生じます。

• コピーレフトの発生: AGPLライセンスの特性上、OSSでUAParser.jsのv2系を利用する場合、その派生ソフトウェアのソースコード開示が求められます。
• 商用利用時の制限: v2.0.0以降は、商用利用の場合にはPRO版の購入が求められるようになりました。

MITとAGPLの概要

ここでMITとAGPLについて簡単に説明します。

MIT

• 非常に 寛容（Permissive） なオープンソースライセンス
• 自由な利用: 自由にソフトウェアの複製、改変、再配布、販売が可能
• 商用利用OK: 作成したソフトウェアを商用目的で利用したり、有料で販売したりすることが可能
• ソースコードの公開義務なし: MITライセンスのソフトウェアを改変して作った派生物のソースコードを公開する必要がない
• 義務は著作権とライセンス表示のみ: 再配布や派生物に、元のソフトウェアの著作権表示とMITライセンスの条文を含めることだけが求められる

AGPL

• 強力なコピーレフト（Strong Copyleft） を持つ
• 自由な利用: ソフトウェアの複製、改変、再配布は自由
• GPLの派生で、特にネットワーク経由でソフトウェアを提供する場合に、そのソフトウェアのソースコードを公開することを義務付ける
• サービス全体のソースコード公開が求められる可能性があり、商用利用やクローズドソースでの開発には非常に大きな影響を与える可能性がある
• ネットワーク利用でもソースコード開示義務: AGPLのソフトウェアを改変し、その機能をネットワーク越しに（例: SaaS、Web APIなど）ユーザーへ提供する場合、その利用者全員に対して改変後のソースコード全体を入手できるようにしなければいけない

UAParser.jsがMITからAGPLに変更されたことで、「自由に使えるライブラリ」から「利用方法に強い制約がかかるライブラリ」へと変化しました。

Bowser へのリプレイス

利用率の高さやコードの修正コストの低さから、代替ライブラリとしてBowserを採用しました。

コードの軽微な修正と、既存動作の確認のみで乗り換えが完了しました。

まとめ

OSSライブラリのライセンスは、プロジェクトの法的リスクや運用コストに直結する重要な要素です。
今回のUAParser.jsのように、利用中のライブラリのバージョンアップによってライセンスが変更されるという事態は、開発チームにとって予期せぬ大きな課題となり得ます。

ライブラリ選定時だけでなく、バージョンアップ時にもライセンスについて十分に注意を払い、継続的にウォッチしていくことで、健全なプロダクト開発を続けていきます。