Japan
サイト内の現在位置を表示しています。
OBCIメールマガジン特別寄稿
本ページの掲載情報は、オープンソースビジネス推進協議会(OBCI)のメールマガジンに
執筆した特別寄稿です。
第1回 「OSSのライセンス遵守と普及促進」 (2009年11月6日)
「伽藍とバザール」のキーワードを利用させていただくと、「伽藍」の時は、侵さざるべき孤高の存在に見えて近寄り難かったところが、「オープンソース」「OSS」というキーワードで企業にもグッと身近な存在になってきました。
企業がLinuxやOSSを利用してシステム構築することが歓迎されたり、企業の開発者が開発コミュニティに参加して、業務で必要な機能強化することも少なくありません。
そして、この10年、OSSは着実に強化され普及してきましたが、OSSライセンスが難しくて、OSSを商材として活用することに躊躇されているということはありませんでしょうか?
孤高のコミュニティに比べると、OSSのコミュニティは企業に使われることも歓迎していただける雰囲気があります。つまり、
(1) 企業の製品開発者が正しくOSSライセンスを理解すると
(2) 製品でのOSS活用は進み
(3) 活用事例としてなどのOSSコミュニティへの還元が増え
(4) OSSの機能改善が進み
(5) OSS活用のコストメリットが増大する
そうすると
(2) 製品でのOSS活用は進み
・・・と、正のスパイラルに乗って共に成功の道を歩む形になりたいものです。
このスパイラルの乗るために必要なOSSライセンスの入門を次回からご紹介したいと思います。
(NEC・姉崎章博)
第2回 「OSSライセンスは企業に優しくない」 (2009年12月4日)
11月18日パシフィコ横浜で開催された Embedded Technology2009(ET2009)のスペシャルセッションC-5「Android利用時に気を付けたいGPLのABC」での話です。
いつもお世話になっているGPLやOSIの定義の参考日本語訳をされたDebianの八田真行氏が「OSSライセンスは企業に優しくない」と発言されていたのが私の印象に残りました。
今、組込み業界でAndroidシフトが盛んで、いろいろな方が安易に参入していることへの警鐘の意味で述べられたのだと思います。
マスコミではAndroidは、Apacheライセンスと書かれることが多いらしいのですが、組込機器に関わる方は、デバイスドライバの開発に関わる方が多いので、そういう方が扱うAndroidの部分はOSのLinux部分ですから、GNU GPLのライセンスに従って、通常デバイスドライバもGPLで頒布することになります。
(これを「GPLの伝播」などと称します。)
そのため、OSSライセンス・セミナーで話をしていても、よく「どうしたら、GPLにせずに済むのか?」「使ってもらうには、どうすればGPLにせずに済むのか明らかにすべきではないか。」という声を聞くことがあります。
でも、GPLのプログラムを増やしたいと思うライセンサーが、優しく、その方法を明示することはありませんし、ライセンス条文を読んでも機械的に判断できるようなものでもありません。
このことを指して「OSSライセンスは企業に優しくない」と言っているのだと思います。
すべてのソースコードをダウンロード可能にしているLinuxディストリビュータは企業でも著作権表示するドキュメント自身が無いこともありますし、なにも特別な作業もしていません。OSS開発コミュニティと同じような状況にして、サポートビジネスやハードウェアへ組込むハードウェアビジネスを展開しています。
それに対して、OSSを利用しているけれども、従来のロイヤリティビジネスを展開しようとプロプラ部分を隠そうとするから難しくなるわけです。
このため、「難しいことをするなら、それなりに勉強して、きちんと(OSSライセンスに)対応しなければならない。」という発言もありました。
そういうニーズのためにOSSライセンス教育のメニューもコンサル・サービスにご用意しております(*1)が、ある種、プログラマのリテラシー教育になっているのかもしれません。
BSD系のOSSを昔から利用されてきた部門の方とお話した際、「プログラマが(OSS)を利用する際、ライセンスを読んで使うのは当たり前でしょ。」と言われ、改めて教育する必要性は無いこともあります。
会社、職場によって、リテラシー度合いにずいぶん差があるようです。
皆さんの職場では大丈夫ですか?
*1:OSSライセンス・コンプライアンス コンサルティング・サービス (2024年現在、OSSライセンス コンサルティング)
https://jpn.nec.com/oss/osslc/
(NEC・姉崎章博)
第3回 「訴訟とならないために、できること」 (2010年1月8日)
米国時間12月14日にSoftware Freedom Law Center(SFLC)が一昨年12月に提訴して以来、一年ぶりにGPL違反で提訴しました。
SFLC、Best Buyなど14社をGPL侵害で提訴
https://japan.cnet.com/article/20405353/
提訴に至った状況は企業それぞれ違うでしょうが、下記のような誤解があったのかもしれません。
@ITの連載(*1)でも最初に「使えるんだから、勝手に使っていいんでしょう」という発言を受けて驚いた旨を述べましたが、この言葉をもう少し厳密に表現すると以下のようになります。
「Webからダウンロードして実行して使えるんだから、
勝手に製品に同梱するように使ってもいいんでしょう」←×!
連載の2/2ページに書いていますが、日本の著作権法では、前者を「使用」、後者を「利用」と言って、言葉を使い分けています。
つまり、「利用」には著作権があり、勝手に「使用」出来ていても、勝手に「利用」することは著作権侵害になるということです。
この「使用」と「利用」を誤解している方が少なくありません。
また、よくある誤解に「何も手を加えていないから(同梱するだけ)」と免罪符かのようにおっしゃる方がいますが、何も編集していない番組を勝手に再放送できないように、手を加えていないOSSを頒布(同梱して販売)するだけでも「利用」となりますので、ライセンス条件を遵守しなければ(GPLでソース開示などしなければ)著作権侵害になります。
この辺りの誤解さえなければ、上記のような訴訟にまで至らなかったのではないかと思ったりもします。
OSSライセンス条文は英語のことが多く、そこでつまずく方もいらっしゃるようですが、多くのOSSライセンスに日本語参考訳があります(*2)。ドキュメントに添付するライセンス条文は原文の英文でなければなりませんが、理解のためには、これら日本語参考訳を(ありがたく)多いに活用させていただきましょう。
*1:@IT企業技術者のためのOSSライセンス入門 第1回 訴訟が増えている!? OSSライセンス違反
https://atmarkit.itmedia.co.jp/ait/articles/0812/08/news122.html
*2:オープンソースライセンスの日本語参考訳 (←2024年新サイトへのリンクに修正)
https://licenses.opensource.jp/
(NEC・姉崎章博)
第4回 「GPLのあいまいさ、って」 (2010年2月19日)
「GPLの解釈って、いろいろあって、よく分からない。」
そういう声もあって、GPLv3ができたのでしょうが、それでは本当にGPLはあいまいなのでしょうか。GPLv3では条文上の法的な曖昧さを排除しようとしたもので、それは全体の声のほんの一部だけではないでしょうか。
(以下、GPLv2を前提にGPLと記述します)
もしかしたら、「あいまい」と思われている方のほとんどが、単に分かっていないだけかもしれません。
一例を示します。
例1. 「だって、人によって言うこと違うじゃないか。BusyBoxをソース開示してないで多くの企業が提訴されたが、Linuxのソース開示しないで提訴された話は聞かないし。」
→当たり前です。
著作権侵害であるOSSライセンス違反は、親告罪です。
つまり、著作権者が侵害されたと提訴して、初めて発生する罪です。
著作権者によって、侵害されたと思うか否かは変わるものであって、
GPLの解釈が違うわけではありません。
ソース開示が必要なのはGPL条文上は普遍です。
実際に開示されていない事象に出会って、提訴するか否かが著作権者次第なだけです。
GPLの定義に従って、著作権者が提訴するわけではありません。
それでは本末転倒です。
例2. 「GPLのソースコードをWeb公開しているものとしていないものがあるし。」
→GPLのライセンス上、Web公開を義務づける直接的な記述はありません。
第3項に書かれているオブジェクトコードないし実行形式で頒布する際の条件は、どれか一つと書かれています。(*1)
a) ・・・完全かつ機械で読み取り可能なソースコードを添付する。・・・
b) ・・・完全かつ機械で読み取り可能なソースコードを・・・提供する旨述べた少なくとも3年間は有効な書面になった申し出を添える。・・・
c) ・・・(ちょっと例外的なので省略)
つまり、ソースコードは製品に添付するか、提供する旨を明記した書面を添付することのみ条文上は明記されているのです。
このb)の書面に書かれた提供方法の一例として、Webサイトでの公開があり、皆で共有してバザール的に開発しようというスタンスからコミュニティ的にはOSD(*2)の2.項で述べているように、Web公開が推奨されているのです。
> 2. ソースコード
> 「オープンソース」であるプログラムはソースコードを含んでいなければ
> ならず、コンパイル済形式と同様にソースコードでの頒布も許可されて
> いなければなりません。
(省略)
> 方法として好ましいのはインターネットを通じての無料ダウンロードです。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ソースコードは、プログラマがプログラムを変更しやすい形態でなければ
> なりません。意図的にソースコードを分かりにくくすることは許されませんし、
> プリプロセッサや変換プログラムの出力のような中間形式は認められません。
これら属人的な話が「あいまい」と言われるのであれば確かに機械処理できない法律の世界ですから、その通りです。
しかし、それはGPLがあいまいというわけではなく、著作権法など法律の世界が機械処理できないだけのことです。
それを指して「GPLはあいまい」と言われているのであれば、ちょっと違うかと思います。
*1:GNU 一般公衆利用許諾契約書
https://licenses.opensource.jp/GPL-2.0/gpl/gpl.ja.html
*2:オープンソースの定義(OSD)
https://opensource.jp/osd/
(NEC・姉崎章博)
第5回 「ライセンスって何のライセンス?」 (2010年3月19日)
「ライセンス」というと、なにか「お金を払って権利を買うもの」とイメージされている方もいらっしゃるのではないでしょうか。
そのイメージがあるために、OSSライセンスをうまく理解できない方がいらっしゃるようです。
「ライセンス」とは、広辞苑 第六版には以下のように書いてあります。
許可・免許。また、その証明書。
特に、輸出入その他の対外取引許可や自動車運転免許。
つまり、「ライセンス」とは、何らかの「許可」を表すもので、自動車運転免許の例で分かるように、お金を払って取得するという定義のものではありません。
「許可」を得るために、「お金を支払う」「資格を取得する」「契約を結ぶ」など条件はいろいろ異なります。
それは何の「許可」を得るかによって、個々に違うものです。
では、OSSライセンスとは何の「許可」でしょう?
細かいところは、個々のOSSライセンスで異なりますが、基本は、
著作物であるOSS(プログラム)の著作権(の一部)を行使(利用)することの許可
と解釈するのがキモのようです。
このことは、何かに書かれているわけでもないので、私自身、そのことに気がつくまで、すっきりしない日々が続きましたが、当たり前のことなのでしょうが、このことに気がついたことによって一気に理解が進んでように思えます。
プログラムを販売する行為は、著作権の権利の内、複製権の行使(した上での譲渡, 2014.3.24譲渡権から訂正)に当たり、これは「著作者(つまり開発者)が専有する権利」と著作権法に記載されています。(第二十一条)
その著作者が専有する権利の行使の許可がOSSライセンスであり、その許可のための条件が各OSSライセンスに記載されているわけです。
今までの記事でたびたび「著作権」を引っ張り出して説明した理由は、このようにOSSライセンスが著作権に基づいて記述されているからです。
このことを押さえておくことが、OSSライセンスを理解するポイントです。
この点を踏まえて、各OSSライセンスをもう一度読み解くと、目から鱗が落ちる、かも知れません。(^^;
P.S. 先日、セミナー講師で京都へ出張してきました。そのお客様のところではビデオ撮影させてほしい(二次利用はしない)とのことで理由をお聞きしたところ、「中小企業緊急雇用安定助成金における社内教育訓練の一貫として行う」ため、教育の確証に役所に提出するためとのことでした。
「中小企業緊急雇用安定助成金」
https://www.mhlw.go.jp/stf/newpage_04294.html
「中小企業緊急雇用安定助成金」「研修」でググると、「研修費用が無料になります」「助成金の活用 1日1人あたり最大13,685円受給の可能性」とか「休業するだけではもったいない!!」と、パソコン教室の案内などがヒットします。
一研修のために申請するのは大変かもしれませんが、申請済みの会社では、この機会に「OSSライセンス」セミナーを実施されてはいかがでしょうか。
https://jpn.nec.com/oss/osslc/OSSedu.html
(NEC・姉崎章博)
第6回 「OSSライセンス模擬試験」 (2010年4月16日)
過日のことになりますが、今年2月26日(-27日)に明星大学 日野キャンパスで開催されましたオープンソースカンファレンス2010 Tokyo/Spring(*1)にて、JLA(日本Linux協会、*2)としての後援枠で
「オープンソースのライセンス模擬試験」
を実施しました。
10分で15問の四択問題を回答いただき、残り35分ほどで回答解説したものです。
「試験」にも関わらず、*24名も* の方が回答いただきました。
結果、
15点満点で、満点2名、平均9.79点
と意外に好成績でした。
実は、内輪の者が3名参加しており、それを除くと、
15点満点で、最高12点3名、平均9.10点
が一般参加者21名の結果です。
それでも6割以上と意外に高い正解率かと思います。
さすがに、わざわざ受験に参加いただいた方々、スキルが高いです。
以下、再び24名での数字でお話します。
問題用紙、解答用紙、解答解説資料は、弊社サイト(*3)から参照できます。
15問中、5問は情報処理技術者試験からの流用していますが、問題の正答率は、最も簡単だったQ5(情処問題)の96%から、最低だったQ8(独自問題)の33%まで、様々なレベルの問題があり、誰も回答できなかった問題も、全員正解の問題もなかったわけです。
最も難しかったというQ8は、
「プログラムのバイナリのみの配布を禁止していないOSSライセンスはどれか。
ア GPL, イ LGPL, ウ Eclipse Public License, エ Apache License」
というものでした。回答状況は、以下のとおりです。
ア | GPL | 12.5% |
イ | LGPL | 20.8% |
ウ | Eclipse Public License | 33.3% |
エ | Apache License | 33.3% |
答えは、エのApache Licenseだけですから、正答率33.3%ということになります。
GNUのGPLやLGPLでさえ、ソースコードを開示せず、バイナリのみの配布でも良いと思っていた方も、33.3%もいたことになります。
第18号の第3回「訴訟とならないために、できること」でご紹介した「SFLC、Best Buyなど14社をGPL侵害で提訴」(*4)された企業では、その3割の方と同じ意識だったのでしょうね。
GPLは、派生物、つまり二次的著作物へのGPLの伝播の話がよく議論のネタになりますが、それ以前にまずは、GPLのプログラムそのもののソース開示(ソースを同梱するか、ソース提供する旨を記載した3年間は有効な書面を添付)することです。
まずは、ここから、OSSライセンスのコンプライアンスを始めましょう。
*1:OSC2010 Tokyo/Spring
https://www.ospn.jp/osc2010-spring/
*2:JLA (一般社団法人 日本Linux協会)
https://www.facebook.com/JapanLinuxAssociation/
*3:OSSライセンス・コンプライアンス コンサルティング・サービス (2024年現在、OSSライセンス コンサルティング)
https://jpn.nec.com/oss/osslc/
*4:14社提訴
https://japan.cnet.com/article/20405353/
(NEC・姉崎章博)
第7回 「遵守のための支援ツール」 (2010年5月7日)
@ITでの連載「企業技術者のためのOSSライセンス入門」(*1)の最終回では、「OSSライセンス順守のための支援ツール」を4カテゴリぐらいに分けて紹介しました。これに対して、「いつも思うんだけど流用していないのに一致してしまうコードはちゃんとスルーされるんだろうか。」というブックマークコメントをいただいています。
「一致したものを勝手にスルーは出来ません。」
本文でも「もう1つ注意しなければならないことがあります。これらの支援ツールは、あくまで検索ツールにすぎないということです。『これを掛ければOSSライセンス違反がたちどころに判定できる』などということはありません。」と書いている通りです。
機械的に判断できるようなものならば、著作権侵害で裁判など存在しませんし、著作権侵害が「親告罪」であるはずがありません。
それでも、「何十万、何百万と存在するOSSからの流用を人手でチェックすることは不可能」ですから、ツールがあると無しとでは、不可能を可能にするほどの違いがあります。
最も有効的な使い方は、「すべて自社開発し、すべてプロプライエタリなライセンスとする製品を対象にツールを掛け、1つもOSSが検出されない」ことによって、確かに商用ライセンスで販売できることを確認することです。
OSSのソースコードやインターネットで見つかるバイナリデータ(画像、アイコンなど)を含まなければ、検査時間も(サイズにも寄りますが)1~10分程度と短くて済みます。
来週、5月12日(水)~14日(金)東京ビッグサイトにて開催のESEC(組込みシステム開発技術展)2010にて、NECで扱うツール「Black Duck Protex」の動態展示と15分のステージプレゼンがあります。
ブースには私はいませんが、「すべて自社開発し、すべてプロプライエタリなライセンスとする製品」のソースコードをUSBメモリで持参いただき、
【「OBCIメルマガを見た。これを掛けてみてくれ。】
と係の者におしゃってもらえれば、その場で、OSSソースコードが検出されるか否かを検査いたします。
※ OSSを含むソースコードは検査時間が掛かりますのでご遠慮ください。
※ アイコンなどの画像データを含めても構いません。急遽発注して作成した画面インターフェースを含むプログラムをProtexで掛けて、IEのアイコンが含まれていたことを検出したこともあります。
また、「Black Duck Protex」について、じっくり説明を聞きたい方、急増するGPL違反訴訟の概要を知りたい方は、5月19日(水)に
「急増するOSSライセンス違反訴訟!実践的リスク対策セミナー」
を開催しますので、是非、お申し込みください。
*1:@IT「企業技術者のためのOSSライセンス入門」
https://atmarkit.itmedia.co.jp/flinux/index/indexfiles/osslcindex.html
(NEC・姉崎章博)
第8回 「ジャイアン理論」 (2010年6月18日)
皆さん、「ジャイアン理論」ってご存じでしょうか?
@ITの連載(*1)時に記者さんに教えてもらったのですが、
“お前のものは俺のもの、俺のものは俺のもの”
という理論?だそうです。(^^;
OSSライセンス違反、著作権侵害は、どうも、このような自分勝手な気持ちが根底に見え隠れします。
有料セミナーでお話することですが、著作権侵害を防ぐ基本姿勢は、
「他人のものまで、自分のものかのように主張しない。」
ということだと思います。
例えば、昔の使用許諾書には、
「本製品に含まれる知的財産権は、XX社に帰属します。」
という文言をよく見かけますが、これだけでは、製品に含まれる他社の知的財産権もOSS開発者の知的財産権も無視し、すべてこのXX社の知的財産権かのような主張になっています。
そう、「お前のものは俺のもの」と主張してしまっているのですね。
Windows XPの使用許諾書(EULA)でさえ、「他人のものまで、自分のものかのように主張しない。」ように気を配って「ただし書き」があるのは、ご存じでしょうか?このように書かれています。
ただし、本ソフトウェアに含まれている、
または本ソフトウェアから入手可能なソフトウェア、ドキュメントまたは
Webサービスに独自の使用許諾契約書または使用条項が付属している場合は、
その付属の使用許諾契約書または使用条項に準拠します。
IE6のヘルプを開くと、"NCSA Mosaic"のクレジットが見えていたと思います。
IE8でも「警告:この製品は、著作権に関する法律および国際条約により保護されています。この製品の全部または一部を無断で複製したり、無断で複製物を頒布すると、著作権の侵害になりますのでご注意ください。」と書いて、マイクロソフト社の著作物とは書いていないのです。
それは、マイクロソフトの著作物もありますが、NCSAの(Mosaicの)著作物などもあるからだと思います。
このような書き方をして、安易にジャイアン理論を振り回したことにならないように気配りをした記載を心がけていただきたいと思います。
開発者の方は、使用許諾書など気になさらない方もいらっしゃるかもしれませんが、一度、開発製品の使用許諾書の記載を見直してはいかがでしょうか。
*1:「企業技術者のためのOSSライセンス入門」
https://atmarkit.itmedia.co.jp/flinux/index/indexfiles/osslcindex.html
(NEC・姉崎章博)