GPLライセンスのプログラムで実行されるスクリプトのライセンスについて

programming

以下は自身のGPLライセンスの認識の整理の為に書かれた記述で、不確実な事項を含んでいます。間違っているところがあればご指摘ください。

GNU 一般公衆利用許諾契約書 - GNU プロジェクト - フリーソフトウェア財団 (FSF)

このようなライセンス構成のアプリケーションがあると仮定します。

  • 【A】GPLライセンスのプログラム。バイナリ。
  • 【B】MITライセンスのプログラム。PHPで記述されたWebフレームワーク。
  • 【C】Webフレームワーク【B】で動作するユーザーアプリケーション（PHPで駆動）。PHPのexec関数でスクリプト【target】を実行する。|
  • 【target】【A】によって実行されるスクリプト。入力ファイルを処理して画像を出力する。

GPLライセンスのプログラムが絡んで混乱してしまったので、【C】および【target】のライセンスは何になるのか（できるのか）情報を整理してみました。

理想としては【C】も【target】もMITライセンスが適用できればいいなあ、と思っています。

プログラムの構成

【target】は以下のようにユーザーアプリケーション【C】に組み込まれています。

  • b.php（ユーザーアプリケーション【C】。Webフレームワーク【B】によって駆動。）
exec('go.sh input.cxv arg1 arg2...');
  • go.sh（共通処理用bashスクリプト）
#!/bin/bash
:
:(カレントディレクトリの制御)
:
c.m input.csv arg1 arg2...
:
:(エラー処理)
:
  • c.m（プログラム【A】によって実行されるスクリプト）
#!/usr/local/bin/octave
:
:(入力データを処理してグラフを出力)
:

FAQで関連ありそうな問答を抜粋

以下の2項目が1番近そうな問答でした

以下は単なるスクリプトとして同梱する場合とリンクして一つのバイナリにする場合の違いについて言及。

以下は【A】GPLライセンスで動作する【target】スクリプトに関する記述ではないが、プログラムをサーバー本体ごと提供する頒布形式に引っかかる問答かも。

これらの問答だけ目にすると、リンクしたバイナリではなくスクリプト（テキストファイル）として提供するならGPLにしなくてもOKっぽい。

その他プログラムもWebサービスではなく諸々のプログラムを組み込んだサーバーごと提供する方針なので*1、ソースを公開しているも同義*2なのでまあGPLでなくても大丈夫であろうと判断。

結論

ライセンス文書及びFAQを読めば読むほど迷いが生じるのですが、

  • スクリプト【target】はテキストファイルであること
  • プログラム【A】のソース本体を改変していないこと
  • プログラム【A】とリンクしてバイナリとして提供するわけではないこと

を判断基準として、GPLライセンスは適用せず、プログラム【B】と同じくMITライセンス適用することにしました。

感想

OSSって面倒くさい。ライセンス文書を読んでも『利用』と『使用』の違いがまず明確に示されていないので、スクリプト書いてプログラム（インタプリタ）に実行させて結果（画像なり数値なり）を得る行為が、OSSの『利用』なのか『使用』なのか、それがOSSライセンス条項に縛られる行為なのかそうでないのかが非常にわかりにくかったです。

特にGPLライセンスは、悪い面（ソースコード公開）ばかり強調されていると思います。OSSに馴染みのない中小企業なんかでは、触らぬ神に祟りなしで『利用』も『使用』も一律不可としてたりします。パッケージソフトみたいに『使用』に関するライセンス料金とごっちゃになっているんですよね。

OSSのライセンスを理解するのに必須の用語として

  • 『利用』：プログラムを再頒布すること（例：本を売ること）

  • 『使用』：プログラムを使ってデータを得ること（例：本を読んで知識を得ること）

があるのですが、日本語では両者に明確な違いがないのもあって、OSSライセンスの理解をより困難にしていると思います。

OSSの各種ライセンス条項が縛りを入れるのは『利用』に関する部分なのです。

このへんの誤解が個人および中小企業での商用”利用”（有償）のOSSの『利用』および『使用』促進への大きな障壁になっていると思います。

お上に於かれましては、製造業対象のものづくり補助金とか百害あって一利あるかないかの事業に金を投資するより、OSSとかソフト方面に投資して中小企業を教育したほうがより効果的な気がするんですけどね。