メインコンテンツにスキップ
オープンソース

オープンソースソフトウェアライセンスの理解

オープンソースソフトウェアライセンスの場合、2つの大きなカテゴリがあります。 一部のライセンスはコピーレフトライセンスのカテゴリに属し、他のライセンスは許可のあるオープンソースライセンスです。

記事のクレジット

マーティン・ドナディュー

ライター

バレリア

レビュアー

ジョーダン

編集者

オープンソースソフトウェアライセンスの理解

オープンソースソフトウェアライセンスについては、2つの大きなカテゴリがあります。 一部のライセンスはコピーレフトライセンスのカテゴリに属し、他のライセンスは許容的なオープンソースライセンスに分類されます。

この記事では、オープンソースソフトウェアライセンスとは何か、またその種類について説明します。

導入

An Open Source License is a type of license that allows users to freely view, modify, and share the source material of the software. This way, users are able to frequently update the source code and build on the original product.

Depending on the Open Source License type chosen, users may or may not be able to do certain activities with the code, such as selling it or using it commercially. In addition, there are many different types of Open Source Licenses out there, each offering different terms and conditions depending on how you want to use the source material.

したがって、オープンソースライセンスの種類を理解するには、十分な情報を得ることが重要です。 したがって、決定を下す前に、以下の情報を参照してください。

オープンソースライセンスの種類

種類

許容的なライセンス

A permissive license, sometimes referred to as a non-copyleft license, grants users permission to use, modify, and share the source code, but users also have the option to change some of those terms and conditions for redistribution, including derivative work. In the context of software, a derivative work is a piece of software that is based on an existing program. If the original was released under a permissive license, a creator can choose to share their derivative work with different terms than what the original work’s license might have required.

オープンソースライセンスのコピーレフト

コピーレフトライセンスは、オープンソースソフトウェアのユーザーに、ソフトウェアを変更、使用、再配布する権利を与えます。ただし、ユーザーは、元のライセンスが与えた権利を、他のユーザーに引き継ぐ必要があります。

Copyleft licenses define how redistribution and changes to the code are allowed, prohibiting any attempts at making it proprietary or non-open. This ensures that developers modifying the software have access to the source code to update it or even incorporate their own changes. Of course, any modifications must also be made available so others can benefit from its open source availability. This is a non-issue for academic or research use-cases, but is often a deal breaker when building commercial software.

オープンソースソフトウェアライセンスを含める理由

オープンソースソフトウェアのライセンスを含めることは、ソフトウェアをオープンソースとして公開または共有する場合に不可欠です。ライセンスは以下の重要な目的を果たします:

  • コラボレーションと革新を促進する。

Open source licenses allow anyone to view, modify, and distribute the source code of your software. This encourages other developers to contribute to your project, fix bugs, and add new features. This can lead to a more robust and innovative software product.

  • ユーザーにコントロールと柔軟性を与える。

オープンソースライセンスは通常、ユーザーがソフトウェアを商用目的で使用、修正、配布できるようにします。これにより、ユーザーがソフトウェアの体験をより制御し、独自のソフトウェアベンダーに依存する必要が減ります。

  • ソフトウェアのコミュニティを構築する。

オープンソースライセンスは、ユーザーと開発者がソフトウェアに情熱を注ぐコミュニティを構築するのに役立ちます。このコミュニティは、サポート、フィードバック、プロジェクトの新しいアイデアを提供できます。

  • ソフトウェアをよりアクセスしやすく包括的にする。

オープンソースソフトウェアは通常、ダウンロードと使用が無料で、複数の言語で利用可能です。これにより、世界中の人々が、収入や背景に関係なく、ソフトウェアにアクセスできるようになります。

さらに、これらの利点の他に、オープンソースライセンスは以下の利点も提供します:

  • 著作権侵害を回避する。

ソフトウェアをライセンスなしで配布すると、著作権侵害訴訟のリスクにさらされる可能性があります。オープンソースライセンスは、ユーザーにソフトウェアの使用、修正、配布の許可を明示的に与え、法的責任から保護することができます。

  • トップの才能を引き付け、保持する。

多くの才能あるソフトウェア開発者は、オープンソースプロジェクトに惹かれています。オープンソースライセンスでソフトウェアをリリースすることで、会社を潜在的な従業員に魅力的な企業にすることができます。

  • ブランドの評判を高める。

オープンソースソフトウェアは、テクノロジー界で広く尊敬されています。オープンソースライセンスでソフトウェアをリリースすることで、協力と革新への取り組みを示すことができます。

oss_licence(1)

許可なしのソフトウェアライセンスは、最も人気のあるものです。実質的には、これらのライセンスはユーザーにソフトウェアを自由に修正および再配布できるようにし、最小限の制限を設けます。許可なしのソフトウェアライセンスの3つの最も人気のあるバージョンは次のとおりです。

MITライセンス

MITライセンス MITライセンスは、最も人気のある許可なしのオープンソースソフトウェアライセンスです。ユーザーに著作権の自由を与え、著作権の条件を遵守する限り、ソフトウェアを自由に共有、修正、使用、商用化できるようにします。 The

Apache License 2.0

Apache License 2.0 Apache License 2.0は、ソフトウェアを自由に変更および再配布できるようにする人気のある許可ソフトウェアライセンスです。ソフトウェアの結果の著作権ステートメントおよび通知が主な形で保持されることを保証するため、ユーザーはソフトウェアを自由に変更および再配布できます。このオープンソースライセンスは、独自の変更と再配布を許可し、ソフトウェアを使用する場合に誰でも自分の権利を理解できるようにする明確なライセンス条項を提供します。

BSD (Berkeley Software Distribution) License

GitHub lets you choose between two BSD licenses, the BSD 2-Clause “Simplified” License, これは “FreeBSD” ライセンスとしても知られています。 BSD 3-Clause “New” or “Revised” License. これらの2つのライセンスの主な違いは、3条項です。この条項では、著者、著者、または貢献者を使用して製品またはサービスを推奨することをソフトウェアユーザーに制限しています。

Boost Software License

Boost Software License, はC++のBoostライブラリから派生し、2008年にOSIによって承認されました。このライセンスは、MITおよびBSDライセンスと似ていますが、バイナリ形式で再配布するときにAttributionを要求していません。

オープンソースライセンス

Copyleft licenses grant software users permission to use, modify, and share the source code, but also protect against relicensing through specific restrictions and terms and conditions. This represents the reciprocal characteristic of this license that requires users’ work to adhere to the original rights outlined in the license.

GNUライセンス コピーレフトソフトウェアライセンスの場合、最も人気のあるものは GPL (General Public License) です。このオープンソースライセンスは、特定の条件を維持する限り、プログラムのコピーと修正されたバージョンを配布するユーザーの自由を許可します。例えば、著作権表示、保証の否認、または追加された未修正プログラムに付加されたライセンスなどです。

By making software available with this license type, developers are ensuring that others have access to their source code, allowing them to make improvements and adaptations that benefit the community. In addition, this concept of “copyleft” ensures that anyone can collaboratively share the same freedoms when working with free software.

Mozilla Public License

Mozilla Public License Mozilla Foundation から と、弱いコピーレフトライセンスとしても考慮される。 このライセンス (Eclipse Public License と比較して) の主な違いは、ファイルベースのコピーレフトであることであり、code はオープンソースまたはプロプライエタリの code と組み合わせることができることを意味します。

Eclipse Public License

Eclipse Public License Eclipse Public License は、Eclipse Foundation から派生し、弱いコピーレフトライセンスとして考慮される。 弱いコピーレフトライセンスは、ソフトウェアユーザーに、変更を加えた __CAPGO_KEEP_0__ を共有することを要求する。 このライセンスは、GNU の General Public Licenses のより厳しい要件に遭遇するユーザーを減らすために、弱いコピーレフトを実装することを選択した。, is from the Eclipse Foundation and is considered a weak copyleft license. A weak copyleft license requires software users to share any changes they make to the code. This license chose to implement a weaker copyleft as a way to reduce the stricter requirements users encountered with GNU’s General Public Licenses.

オープンソースライセンスでプロジェクトを公開する場合、使用しているプロジェクトと互換性のあるライセンスを選択する。

  • 商用目的で他者がプロジェクトを使用できるようにする場合、商用目的を許可するライセンスを選択する。

  • 他者がプロジェクトを変更および配布できるようにする場合、変更および配布を許可するライセンスを選択する。

  • プロジェクトが自由かつオープンソースのままになるようにする場合、コピーレフトライセンスを選択する。

  • 不明な場合は、Open Source Initiative が比較できる人気のライセンスのリストがあります。

  • オープンソースプロジェクトのための正しいライセンスを選択することは重要な決定です。 必要なものと目標を慎重に検討することで、望ましい結果を達成するために役立つライセンスを選択できます。

__CAPGO_KEEP_0__

Capgoの新しいライセンス

それを実現するにはどうすればいいのでしょうか?ライセンスを変更することです。

CapgoはMITライセンスからGNU Affero General Public License V3 (AGPLv3)またはそれ以降のバージョンに変更されました。Capgoのバージョンは ここにあります。.

Capacitor-updater(プラグイン)はLGPLv3からMozilla Public License Version 2.0 (MPLv2)またはそれ以降のバージョンに変更されました。Capacitor-updaterのバージョンは ここにあります。.

この変更は、Capgo CloudのサブスクライバーまたはCapgoを自社でホストしているユーザーには影響しませんが、直接競合するために私のソフトウェアを使用しようとした企業に影響を与えるかもしれません。

AGPLはGoogleが問題にしているライセンスです。Googleは閉鎖ソースのcodeを公開することを拒否しており、 AGPLの目的はユーザーの自由を最大化し、企業にオープンソースへの貢献を促すことです。私はユーザー向けの独立したアプリケーションです。私はライブラリや大きなプロジェクトの一部ではありません。Googleの寄付を求める必要はありません。したがって、AGPLライセンスを採用することに問題はありません。__CAPGO_KEEP_0__のために正しいライセンスです。: “Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google”.

The goal of the AGPL is to maximize user freedom and to encourage companies to contribute to open-source. I’m a user facing, standalone application. I’m not a library or a piece of a bigger project. I’m not looking for Google’s donations, so we’re happy to be AGPL-licensed. It is the right license for Capgo.

: “__CAPGO_KEEP_0__はGNU Affero General Public License (AGPL)の下でライセンスされているため、Googleで使用することはできません。”

オープンソースソフトウェアライセンスを選択する際には、多くの要素を考慮する必要があります。ただし、開発者コミュニティでは、人気のある選択肢があります。許可のある一般的なライセンスには、MITライセンス、Apacheライセンス、BSDライセンスが含まれます。コピーレフトの一般的なライセンスには、GNU一般公衆利用許諾書とMozilla Public Licenseが含まれます。

Open-Sourceソフトウェアライセンスを理解する

あなたは Open-Sourceソフトウェアライセンスを理解する Capgoを使用してライブアップデートの配信を計画する場合、Capgo Live Updatesと接続する Capgo Live Updates for the product workflow in Capgo Live Updates, 概要 概要の実装詳細 機能 機能の実装詳細 アップデートの動作 アップデートの実装詳細について アップデートの種類 アップデートの種類の実装詳細について

Capacitor アプリ用の即時更新

When a web-layer bug is live, ship the fix through Capgo instead of waiting days for app store approval. Users get the update in the background while native changes stay in the normal review path.

ウェブ層のバグが生じた場合、__CAPGO_KEEP_0__ を使用して修正を配信するのではなく、数日間待ってアプリストアの承認を待つのではなく、ユーザーはバックグラウンドで更新を受け取り、ネイティブの変更は通常のレビュー経路を通じて残る。

コンテキスト: ページ/エリア: Capgo マーケティング ウェブサイト。役割: サポートする説明文またはメタ説明文。見つかった場所: コンポーネント GetStarted.astro。Capgo の製品/ブランド名と開発者用語をそのまま保存する。メッセージキー `instant_updates_for_capacitor_apps_description` (Capacitor アプリ用の即時更新の説明)。

最新のブログ

Capgo gives you the best insights you need to create a truly professional mobile app.