@yam_asaki(山崎進)

Redmineとプラグインのライセンスに関してGeminiに聞いてみた（2）

Posted at 2025-12-13

Redmineとプラグインのライセンスに関してGeminiに聞いてみた（２）

Redmine Advent Calendar 2025

今回の記事は下記の「Redmine Advent Calendar 2025」の12/11の記事として作成しました。

12/10は遠藤裕之さんの「Redmine 6.1.0リリース（2025年9月）ファーエンドテクノロジーによるRedmineへの開発協力」という記事でした。

急に寒くなり今年も残り数日です。今年もRedmine Advent Calendarの時期になりました。Advent Calendarに参加してRedmine界隈を盛り上げていけたらと思っています。

Geminiを使ってRedmineのライセンの調査

RedmineはOSSでできており、その使用に関してはGPLv2ライセンスで提供されています。
RedmineとGPLv2ライセンスの関係をいくつかの観点からGeminiに質問をしてみました。
なお、この記事はGeminiの回答を元にしており、法律的な観点が含まれるため、その真実性に関しては著者はいかなる責任も負いません。法律の解釈の問題が発生するため、正確な情報が必要な方は弁護士など専門家の方にご確認ください。
前回に続けてGeminiを使ってRedmineのライセンの調査をしてみました。

プログラムソースの公開方法に関して

質問５

「公開プラグインがRedmineのコードを含む派生著作物となるため、
プラグインのソースコード全体を、その利用者に提供する義務があります。」
とのことですが、公開方法の制限はありますか？
例えばプログラムソースを印刷をしてオフィス内で公開をしても
公開義務を果たしたことになりますか？
公開とは相手方にプログラムソースを閲覧可能な状態にすることを意味しますか？

ご質問の意図は、GPLにおける「ソースコードの提供義務」を、どれだけ形式的に満たせば良いのかという点ですね。

GPLライセンスは、ソースコードの提供方法について、柔軟性を持たせつつも、利用者が実質的にソースコードを入手し、改変や再配布に利用できる状態を求めています。

1. GPLが求めるソースコードの提供方法

GPLv2やGPLv3には、ソースコードの提供方法に関する具体的な規定があります。特に重要なのは、配布されるソースコードが**「対応するソースコード (Corresponding Source)」**であることです。

対応するソースコードとは: オブジェクトコード（実行形式のプログラム）を再生成したり、必要に応じて改変を加えたりするために使用できる、プログラムの優先される形式を指します。これには、すべてのモジュール、インターフェース定義ファイル、コンパイルやインストールに使用されるスクリプトなどが含まれます。
「閲覧可能な状態」以上の要求: 単にプログラムソースを閲覧できるだけでは、GPLの要求を満たしたことにはなりません。利用者がそれを入手し、自身のコンピューターに保存し、改変し、そして再コンパイルできる必要があります。

2. ご提示の公開方法に対する評価

提案された方法	GPLの要件を満たすか	理由
プログラムソースを印刷してオフィス内で公開する	満たしません。	印刷物では、利用者が簡単にソースコードをコンピューターに取り込み、改変、コンパイル、再配布に利用することが極めて困難です。「優先される形式」ではないため、GPLの要求を満たさないと解釈されます。
公開とは相手方にプログラムソースを閲覧可能な状態にすること	不十分です。	閲覧できるだけでなく、利用者が容易に取得・利用できる電子的形式（例：ダウンロード可能なファイル）で提供することが必要です。

3. 一般的なソースコードの提供方法

GPLの義務を果たすための一般的な方法（安全な方法）は以下の通りです。

物理的な配布（非推奨）: プログラムの実行形式をCDやUSBメモリなどで配布する場合、同じ媒体にソースコード（例：ZIPファイルなど）を含めて配布する。
ダウンロード提供 (最も一般的):
- プログラム配布時に、ソースコードがダウンロードできるURLを明記する。
- そのURLからソースコードの完全なアーカイブ（tar.gz、zipなど）をダウンロード可能にしておく。
書面による提供の申し出: GPLv3では、ソースコードの入手方法を書面で通知すること（例：有料でデータメディアにコピーして送付する旨を申し出る）も認められていますが、これはウェブサイトなどで簡単にダウンロードできるようにする方法よりも複雑で、一般のプラグイン販売ではあまり使われません。

結論として、利用者が手間なくデジタル形式でソースコードをダウンロードし、再利用できる状態にすることが、GPLの提供義務を果たすための実質的な要求となります。

公開の義務に関して

質問６

書面による提供の申し出があった場合のみ、ダウンロード可能なURLを提示しても
公開の義務を果たしたことになりますか？

書面による提供の申し出があった場合のみダウンロード可能なURLを提示する方法が、GPLの公開義務を果たすかどうかは、GPLのバージョンによって扱いが異なりますが、一般的には認められる方法の一つです。

特に、配布された実行形式（オブジェクトコード）に対して、ソースコードの提供を求める旨の書面による申し出を受け付け、それに応じてソースコードを提供するという形態が、GPLによって明示的に認められています。

GPLv2とGPLv3の規定

GPLバージョン	提供方法の規定
GPLv2	オブジェクトコード（実行形式）に付随して、ソースコードの提供方法を書面で申し出ること（書面による提供の申し出）が認められています。これに基づき、申し出があった者にソースコードを提供することで義務を果たせます。
GPLv3	GPLv2の書面による提供の申し出に加え、ネットワークサーバーからのダウンロード提供（例：URLを提示する）も、提供方法の一つとして明確に認められています。

「書面による提供の申し出」の解釈

あなたが検討されている方法は、以下のステップを踏むことになります。

プラグインの配布時:
- プラグインの実行形式（オブジェクトコード）と一緒に、ソースコードの入手方法を書面で通知します。
- この通知には、「ソースコードが必要な場合は、所定の連絡先へ書面で申し出てください」といった文言と、申し出の宛先を含めます。
- これは、多くの場合、GPLライセンス文書自体、またはそれに付随するドキュメントに記載されます。
申し出があった場合:
- 購入者や受領者から書面による申し出があった際に、ソースコードがダウンロードできるURLを提示する（または、データメディアにコピーして送付する）ことで、提供義務を果たします。

まとめ

書面による申し出があった場合のみURLを提示する方法は、GPLが定めるソースコード提供義務の形式の一つとして有効です。

ただし、現代のソフトウェア配布では、プログラムと一緒に常にダウンロード可能なURLを提示しておく方が、利用者にとって最も便利であり、トラブルを避ける上でも主流となっています。

この方法を採用する場合は、GPLライセンス文書内の要求事項を正確に守っているかを、念のため専門家と確認することをお勧めします。

プログラムソースに関して

質問７

redmineはrailsでできているため、提供されるプログラム自体に
プログラムソースが平文で書かれています。
そのためプラグインの提供自体がプログラムソースの提供と
見做されると思いますが、どうでしょうか？

ご指摘の点は、Ruby on Rails（Rails）で開発されたRedmineや、それに対応するプラグインの配布形態において、非常に重要なポイントです。

結論として、ご認識の通り、Redmineプラグインのファイル群を配布することは、GPLが要求する「プログラムソースの提供」を概ね満たしていると見なされます。

1. Railsアプリケーションとソースコード

RedmineはRuby言語で書かれており、Railsフレームワーク上で動作します。Rubyはインタープリタ言語であり、実行時にソースコードを読み込んで処理します。

配布されるファイル: Railsアプリケーションやプラグインを配布する際、通常、コンパイル済みの実行ファイル（オブジェクトコード）ではなく、.rb ファイルなどのテキスト形式のソースコードファイルそのものを配布します。
「優先される形式」の充足: GPLが求める「対応するソースコード（Corresponding Source）」とは、「実行形式から改変・再コンパイルを容易に行うことができる、優先される形式」を意味します。インタープリタ言語の場合、配布されるソースコードファイルこそが、この「優先される形式」そのものです。

2. GPLの義務の充足

したがって、あなたがRedmineプラグインのファイル（.rbファイル、ビューファイル、マイグレーションファイルなど）をそのまま利用者に提供する場合、以下のGPLのソースコード提供義務の実質的な要件を満たしていると言えます。

GPLの要件	Redmineプラグインの提供でどうなるか
ソースコードの提供	`.rb`ファイルなどのプログラムソースそのものを配布しているため、要件を満たします。
「優先される形式」	Rubyのようなインタープリタ言語では、配布ファイルがそのままこの形式であると見なされます。

3. ただし注意すべき点

単にファイル群を配布するだけでは、GPLのすべての義務を満たしたことにはなりません。以下の付帯条件も同時に満たす必要があります。

GPLのライセンス文書の添付: プラグインの配布物に、GNU GPLの全文（Redmineが採用しているバージョン、通常はGPLv2）を必ず含める必要があります。
著作権表示の保持: コピーしたRedmineのコードを含むファイルには、元の著作権表示を保持しなければなりません。
完全性の保証: プラグインを構成するすべてのファイル（ビューテンプレート、設定ファイル、使用されている外部ライブラリなど、プラグインが動作するために必要なすべてのソースファイル）が提供に含まれている必要があります。

配布するファイル群にこれらの情報が欠けている場合、ファイル自体がソースコードであっても、GPLの義務を完全に果たしたとは見なされない可能性があるため、ご注意ください。

プログラムソースの難読化に関して

質問８

プログラムソースを難読化してプラグインを公開をした場合、
公開の義務に違反する可能性はありますか？

はい、プログラムソースを難読化してプラグインを公開した場合、GNU GPLのソースコード公開義務に違反する可能性は非常に高いです。

これは、GPLが求める「ソースコード」の定義に関わる重要な点です。

1. GPLが要求する「ソースコード」の定義

GPLは、単にテキストファイルを提供すれば良いわけではなく、それが「対応するソースコード (Corresponding Source)」でなければならないと定めています。

GPLv3（RedmineがGPLv2である場合でも、その趣旨は同じです）では、ソースコードを以下のように定義しています。

**「対応するソースコード」**とは、オブジェクトコード（実行形式）から改変や再コンパイルを容易に行うことができる、プログラムの優先される形式を意味します。

2. 難読化が問題となる理由

Rubyのようなインタープリタ言語のソースコードを難読化ツールなどで処理すると、以下の理由により「優先される形式」とは見なされなくなります。

問題点	詳細	GPLの違反可能性
可読性の喪失	GPLは、利用者がプログラムの動作を研究し、自分の必要に応じて改変する自由を保証することを目的としています。難読化されたコードは、人間が理解し、意味のある改変を加えることが非常に困難になります。	高い
改変の困難性	変数名や関数名が意味のない文字の羅列に変換されるため、利用者がソースコードの改変やデバッグを行うことが実質的に不可能になります。GPLはソースコードの「利用」を保障しています。	高い
再生成の困難性	難読化されたコードは、元のソースコードを「再生成」する目的から逸脱していると見なされます。	高い

結論

あなたがプラグインのソースコードを難読化して提供した場合、それはGPLが意図する「利用者が自由に研究、改変、再配布できる状態」を著しく損ないます。

したがって、難読化されたソースコードは、GPLの定める「対応するソースコード」とは認められず、ソースコード提供義務の違反と見なされる可能性が極めて高いです。

有料で販売する場合でも、GPLに従い、難読化されていない平文の、人間が可読なソースコードを同時に提供する必要があります。

感想

前回に引き続き、ライセンスに関して色々なケースをGeminiに質問してみました。
内容が100%正確ではないにしても、個別具体的な内容に丁寧に回答ができるAIの能力の高さには驚かされます。
次回、残りの疑問点に関しても質問をしてみます。

この記事の作成者の紹介

山崎進

Redmine、Jquery、JavaScript,Rails、Ruby、SQL、VBA、RPAの開発を行なっています。
自動化、業務の効率化に高い関心があります。
下記の媒体で情報を発信しています。Redmineのプラグインの開発などに対応が可能ですので、お気軽にご連絡ください。

　* Qiita：https://qiita.com/ankosoft
　* Twitter：https://twitter.com/yamasaki24
　* Redmine Advent Calendarで記事投稿
　* redmine.tokyoで講演多数
　* Redmine Japan Vol.1 前夜祭、Redmine Japan Vol.3で講演
　* https://ankosoft.co.jp/blog/
　* https://technology.ankosoft.co.jp/