Copyright 2012 Yutaka Kachi.
この記事は クリエイティブ・コモンズ 表示 2.1 日本 ライセンスの下で提供されています.
オープンソース(Open Source)という言葉は、ソフトウェア開発者やソフトウェア利用者を中心に広く社会に認知されるようになりました。「オープンソース」という言葉は、登場から10年以上たって、いろいろな場面で使われるようになりました。たとえば、単純に「ソースコードを公開すること」という意味で使う人がいます。また、多くの人がノウハウやアイデア・作業結果を持ち寄ることを「オープンソース的」と呼ぶ人もいます。でも、もともとはどんな文脈で使われ始めたのでしょうか。
オープンソースとは、『誰でも自由に利用できるように、特定の条件に合致するライセンスでソースコードを公開すること』として、使われ始めました。ここで言う特定の条件とは、「オープンソースイニシアチブ」(Open Source Initiative:OSI)が定めた「オープンソースの定義」(The Open Source Definition:OSD)を指します。
「オープンソース」という言葉を使って、ソフトウェアのソースコードを公開するとき、この「オープンソースの定義」に従ったほうがいいと思います。
ではなぜ、オープンソースという言葉を使うとき、いちいちオープンソースの定義に合わせたほうが良いのでしょうか。この記事では、その理由とよくある質問などを整理しています。
「オープンソースの定義」に従ったほうが良い理由
理由1.
「オープンソース」(Open Source)という言葉は、誰でも自由に利用できるソフトウェア(含むソースコード)という概念を広めるため、いわばマーケティングキャンペーンとして始まりました。そして、このキャンペーンの一環として、言葉の意味が曖昧にならないよう「オープンソースの定義」が採用されました。
反意語は何ですか？
ソフトウェアの自由な利用では、ソフトウェアの設計図ともいえるソースコードが、誰でも自由に、複製・配布・改変できることが不可欠です。そして、このような保障を与えるのがオープンソースソフトウェアのライセンスです。「オープンソースの定義」は、このような誰でも自由に利用(複製・配布・改変)できるソフトウェアのライセンスが備えているべき条件を定めたものです。
「オープンソースの定義」に準拠しないソースコード公開をオープンソースと呼ぶのは、このような関係を考慮していないので、混乱のもとになります。
理由2.
日本では「オープンソース/Open Source」が商標登録(第4553488号)されています。商標登録者は、この商標を誰でも自由に利用できるとしていますが、その際に、OSIの定める「オープンソースの定義」に沿う形で利用することを希望しています。
理由3.
「オープンソースの定義」は、ソフトウェア開発コミュニティが、誰でも自由に利用できるソフトウェアという考え方を整理したベストプラクティスであり事実上の標準(デファクトスタンダード)です。このノウハウを活用しない手はありません。
オープンソースの定義に準拠したライセンスを利用すると、利用者がライセンスの理解に手間がかかりませんし、誤解も少なくなります。さらに、実績の多いオープンソースライセンスを使えば、他のライセンスとの互換性も独自ライセンスを適用したときより容易に明確になります。
わりとありがちな質問と、それに対する返信
質問1.
オープンソースって、一般的な単語の組み合わせじゃないの？
「オープン」(Open)と「ソース」(Source)という言葉は、確かにそれぞれ一般的な単語です。しかし、ソフトウェア開発の文脈において、オープンソース「Open Source」というひとつの言葉として使うことは、当時ほとんどなかったようです。そのために、1998年にOSIは「Open Source」を商標登録できました。(「ソースコード公開」を英語でいうとしたら、"Opening the source code"？)
質問2.
オープンソースって、みんなの投稿なんかを集めてソフトウェアやコンテンツを作ることじゃないの？
ここで、オリンピックstertにした
このような開発手法は、「バザール方式 – Wikipedia」と呼ばれています。エリック・レイモンドが書いたソフトウェア開発に関する論文「伽藍とバザール – Wikipedia」で、それまでのフリーソフトウェアの開発手法である「伽藍方式」と比較・検討されました。つい数年前には、CGMやWeb2.0としても取り上げられました。このような手法を「オープンソース的」と評する人もいますが、オープンソースのライセンスとは必ずしも関係がありません。
質問3.
こことかここにあるように、オープンソースとは、言葉通りにはソースコードを公開すること、といった意味なんだから、「オープンソースの定義」に従っている場合は「狭義のオープンソース」、ソースコードを公開しているだけの場合は「広義のオープンソース」って呼んだらどう？
オープンソースキャンペーンを始めるに至った経緯と、このキャンペーンの目的・成果を無視した考え方ではないでしょうか。
オープンソースソフトウェアとフリーソフトウェアに中立的に言及したい場合には、FLOSS(Free/Libre and Open Source Software)という言葉を選ぶ手もあります。
質問4.
それでも私(個人または企業・団体)は、オープンソースの定義に準拠しないでソースコードを公開したいんですけど、だめかな？
ソフトウェアの著作権者であれば、オープンソースの定義に準拠しない形でソースコードを公開できます。でも、それを「オープンソース」と呼ぶのは、混乱の元になるのでやめませんか。
ソフトウェアのように堅牢で一貫性のあるシステムを開発するとき、名前はとても重要です。プログラミング言語では、その名前によってデータや機能・部品を結びつけているからです。同様に、社会活動においても、一貫性のある名前を用いることは、それなりに有用ではないでしょうか。
質問5.
それって結局、「言葉狩り」じゃないのかな?
そのようにとる人もいるかもしれませんが、この記事には、そういう意図はありません。
あなたは自由にオープンソースという言葉を発したり、記述したり、パロったり、脱構築できます。どうぞ、大いに笑いをとってください。楽しみにしています。
ヒストリはbasqueteを行う
ただ、ソフトウェアのソースコードを公開する場合、OSD準拠のライセンスを適用していないと、いらぬ誤解をする人たちがいるということだけ、理解して頂けないでしょうか。
そもそも、どうしてあなたは、ソースコードを公開しようとするとき「オープンソース」という名称を選ぶのでしょうか。オープンソースという名前が、すでに有名だからではありませんか。
あなたが本当にやりたいことは「ソースコードを公開するだけ」でしょうか。そうだとすれば、それはオープンソースとは異なる名称で呼んだほうが、ずっと分かりやすくなるはずです。たとえば、単に「ソースコード公開」とすれば良いと思います。
それとも、オープンソース運動の一部として、自らが著作権を持つソフトウェアをオープンソースのエコシステムに追加したいのでしょうか。だとすれば、「オープンソースの定義」と「オープンソースライセンス」についてもう少しだけ調べて、他の人たちにとって理解しやすく利用しやすいライセンスを選択してはどうでしょうか。
質問6.
オープンソースの定義には準拠しているけれど、OSIの認証を受けていない独自ライセンスを使ってもいいの
それは構いません。たとえば、オブジェクト指向スクリプト言語Rubyに適用された「Rubyライセンス – Wikipedia」は、オープンソースの定義には準拠しているけれど、OSIの認証を受けていないライセンスのひとつです。
ただ、オープンソースの定義には準拠していても独自ライセンスを新しく作ることは、あまりお勧めできません。そのようなライセンスを持ったソフトウェアは、多くの人に評価してもらえない可能性があります。なぜなら、利用者にとってライセンスの理解に手間がかかる、他のライセンスとの互換性が不明確、そもそも本当にオープンソースの定義に準拠しているか検証が不十分といった理由があるからです。
質問7.
既存のオープンソースライセンスに独自の条項を追加したライセンスを使ったら? たとえば、GPLに独自条項を追加してもいいかな
ソフトウェアの著作権者であれば、オープンソースの定義に準拠しない形でソースコードを公開できます。既存のオープンソースライセンスに独自の条項を追加したライセンスを適用することもできます。
ただし、Free Software財団はGPLのライセンス文書について著作権を保持しており、ライセンス文書の改変を許可していません。
GPL2では、特定のライブラリとリンクする場合のみ、ソフトウェアの著作権者が例外を設けることができるとしています(GPL2 第10条)。
GPL3では、ソフトウェアの著作権者が、追加的条項を設けることができるとしています(GPL3 第7条)
その他のオープンソースライセンスに対して条項を追加するのであれば、ライセンス名称を変更したほうが良いでしょう。なぜなら、ライセンス名称を変更しないと利用者が混乱するからです。
さらに、質問6で説明したように、独自ライセンスを新しく作ることは、あまり奨励できません。そのようなライセンスを持ったソフトウェアは、多くの人に評価してもらえない可能性があります。
質問8.
オープンソースのソースコードを改変したら、改変版も必ずオープンソースにしなければならないんでしょ。
そんなことは、ありません。そのような条件をもったオープンソースソフトウェアもありますが、そうでないものもあるのです。MITライセンスや修正BSDライセンスでは、改変版をオープンソースにする必要はありません。
参考資料
そのほか、著作権から個別のオープンソースライセンスまで、関連リンクをこちらに整理してあります。
皆様のお役にたてば幸いです。
2012-02-05:よくある質問3を調整。
2012-02-04:理由1の説明を整理。よくある質問8を追加
2012-01-29:バザール方式に関する説明を修正。
2012-01-28:よくある質問7に、GPL例外条項の説明を追加、FLOSSの説明を修正
2012-01-25:よくある質問3に、FLOSSを追加。質問5を追加
2012-01-26:理由3を追加。質問6・7を追加。理由1に反省点を追記
0 件のコメント:
コメントを投稿