はじめに

オープンソースソフトウェアの世界で重要な位置を占めるEPL(Eclipse Public License)。
企業での利用とオープンソースコミュニティのバランスを取った「コピーレフト」ライセンスとして注目されていますが、実際にはどのような特徴があるのでしょうか。
今回は、EPLライセンスの基本から実際の使い方まで、わかりやすく解説します。

EPL(Eclipse Public License)とは

EPL(Eclipse Public License)は、IBM によって開発され、現在は Eclipse Foundation によって管理されているオープンソースライセンスです。 
現在は「EPL-2.0」が最新版で、2017年8月にリリースされています。 
EPLは、IBMが2001年に策定したCPL(Common Public License)を基に発展したライセンスです。
CPLの企業利用における実用性を保持しながら、コミュニティのニーズに合わせて改良されたのがEPLの特徴といえます。Eclipseプラットフォームをはじめとする多くのJavaプロジェクトで採用されており、「ウィークコピーレフト」ライセンスの代表格として知られています。

主な特徴

1. ウィークコピーレフト(弱いコピーレフト)

EPLは「ウィークコピーレフト」に分類され、以下の特徴があります:

  • EPLライセンスのコード自体を改変した場合は、その改変部分もEPLでオープンソース化する必要がある
  • しかし、EPLライセンスのソフトウェアと「別のファイル」や「別のモジュール」として組み合わせるプロプライエタリソフトウェアはクローズドソースのまま配布可能

2. 企業利用への配慮

  • 商用利用が可能
  • プロプライエタリソフトウェアとの組み合わせが柔軟
  • 法的な安全性を考慮した条文構成

3. 特許保護を含む

  • コード提供者からの特許ライセンスが付与される
  • 特許訴訟に対する防御機能
  • 特許攻撃への対抗措置

4. GPL互換性

  • EPL-2.0は「Secondary License」メカニズムにより、GPL系ライセンス(GPLv2、GPLv3等)への一方向の移行が可能

EPLライセンスの全文

EPL-2.0ライセンスの全文は中程度の長さ(約5,000文字)で、詳細な条項が含まれています。
公式の全文はEclipse Public License – v 2.0で確認できます。

主要部分の構成:

Eclipse Public License - v 2.0

1. DEFINITIONS
2. GRANT OF RIGHTS
3. REQUIREMENTS
4. COMMERCIAL DISTRIBUTION
5. NO WARRANTY
6. DISCLAIMER OF LIABILITY
7. GENERAL

※日本語訳についてはOSI承認ライセンス日本語参考訳をご参照ください。

この条文により、オープンソースの利益と企業での実用性のバランスが保たれています。

何ができるのか

自由な利用

  • 個人利用・商用利用問わず使用可能
  • 改変・カスタマイズが自由
  • 他のプロジェクトへの組み込み

配布・再配布

  • 元のソースコードの配布
  • 改変したバージョンの配布(ただし改変部分はEPLで公開)
  • プロプライエタリソフトウェアとの組み合わせ配布

ハイブリッド開発

  • EPLライセンスのコンポーネント + プロプライエタリコンポーネントの組み合わせが可能
  • 「別ファイル」「別モジュール」であればクローズドソース部分を秘匿可能
  • プラグインアーキテクチャでの利用に最適

Secondary Licenseメカニズム

  • EPL-2.0では「Secondary License」として指定された場合、GPL系ライセンスでの配布も可能
  • これによりGPLプロジェクトとの統合が容易に

EPLのウィークコピーレフトの仕組み

EPLには以下の重要なルールがあります:

1. ファイルレベルでのコピーレフト

EPLライセンスのファイルを改変した場合、その改変されたファイルはEPLライセンスで公開する必要があります。
これは「ファイルレベル」でのコピーレフトです。

2. 別ファイル・別モジュールの自由

EPLライセンスのコンポーネントと「組み合わせる」だけで、改変を加えない場合、または完全に別のファイル・モジュールとして開発されたコードは、プロプライエタリライセンスのまま配布できます。

3. プラグインアーキテクチャでの利用

Eclipseプラットフォームのようなプラグインベースのシステムでは、EPLライセンスのコア部分に対してプロプライエタリなプラグインを開発・配布することができます。

注意すべき点

1. 改変部分の公開義務

EPLライセンスのソースコードを改変した場合、その改変部分はEPLライセンスで公開する必要があります。
これはMITやApache-2.0にはない制約です。

2. ソースコード提供義務

バイナリ形式で配布する場合でも、EPL部分のソースコードを提供する手段を用意する必要があります:

ソースコード提供の方法:

  • 同じ場所でのソースコード配布
  • 書面による申し出書の同梱(3年間有効)
  • インターネット上でのアクセス提供

3. 著作権とライセンス表示の保持

  • 元の著作権表示を削除・改変してはいけない
  • ライセンス文書を同梱する必要がある
  • 改変した場合はその旨を明記

4. 特許訴訟による権利終了

EPLライセンスソフトウェアに関して特許訴訟を起こした場合、その利用者のライセンス権利は自動的に終了します。

5. ライセンス互換性の複雑さ

EPLと他のライセンスの互換性:

  • GPLv2/GPLv3:EPL-2.0のSecondary Licenseメカニズムにより互換性あり(条件付き)
  • Apache-2.0:一般的には互換性があるが、詳細な検討が必要
  • MIT/BSD:組み合わせ可能だが、全体のライセンス処理に注意

6. Secondary Licenseの理解

EPL-2.0では「Secondary License」として、GPL v2.0以降(GPL-2.0+)との互換性を提供できます。
具体的には、著作権者が明示的に指定した場合にのみ、GPL系ライセンスでの配布が可能になります。

これにより、EPLプロジェクトをGPL系ライセンスとして配布することも可能になります。

他のライセンスとの比較

ライセンスコピーレフト特許保護企業利用主な特徴
EPL-2.0ウィークあり容易ファイルレベルのコピーレフト
GPL v3ストロングあり制限ありプロジェクト全体がオープンソース化
LGPL v3ウィークあり容易ライブラリ利用に特化
Apache-2.0なしあり非常に容易最も企業フレンドリー
MITなしなし非常に容易最もシンプル

実際の使用例

EPLライセンスは多くの有名なプロジェクトで採用されています:

  • Eclipse IDE – 統合開発環境の代表格
  • Eclipse Mosquitto – MQTT軽量ブローカー(EPL/EDLデュアルライセンス)
  • Eclipse Jetty – Javaベースのウェブサーバー・サーブレットコンテナ(EPL-2.0 OR Apache-2.0)
  • Eclipse Paho – MQTTクライアントライブラリ(EPL/EDLデュアルライセンス)

開発者として気をつけること

プロジェクトでEPLライセンスを採用する場合

1. ライセンスファイルの設置

  • プロジェクトルートに「LICENSE」ファイルを作成
  • EPL-2.0ライセンス全文をコピー
  • 必要に応じて「NOTICE」ファイルも作成

2. ソースファイルへのヘッダー追加

/*******************************************************************************
 * Copyright (c) [yyyy] [name of copyright owner].
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0
 *
 * SPDX-License-Identifier: EPL-2.0
 *******************************************************************************/

3. README.mdでの表示

## License
This project is licensed under the Eclipse Public License 2.0 - see the [LICENSE](LICENSE) file for details.

4. 特許およびコピーレフトの理解

  • 公開するコードが自社特許を含む場合の検討
  • どの部分がコピーレフトの対象になるかの明確化
  • プラグインアーキテクチャでの境界設計

EPLライセンスのソフトウェアを利用する場合

1. ライセンス確認の手順

  • プロジェクトのLICENSEファイルでEPLのバージョンを確認
  • Secondary Licenseが指定されているかの確認
  • NOTICEファイルや追加の著作権情報の確認

2. 改変する場合の対応

  • 改変したファイルはEPLライセンスで公開
  • 改変内容と改変者の情報を明記
  • 改変版のソースコードを入手可能にする

3. バイナリ配布時の対応

  • EPL部分のソースコード提供手段を用意
  • 著作権表示とライセンス文書を同梱
  • ソースコード取得方法の明示

4. プロプライエタリ部分との分離

  • EPL部分とプロプライエタリ部分の境界を明確化
  • 別ファイル・別モジュールとしての設計
  • 動的リンクやプラグインアーキテクチャの活用

5. 依存関係の確認

  • 使用するライブラリとの互換性確認
  • Secondary Licenseオプションの検討
  • ライセンス継承の影響範囲の把握

EPL-1.0 vs EPL-2.0の違い

主な改善点

1. GPL互換性の追加

EPL-2.0では「Secondary License」メカニズムにより、GPL系ライセンスとの互換性が実現されました。

2. 国際化への配慮

  • 準拠法がニューヨーク州法から削除
  • より国際的な環境での利用に配慮

3. 言語の明確化

  • ライセンス条項の言い回しが明確化
  • 解釈の余地が少なくなる改善

移行の考慮事項

既存のEPL-1.0プロジェクトをEPL-2.0に移行する際は:

  • 全ての著作権者の同意が必要
  • Secondary Licenseオプションの検討
  • 互換性の向上による恩恵の評価

EPLの歴史的変遷

CPL → EPL-1.0 → EPL-2.0

  1. CPL 1.0(2001年)
    • IBM によって策定
    • 企業でのオープンソース利用を想定した先駆的ライセンス
    • ウィークコピーレフトの概念を導入
  2. EPL-1.0(2004年)
    • CPL をベースに Eclipse Foundation で改良
    • コミュニティ開発により適した条項に調整
    • より明確な言語での記述
  3. EPL-2.0(2017年)
    • GPL互換性の追加(Secondary License)
    • 国際化への配慮
    • より現代的な法的環境に対応

この変遷により、EPLは企業利用とオープンソースコミュニティの両方のニーズを満たすライセンスへと発展してきました。

まとめ

EPLライセンスは、オープンソースコミュニティの利益と企業での実用性を両立させた優れたライセンスです。
ウィークコピーレフトという特性により、改良はコミュニティに還元しつつ、プロプライエタリソフトウェアとの組み合わせも可能にしています。

特にプラグインベースのアーキテクチャを持つソフトウェアや、企業での利用が想定されるライブラリプロジェクトにとって、EPLは理想的な選択肢となるでしょう。EPL-2.0のSecondary Licenseメカニズムにより、さらに柔軟なライセンス戦略も可能になっています。

開発者として、ライセンスの特性を正しく理解し、適切に運用することで、健全なオープンソースエコシステムの発展に貢献できるでしょう。


用語解説

ウィークコピーレフト(弱いコピーレフト):改変した部分のみオープンソース化を要求し、単純な利用や組み合わせではコピーレフトが及ばないライセンス形態。

ストロングコピーレフト(強いコピーレフト):GPLのように、組み合わせたプロジェクト全体にオープンソース化義務が及ぶライセンス形態。

Secondary License:EPL-2.0で導入された仕組みで、著作権者が指定した場合にGPL系ライセンスでの配布も可能にする制度。

プラグインアーキテクチャ:コアシステムに機能を追加するモジュール(プラグイン)を動的に組み込める設計パターン。EPLライセンスとの相性が良い。


この記事は一般的な情報提供を目的としており、法的アドバイスではありません。具体的な法的問題については、専門家にご相談ください。