• Top
  • Web業界の動向・情報
  • これだけは押さえたい！リスクを回避オープンソースライブラリ活用とライセンスの基本
Web業界の動向・情報
投稿日：

これだけは押さえたい！リスクを回避オープンソースライブラリ活用とライセンスの基本

コーディング代行・フロントエンド開発はファストコーディング

WEBサイトやWEBシステムを作るとき、オープンソースライブラリを使うことってよくありますよね。でも、ライブラリにはそれぞれ違ったライセンスがついていて、条件をちゃんと守らないとトラブルの原因になることも。

この記事では、リスクを減らすためのライセンス選びのポイント、避けたほうがいいライセンス、利用時の具体的な方法、そして改変や特許出願をする場合の注意点を分かりやすく説明します。

※本記事は弊社調べとなり、法律的に確実な情報をご提供するものではありません。法務上必要な場合は、必ずご自身や法務部門との確認を済ませるようお願いいたします。本情報により発生した問題について弊社では責任は負いかねます。

1. リスクの少ないオープンソースライセンスはこれ！

オープンソースライブラリを使うなら、以下の利用条件が緩やかなライセンスが安心です。これらは商用利用にも適しています。

おすすめのライセンス

  1. MIT License
    • 特徴: 非常に自由度が高く、商用利用も個人利用も可能。改変や再配布も自由に行えるため、幅広い用途で使われています。開発者にクレジットを与えるために、著作権表示とライセンス文書を残す必要があります。
    • 公式サイト: MIT License
    • 条件: 著作権表示とライセンス文書を残しておく。
    • 例: フロントエンド開発で広く利用される場面に適しています。シンプルで拡張性の高いライブラリやフレームワークに採用されています。
  2. Apache License 2.0
    • 特徴: MITに似ていますが、特許権に関する保証が含まれており、利用者が特許侵害を主張されるリスクを軽減します。また、改変したコードを再配布する際には変更内容を記載する必要があります。
    • 公式サイト: Apache License 2.0
    • 条件: 著作権表示やライセンス文書の保持、変更点の記載。
    • 例: 機械学習やビッグデータ処理の分野で利用されることが多いライブラリに適しています。特に特許に関する保護を重視する場合に安心です。
  3. BSD License (2-Clause, 3-Clause, 4-Clause)
    • 特徴: BSDライセンスは、いずれのバージョンも利用条件が緩やかで、オープンソースプロジェクトや商用プロジェクトで幅広く使われています。
      • 2-Clause版: 著作権表示と免責条項を保持するだけのシンプルな形式で、最も基本的なバージョン。
      • 3-Clause版: 2-Clause版に加えて、「名前や貢献者の情報を広告や宣伝に使用しない」という条件が追加され、商用利用にも安心。
      • 4-Clause版: 「広告条項」が追加され、再配布時に「オリジナル開発者に由来する」旨を明記する必要があるため、他ライセンスとの互換性に制約が出る場合があります。
    • おすすめ: いずれのバージョンも利用に大きな問題はありませんが、3-Clause版が商用利用や再配布時の安心感から最も広く採用されています。
    • 公式サイト: BSD License
    • 条件: 著作権表示と免責条項を残す。
    • 例: ネットワークセキュリティや暗号化の分野で利用されるライブラリに適しています。特に商用利用を含むプロジェクトで採用されることが多いです。

2. 避けたほうがいいライセンス

一部のライセンスは、使う場面やクライアントの意向によってリスクが高いことがあります。

避けたいライセンスとその理由

  1. GNU General Public License (GPL)
    • 理由:
      • 改変や再配布をするとき、システム全体のソースコード公開が必要。
      • クライアントが独占的に利用したい場合には不向き。
  2. GNU Affero General Public License (AGPL)
    • 理由:
      • ネットワーク経由で使うシステム（SaaSなど）でも、ソースコード公開が必須。
      • 商用サービスにはあまり向いていない。

3. ライブラリ利用時の具体的な手順

ライセンス条件を守るために、次のステップをしっかり押さえましょう。

a. 使用ライブラリのライセンス確認

  • 公式のリポジトリやドキュメントでライセンス内容をチェック。
  • 特許に関する条件（例: Apache License 2.0）や公開義務条項（例: GPL）がないか確認。

b. 著作権表示とライセンス文書を残す

  • プロジェクト内にライブラリの著作権表示やライセンス文書を保存。
    • 例: docs/licenses/ フォルダに LICENSE ファイルを配置。

c. クレジットを明記する

  • Webサイトやシステム内でライブラリのクレジットを表示。
    • 例:
      • フッターに「このシステムでは以下のオープンソースライブラリを使用しています」と記載。
      • 利用ライブラリ名とライセンス情報を記載。

4. ライブラリを改変する場合の注意点

ライブラリを一部改変する必要があるときは、以下を確認してください。

a. 改変可能なライセンスを選ぶ

  • MIT, Apache 2.0, BSDのような寛容なライセンスは改変OK。
  • GPLやAGPLのように改変後のコード公開が必要なものは避ける。

b. 改変内容を明確にする

  • どこを改変したのかを明記し、必要に応じてクライアントに説明できるようにしておきます。
  • Apache License 2.0では、改変部分を NOTICE ファイルに記載する必要があります。

c. 改変部分と元コードを分ける

  • 改変した部分をモジュール化して分けておくと、ライセンス適用範囲が分かりやすくなります。

5. 特許出願を考える場合の注意点

オープンソースライブラリを使ったシステムで特許を取る場合、注意点がいくつかあります。

a. ライセンス条件と特許の関係

  1. Apache License 2.0:
    • 特許に関する条項があり、ライブラリ由来の技術を特許として主張するのは制限される場合があります。
  2. GPL/AGPL:
    • 特許を主張するとライセンス違反になる可能性があります。
  3. MIT/BSD:
    • 特許の条項はありませんが、特許の範囲を独自部分に限定するのが望ましいです。

b. 特許の対象を独自技術に限定

  • ライブラリそのものではなく、自分で開発した独自部分（アルゴリズムやインターフェースなど）を特許の対象にします。

c. 特許調査を行う

  • 他社の特許を侵害していないか、専門家に調査を依頼するのがおすすめです。

6. まとめ

オープンソースライブラリを使うときは、以下のポイントを押さえてリスクを避けましょう。

  1. リスクが少ないライセンスを選ぶ:
    • MIT, Apache 2.0, BSD など。
  2. 避けるべきライセンス:
    • GPL, AGPL など、公開義務が強いライセンス。
  3. 利用時の具体的な手順を守る:
    • 著作権表示やライセンス文書を残し、クレジットを明記する。
  4. 改変や特許出願の際は注意する:
    • 改変部分を分けて管理し、特許は独自技術に限定。

また、この記事で紹介した内容はあくまで参考情報です。実際にオープンソースライブラリを利用する際は、公式ドキュメントやライセンス条件を必ず確認し、必要に応じて専門家に相談してください。

オープンソースライブラリを正しく活用して、安心して高品質なシステムを作りましょう！

この記事を見た人がよく見ている記事

SEO