Matzにっき

_ [教会]岡山訪問

岡山で会議。夕べ夜更かししたせいで途中眠くて困る。

久米南の辺りで今月もまたツーリングの一団に遭遇。やはり岡山はツーリング人口が多いのか。 日差しがまぶしい。

会議では情報共有と水平展開が話題に。関係者全員がIT化されていないのが問題といえば問題だな。

_ [OSS]フリーソフトウェアライセンス診断

あなたが自分で開発したソフトウェアをフリーソフトウェアとして公開しようとしたとしよう。 その時にどのライセンスを選ぶか迷ってしまうかもしれない。たくさんあるしね。

ここではそんなあなたにどんなライセンスがぴったりか診断してあげよう*1。 そのためにはいくつかの質問に答えてもらう必要がある。

やってはいけないこと

ライセンスの選択として決してやってはいけないことは、自分用の新しいライセンスを作ることだ。 自分の経験から言って、これは避けた方が良い。俺ライセンスには危険がいっぱいだ。

• 実はGPLコンパチでなく、GPLソフトウェアとのリンクに問題が生じるかも
• 実はOSDコンパチでなく、フリーソフトウェアやオープンソースソフトウェアの条件を満たさないかも。
• 法的な不備がある、あるいは有効なライセンス文書でないかも
• そのライセンスを読んだ人が理解できず、結局問い合わせを受ける破目になるかも

既存のライセンスでは満足できないと思うことはあるかもしれないが、 既存のライセンスを選んだ方が無難だ。 既存のライセンスはそれなりに考えられているし、 広く知られているぶんだけみんなに理解してもらいやすい。

自分独自のこだわりというのは実はあんまり重要じゃないことが多い。 たとえば、私がRubyライセンスを定めた時には、 コードの一部を引用することについて明示的に許可したいと考えた。 しかし、実際にはBSDライセンスやGPLでも(少々明示的でないだけで)十分にカバーできる。

質問1

最初の質問は

である。もちろん、あなたには報酬はない。断りさえないかもしれない。

これが許せないと思うあなたはGPLを選択すべきである。 GPLならあなたのコードを組み込んだソフトウェアには同様にGPLを適用する必要がある。 ソース非公開で自由でないソフトウェアに利用される組み込まれる危険はない。

また、あなたは自分の書いたコードのライセンスを任意に設定できるので、 商用ソフトウェアに組み込みたい人が(有償で)特別のライセンスを結びたいと申し出るかもしれない。 いずれにしてもあなたに損はない。

質問2

これにYesと答えたあなたは当然GPLを選択すべきである。

その他のライセンス(の多く)は利用者がコードを自由でないソフトウェアに流用することを容認する。 これは結果として不自由なソフトウェアを容認し、間接的に支援することにつながる。 フリーソフトウェア運動に賛同するあなたにはGPLをお勧めする。

質問3

つい昨日「Rubyライセンスを選択する必然性はない」と書いたばかりだが、必然性のあるケースがひとつあった。 Rubyの一部として配布する場合にはRubyライセンスを選んだ方がいろいろ都合が良い。 異なるライセンスのものを混ぜるのはいろいろ面倒だからだ。

同様に他のソフトウェアと同時に使われる、また将来その一部になりえるソフトウェアの場合には ライセンスを揃えておいた方が得策だ。

最後に

ここにたどりついたあなたは自分のソースコードが自由な状態にあることには関心があっても、 そこからの派生物はどうなってもよいと考えているはずだ。

そういうあなたにはBSDライセンスまたはMITライセンスのいずれかをお勧めする。

知名度から考えるとBSDライセンスの方が誤解が少ないかもしれない。 BSDライセンスの場合、宣伝条項のない新しいものを選ぶこと(上記のリンクは新しいものである)。

Apacheライセンスは宣伝条項エンドユーザドキュメント条項を含むので選択すべきではない。エンドユーザドキュメント条項とは

3. The end-user documentation included with the
   redistribution, if any, must include the following
   acknowledgment:

      "This product includes software developed by the
      Apache Software Foundation (http://www.apache.org/)."

   Alternately, this acknowledgment may appear in the
   software itself, if and wherever such third-party
   acknowledgments normally appear.

のようなものだ。これがあるとたとえばディストリビューションのドキュメントには似たような告知を延々と書き連ねなければならない。これは結構不自由だ。

もしも、ユーザにオリジナルのソースコードの入手先を告知したいのであれば、 Sleepycatライセンスというものもある。 しかし、先にも述べたように独自のこだわりでマイナーなライセンスを選ぶリスクは覚悟しておくべきだ。 どうせ、昨今ソースコードの入手先はWebで検索すればすぐ分かるので告知は不要というのもひとつの考え方だ。

フリーソフトウェアのライセンスに関する判例は日米ともにほとんどない。 専門家の間でもこれらの文章の法的な有効性すら確定的ではないそうだ。 となると、ライセンス文書は「開発者が自分のコードをどう扱ってほしいのかの意思表明」と考えるべきだろう。

あなたは自分のコードをどう扱ってほしいのか、どう扱ってほしくないのか。

追記:

Apacheのこの条項はBSD宣伝条項とは違うのですね。勘違いしてました。 解説するなら条文くらいちゃんと読みなさい ＞ 自分。

見返してみるとBSD宣伝条項ほどダメージは深刻ではないですね。 ただ、それでも面倒なのは確かなので私はお勧めしません。

追記2:

拡充していくことができればこれに越したことはないと思います。 追加する質問や条件などは歓迎します。