jonaspammer.core_dependencies

以下のテキストを日本語に翻訳します。

// このファイルは .github/workflows/gh-pages.yml によって生成されています - すべてのローカル変更は最終的に失われます！
= ansible-role-core_dependencies
Jonas Pammer <opensource@jonaspammer.at>;
:toc: left
:toclevels: 2
:toc-placement!:
:source-highlighter: rouge


https://galaxy.ansible.com/jonaspammer/core_dependencies[image:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.core_dependencies-brightgreen[バージョン情報]]
// 非常に関連性の高いステータスバッジ
https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml[image:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml/badge.svg[テストCI]]


Ansibleのコアモジュールを適切に実行するために必要なシステムパッケージをインストールするためのAnsibleロールです。具体的には以下のモジュールが含まれます：

* `ansible.builtin.apt_repository`
* `ansible.builtin.archive`
* `ansible.builtin.debconf`
* `ansible.builtin.dnf`
* `ansible.builtin.git`
* `ansible.builtin.subversion`
* `ansible.builtin.unarchive`
* `ansible.builtin.user`
* `ansible.builtin.yum`
* `ansible.posix.seboolean`

このロールはほとんどのシステムのために最新のパッケージキャッシュも確保します。

ほとんどの場合、このロールは私の
https://github.com/JonasPammer/ansible-role-bootstrap[`bootstrap`ロール]と組み合わせて使用することが推奨されます。

[注]
.DISCLAIMER
=====
このロールは https://github.com/robertdebock/ansible-role-core_dependencies/releases/tag/2.1.9[robertdebock/ansible-role-core_dependencies v2.1.9 on GitHub (2022年2月11日)] を基にしています（https://github.com/robertdebock/ansible-role-core_dependencies/compare/2.1.9...master[ここからの変更の比較]）。
（Apacheライセンス 2.0、著作権 Robert de Bock (robert@meinit.nl)）。
現時点では、コードコメントが追加されたもののみです。
=====

toc::[]

[[meta]]
== 🔎 メタデータ
以下に関する情報を見つけることができます：

* このロールに必要なAnsibleのバージョン
* このロールがサポートしているプラットフォーム
* このロールの https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[ロールの依存関係]

.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
  role_name: "core_dependencies"
  description:
    "Ansibleのコアモジュールをサポートするための依存関係をインストールするためのAnsibleロールです。
    robertdebockのcore_dependenciesロールに基づいています。"

  author: "jonaspammer"
  license: "MIT"

  min_ansible_version: "2.11"
  platforms:
    - name: EL # (エンタープライズLinux)
      versions:
        - "9" # 活動的にテスト済み: rockylinux9
    - name: Fedora
      versions:
        - "38" # 活動的にテスト済み: fedora38
        - "39" # 活動的にテスト済み: fedora39
    - name: Debian
      versions:
        - bullseye # 活動的にテスト済み: debian11
        - bookworm # 活動的にテスト済み: debian12
    - name: Ubuntu
      versions:
        - focal # 活動的にテスト済み: ubuntu2004
        - jammy # 活動的にテスト済み: ubuntu2204

  galaxy_tags: []

dependencies: []
----


[[requirements]]
== 📌 必要条件
// このロールやAnsible自体でカバーされない可能性のある前提条件をここに記載する必要があります。
Ansibleユーザーは `become` できる必要があります。

https://galaxy.ansible.com/community/general[`community.general` コレクション]
はAnsibleコントローラーにインストールされている必要があります。

[[variables]]
== 📜 ロール変数
// このロールの設定可能な変数の説明がここに必要です。
// また、ロールのパラメータを通じて設定できるべき変数も含まれます。
// 他のロールやグローバルスコープ（ホスト変数、グループ変数など）から読み取られた変数もここに記載する必要があります。

[[public_vars]]
== 📜 このロールによって定義されたファクト/変数

このセクションにリストされた各変数は、
このロールを実行しているときに動的に定義され（`ansible.builtin.set_facts` を使用してのみ上書き可能）、
内部使用だけでなく、外部でも使用されることを意図しています。

[[tags]]
== 🏷️ タグ

// タスクをタグでグループ化するための素晴らしい例を見たい場合は、https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tagsをチェックしてください。

タスクには以下の https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[タグ] が付けられています：

[cols="1,1"]
|===
|タグ | 目的

2+| このロールには公式に文書化されたタグはまだありません。

|===
 
Ansibleを使用してタスクをスキップしたり、特定のタスクのみを実行したりするためにこれらのタグを使用できます。デフォルトでは、タグが指定されていない場合はすべてのタスクが実行されます。

[[dependencies]]
== 👫 依存関係
// 他のロールのリストをここに記載する必要があります。
// 他のロールに設定する必要のあるパラメータに関する詳細や、他のロールから使用される変数も説明する必要があります。

[[example_playbooks]]
== 📚 使用例のプレイブック
// 一般的なシナリオでこのロールをプレイブックで使用する例を含めることは、ユーザーにとって常に便利です。

[注]
====
このロールは https://github.com/JonasPammer/ansible-roles[
私の多くの目的別ロールの一部です]。

マシンは準備される必要があります。
CIでは、このプロセスは `molecule/resources/prepare.yml` で行われ、
そのソフト依存関係は `requirements.yml` から取得されます：

.link:molecule/resources/prepare.yml[]
[source,yaml]
----
---
- name: prepare
  hosts: all
  become: true
  gather_facts: false

  roles:
    - role: jonaspammer.bootstrap
----

この以下のダイアグラムは、このロールの "ソフト依存関係" と、それらのソフト依存関係の再帰的ツリーの集成です。

image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_core_dependencies.svg[
requirements.ymlの依存関係グラフ]
====

.Minimum Viable Play
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Ansibleによって管理されるlinuxマシンを起動します。
  gather_facts: false

  roles:
    - role: jonaspammer.core_dependencies
-----
====

.More Common Play
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Ansibleによって管理されるlinuxマシンを起動します。
  become: false
  gather_facts: false

  roles:
    - role: jonaspammer.bootstrap
    - role: jonaspammer.core_dependencies
      become: "{{ bootstrap_become | default(omit) }}"
      become_user: "{{ bootstrap_become_user | default(omit) }}"
-----
====


[[tested-distributions]]
== 🧪 テスト済みの配布

ロールは、Red Hat Enterprise Linux (RHEL)のような異なる *配布* で動作する可能性がありますが、この特定の配布に対するテストは行われていません。

|===
| OSファミリー | 配布 | 配布リリース日 | 配布のサポート終了日 | 付随するDockerイメージ

| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 の変種])
| 2021年6月
| 2029年5月
| https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux8-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Rocky
| Rocky Linux 9
| 2022年7月
| 2032年5月
| https://github.com/geerlingguy/docker-rockylinux9-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

| RedHat
| Fedora 39
| 2023年11月
| 2024年12月
| https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-fedora39-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Ubuntu 20.04 LTS
| 2021年4月
| 2025年4月
| https://github.com/geerlingguy/docker-ubuntu2004-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2004-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Ubuntu 22.04 LTS
| 2022年4月
| 2027年4月
| https://github.com/geerlingguy/docker-ubuntu2204-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Debian 11
| 2021年8月
| 2024年6月 (2026年6月 LTS)
| https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian11-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Debian 12
| 2023年6月
| 2026年6月 (2028年6月 LTS)
| https://github.com/geerlingguy/docker-debian12-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]]
|===


[[tested-ansible-versions]]
== 🧪 テスト済みのAnsibleバージョン

テスト済みのAnsibleバージョンは、https://github.com/ansible-collections/community.general#tested-with-ansible[
community.generalコレクションのサポートパターン]に対応しています。
執筆時点では以下の通りです：

* 2.13 (Ansible 6)
* 2.14 (Ansible 7)
* 2.15 (Ansible 8)
* 2.16 (Ansible 9)


[[development]]
== 📝 開発
// このプロジェクトの規約に関するバッジ
https://conventionalcommits.org[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Conventional Commits]]
https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-core_dependencies/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-core_dependencies/master.svg[pre-commit.ciステータス]]

[[development-system-dependencies]]
=== 📌 開発マシンの依存関係

* Python 3.10以上
* Docker

[[development-dependencies]]
=== 📌 開発依存関係
開発依存関係は、https://pip.pypa.io/en/stable/user_guide/#requirements-files[pipの要件ファイル]内で定義されています。
Linuxのためのインストール手順の例は以下の通りです：

----
# "オプショナル": Python仮想環境を作成し、現在のシェルセッションでそれをアクティブにします
$ python3 -m venv venv
$ source venv/bin/activate

$ python3 -m pip install -r requirements-dev.txt
----

[[development-guidelines]]
=== ℹ️ Ansibleロール開発ガイドライン

私の https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[Ansibleロール開発ガイドライン] をご覧ください。

興味があれば、私はいくつかの https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[一般的なAnsibleロール開発（ベスト）プラクティス]を書き留めています。

[[versioning]]
=== 🔢 バージョン管理

バージョンは https://git-scm.com/book/en/v2/Git-Basics-Tagging[タグ]を使用して定義されており、
そのため、Ansible Galaxyで使用されることをhttps://galaxy.ansible.com/docs/contributing/version.html[認識されています]。

*バージョンは `v` では始まってはいけません。*

新しいタグがプッシュされると、https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml[
GitHub CIワークフロー]が
ロールを私のAnsible Galaxyアカウントにインポートする処理を行います。

[[testing]]
=== 🧪 テスト
自動テストは、各貢献の際にGitHubワークフローで実行されます。

テストは主に https://molecule.readthedocs.io/en/latest/[Molecule]を以下の <<tested-distributions,varying set of linux distributions>> に対して実行し、
<<tested-ansible-versions,various ansible versions>> を使用しています。

Moleculeテストには、すべてのAnsibleプレイブックをリンター `https://github.com/ansible/ansible-lint#readme[`ansible-lint`]を使用してのステップも含まれており、最良のプラクティスと改善可能な動作を確認します。

テストを実行するには、コマンドラインで `tox` を実行します。
MoleculeによりスピンアップされるDockerコンテナの配布を定義するために、オプションの環境変数を渡すこともできます：

----
$ MOLECULE_DISTRO=ubuntu2204 tox
----

`MOLECULE_DISTRO` に提供される可能な値のリストについては、link:.github/workflows/ci.yml[]のマトリックスを見てください。

==== 🐛 Moleculeコンテナのデバッグ

1. `MOLECULE_DESTROY=never` オプションを使ってMoleculeテストを実行します。例：
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TASK [ansible-role-pip : (省略).] pass:[************************]
  failed: [instance-py3-ansible-9] => changed=false
...
 pass:[___________________________________ summary ____________________________________]
  pre-commit: commands succeeded
ERROR:   py3-ansible-9: commands failed
----

2. MoleculeでプロビジョニングされたDockerコンテナの名前を確認します：
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   8 minutes ago   Up 8 minutes                                                                                                    instance-py3-ansible-9
----

3. コンテナのbashシェルに入ってデバッグを行います：
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*

root@instance-py3-ansible-2:/#
----
+
[TIP]
====
デバッグしようとしている失敗が `verify.yml` ステップの一部で、実際の `converge.yml` ではない場合は、Ansibleのモジュール（`vars`）、ホスト（`hostvars`）および環境変数がプロビジョナーとDockerマシン内の次のファイルに保存されています：
* `/var/tmp/vars.yml`（`hostvars` キーの下にホスト変数が含まれています）
* `/var/tmp/environment.yml`
必要に応じて `grep`、`cat` するか、ファイルを転送できます！
====
+
[TIP]
=====
上の警告で示されたファイルは、特定のワークフローランの *GitHub CIアーティファクト* に添付されています。+
これにより、実行間の違いを確認することができ、
そのため、ビットロートや全体的なエラーの原因をデバッグするのに役立ちます。

image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]
=====

4. デバッグが終わったら、終了しコンテナを削除します：
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*

$ *docker stop #30e9b8d59cdf#*

$ *docker container rm #30e9b8d59cdf#*
または
$ *docker container prune*
----

==== 🐛 ローカルのインストールパッケージバージョンのデバッグ

tox 3における標準機能ですが、これは https://github.com/tox-dev/tox/pull/2794[今]のみCI変数の存在を認識した場合に発生します。
例えば：

----
$ CI=true tox
----


[[development-container-extra]]
=== 🧃 TIP: コンテナ化された理想的な開発環境

このプロジェクトは、"1クリックのコンテナ化された開発環境" の定義を提供します。

このコンテナは、Docker-in-Docker（dind）の中でDockerコンテナを実行できるようにし、
Moleculeの実行を可能にします。

使用するには：

1. Visual Studio Codeの開発コンテナのリンク：https://code.visualstudio.com/docs/remote/containers#_system-requirements[
   システム要件] を満たすことを確認します。
   必要に応じて、リンク先の___インストール___セクションに従ってください。+
   この内容には、Dockerのインストール、Visual Studio Codeのインストール、必要な拡張機能のインストールが含まれます。
2. プロジェクトを自分のマシンにクローンします。
3. Visual Studio Codeでリポジトリのフォルダーを開きます（_ファイル - フォルダーを開く..._）。
4. 開発コンテナの定義が存在することを知らせるプロンプトが右下隅に表示されたら、付随するボタンを押して入ります。
*そうでない場合*は、Visual Studioのコマンド `Remote-Containers: Open Folder in Container` を自分で実行できます（_表示 - コマンドパレット_ -> _上記のコマンドを入力_）。

[TIP]
====
時々、開発コンテナの特徴は変更を正しく認識しない問題を抱えているため、ここでは `Remote-Containers: Rebuild Without Cache and Reopen in Container` を使うことをお勧めします。
====

[注]
=====
コンテナがSSH/GPGキーを使用できるようにするために、ホストシステムを設定する必要がある場合があります。

手順は、公式の開発コンテナのドキュメントの「コンテナとのGit資格情報の共有」のリンク先に記載されています：https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[]
=====


[[cookiecutter]]
=== 🍪 CookieCutter

このプロジェクトは、
https://github.com/JonasPammer/cookiecutter-ansible-role[元々テンプレート化されたCookieCutter]と同期しておく必要があります。
可能であれば https://github.com/cruft/cruft[cruft] を使用し、必要に応じて手動で変更を加えます。

.公式の `cruft update` 使用例
____
image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[公式の `cruft update` 使用例]
____

==== 🕗 変更履歴
新しいタグがプッシュされると、リポジトリのメンテナーが適切なGitHubリリースを作成することで、タイトルと説明を付けた人間の変更履歴を提供します。


[[pre-commit]]
=== ℹ️ 一般的なリンティングとスタイルの規約
一般的なリンティングとスタイルの規約は、
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*自動的に*標準に従います]
さまざまな https://pre-commit.com/[`pre-commit`] フックによって、少なくともある程度は実施されています。

自動的にpre-commitが各貢献時に実行されます
https://pre-commit.ci/[`pre-commit.ci`]<<note_pre-commit-ci,*>>。
プルリクエストは同じツールによって自動的に修正されることもあり、
少なくともファイルを自動的に変更するフックによって修正されます。

[注]
====
混同しないでください：
一部のpre-commitフックは、構文やコードのフローに関する不具合について警告を出すことができるかもしれませんが（そのため、pre-commitのフックは*テストスイートの一部*です）、
pre-commit自体は実際のテストスイートを実行しません。
テストに関する情報は<<testing>>を参照してください。
====

[TIP]
====
[[note_pre-commit-ci]]
ただし、私はあなたが自分のローカル開発ワークフローにpre-commitを統合することをお勧めします。

これを行うには、クローンしたプロジェクトのディレクトリに移動し、`pre-commit install` を実行します。
そうすると、gitはあなたが行うすべてのコミットに対してpre-commitチェックを実行し、
フックがアラームを発する場合はコミットを中止します。

また、例えば、`pre-commit run --all-files` を実行することで、いつでもpre-commitのフックを実行することもできます。
====


[[contributing]]
== 💪 貢献
https://open.vscode.dev/JonasPammer/ansible-role-core_dependencies[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Visual Studio Codeで開く]]
image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[プルリクエスト大歓迎]

// README.adocに含まれています
:toc:
:toclevels: 3

以下のセクションは一般的な性質のもので、新しい寄稿者を助けるために使用されます。
このプロジェクトの実際の「開発ドキュメント」は<<development>>にあります。

=== 🤝 はじめに
まず、このプロジェクトに貢献しようとしてくれてありがとうございます。

これらのガイドラインに従うことで、あなたがこのオープンソースプロジェクトを管理し、開発している開発者の時間を尊重していることを示すことができます。
その対価として、彼らはあなたの問題に対応し、変更を評価し、プルリクエストを最終化で手助けする際に、その尊敬を返します。

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
このプロジェクトは、多くのファイルを
https://github.com/JonasPammer/cookiecutter-ansible-role[元々テンプレート化されたCookieCutter]に属しています。

考えている編集が実際にテンプレートに適用可能かどうかを確認し、
そうであれば適切な変更をそこで行ってください。
あなたの変更は、テンプレートに部分的に適用可能である場合もあれば、このプロジェクトに特化した部分に適用可能な場合もあります。
その場合、複数のプルリクエストを作成することになります。

=== 💬 一般的なコミット

カジュアルな寄稿者は https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__指定された仕様__]
https://www.conventionalcommits.org/en/v1.0.0/[__によって__]に従うことを心配する必要はありません。
プルリクエストはプロジェクトに1つのコミットとしてマージされます。
プルリクエストの編集が行える権限を持つコア寄稿者のみが、それに従う必要があります。
（自動バージョン決定や変更履歴生成を機能させるため）。

=== 🚀 始め方

貢献は、Issuesおよびプルリクエスト（PR）を通じてこのリポジトリに行われます。
いくつかの一般的なガイドラインは、両方に適用されます：

* 自分自身のものを作成する前に、既存のIssuesやPRを検索してください。
* まだ貢献したことがない場合は、https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
  Auth0ブログの初めての寄稿者ガイド]を確認して、どのように始めるかに関するリソースやヒントを見つけてください。

==== Issues

Issuesは、問題を報告したり、新しい機能をリクエストしたり、PRを作成する前に潜在的な変更について議論するために使用されるべきです。
新しいIssueを https://github.com/JonasPammer/ansible-role-core_dependencies/issues/new[
作成する]ときは、調査に必要な情報を収集し提供するためのテンプレートがロードされます。

あなたが抱えている問題に関するIssueがある場合は、
新しいIssueを作成するのではなく、既存のIssueに自分の再現情報を追加してください。
反応を追加することで、特定の問題が単なる報告者だけでなく、他にも影響を与えていることを保守者に伝えることもできます。

==== プルリクエスト

このプロジェクトへのPRは常に歓迎されており、次のリリースに向けて修正や改善を早く反映させるための素早い方法です。
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[一般的に]、PRは：

* 質問の機能のみを修正または追加するか、広範なホワイトスペース/スタイルの問題に対処するかのどちらかに留めるべきです。
* 修正または変更された機能に対する単体テストや統合テストを追加する（テストスイートがすでに存在する場合）。
* *単一の懸念を扱う*
* *リポジトリ内の文書を含める*
* プルリクエストを作成する際に自動的に読み込まれる完全なプルリクエストテンプレートを伴う。

コア機能に関する変更や破壊的変更を伴う変更（例：メジャーリリース）が必要とされる場合は、
まず提案について議論するためにIssueを開くのが最善です。

一般的に、私たちは "フォークしてプル" Gitワークフローに従います。

1. リポジトリを自分のGitHubアカウントにフォークします。
2. プロジェクトを自分のマシンにクローンします。
3. 簡潔でありながら説明的な名前のローカルブランチを作成します。
4. ブランチに変更をコミットします。
5. このリポジトリ特有のフォーマットやテストガイドラインに従います。
6. フォークしたリポジトリに変更をプッシュします。
7. 私たちのリポジトリにPRをオープンし、変更を効率的にレビューできるようプルリクエストテンプレートに従います。


[[changelog]]
== 🗒 変更履歴
このリポジトリの https://github.com/JonasPammer/ansible-role-core_dependencies/releases[リリースページ] を参照し、このプロジェクトの対応する
https://github.com/JonasPammer/ansible-role-core_dependencies/tags[タグ（バージョン）]の人間向け変更履歴を確認してください。

このプロジェクトはセマンティックバージョニングに従っています。
マイナーバージョンの更新での偶発的な破壊的変更に関しては報告してください。


[[license]]
== ⚖️ ライセンス

.link:LICENSE[]
----
MITライセンス

著作権（c）2022、Jonas Pammer

本ソフトウェアおよび関連ドキュメントファイル（以下「ソフトウェア」という）のコピーを入手したすべての人に、制限なく次の行為を行う権利が無償で付与されます：ソフトウェアを使用、コピー、改変、結合、公開、配布、サブライセンス、販売、およびそのソフトウェアを提供された人に対して行うこと。

上記著作権表示およびこの許可表示は、すべてのコピーまたは著作権表示の重要な部分に含まれるものとします。

このソフトウェアは「現状のまま」提供され、いかなる種類の保証もなく、明示または暗示を問わず商業性、特定の目的への適合性、非侵害に関する保証も含まれません。著作権者または著作権保有者は、契約、過失または他のいかなる請求に関連して、損害やその他の責任について責任を負わないものとします。
---- 

この翻訳は、内容を簡潔かつ理解しやすくし、技術的な情報を保持しています。必要に応じてさらに調整を行うことも可能です。