その他 - ソフトウェアライセンス
概要
ソフトウェアライセンスとは、ソフトウェアの使用、配布、修正に関する法的な取り決めである。
開発者や企業が自身のソフトウェアをどのように他者に使用させるかを定義・制御するために使用する。
ライセンスの主な目的を示す。
- 著作権保護
- ソフトウェアの不正使用や複製から開発者を守る。
- 使用条件の明確化
- ユーザがソフトウェアをどのように使用できるかを定める。
- 責任の制限
- ソフトウェアの使用に伴う問題に対する開発者の法的責任を制限する。
主なライセンスの種類を以下に示す。
- プロプライエタリ (独占的) ライセンス
- 商用ソフトウェアでよく使用される。
- ソースコードは非公開である。
- 使用、複製、改変に厳しい制限がある。
- 例: Microsoft Office、Adobe Photoshop
- オープンソースライセンス
- ソースコードが公開されている。
- 使用、複製、改変、再配布が許可されている。
- 主な種類
- GPL (GNU General Public License)
- 派生物も同じライセンスで公開必須
- MIT License
- 比較的制限が少なく、商用利用も可能である。
- Apache License
- 特許権の取り扱いに言及している。
- 例: Linux、WordPress、Python
- フリーウェアライセンス
- 無料で使用可能である。
- ソースコードが非公開の場合もある。
- 商用利用や再配布が制限される場合がある。
- 例: Skype (以前のバージョン)、AVG無料アンチウイルス
- シェアウェアライセンス
- 試用期間後に購入が必要である。
- 機能制限がある場合もある。
- 例: WinZip、WinRAR
ソフトウェアを使用する時は、常にライセンス条項を確認して、遵守することが重要である。
特に、企業や組織でソフトウェアを使用する場合、ライセンスコンプライアンスは法的リスクを回避するために不可欠である。
- 法的保護
- 開発者の権利を守り、不正利用を防ぐ。
- ビジネスモデル
- ソフトウェアの収益化方法を定義する。
- コミュニティ貢献
- オープンソースの場合、開発コミュニティの成長を促進する。
- 互換性
- 他のソフトウェアやライブラリとの統合可能性を決定する。
パブリック・ドメイン
パブリック・ドメインとは
パブリック・ドメイン(公有)とは、ある無体物に関して、著作権や商標権が消滅ないし放棄された状態を指す。
パブリック・ドメインをGNU GPL等と同様のライセンスの一種と勘違いしがちであるが、パブリック・ドメインは状態であって、ライセンスではない。
作者は何の権利も主張しないため、ライセンスを指定する必要もない。
国内では、著作権は譲渡・放棄できるが著作者人格権は放棄できない等の様々な事情があるため、本来の意味でパブリック・ドメインに置くということはできない。
しかし、"一切権利を行使しない"と明確に宣言しておけば、パブリック・ドメイン相当にはなる。
実際そのようにして、ソフトウェアをパブリック・ドメイン相当に置くという開発者はそれなりに多い。
ライセンスの一種としてのパブリック・ドメイン
パブリック・ドメインはライセンスではないが、OSSのライセンスを考える場合、パブリック・ドメインもライセンスの一種と強引にみなすことにより、
以下の4種類のオープンソースライセンスのみを考えるだけでよい。
- タイプ1: パブリックドメイン
- タイプ2: パブリックドメイン + 著作者の権利
- タイプ3: パブリックドメイン + 著作者の権利 + コピーレフト
- タイプ4: パブリックドメイン + 著作者の権利 + コピーレフト + その他
近年では、多くのライセンスが存在しており、その文面は非常に複雑で解釈が困難な言い回しになっていることが多い。
しかし、各ライセンスが上記のどのタイプに属するのかさえ把握すれば理解しやすい。
例えば、BSDライセンスはタイプ2、 GNU GPLはタイプ3ということになる。
著作者の権利
著作権は、著作権者が有する数多くの権利の束として把握されるが、大別すれば、"コピーライト"と"著作者の権利"の2種類に分けられる。
著作権法上は、氏名表示権や同一性保持権など"著作者人格権"として規定されているが、これは"著作者の権利"である。
コピーライトは、著作権法では複製権とそれに付随する様々な権利として規定されている。
しかし、この2つは、ほとんど相互に関連していない。
例えば、コピーライトは著作物の流通を規定、著作者の権利は改変を規定していると言えば分りやすい。
パブリック・ドメインの場合、一切の権利が消滅しているため、著作者の権利も存在せず、改変も流通も完全に自由である。
一方、流通(頒布)の面では、パブリック・ドメインと同様に非常に制限の緩いBSDライセンスでも、著作者の権利は少なくとも部分的には明確に留保されている。
これが、タイプ1とタイプ2の目に見える違いということである。
著作権表示
著作権表示とは
Copyright (c) [年] [著作権者の名前] # 例 Copyright (c) 2024 Taro Yamada
著作権表示は、一般的には、以下に示すような場所に記載する。
- ソースコードの先頭
- 各ソースファイルの先頭にコメントとして記載する。
- READMEファイル
- プロジェクトのルートディレクトリにあるREADMEファイルに記載する。
- ライセンスファイル
- LICENSEやCOPYINGというファイル名で、プロジェクトのルートディレクトリに配置して、その中に著作権表示を含める。
- ドキュメンテーション
- ユーザマニュアルやAPIドキュメント等にも記載することがある。
- Webサイト
- ソフトウェアがWebアプリケーションの場合、フッタ等の適切な場所に表示することもある。
例 : libxml2ライブラリ (MITライセンス)
例えば、libxml2ライブラリ (MITライセンス) を組み込んだプロジェクトを開発する場合、ライセンス条項を遵守するために以下に示すような対応が推奨される。
- ライセンス情報の保持
- libxml2ライブラリのCopyrightファイルの内容を、開発しているプロジェクトのルートディレクトリ等に配置する。
- ただし、ファイル名は、COPYING.libxml2やLICENSE.libxml2のように、libxml2ライブラリと理解できるものにするとよい。
- READMEへの記載
- プロジェクトのREADMEファイルに、libxml2ライブラリを使用していること、および、そのライセンス情報の場所 (例: COPYING.libxml2ファイル) を明記する。
以下に示す対応は、透明性とアクセシビリティを理解またはアクセスしやすくするためのものである。
これらは法的要件というよりは、グッドプラクティスと考えられる。
- ソースコード内での言及
- libxml2ライブラリを使用しているソースファイルの冒頭にコメントにおいて、libxml2ライブラリを使用していることとそのライセンス情報の場所を記載する。
- ドキュメンテーション
- 製品のドキュメンテーションに使用しているサードパーティ製ライブラリとそのライセンス情報を記載するセクションを設ける。
- バイナリ配布の場合
- 製品をバイナリ形式で配布する場合、libxml2ライブラリのライセンス情報を含むドキュメント (例: THIRD_PARTY_LICENSES.txtファイル) を同梱する。
これらの方法を組み合わせることにより、ライセンスの要件を満たし、ユーザが容易にライセンス情報を確認できるようになる。
GPLv2 (GNU General Public License version 2)
世界中で広く使われているオープンソースおよびフリーソフトウェア用のライセンスである。
GPLライセンスのソフトウェアは、誰でも自由に複製して編集することができ、
また、その編集したソフトウェアは自由に配布・販売することも許可されている。
GPLでは、"GPLのライセンス文言をOSSの頒布を受けた人が読めること"、"ソースコードの開示をすること (入手方法も明記)" の2つが条件となる。
GPLライセンスの特徴は、以下の4つである。
- すべて自己責任である。
- 著作権表示の保持する。
- 誰でも複製・改変・再配布・販売ができる。
- GPLライセンスのものをソフトウェアに使用する場合、そのソフトウェアやプログラムのライセンスもGPLライセンスにしなければならない。
ここで最も重要なのは4.である。
編集したGPLライセンスのソフトウェアは自由に配布・販売することが許可されているが、そのソフトウェアもGPLライセンスにしなければならない。
つまり、改変して販売したソフトウェアをさらに配布・販売されても文句は言えないということである。
例えば、開発するソフトウェアに1行でもGPLライセンスのソフトウェアが使用されていれば、そのソフトウェアはGPLライセンスとなる。
ただし、以下に示す条件の場合は、GPLライセンスは適用されない。
- ネットワーク経由でGPLプログラムと協調動作する。
- Webアプリケーションの場合は、GPLライセンスを使用しても公開義務はない。
- 単独で利用するプロセスとしてバンドル。
- GPLのOS上(例えばLinux上)で動作するソフトウェア。
- GPLのシステムライブラリを使用する。
fork
やexec
等を使用して外部コマンドとして実行する (異なるプロセス空間で使用する) 場合、別個のプログラムであるため、GPLライセンスは適用されない。
以上の特徴から、GPLライセンスは"フリーソフトであり続ける"ことが可能になっている。
GPLv2の完全なライセンスファイルは、以下に示すURLから入手できる。
COPYINGファイル
ライセンスファイルとは別にCOPYINGファイルを作成することが推奨される。
COPYINGファイルでは、著作権表示 (Copyright) およびGPLv2について記載する。
- 公開した年
- 複数年に渡る場合は範囲を記載する。
- 例 : 2020-2024
- 著作権者名
- 複数の著作権者がいる場合は、それぞれを記載する。
※注意
GPLv2の場合は、URLではなくFSFの住所を記載する。
# COPYINGファイル Copyright (C) <公開した年> <著作権者名> <メールアドレス> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. # GPLv2の完全なライセンステキストを以下に記載する # ...略
GPLv3 (GNU General Public License version 3)
GPLv3では、頒布時に守るべきこととして、ユーザ製品に含まれるソフトウェアのインストール用情報の提供が求められる。
ユーザ製品とは、個人向けや住宅設置向け (B2C) の利用形態が意図されている製品を指す。
業務用途のみ意図されている工作機械等の製品 (B2B) は該当せず、家電製品や自家用車の車載機等 (B2C) は該当する。
インストール用情報とは、ユーザが改変したソースコードを対象機器にインストールして実行する手段の情報を意味する。
ただし、例外条項として、GCCのライセンスに基づきGCCでコンパイルされたソフトウェアは、GCCのランタイムライブラリをリンクしてもGPLv3を適用しなくてもよい。
GPLv3の完全なライセンスファイルは、以下に示すURLから入手できる。
COPYINGファイル
ライセンスファイルとは別にCOPYINGファイルを作成することが推奨される。
COPYINGファイルでは、著作権表示 (Copyright) およびGPLv3について記載する。
- 公開した年
- 複数年に渡る場合は範囲を記載する。
- 例 : 2020-2024
- 著作権者名
- 複数の著作権者がいる場合は、それぞれを記載する。
# COPYINGファイル Copyright (C) <公開した年> <著作権者名> <メールアドレス> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>. # GPLv3の完全なライセンステキストを以下に記載する # ...略
AGPL
AGPL (Affero General Public License) は、GPLライセンスの条件の他、ネットワーク経由でアクセスしたユーザに対してもソースコードを公開する必要がある。
- ネットワーク使用条項
- AGPLの最も重要な特徴は、ネットワーク経由でソフトウェアを使用するユーザに対してもソースコードを提供する必要がある。
- GPLの継承
- AGPLはGPLの拡張版であり、GPLの全ての条件も含む。
- つまり、派生物の配布時にはソースコードの公開が必要となる。
また、GPLと同様、fork
やexec
等を使用して外部コマンドとして実行する (異なるプロセス空間で使用する) 場合、別個のプログラムであるため、AGPLライセンスは適用されない。
LGPL (GNU Lesser General Public License)
LGPLは、GPLライセンスの制約を緩めたものである。
GPLライセンスとの違いは、以下の1つである。
- 動的ライブラリをリンクして使用する場合、LGPLライセンスを適応させなくてもよい。
開発するソフトウェアにおいて、LGPLライセンスの動的ライブラリを使用する場合、
LGPLライセンスのプログラムを外部ファイルとして使用するならば、LGPLライセンスにする必要はないということである。
ただし、静的ライブラリをリンクして使用する場合、開発するソフトウェアは全てLGPLライセンスとなる。
例えば、以下に示すような成果物があるとする。
- LGPLのライブラリ
- LGPLのライブラリを使用した実行ファイルおよびライブラリ
- 開発者が開発したファイル
- 結合された成果物
- 開発者が開発したファイルとLGPLのライブラリを併せて配布する場合
この時、LGPLライブラリを動的リンクした実行ファイルおよびライブラリを開発する場合は、以下に示すような事柄を守る必要がある。
- 遵守すること。
- 配布物に含まれるLGPLのライブラリの改変を許す。
- 開発者が開発したものも含めて、リバースエンジニアリングを許す。
- LGPLのライブラリを使用していること、および、LGPLのライブラリがLGPL v2.1またはLGPL v3で保護されていることを配布物のファイル群のどこかで告知する。
- 配布物にLGPLライセンス (v2.1、LGPL v3等) の文書を添付する。
- 実行ファイルの実行中にコピーライトの告知を表示する場合は、LGPLのライブラリの著作権の告知、および、LGPLの文書の所在(配布物のどこにあるかということ)を表示する。
- 許可されていること。
- 有償で配布してもよい。 (GPLでも許可されている。(GPL v3 4章))
- インストーラにLGPLのライブラリを含めて二次配布 (再配布) することは可能である。 (商用利用も可能)
- LGPLのライブラリを除く箇所(開発者が開発した箇所)について、再配布を禁止してもよい。
- ソースコードを非公開にしてもよい。
- 改造を禁止してもよい。
LGPLのライブラリをリンク(動的リンクや静的リンクを問わず)した実行ファイルおよびライブラリを開発する場合は、以下に示すようなライセンスファイルを作成する。
- License.txtファイル
- プロジェクトのトップディレクトリ等にLicense.txtファイル等を作成して、自身のソフトウェアのライセンスを記載する。
- ThirdPartyLicenseディレクトリ
- 各ライブラリごとにテキストファイルを作成して、使用しているライブラリのライセンスを列挙する。
使用しているライブラリのライセンスは、ThirdPartyLicenseディレクトリにあるXXX.txtファイルを閲覧するような旨を、README.txtファイル等に記載する。
GPLv3の完全なライセンスファイルは、以下に示すURLから入手できる。
COPYINGファイル
ライセンスファイルとは別にCOPYINGファイルを作成することが推奨される。
COPYINGファイルでは、著作権表示 (Copyright) およびLGPLv2.1またはLGPLv3について記載する。
- 公開した年
- 複数年に渡る場合は範囲を記載する。
- 例 : 2020-2024
- 著作権者名
- 複数の著作権者がいる場合は、それぞれを記載する。
# COPYINGファイル (LGPLv2.1の場合) Copyright (C) <公開した年> <著作権者名> <メールアドレス> This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # LGPLv2.1の完全なライセンステキストを以下に記載する # ...略
# COPYINGファイル (LGPLv3の場合) Copyright (C) <公開した年> <著作権者名> <メールアドレス> This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # LGPLv3の完全なライセンステキストを以下に記載する # ...略
LGPL v3 / LGPL v2.1の共通部分
- アプリケーション本体のソースコード公開は不要である。
- LGPLライブラリ部分のソースコード提供は必要となる。
- ユーザが再リンク可能な形でのオブジェクトファイルの提供が必要となる。
LGPL v3は、よりオープンな利用環境を保証するための追加規定が含まれているが、基本的なソースコード公開の要件は変化していないと言える。
LGPL v3 / LGPL v2.1の違い
"デジタル著作権管理 (DRM)"と"特許"に関する条項の追加、および、より明確な定義付けにある。
例 1 : 組み込み機器での利用 あるメーカーが組み込み機器を開発して、LGPLライブラリを静的リンクして使用する場合 # LGPL v2.1の場合 リバースエンジニアリングの禁止等のハードウェア制限を設けることができる可能性がある。 特許ライセンスの提供についての明確な規定がない。 # LGPL v3の場合 ユーザがライブラリを更新できることを妨げるハードウェア制限を設けることができない。 特許ライセンスの提供が明確に要求される。
例 2 : モバイルアプリでの利用 開発者がスマートフォンアプリを開発して、LGPLライブラリを静的リンクして使用する場合 # LGPL v2.1の場合 App Store等のDRM制限があっても、特に言及がないため問題ない可能性がある。 再リンクの方法の提供について、具体的な規定が少ない。 # LGPL v3の場合 DRM制限がユーザの権利を制限する場合、追加の対応が必要となる。 インストール情報やスクリプト等、再リンクに必要な情報の提供がより具体的に規定されている。
BSD (Berkeley Software Distribution License)
BSDライセンスとは
BSDライセンスは、GPL / LGPLと比較して緩いライセンスである。
BSDライセンスの特徴は、以下の2つである。
- すべて自己責任
- 再配布時には著作権表示を保持する
上記の2つを守れば、複製・改変・再配布・販売が可能である。
BSDライセンスをGPLに変更して再配布すること、ソースコードを非公開にしてソフトウェアを販売することもできる。
ただし、BSDライセンスには、以下の2種類のBSDライセンスが存在する。
- 初期BSDライセンス
- 2条項BSDライセンス
- 著作権を表示すること。
- 無保証であること。
- 修正済みBSDライセンス(3条項BSDライセンス)
- 著作権を表示すること。
- 無保証であること。
- 開発の貢献者(継承元のソースコード開発者)の名前は、事前の許可なしに製品保証や販売促進に使ってはいけない。
- 例. 不可なもの 「この製品は、○○氏が開発したものを改良したものです。」等
- 4条項BSDライセンス
- 開発の貢献者(継承元のソースコード開発者)の名前は、事前の許可なしに製品保証や販売促進に使ってはいけない。
- 著作権およびライセンスを表示すること。
- 宣伝条項を入れること。(ソフトウェアの機能に言及するまたは使用するすべての宣伝物には、次の謝辞を表示する必要がある)
- 例. 「この製品は、○○によって開発されたソフトウェアが含まれています。」等
BSDライセンスは、初期開発者を表示することという条件があるが、これは謝辞のためというよりほとんど広告だった。
後日、その条項が削除された修正済みBSDライセンスが発表されたが、単にBSDライセンスと表記しているソフトウェアも多くある。
この違いに過敏になる必要はないが、BSDライセンスには2種類あるということは留意した方がよい。
2条項BSDライセンス
修正BSDライセンス(2条項BSD)とも呼ばれており、オープンソースのライセンスである。
主な特徴を以下に示す。
- 再配布の条件 (ソースコード形式)
- ソースコードの再配布は、ライセンス通知と免責事項を含める必要がある。
- 再配布の条件 (バイナリ形式)
- バイナリ形式での再配布は、ドキュメントやその他の配布物にライセンス通知と免責事項を含める必要がある。
2条項BSDライセンスは、MITライセンスやApache 2.0ライセンスと同様、非常に寛容なライセンスであり、プロプライエタリソフトウェアでライブラリを使用することを許可している。
ただし、いかなる場合も、著作権表示とライセンスの全文を含める必要がある。
3条項BSDライセンス
3条項BSDライセンス (3-clause BSD license) は、2条項BSDライセンスの前身であり、修正BSDライセンスとしても知られている。
オリジナルのBSDライセンス (4条項BSDライセンス) から派生したものであり、4条項BSDライセンスにあった「謝辞要件」が削除されている。
このライセンスは2条項BSDライセンスとほぼ同じであるが、追加の条項がある。
3条項BSDライセンスは、名前の通り3つの主要な条項で構成されている。
- 再配布の条件 (ソースコード形式)
- 著作権表示の保持
- ライセンス条項のリストの保持
- 免責事項の保持
- 再配布の条件 (バイナリ形式)
- 配布物に付属するドキュメンテーションや他の資料に、上記の著作権表示、ライセンス条項のリスト、免責事項を含めること。
- 宣伝における制限 (これが3条項BSDライセンスの特徴的な条項)
- ソフトウェアから派生した製品の宣伝や販促において、著作権者や貢献者の名前を書面による事前の許可なしに使用してはならない。
- また、ライセンサーの名前や貢献者の名前を、書面での事前の許可なしに、製品の推奨や販促に使用してはならない。
- 例えば、「XYZ社のソフトウェアは、著名なABC大学のプロフェッサーDEFが開発したアルゴリズムを使用しています」といった宣伝文句は、
- 事前に書面での許可を得ていない限り、このライセンス下では許可されない。
- この条項は、書面による事前の許可があれば、名前の使用が可能であることを示唆している。
- 許可を得るプロセスは、一般的に、著作権者や貢献者に直接連絡を取ることを含む。
2条項BSDライセンスとの主な違いは、3つ目の条項 (宣伝における制限) が存在することであり、これは「非承認条項」や「宣伝禁止条項」とも呼ばれている。
- <YEAR>
- 製作年を入力する。
- <COPYRIGHT HOLDER>と<OWNER>
- 著作権者の名前を入力する。
- <ORGANIZATION>
- 団体名を入力する。
- 個人の場合は、<copyright holder>や<owner>と同義に扱えるため、同じ名前を入力してもよい。
# 原文 Copyright (c) <YEAR>, <OWNER> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
# 和訳 Copyright(c) <YEAR>、 <OWNER> 著作権所有 次の条件が満たされていれば、ソースおよびバイナリ形式での再配布および使用は、変更の有無にかかわらず許可されます。 * ソースコードの再配布には、上記の著作権表示、この条件リスト、および以下の免責条項を保持する必要があります。 * バイナリ形式の再配布は、上記の著作権表示、この条件一覧、および以下の免責条項を、配布に付属のドキュメントおよび/またはその他の資料に複製する必要があります。 * 特定の書面による事前の許可なしに、このソフトウェアから派生した製品を推薦または宣伝するために、<ORGANIZATION>の名前またはその貢献者の名前を使用することはできません。 本ソフトウェアは、著作権者および寄稿者によって「現状のまま」提供され、商品性および特定の目的への適合性を含む黙示の保証を含みますが、明示または黙示の保証はされず、 免責<COPYRIGHT HOLDER>は、直接的、間接的、偶発的、特別、懲罰的、派生的損害(代替商品やサービスの調達を含むが、これに限定されない。使用、データ、または利益の喪失; (たとえこのような損害の可能性について知らされていたとしても)、いかなる責任も負いません。 また、本ソフトウェアの使用中に生じるいかなる損害についても責任を負わないものとします。
4条項BSDライセンス
4条項BSDライセンスは、3条項BSDライセンスの前身であり、オリジナルのBSDライセンスとしても知られている。
このライセンスは3条項BSDライセンスとほぼ同じ構造を持つが、追加の条項が含まれている。
4条項BSDライセンスの主な特徴を以下に示す。
- 再配布の条件
- 3条項BSDライセンスと同様、ソースコード形式およびバイナリ形式での再配布に関する条件が含まれる。
- これには著作権表示の保持、ライセンス条項のリストの保持、免責事項の保持が含まれる。
- 宣伝における制限
- 3条項BSDライセンスと同様、宣伝における制限が設けられている。
- これは、ソフトウェアから派生した製品の宣伝や販促において、著作権者や貢献者の名前を書面による事前の許可なしに使用することを禁じるものである。
- 謝辞要件 (4条項BSDライセンスのみ)
- ソフトウェアの使用に関する全ての宣伝資料において、特定の謝辞を含めることを要求する。
- 具体的には、「This product includes software developed by the organization」のような文言を含める必要がある。
謝辞要件は、ソフトウェアの開発元への適切な認識を確保することを目的としている。
しかし、多くのプロジェクトが関与する場合、謝辞リストが長くなりすぎる問題が生じたため、
これらの理由から、後に3条項BSDライセンスが作成されて、「謝辞要件」が削除された。
3条項BSDライセンスは、この問題を解決しつつ、オリジナルのライセンスの主要な特徴を維持している。
現在では、4条項BSDライセンスは現在ではあまり使用されていないが、オープンソースライセンスの歴史において重要な役割を果たした。
MIT License
MITライセンスは、上記の修正済みBSDライセンスと同様の条件になる。
X11ライセンスやXライセンスと呼ばれることもある。
開発者を記載、および、開発者に一切の責任を求めない限り自由に扱うことができる。
- 無保証(全て自己責任)である。
- 再配布時には著作権表示および本許諾表示する。(ソースコード内に記述してもよい)
上記の2つを守れば、自由に使用することが可能である。
MIT Licenseのライブラリまたはヘッダファイルを同梱してソフトウェアを配布する場合の注意点を、以下に示す。
- ソフトウェアのソースコードのみを配布する場合
- MIT License条項がソースコードファイル内にコメントとして記述されているならば、MIT License条項下のソースコードと一緒に表示されることになるため、
- ライセンス条項を満たすことになる。
- ソフトウェアのバイナリを配布する場合
- MIT Licese条項が記述されたコメントはコンパイル時に削除されるため、ライセンス条項を満たさないことになる。
- そのため、テキストファイルまたはソフトウェア上でのダイアログ表示により、MIT License条項をバイナリと合わせて配布する必要がある。
- 例 :
- インストールメディアのトップディレクトリにLicensesという名前のディレクトリを作成する。
- そのディレクトリ下に各ライブラリの名前のディレクトリを作成して、各ライブラリのLICENSE.MITファイルをコピーする。
Apache Software License 2.0
LICENSE / LICENSE.txt
まず、以下に示すURLからApache 2.0ライセンスをダウンロードする。
curl -OsS https://www.apache.org/licenses/LICENSE-2.0 # .txt拡張子をダウンロードする場合 curl -OsS https://www.apache.org/licenses/LICENSE-2.0.txt
次に、ダウンロードしたファイルの下部にあるCopyright 〜の箇所を編集する。
括弧[]で囲まれたフィールドを著作者自身の識別情報で置き換える。 (括弧は含めないこと)
Copyright <西暦 例: 2024> <著作者 例: Taro Yamada> Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
NOTICEファイル
Apache 2.0ライセンスのライブラリを改変して配布する場合は、その旨を表示する必要がある。
NOTICEファイルが必要になる条件として、以下に示すような特定の状況に該当する場合である。
基本的には、Apache 2.0ライセンスを適用している他のライブラリを取り込む場合に意識する必要がある。
- NOTICEが必要な場合
- 他のApache 2.0ライセンスのソースコードを組み込む場合、または、独自の通知が必要な場合
- 不要な場合
- 自身がフルスクラッチで作成したソースコードのみで、通知すべき特別な情報が無い場合
NOTICEファイルは法的義務というよりも、配布物に必要な通知をまとめる役割を果たす。
そのため、必要に応じて作成するのがよい。
他のApache 2.0ライセンスのソースコードを組み込む場合
Apache 2.0ライセンスのソースコードを自身のプロジェクトに組み込む場合、そのプロジェクトにNOTICEファイルが存在すれば元のプロジェクトで指定されているNOTICEファイルを引き継ぐ必要がある。
具体的には、元のプロジェクトにNOTICEファイルが存在する場合、その内容をそのまま新しいNOTICEファイルに記載する。
例えば、他のライブラリにおいて、以下に示すようなNOTICEファイルがあったとする。
This product includes software developed by John Smith https://www.example.com/
この時、自身のNOTICEファイルにこの記載をそのまま含める。
自身のプロジェクトで独自の通知事項がある場合
もし自身のプロジェクトにおいて、特定の著作権表示や追加の通知が必要な場合は、NOTICEファイルを作成して記載する。
- 特定の商標やブランドを利用する許可が付属している場合
- プロジェクトが特定の組織に関連していることを通知する必要がある場合
# 例: This product includes software created by Taro Yamada.
配布物に関連する重要な通知を含める必要がある場合
NOTICEファイルは、配布物の一部として通知が必要な情報を提供するために使用する。
- 再配布するソフトウェアが特定の商標やロゴの使用を伴う場合 (例: プロジェクトにロゴ画像が含まれている場合)
- 著作権者や貢献者から指定された通知が必要な場合
NOTICEが不要な場合
- 自身でゼロからフルスクラッチしたソフトウェアであり、第3者のApache 2.0ライセンスコードや他の通知事項が無い場合、NOTICEファイルを作成する必要はない。
- 自身のプロジェクトに通知すべき特別な情報が無い場合
実際のプロジェクト例
- シンプルなプロジェクト (NOTICE不要)
- 内容
- 自分で開発したコードのみ
- 必要なファイル
- LICENSEファイル (Apache 2.0ライセンス全文) とソースコードのヘッダのみ
- 内容
- 他プロジェクトのソースコードを利用する場合 (NOTICE必要)
- 内容
- 他のApache 2.0ライセンスのライブラリを使用 (例: ライブラリA)
- 対応
- 元のライブラリAにNOTICEファイルが含まれている場合、それを自身のプロジェクトのNOTICEファイルにコピーして含める。
- 追加の通知事項があれば追記する。
- 内容
- 独自の特別な通知を行う場合 (NOTICE必要)
- 内容
- 商標、著作権その他の通知が必要
- 対応
- NOTICEファイルを作成して、通知内容を記載
- 内容
NOTICEファイル記載例
# 基本的な例 This product includes software developed by Taro Yamada (https://www.example.com).
# 他プロジェクトの通知を含む場合 This product includes: - Software developed by Taro Yamada (https://www.example.com). - Software developed by Original Author/Organization (https://www.other.org/).
特許条項
- 配布されているOSSの中に特許が含まれていたら、それは無償で自由に実施してよい。
- 自身の特許がそのOSSに含まれていると主張した場合、そのOSSは使用できない。
MPL (Mozilla Public License) ライセンス
MPL 2.0ライセンス
MPL 2.0は、オープンソースソフトウェアのためのライセンスである。
Mozilla Foundationにより作成されて、2012年に公開された。
MPL 2.0の主な特徴として、コピーレフト条項の緩和が挙げられる。
これにより、MPLでライセンスされたコードをプロプライエタリなソフトウェアと組み合わせて使用することが可能になる。
ただし、MPLでライセンスされた部分については、ソースコードを公開する必要がある。
また、商用利用を許可しており、特許権の明示的な付与も含んでいる。
これにより、ライセンス利用者は、コントリビュータが所有する特許をそのソフトウェアの使用に関して無償で利用できる。
LGPLライセンスと同様、動的ライブラリをリンクして使用する場合、MPLライセンスが適用されない。
- コピーレフト条項
- MPL 2.0は「ファイルレベルのコピーレフト」を採用している。(ファイル単位でのライセンス適用を許可している)
- これは、MPLでライセンスされたファイルの変更部分のみをMPLで公開する必要があるが、プロジェクト全体をMPLにする必要がないことを意味する。
- 例えば、プロジェクトに新規ファイルを追加する場合は、異なるライセンスを選択することができる。
- 特許ライセンス
- MPL 2.0は特許に関する明示的な条項を含んでおり、
- コントリビュータからのソフトウェアに関連する特許の使用権をユーザに自動的に付与する。
- 配布条件
- ソースコードを利用可能にする必要がある。
- ライセンスのコピーを含める必要がある。(オリジナルのライセンス条項を維持する)
- 著作権表示を保持する必要がある。
- ソースコードの変更
- 変更を加えた場合、その旨を明確に示す必要がある。(変更内容を明確に示す必要がある)
- また、変更を加えた部分はMPLライセンスで公開する。
- 商標の扱い
- ライセンスは商標権を付与しない。
- 保証の否認と責任の制限
- ソフトウェアは現状のまま提供され、法律で許される範囲で保証は否認される。
- 互換性
- MPL 2.0は、Apache License 2.0やGPL 3.0等、他の主要なオープンソースライセンスとの互換性も考慮されている。
- これにより、異なるライセンスのコードを組み合わせて使用することが可能である。
- 複数ライセンス
- MPLでライセンスされたコードを他のライセンスの下で再ライセンスすることが可能である。
- 寄稿者の定義
- コードを変更または追加した人を「寄稿者」として定義しており、その権利と責任を明確にしている。
- 準拠法
- 特定の準拠法は指定されていないが、ライセンスの解釈に関する紛争解決のメカニズムが含まれている。
MPLライセンスは、LGPLライセンスとBSDライセンスの中間のような条件となっている。
MPLライセンスのソフトウェアまたはソースコードを別ファイルとして使用する場合、MPLライセンスは開発するソフトウェアにまで影響しない。
例えば、MPLライセンスのソフトウェアを使用する場合、そのプログラムが独立して1つのファイルとなっている状態であれば、
開発するソフトウェアをMPLライセンスにする必要はない。
CC(Creative Commons)
CCライセンスは、著作物全般に使用できるライセンスである。
CCライセンスの特徴は、"著作権者のクレジット表記"のみが絶対条件とされており、
他の3つの使用条件を組み合わせることで、著作権者の希望に沿ったライセンスを明示できる。
以下に、CCライセンスの4つの使用条件を示す。
- 著作権者のクレジット表記義務
- このアイコンが表示されている場合、原著作権者のクレジットを明記しなければならない。
- 非営利の場合のみ使用許可
- このアイコンが表示されている場合、この作品を営利目的で利用してはならない。
- 改変の禁止
- このアイコンが表示されている場合、この作品を改変・変形または加工してはならない。
- 同一条件の継承義務
- このアイコンが表示されている場合、この作品を改変・変形または加工した場合、その制作物をこの作品と同一の許諾条件でのみ、頒布することができる。
CCライセンスはクレジット表記が絶対条件であるため、Webサイトの制作において、使用が難しいライセンスである。
無料配布されているファイルにおいても、CCライセンスのものが多いため、使用する場合は著作者のクレジットを表記しなければならない。
Boostソフトウェアライセンス
全ての人もしくは組織に対し、このライセンスで保護されたソフトウェアおよび添付されるドキュメント(以下「ソフトウェア」)のコピーを取得し、
ソフトウェアを利用、複製、表示、頒布、実行、伝送すること、ソフトウェアの派生成果物を作成すること、ソフトウェアを提供された第三者に同様の権利を与えることに対する許可が無料でここに与えられる。
全ては以下の条件に従う。
ソフトウェアとこの条文全ての著作権表記(上記のライセンス許可とこの制約、次の免責事項を含む)を、ソフトウェアの全体あるいは一部のあらゆるコピーあるいはソフトウェアの全ての派生成果物に含めなければならない。
ただし、そのようなコピーあるいは派生成果物が、単にマシン上で実行可能なオブジェクトコードの形でソース言語処理器によって生成された場合は除く。
ソフトウェアは「あるがまま」に提供され、いかなる保証もない。
これには、明示的か暗黙的かを問わず、商業性の保証や特定の目的、タイトル、非侵害性に対する適合性も含まれるが、それに限定するものではない。
契約、不法行為、その他に関わらず、著作権者あるいはソフトウェアを頒布するいかなるものもソフトウェアの使用やその他の扱いから発生または発展、関連する、一切の損害や他の法的責任に対する法的義務を負わないものとする。
ISCライセンス
ISC (Internet Systems Consortium) ライセンスは、非常に簡潔で読みやすく、比較的自由度が高いオープンソースライセンスの1つである。
「ベルヌ条約によって不要となる言い回し」を取り除いた2条項BSDライセンスと機能上同等である。
ISCライセンスの下でライブラリを使用する場合、以下の条件が必要となる。
- 著作権表示の保持
- ISCライセンスでは、著作権表示を残すことが義務付けられている。
- ライセンスファイル、コード内の著作権表示、ドキュメンテーション等、ライブラリを含むソフトウェアの全ての部分で、著作権表示を保持する必要がある。
- 免責事項の表示
- ISCライセンスには免責事項が含まれており、ライブラリの使用に関するあらゆる責任を負わないことが明記されている。
- 使用者は、この免責事項を理解して、ライブラリを自己責任で使用する必要がある。
- ライセンスの再配布
- ISCライセンスでは、ライセンス条項を再配布することが必要となる。
- ライブラリを再配布する場合は、著作権表示とライセンス条項 (免責事項を含む) を含める必要がある。
ソースコードを改変した場合は、特にその変更を明示しなくともよい。
これは、BSDライセンスやMITライセンスなど他のパーミッシブライセンスと同様である。
ISCライセンスは、商業利用を含むほぼ全ての用途でソフトウェアの使用、修正、配布を許可している。
派生物を作成する場合は、異なるライセンス (プロプライエタリなものを含む) で配布することが可能である。
また、特許に関する明示的な条項はない。
OpenSSLライセンス
OpenSSLライセンスは、OpenSSLプロジェクトが開発したソフトウェアに適用される特殊なライセンスである。
このライセンスは、オリジナルのSSLeayライセンスとApache License 1.0を組み合わせて作成された。
OpenSSLライセンスの主な特徴は、ソフトウェアの自由な使用、修正、再配布を許可しつつ、一定の条件を課していることである。
OpenSSLライセンスの下でライブラリを使用する場合、以下の条件が必要となる。
- 著作権表示の保持
- OpenSSLライセンスでは、著作権表示を保持することが義務付けられている。
- 再配布する場合には、オリジナルの著作権表示を含める必要がある。これは、ソースコード、バイナリ形式、ドキュメンテーションなど、配布されるすべての形式に適用される。
- 免責事項の表示
- OpenSSLライセンスには明確な免責事項が含まれており、ソフトウェアの使用に関する一切の保証を否定している。
- 使用者は、この免責事項を理解し、OpenSSLを自己責任で使用する必要がある。
- 広告条項の遵守
- OpenSSLライセンスには「広告条項」が含まれており、OpenSSLを使用して作成された製品のプロモーション資料に、OpenSSLプロジェクトへの謝辞を記載することを要求している。
- ただし、この条項は書面による許可があれば省略することができる。
- ライセンスの再配布
- OpenSSLライセンスでは、ライセンス条項を再配布することが必要となる。
- OpenSSLを再配布する場合は、オリジナルのライセンス条項 (著作権表示、免責事項、広告条項を含む) を含める必要がある。
- 派生物の取り扱い
- OpenSSLライセンスは、派生物に対する制限が比較的緩やかである。
- OpenSSLを改変したソフトウェアを、別のライセンスで配布することも可能であるが、オリジナルのOpenSSLライセンスの条項も遵守する必要がある。
OpenSSLライセンスは、商用利用も許可しており、企業がOpenSSLを自社製品に組み込んで販売することが可能である。(ただし、ライセンス条項を遵守する必要がある)
ただし、OpenSSLライセンスは複雑で理解しづらい面もあり、法的な解釈が難しい場合がある。
そのため、OpenSSLを使用する場合は、ライセンスの詳細を慎重に確認して、必要に応じて法律の専門家に相談することが推奨される。
このライセンスは、暗号化やセキュリティ関連のソフトウェア開発において広く使用されているが、その複雑さゆえに、近年ではより単純なライセンスへの移行を検討する動きもある。
Unlicense
Unlicenseは、ソフトウェアライセンスの中でも特に自由度の高いものとして知られている。
このライセンスの主な目的は、ソフトウェアを可能な限り制約のない形で公共領域に置くことである。
Unlicenseの最も特徴的な点は、著作権の完全な放棄である。
このライセンスを適用したソフトウェアの著作者は、自身の作品に関する全ての著作権および関連する権利を放棄し、公共領域に譲渡する。
これにより、ソフトウェアの使用者は、著作権法による制約を受けることなく、そのソフトウェアを自由に扱うことができる。
- 著作権放棄
- Unlicenseは、著作権を完全に放棄することを目的としている。
- 著作者は、ソフトウェアに関するすべての著作権および関連する権利を公共領域に譲渡する。
- 制約の不在
- Unlicenseでは、ソフトウェアの使用、複製、変更、配布、サブライセンス、販売に関する制約を一切設けていない。
- 使用者は、ソフトウェアを自由に扱うことができ、著作権表示や許可の明示を必要としない。
- 免責事項の表示
- Unlicenseには明確な免責事項が含まれており、ソフトウェアの使用に関するあらゆる保証を否定している。
- 使用者は、この免責事項を理解し、ソフトウェアを完全に自己責任で使用する必要がある。
- ライセンスの再配布
- Unlicenseでは、ライセンス条項の再配布は必須ではない。
- ただし、法的な明確性を確保するために、Unlicenseのテキストを含めることが推奨される。
- 著作者名の扱い
- Unlicenseでは、著作者名の表示や保持を要求していない。
- 使用者は、著作者名を削除したり、自身の名前に置き換えたりすることが可能である。
しかし、このような極端な自由度は、法的な観点から見ると課題を抱えている可能性がある。
これは、著作権を完全に放棄することが法的に可能かどうかは、国や地域によって異なるからである。