⛑️

Minio AGPL rpm

2025/08/22に公開

minio は商用版とAGPLv3版の 2 つのライセンスがあり、Dual licenseの形式になっているとされている。しかし実のところ、全く同じソースコードのプログラムが異なるライセンスで提供されている、というわけではない。ほとんど共通だが異なるソースコードからビルドされた、異なるプログラムのバイナリである。
minio version を実行すると確認できる。
# /server/
minio version RELEASE.2025-07-23T15-54-02Z (commit-id=7ced9663e6a791fef9dc6be798ff24cda9c730ac)
Runtime: go1.24.5 linux/amd64
License: GNU AGPLv3 - https://www.gnu.org/licenses/agpl-3.0.html
Copyright: 2015-2025 MinIO, Inc.

# /aistor/
minio version RELEASE.2025-08-13T17-08-54Z (commit-id=b927b6cd81bc2ba713183f46cf6c938e7b8a6cae)
Runtime:go1.24.6 linux/amd64
License: MinIO Enterprise License
Copyright: 2015-2025 MinIO, Inc.
現在 AIStor と呼称して配布されているプログラムは minio という名前のバイナリだが、これは商用版の minio である。AIStor は商用ライセンスである。minio/aisor（現在は非推奨）は helm チャートで、minio を中心としたプログラムスイートの名称のようだ。
Docker image quay.io/minio/minio は AGPLv3 になっている。github.com/minio/minio のソースコードも AGPLv3 である。
minio の rpm を求めて探し回ると AIStor の案内にすぐにたどり着き、商用ライセンスの rpm が案内される。minio 自身がこのように案内するのはとても納得できる。困るのはその他の有象無象の解説ページも同じように商用ライセンスを案内するところで、単にライセンスに無頓着なんじゃないかという気さえしてくる。素晴らしいことに minio は AGPLv3 版の rpm もきちんと配布している。導線がなかなか見つからないからたどりつけないけれども、やることをちゃんとやってる minio は偉いと思う。
商用版 : https://dl.min.io/aistor/minio/release/linux-amd64/
AGPLv3版 : https://dl.min.io/server/minio/release/linux-amd64/
なぜライセンスを気にしなければならないかという話で、実務的な話はあまり見かけないので、記述しておこうと思う。

 デバッグできるのか何か問題があって、調査しなければならないとき。かつ自分自身がコードを理解できるときは、すぐにでもソースコードを調べ始めるだろう。ただ一度足を止めて頭に置いておかなければならないのは、実際に問題のあった状況とソースコードの間の関係だ。
確実にデバッグを行うには、状況の再現性が大変重要になる。
状況の再現には、同じ状況のバイナリが是非とも欲しい。さらにソースコードから同じバイナリが生まれると期待したい。
ソースコードから同じバイナリが生成されないのであれば、どこかで何か手を加えたせいでバグが発生しているのかもしれない。確実にデバッグしたければ、そういった改変は無いほうが嬉しい。現実にはなかなか難しいのだけれど。
確実に同じバイナリが是非とも欲しいので、「再現性のあるビルド（reproducible build）」を目指したい。SRE の文脈でのリリースエンジニアリングで「密封ビルド」と呼んでいるものになる。
golang で CGO 依存コードが無ければ、reproducable build は実現しやすい。大変ありがたいことに minio/minio の Makefile を使えば自然とそうなる。例えば次のようにする。これが AGPLv3 で minio が配布しているバイナリに最も近く、もっとも信頼できるものとなる。
$ MINIO_RELEASE=RELEASE make
面白いことに minio が配布しているバイナリは、上記で生成されるバイナリと sha256 が異なる。次のように調べられる。前者が AGPLv3 で minio が配布しているバイナリで、後者が手元でビルドしたバイナリである。手元でビルドした binary がより clean なのだろう。実際は、このようにいろいろな理由で、ずれることが多い。
$ diff -u <(go version -m minio) <(cd ../minio && go version -m minio)
--- /dev/fd/63  2025-08-22 11:00:31.932438073 +0900
+++ /dev/fd/62  2025-08-22 11:00:31.932438073 +0900
@@ -1,6 +1,6 @@
 minio: go1.24.5
        path    github.com/minio/minio
-       mod     github.com/minio/minio  v0.0.0-20250723155402-7ced9663e6a7+dirty
+       mod     github.com/minio/minio  v0.0.0-20250723155402-7ced9663e6a7
        dep     aead.dev/mem    v0.2.0  h1:ufgkESS9+lHV/GUjxgc2ObF43FLZGSemh+W+y27QFMI=
        dep     aead.dev/minisign       v0.3.0  h1:8Xafzy5PEVZqYDNP60yJHARlW1eOQtsKNp/Ph2c0vRA=
        dep     aead.dev/mtls   v0.2.1  h1:47NHWciMvrmEhlkpnis8/RGEa9HR9gcbDPfcArG+Yqs=
@@ -253,4 +253,4 @@
        build   vcs=git
        build   vcs.revision=7ced9663e6a791fef9dc6be798ff24cda9c730ac
        build   vcs.time=2025-07-23T15:54:02Z
-       build   vcs.modified=true
+       build   vcs.modified=false

 セキュリティ「再現性のあるビルド」は、デバッグの話にとどまらない。サプライチェーンのセキュリティの話でもある。「実行されているそのバイナリは、本当に信頼しているソースコードから生まれたものですか？」という問いに答えるものでもある。普通は、こっそり改変されてバイナリが配布されても気が付かないだろう。
ソースコードもオープンになっていて、再現性のあるビルドになっていて、誰もが処理内容を確認できるようになっていれば、どこで何が起こったのかは信頼性を持って調べられるだろう。たとえ minio を信頼しなくとも調べて確認できるようになる。
つまり AGPLv3 ライセンスは minio のビジネスを守っているのと同時に、ここで不正が入り込む余地がないという意味で、実は利用者側も守っている。
だからこそ、ライセンスには注意を払っていい。

デバッグできるのか

セキュリティ

Discussion