「opensource」カテゴリーアーカイブ

のがたじゅんさんによる「オープンソースとライセンス」

姫路IT系勉強会 Vol.3で発表されたという、のがたじゅんさんの「オープンソースとライセンス」解説。分かりやすいし、コンパクトにまとまっています。

「オープンソース」と「ライセンス」

View more presentations from Jun NOGATA

このエントリーをはてなブックマークに追加

邪悪なことに使うなという、JSONライセンスに関する個人的な解釈

json.orgにある「The JSON License」が話題を呼んでいます。「The JSON License」は、MITライセンスをベースに、「The Software shall be used for Good, not Evil.」（このソフトウェアは良いことに使うべきであり、悪いことに使うべきではない）という一文が追加されているためです。

JSON(ジェイソン、JavaScript Object Notation)とは、Javascriptのオブジェクト表記法に基づいたデータ形式の記述方法です。Webサービス間の通信などに広く使われています。

このような用途による制限がある場合、オープンソースライセンスには適合しないと言われています。なぜなら、The Open Source Initiative: オープンソースの定義では、用途による制限はできないからです(6. 利用する分野に対する差別の禁止)。スラッシュドットでも、なんだこれは的なコメントが多数寄せられています。フリーソフトウェア財団のVarious Licenses and Comments about Themでも、フリーソフトウェアではない、としています。

たしかに、JSONライセンスという文書を単独で見た場合には、オープンソースライセンスには適合しないでしょう。しかし、実際に問題として、このライセンスをどのように用いるかについては、いくつか疑問があります。

  • JSONフォーマットは、RFC4627として別に規定されている。そちらには、この条項がない
  • JSONフォーマットについて説明した「Introducing JSON」(http://www.json.org/index.html)には、このライセンス文書に対するリンクがない。

つまり、このJSONフォーマットのWebページは、json.orgにおかれているだけで、具体的に何かに適用されているわけではないのです。

なお、日本の著作権法では、コンピュータプログラムのプロトコル自体には著作権はないとされています。データフォーマットについても、あんまり気にすることは無いのかも知れません。そもそも、データ交換で、データフォーマットの独占権を主張して、相手とのデータ交換が自由にできなくなったら本末転倒なだけですし。

このエントリーをはてなブックマークに追加

WordPressのテーマ(テンプレート)のライセンスは、本体と共通なのか

※この記事は、2012/03/04に最初に公開し、2012/11/07-09に大幅に改訂しました。

ブログエンジン／CMSとして高いシェアを持つオープンソースソフトウェアWordPress(ライセンスは、GPL2またはそれ以降)。これに標準添付されているこの表示用のスタイルテンプレートであるWordPressテーマが、本体と同じライセンスが適用されるのか、ということで長らく話題になっていました。

結論だけ書くと、「WordPressテーマの PHP コードは、**すべて(改変版も新規開発も)**がGPL(GPL2またはそれ以降) でなければならないが、画像や CSS は GPL でもそうでなくてもよい」。

WordPressのテンプレートタグを使ったテーマは、GPL(GPL2またはそれ以降) でなければなりません。ただし、対象になるのはテーマのコード(PHP)だけ。画像やCSS・JSファイルは別のライセンスを設定できます。

あまり現実的ではありませんが、テンプレートタグなどを使ってない場合は、自由にライセンスを設定できます。テンプレートタグを使う場合でも、WordPressの著作権者全員の許可を得ていれば、違うライセンスを設定できます。

ほかにもあります。

WordPressテーマをGPLでどう運用するか

以下は、WordPressテーマにGPLが適用されたとき(ほとんどの場合そうですが)、なにが起こるか／なにをしなければいけないかを整理したものです。最善を尽くしていますが、内容について保証はありません。詳細は、ライセンス文書自体を確認ください。

1. まず、WordPressテーマのカスタマイズ

私は、自分でやったことはないんですけれど、簡単にできるらしい。

テーマファイルは、PHPファイル・画像ファイル・CSSファイルなどで構成されています。このうちPHPファイルは、テンプレートというより、WordPressのテンプレート関数を呼び出すスクリプトになっています。

2. 配布されているテーマは、GPLだけど改変して商用提供してOKか?

GPLは、商売に利用してOKなんです。
WordPressテーマがGPLであっても、デザイン料やカスタマイズ料は請求してもよい。
また、作成したGPLなWordPressテーマは、インターネットなどで公開しなくてもよい。
とはいえ、独自ライセンスによるライセンスビジネスは大変かも。

3. 改変したWordPressテーマのライセンスは？

改変したテーマのライセンスも、元と同じにしなければいけません。つまり、GPL(GPL2またはそれ以降)でなければなりません。ただし、対象になるのはテーマのコード(PHP)だけ。画像やCSS・JSファイルは別のライセンスを設定できます。

4. WordPressテーマを作成・改変した企業／人は、GPLだと、なにをしなければいけないか

誰かにWordPressテーマを提供したら、その相手にソースコードを提供します。
そして、WordPressテーマのPHPコードには、元と同じライセンス(GPL2またはそれ以降)を適用します。
GPL2のライセンス文書もわたします(詳細は、GPL2のライセンス文書の第2項に書いてあります)。

ソースコードを渡すのは、WordPressテーマを渡した相手だけ。
インターネットで公開する必要はありません(本当)。
また、画像とCSS・JSファイルは別ライセンスにできます。

5. 作成・改変したWordPressテーマを受け取った企業／人は、なにができるか

自由に「複製、再配布、改変」ができます。
再配布するときは、WordPressテーマのPHPコードは、元と同じライセンス(GPL2またはそれ以降)を適用します。
とはいえ、「複製、再配布、改変」をしてもいいし、しなくてもいい、という意味です。

また、画像とCSS・JSファイルは別ライセンスの可能性があります。

6. WordPressのWebサイトを見た人は、なにができるか

Webサイトを見ただけでは、新規作成であれ改変版であれWordPressテーマの再配布を受けることはできません。頼んでみてOKだったらいいけれど、強制はできません。
なぜなら、Webサイトを見た人は、WordPressというプログラムの出力結果を見てるだけ。
WordPressテーマのファイルを受け取っていないため、GPLの対象者になりません。

7. WordPressテーマを作成・改変する企業／人は、どうやって商売するか

WordPressテーマがGPLであっても、デザイン料やカスタマイズ料は**請求しても**かまいません。
また、作成したGPLなWordPressテーマは、インターネットなどで**公開しなくても**かまいません。

納入したWordPressテーマは、GPL(GPL2またはそれ以降)になるので、納入された顧客はそれを自由に複製・配布・改変してもよいし、しなくてもよい(No.5と同じ)。

8. WordPressテーマに、企業ロゴやキャラなどを組み込んだら、企業ロゴやキャラがGPLになる？

GPLにはなりません。
WordPressテーマに組み込まれる画像ファイルなどは、GPLの適用対象ではないからです。
WordPressにもともと付属していた画像などを改変する場合は、GPLの適用対象になっているかも知れませんが、あとから追加した企業ロゴやキャラなどは無関係です。

9. 会社で作成したWordPressテーマはGPLなんだから、社内Webデザイナーであるわたしは、個人的に使ってもいい?

職務で仕事するWebデザイナーやプログラマー・ライターの成果物は、各個人の著作物ではなく、会社の著作物になります。そのために、勝手に個人の著作物として利用できません。これは、WordPressテーマであっても同じです。

ただし会社が、インターネットなどで公開しているWordPressテーマであれば、デザイナー個人が利用しても問題ありません。この場合、会社による公開がGPL(GPL2またはそれ以降)になるので、利用する個人もそれに合わせることになります。

また、会社と社員との間で、特別な職務契約や就労規則があれば別ですが、その場合も誰が当初の著作権者で、誰が配布を受けるのか明確にしておく必要があるでしょうし、他者に提供した段階でGPL(GPL2またはそれ以降)の適用対象になります。

10. 改変ではなく新規でWordPressテーマを作成した企業／人は、なにができるか

新規でテーマを作成した場合は、改変ではないので独自のライセンスを設定できます。
なぜなら、WordPressで運用されているサイトをみただけでは、GPLの影響を受けないから。
テーマファイルを受け取っていないため、GPLの対象者になりません。

新しいWordPressテーマを自社で**使用するだけ**なら、テーマファイルとして公開する必要はありません。たとえば、自社のWebサイトで使う場合などでは(自社サイトが自社外に公開されていても)、WordPressテーマを単独で公開しなくてもかまいません。

もちろん、WordPressテーマを単独でダウンロード可能にしてもOKです(ダウンロード可能にするときは、PHPコードにGPL2またはそれ以降を適用)。

WordPressテーマを誰かにわたす場合(たとえば、お客様に納入する、ダウンロード可能にする)、独自ライセンスは適用できますできません。必ず、PHPコードはGPL(GPL2またはそれ以降)にしなければなりません。なぜなら、WordPressテーマを新規で作成した場合、コード(PHP)がWordPressのテンプレートタグなどを含んでいるとWordPressの派生物となり、さらに、お客様への納入はWordPress派生物の領布となるからです。

結論として、提示された WordPress テーマは WordPress の著作権の元にあるコードの派生物を含んでいます。それぞれ独自の作品である画像、CSS、PHP ファイルをまとめたこれらのテーマは、全体的を GPL ライセンスにする必要はありません。むしろ、PHP ファイルは GPL ライセンスの要件に制約されるが、画像や CSS はそうではないと言えます。サードパーティのテーマ開発者は、希望するなら制限付きの著作権を適用することができます。

最後に、WordPress の著作権に制限されない合法な WordPress テーマを作成することも可能ということを言っておきます。しかしそのようなテーマはこのソフトを有益なものにしている WordPress 関数をまったく使わないものである必要があります。

WordPress | 日本語 » テーマも GPL ライセンス

上記で明確に述べられているように、「PHP ファイルは GPL ライセンスの要件に制約される」のです。

11. WordPressテーマのライセンスは、MITライセンスや修正BSDライセンスでもいいんでしょ

WordPressテーマのライセンスは、MITライセンスや修正BSDライセンスではいけません。

MITライセンスや修正BSDライセンスはGPL互換ライセンスですが、GPL互換ライセンスとGPL系ライセンスは同じではありません。じつはWordPressテーマのライセンスはGPL互換ライセンスというだけではダメなんです。GPL(GPL2またはそれ以降)でなければなりません。これは、新規作成でも改変でも同じです。

オープンソースでライセンス互換性というのは、「異なるライセンスが適用された複数のソースコードを結合して、別のソフトウェアを作成することが許可されているか」を説明する言葉です。互換性があるライセンス(たとえば、GPL2とMITライセンス)は、その条項が互いに矛盾していないので、結合して新しいソフトウェアを作ることが許可されています。互換性がないライセンス(たとえば、GPL2とApache2)は、その条項が互いに矛盾しているので、結合して新しいソフトウェアを作ることは許可されていません。

では、ライセンスに互換性があり、新しいソフトウェアの作成が許可されていた場合、その新しいソフトウェアのライセンスには、何を選べばいいでしょうか？

これは次のようになります。

  • 「GPL2またはそれ以降」+「MITライセンス」-> 「GPL2またはそれ以降」
  • 「GPL2またはそれ以降」+「修正BSDライセンス」-> 「GPL2またはそれ以降」

GPLとMIT/修正BSDライセンスを比較すると、両者の条件は矛盾していません(つまりライセンス互換性がある)。ですが、条件はGPLのほうがきびしくなっています。そのために、結合された新しいソフトウェアは、ライセンス条件のきびしいGPLに合わせなければならないのです。

WordPressテーマは、PHPコードにテンプレートタグを含んでいるためWordPressの派生物となり、配布時にはGPL互換ライセンスというだけでなく「GPL2またはそれ以降」を適用しなければなりません。

もしMITライセンスや修正BSDライセンス、または独自ライセンスで配布されているWordPressテンプレートがあって、それがテンプレートタグを含んでいれば、ライセンス違反の可能性があると私は思います。

12. オープンソースやGPLに敬意をはらって、WordPressテーマを作るべきだよね

FOSS(オープンソースソフトウェアやフリーソフトウェア)は、自由に利用できるソフトウェアを作り続けるためのベストプラクティスのひとつです。その環境を維持することは、とても重要なことです。そのために、オープンソースやGPLに敬意をはらっていくことが奨励されると、私も思います。たとえば、WordPressの開発やフィードバック・プロモーションに協力することは、大切なことです。

とはいえ、オープンソースソフトウェアを利用(複製、配布、修正)する場合、
敬意をはらうだけでは不十分です。いうまでもなく、ライセンス条件をきちんと理解し守る必要があります。WordPressテーマに関していうと、その作成・改変は、WordPressの派生物を作ることと同じになるので、ライセンスを守り「GPL2またはそれ以降」を適用しなければなりません。極端なことをいえば、オープンソースであることに敬意を払わないとしても、ライセンス条件は守らなければいけません。

13.WordPressテーマの作り方をブログとかで説明したら、説明文もGPLになるの？

説明文は、GPLでなくても大丈夫だと思います。

説明文は、テンプレートタグを含んでいても、WordPressプログラムの一部として動作するわけではないので、派生物とはならないと考えています。

とはいえ、WordPressテーマは、ソフトウェア開発者でないWebデザイナーでも気軽に作れるWordPressの派生物です。提供時には、そのライセンスが「GPL2またはそれ以降」になることは、きちんと説明したほうがいいでしょう。

GPLは伝搬性があります。「ウィルス性」と批判されたこともあります。不用意に適用されると、自分たちが当初想定していなかった範囲まで、GPLの対象となってしまう可能性があります。場合によっては、お客様が困ることもあるかもしれません。

ですから、WordPressテーマを作る人たちが、GPL(GPL2またはそれ以降)の適用範囲をきちんと適用することが不可欠です。WordPressを活用される皆さんが、GPLとその実務に関して理解を深めることは、WordPressコミュニティを一層豊かなものにすると思います。

以上。

参考になる情報

字幕付き動画「WordPress はなぜ GPL ライセンス？」をご覧ください。WordPressプロジェクトの共同創始者マット・マレンウェッグが、この問題について説明しています。

また、オープンソースライセンスとGPLの概略については、下記のスライドをご覧ください。

コメントを下さった皆さん、ありがとうございました。
(とくに、@naokomc @nogajun @smellman)

間違いや紛らわしい点があるかも知れません。
引き続き、ご意見を頂ければ助かります。

この記事自体は、CC BY 3.0 (改変自由、商用利用可)で提供しています。

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.

再利用のために、別のライセンスで提供する必要があれば、ご相談ください。
よろしくお願いします。

このエントリーをはてなブックマークに追加

busyboxの問題

busyboxは、UNIXベースのコマンドライン・ツール集で、主に組み込み用途のLinuxなどで使われる。GPL2で提供されている。2007年後半以降、BusyBox をGPLに違反した使い方をした複数の企業を訴え勝利したことでも注目された。

このエントリーをはてなブックマークに追加

渡邊フォントの問題

以前に起きた、渡邊フォント問題のリンクを集めておきます。

日本においては、商慣行としては知的財産として取引の対象になっている一方で、タイプフェイスを保護するための法制度は整備されていません。

公有フォントの利用と制作のための参考情報

つまり、フォントに関する権利／ライセンスは、ソフトウェアの著作権とは異なる部分があるということです。

このエントリーをはてなブックマークに追加

なぜ、オープンソースという言葉を使うとき「オープンソースの定義」に合わせたほうが良いのか

Copyright 2012 Yutaka Kachi.

クリエイティブ・コモンズ・ライセンス
この記事は クリエイティブ・コモンズ 表示 2.1 日本 ライセンスの下で提供されています.

オープンソース(Open Source)という言葉は、ソフトウェア開発者やソフトウェア利用者を中心に広く社会に認知されるようになりました。「オープンソース」という言葉は、登場から10年以上たって、いろいろな場面で使われるようになりました。たとえば、単純に「ソースコードを公開すること」という意味で使う人がいます。また、多くの人がノウハウやアイデア・作業結果を持ち寄ることを「オープンソース的」と呼ぶ人もいます。でも、もともとはどんな文脈で使われ始めたのでしょうか。

オープンソースとは、『誰でも自由に利用できるように、特定の条件に合致するライセンスでソースコードを公開すること』として、使われ始めました。ここで言う特定の条件とは、「オープンソースイニシアチブ」(Open Source Initiative:OSI)が定めた「オープンソースの定義」(The Open Source Definition:OSD)を指します。

「オープンソース」という言葉を使って、ソフトウェアのソースコードを公開するとき、この「オープンソースの定義」に従ったほうがいいと思います。

ではなぜ、オープンソースという言葉を使うとき、いちいちオープンソースの定義に合わせたほうが良いのでしょうか。この記事では、その理由とよくある質問などを整理しています。
続きを読む →

このエントリーをはてなブックマークに追加

β版を無料でアップデートできます、「知る、読む、使う！オープンソースライセンス」

「知る、読む、使う！オープンソースライセンス」のβ版をアップデートしました(v0.9.1)。

すでにご購入頂いた方は、達人出版会のマイページから再度ダウンロードください。無料で最新版を入手できます。
電子書籍ならではのメリットです。
お手数をおかけしますが、ぜひご利用ください。

修正内容

すでにご購入頂いたからのコメントなどをもとに、下記の修正を施しています。いくつか説明不足のところ・オープンソースライセンスで紛らわしいところについては、説明を追加しています。

  • typo：2.5「「著作財産権」とは、その名のとおり、作品を複製や配布を許可する権利です。」
  • 表現を変更：2.7「あなたのマンガを週刊雑誌に掲載するという許可を与えたら〜
  • typo：2.8:「ひとつの文ですべての対象と動作を列挙しているたえに、」
  • 表現を変更：4.2「ソフトウェアの改変版を元と同じ条件で配布してもいいし、」
  • 図版入換え：4.4 「図4.7 伽藍方式とバザール方式の比較」の内容とキャプションが一致してない
  • 表現を変更：4.4「OSSのメリット１：コスト」のOpenOffice.orgについて脚注を追加
  • typo：6.2「日本語版は参考訳と位置付けらるのが一般的です。」
  • typo：6.6「日医オープンソース使用許諾契約」のものでソースコードを公開し、
  • 説明追加：6.6 オープンソースライセンスは、利用許諾契約なのか著作権不履行宣言なのか
  • 参考リンク追加：第7章 オープンソースライセンス
  • 表現を変更：7.2 修正BSD ライセンスの2～4条項ライセンスについて
  • 組版修正：7.7「GPL2では、ソフトウェアの配布形式に合わせて、次の3つの条件を持っています。」

コメントをお寄せ頂いた皆様、本当にありがとうございました。
おかげで、本書の品質を一層上げることができました。

フィードバックを受け付けています

本書についてのフィードバックは、達人出版会にて受け付けております。
すでにご購入いただいた皆様、ご意見・ご質問などございましたら、どうぞお寄せください。
あと1ヶ月ほどフィードバックを受け付けたところで、正式版に移行できればと考えています。

フィードバックの方法

本書にご興味をお持ちの皆様

正式版を待つことなく、本書をお求めになることをお勧めします。
あなたのコメントを頂くことで、より多くのフィードバックが集まり、オープンソースライセンスに関する情報を一層磨き上げられると考えております。

ぜひ、ご検討ください。どうぞ、よろしくお願いします。

このエントリーをはてなブックマークに追加

あなたのアウトプットは、誰の著作物になりますか。

まだ十分に整理できていないのだけれど、ちょっと思いついたことがあるので、少し書いて見ます。

オープンソースソフトウェアのライセンスに関して、意見が食い違うとき、実は、それぞれ立脚点が違うんだろうな。と最近思っています。だから、過度に一般化すると無理が出てくる。その立脚点の違いはというと、成果物（コードや文書）が、誰の著作物になるのか、ということ。

昨年末ごろ、Twitter上でTwitter / Search – #笑ってはいけないSIerというタグが流行りまして、そこから派生して、「そもそもOSSがサポート無いと使えない。GPLは禁止。OSSを使うのに研修を受ける必要がある。OSSのソースを読むのは禁止。#笑ってはいけないSIer」から派生したGPLについての談義 – Togetterという具合にマジレスする人たちが現れ、GPLに関するいくつかの意見が飛び交いました。私も、「GPL適用のソースコードを他言語に移植してBSDライセンスに変更できるか」で、少し参戦しましたが(w。

このとき主題のひとつだった「GPLに書いてある翻訳ってどこまで適用されるのか。アイデアの移植にライセンスは影響するのか」について、日本男児さんがFSFに直接問い合わせて、その結果を漢(オトコ)のコンピュータ道: GPLソフトウェアの移植とライセンスの変更に見る著作権の問題で公開しています。結論は「場合による」。

それ自体は、しごくまっとうな結論だと思います。ただ、シロクロつかないからといって、思考停止するのではなく、じゃあどうやったら有効活用できるのか、考え抜くことが不可欠だと思いますが・・・。

で、それに関連して思ったのですけれど、GPLをどう扱うのか意見が異なるのは「成果物（コードや文書）が、誰の著作物になるのか」という違いだと思うのです。

私が、このブログに記事を書くとき、その記事の著作権者は私になります。
私が、個人で(しょぼい)プログラムをゼロベースで書くと、そのプログラムの著作権者は私になります。
私が会社で、何か文書を書いた場合、ほとんどの場合、その著作権者は私が勤める会社になります。私の現在の本業は、会社の広報宣伝担当者なので、ほとんどの場合は職務著作となって、会社の著作物を作ることになるからです(仕事でプログラムを作ることは、まずほとんどありえません)。
しかし、私が会社で、よその会社の広報業務を請け負って文書を作成した場合、作成物は委託元の著作物になります(そういう契約を会社間でしていればですが)。

さてソフトウェア開発者の場合は、どうでしょう。
個人で作成したプログラムは、その個人の著作物になります。
会社で業務でソフトウェアを開発すれば、職務著作となって、会社の著作物になります。
では、受託開発の場合はどうでしょう。委託元に納入するとき、そのソースコードの著作権はどうなるでしょう。それは、業務委託時の契約で決まります。契約をきちんと交わしていないなら、企業コンプライアンス的に事前に契約を交わすべきです。経済産業省が公開している情報システム・モデル取引・契約書が参考になるでしょう。

最近は、委託元はソースコードの権利をもっておきたいし(委託先がなくなってもメンテナンスできるように)、委託先もせっかく開発したソフトウェアをライブラリやミドルウェアにしてビジネスを展開したいので、両者が自由に利用できるというような契約にするんじゃないかと思います。

で、そんな受託開発案件でOSSを使いたい、開発期間も短くなるしコストも下がるしコードは枯れて信頼性も高いし、いいことばかり。でも、GPLが入っていた場合、どうなるんだろ。というのが、今日本の受託開発の現場で起きていることじゃないかと思うのです。そして、そのときGPLなソースコードを参照すべきかどうか、それは委託先となる受託開発企業の一存では決められません（ましては、担当プログラマーの一存で決めることでもありません）。なぜなら、その生成物は委託元企業の著作物になると、契約で決まっているかも知れないから。

というような状況で、開発現場がGPLなソースコード参照禁止とするのは、現実的な解決策のひとつとしてありうることだと思います。

でも、事前の契約や見積りのときに、GPL参照可だと開発費が安くなり、参照禁止だと高くなるとか、委託元と調整の余地は、いっぱいあるような気もします。

つーことで、GPL化されたソースコードをどう扱うべきか、意見交換するとき立脚点を明確にするのが重要ではないかと思いました。それをはっきりさせないで、GPL化されたソースコードはこうあるべきだというディスカッションをしても、話がかみ合わないのは当たり前なんじゃないかなぁ。

このエントリーをはてなブックマークに追加