|
ライセンスとは、コードを入手した後にあなたが持つ権利を詳細に規定したソフトウェア認可文書であり、他者の著作物に対してどのような行為が許され、どのような行為が禁止されているかなどが含まれます。ソフトウェアライセンスは、オープンソースライセンスと商用ライセンスに分けられます。商用ライセンス（法的通知またはライセンス契約とも呼ばれます）の場合、各ソフトウェアには、ソフトウェアの作者または弁護士によって作成された独自の文言が用いられます。ほとんどの人にとって、長々としたライセンス契約を自分で作成するために時間と労力を費やす必要はありません。広く使用されているオープンソースライセンスを選択することが賢明です。
世界には様々な種類のオープンソースライセンスがあり、同じライセンスでも様々なバリエーションが存在します。ライセンスが緩すぎると、著作者は作品に対する多くの権利を失うことになります。一方、厳しすぎると、ユーザーが作品を利用する際や配布する際に不便が生じます。そのため、オープンソースの著作者は、作品に対してどの権利を保持し、どの制限を解除するかを検討する必要があります。 オープンソースライセンスとは何ですか? 1. GPL GPLはGNU General Public Licenseの略です。皆さんがよくご存知のLinuxはGPLを採用しています。GPLの前提は、コードのオープンソース化／フリー利用と、参照／改変／派生コードのオープンソース化／フリー利用ですが、改変・派生コードをクローズドソースの商用ソフトウェアとしてリリース・販売することは認められていません。そのため、私たちは商用企業によるものも含め、様々なフリーLinuxディストリビューションや、個人、組織、商用ソフトウェア企業によって開発された多種多様なフリーソフトウェアを利用できるのです。 最初のバージョンであるGPL1は1989年1月にリリースされました。その目的は、フリーソフトウェアの実現を妨げる行為を防止することでした。これらの行為は主に2つのカテゴリーに分類されます。1つは、ソフトウェア発行者が実際のソースコードを公開せずに実行可能なバイナリコードのみを公開すること、もう1つは、ソフトウェア発行者がソフトウェアライセンスに制限条項を追加することです。したがって、GPLv1では、実行可能なバイナリコードが公開される場合は、読み取り可能なソースコードも公開する必要があり、GPLライセンスの下でソフトウェアをリリースする際に制限条項を追加することはできません。 GPL2は1991年6月にリリースされ、同時に2つ目のライセンスライブラリであるGNU Lesser General Public License (LGPL)もリリースされました。当初はGPLv2との補完性を示すため、バージョン2と名付けられていました。このバージョンは1999年まで使用され続けましたが、その後、派生的なLGPLバージョン2.1がフォークされ、Lightweight General Public License（Lesser General Public Licenseとも呼ばれる）に改名されました。 GPL3は、イブン・モグリン氏とソフトウェア自由法律センターの法的助言を受け、ストールマン氏によって起草されています。2006年2月25日に開催された欧州フリー・オープンソースソフトウェア開発者会議での講演で、ストールマン氏は、すべての変更点の中で最も重要な4つの変更点として、ソフトウェア特許問題への対応、他のライセンスとの互換性、ソースコードの分割と合成の定義、そしてデジタル著作権管理（DRM）問題への対応を挙げました。 GPLライセンスの主な内容は、ソフトウェア製品がGPLライセンスの製品を使用（「使用」とは、ライブラリ参照、改変コード、派生コードを指します）する場合、そのソフトウェア製品もGPLライセンス、つまりオープンソースかつフリーでなければならないというものです。これはGPLのいわゆる「感染性」です。GPLライセンスの製品をスタンドアロン製品として使用することは全く問題なく、フリーであることのメリットを享受できます。しかし、GPLはGPLライブラリを使用するソフトウェア製品もGPLライセンスでなければならないことを厳格に要求しているため、商用ソフトウェアや、GPLライセンスのオープンソースコードを使用したコードに関して機密性を必要とする部門は、ライブラリや二次開発の基盤として統合・採用することは適していません。 2.BSD BSDオープンソースライセンスは、ユーザーに大きな自由を与え、ソースコードを自由に使用・改変し、改変したコードをオープンソースソフトウェアまたはプロプライエタリソフトウェアとして再配布することを許可しています。ただし、この「自由」は、BSDライセンスを適用したコードをリリースする場合、またはBSDライセンスのコードに基づいて独自の製品を開発する場合、以下の3つの条件を満たすことを条件としています。 再リリースされた製品にソース コードが含まれている場合、ソース コードには元の BSD ライセンスが含まれている必要があります。 再リリースがバイナリ ライブラリ/ソフトウェアのみである場合は、元の BSD ライセンスをライブラリ/ソフトウェアのドキュメントと著作権表示に含める必要があります。 オープンソース コードの作成者/組織の名前や元の製品名をマーケティング目的で使用することはできません。 BSD コードはコード共有を推奨しますが、コード作成者の著作権は尊重されなければなりません。 3. マサチューセッツ工科大学（MIT） マサチューセッツ工科大学（MIT）にちなんで名付けられたMITライセンスは、「Xライセンス」または「X11ライセンス」とも呼ばれます。これは、著作権保護と通知のみを提供する簡潔で寛容なライセンスであり、他者にソフトウェアのコピー、変更、統合、公開、配布、ライセンス供与、および/または販売の権利を付与します。ライセンシーは、プログラムの必要に応じてライセンス条項を変更できます。作成者は、その他の制限なしに著作権のみを保持したいと考えています。つまり、バイナリ形式で配布されるかソースコード形式で配布されるかにかかわらず、元のライセンス契約は配布物に含まれている必要があります。 4. MPL MPLはMozilla Public Licenseの略です。よく知られているGPLやBSDライセンスと比較すると、MPLは多くの権利と義務を共有しています（これらはすべてOSIAが認めるオープンソースソフトウェアライセンスであるため）。しかし、MPLには以下の重要な違いもあります。 MPLでは、MPLライセンスの下でリリースされたソースコードへの変更は、他者がMPLの条件の下でソースコードを共有できるようにするために、MPLライセンスの下でライセンスされることが義務付けられていますが、MPLライセンスにおける「リリース」の定義は「ソースコードとしてリリースされたファイル」です。つまり、MPLでは企業が既存のソースコードリポジトリにインターフェースを追加することが許可されています。インターフェースプログラムのソースコードはMPLライセンスの下でライセンスされますが、リポジトリ内のソースコード自体はMPLライセンスの適用を義務付けられることなくライセンスできます。そのため、他者のソースコードを独自の商用ソフトウェア開発に利用できる抜け穴が残されています。 MPL ライセンスの第 3 条第 7 項では、ライセンシーが MPL ライセンスに基づいて取得したソース コードを独自の他の種類のコードと混合して、独自のソフトウェア プログラムを作成することを許可しています。 GPLライセンスとは異なり、MPLライセンスはソフトウェア特許を明確に否定するものではありません。ただし、ソースコードの提供者は、既に特許で保護されているソースコードを提供することはできない（特許権者であり、そのソースコードに対して公衆に無償の書面によるライセンスを付与する場合を除きます）こと、また、オープンソースライセンスに基づいてライセンス供与した後、そのソースコードに関連する特許を申請することもできないことを明確に規定しています。 ソースコードの定義。MPL（バージョン1.1）ライセンスでは、ソースコードは次のように定義されています。「ソースコードとは、改変可能な作品の最も好ましい形態を指します。これには、すべてのモジュールのすべてのソースコード、関連するインターフェースの定義、実行ファイルのインストールとコンパイルを制御する「オリジナル」（文字通り「スクリプト」）、または元のソースコードと実質的に異なるソースコード、あるいはパブリックドメインから入手可能でソースコード提供者によって選択されたプログラムコードが含まれます。」 MPL ライセンスの第 3 条には、ソース コードの変更の記述に関する具体的な規定があり、すべての再配布者はソース コードの変更の時期と方法を記述した専用の文書を用意する必要があります。 5. Apacheライセンス2.0 Apacheライセンスは、著名な非営利オープンソース組織Apacheが採用しているライセンスです。BSDライセンスと同様に、コード共有を奨励し、オリジナル作者の著作権を尊重し、コードの改変と再配布（オープンソースソフトウェアまたは商用ソフトウェアとして）を許可しています。遵守すべき条件もBSDライセンスと同様です。 コードのユーザーには Apache ライセンスが提供される必要がある。 コードを変更する場合は、コードを変更したファイルでこれを指定する必要があります。 拡張コード (変更されたコードおよびソース コードから派生したコード) には、ライセンシー、商標、特許通知、および元の作成者が要求するその他のステートメントが含まれている必要があります。 再発行された製品に通知文書が含まれる場合、その通知文書にはApacheライセンスが含まれている必要があります。通知に独自のライセンスを追加することもできますが、Apacheライセンスの変更を構成するように見えるようにすることはできません。 Apache ライセンスは商業的にも優しいライセンスであり、ユーザーはニーズに合わせてコードを変更し、オープンソースまたは商用製品としてリリース/販売することができます。 6. LGPL LGPL（GPL V2とも呼ばれる）は、主にライブラリ利用のために設計されたオープンソースライセンスです。GPLでは、GPLライブラリを使用、改変、または派生したソフトウェアはすべてGPLライセンスの対象となりますが、LGPLはこれとは異なります。LGPLでは、商用ソフトウェアがリンクを通じてLGPLライブラリを利用することを許可しており、商用ソフトウェアのコードをオープンソース化する必要はありません。そのため、LGPLライセンスのオープンソースコードは、商用ソフトウェアによってライブラリとして利用、配布、販売することができます。 ただし、LGPLライセンスのコードからコードを変更または派生する場合、変更されたコード、変更に関連する追加コード、および派生コードはすべてLGPLライセンスの下でライセンスされる必要があります。したがって、LGPLライセンスのオープンソースコードは、商用ソフトウェアのサードパーティライブラリとして使用するには適していますが、LGPLライセンスのコードを改変および派生によるさらなる開発の基盤として使用することを目的とする商用ソフトウェアには適していません。 GPL と LGPL はどちらもオリジナルの作成者の知的財産権を保護し、他者がオープンソース コードを使用してコピーし、同様の製品を開発することを防ぎます。 オープンソース ライセンスの選択方法: わかりやすくするために、3つの画像を直接見てみましょう。 1. プロトコルの制限は何ですか? 2. 契約承認の詳細: 3. 開発中にプロトコルを選択する方法: Armのライセンスモデルについて: Arm には 3 つの異なるライセンス モデルがあります。 （１）アーキテクチャ／命令セットレベルの認可： これは、Armアーキテクチャを大幅に変更でき、Arm命令セットを拡張または縮小できることを意味します。Appleはその好例です。同社はArmv7-Aアーキテクチャをベースに独自のApple Swiftアーキテクチャを拡張しました。 （２）カーネルレベルライセンス（IPライセンス） これは、コア上に構築し、USART、GPIO、SPI、ADC などの独自の周辺機器を追加して、最終的に独自の MCU を作成する機能を指します。 （３）階層的権限付与を使用する プロセッサを使用するには、使用レベルでのライセンスの取得が最も基本的な要件です。つまり、設計に組み込むことができるのは、他社が提供する定義済みIPのみです。IPを変更したり、そのIPに基づいて独自のパッケージ製品を作成したりすることはできません。 |
