OSSライセンスMeetup Vol.3「知財部門から見たOSSライセンス」参加レポート

2019年6月11日（火）に開催されたOSSライセンスMeetup Vol.3「知財部門から見たOSSライセンス」の参加レポートをお届けします。

OSSライセンスMeetupとは

その名の通り OSS（Open Source Software）のライセンスに関するテーマを扱うMeetupです。一口にOSSライセンスと言ってもさまざまなものが存在し、エンジニアだけではなく知財部門などのいろいろな立場の方も巻き込んで理解が必要なものだと思います。そういう意味でこのMeetupは、ありそうでなかったものですし、とても貴重な場だと思います（参考：Vol.1のレポート、Vol.2レポート⁠）⁠。

今回は「知財部門から見たOSSライセンス」というテーマで、前半は「⁠『⁠知財部門』とOSS⁠」⁠、「⁠OSSライセンスとの格闘経験から⁠」⁠、「⁠（⁠元）特許部門担当の視点から」という3本のセッションでした。知財という、エンジニアから見ると残念ながら少し煙たいと思われがちな部門の方の視点で見たOSSライセンスと、エンジニアとの関わり方についてのとても興味深いお話です。

後半は『知る、読む、使う！オープンソースライセンス』などOSSライセンス関連の著作を持つテクニカルライター可知豊さんと共にディスカッションとなりました。

セッション1：『知財部門』とOSS（大崎雅行さん）
セッション2：OSSライセンスとの格闘経験から（大内佳子さん）
セッション3：（元）特許部門担当の視点から（大崎雅行さん）
オープンディスカッション（司会：可知豊さん）

Meetupの雰囲気

今回も人気が高く参加枠が増枠され、当日キャンセルも少なく70人近くの人が詰めかけました。参加者の皆さんが講演者の方の話を熱心に聞き入っていただけでなく、その後のディスカッションでも積極的に発言をされていたことからも、このMeetupに対する期待や熱を感じました。ライセンスの話と聞くと難しくてカタイものを想像してしまいますが、参加している方々も、エンジニアはもちろん研究者や会社の法務担当と多彩で、参加することが楽しかったです。

セッション1：『知財部門』とOSS

はじめに、大崎さんから知財部門とOSSライセンスの関わりについての短いセッションがありました。

知財部門というのは、一般的には企業で「知的財産関連業務」（⁠権利確保／侵害予防／情報分析／契約支援など）を担当していて、企業によりそれぞれ異なるビジネス形態に合わせて支援を行うとのこと。では、このような業務を行う「知財部門から見たOSSライセンス」とは？というのが、このあとのセッションで語られました。

セッション2：OSSライセンスとの格闘経験から

大内さんから、これまでOSSに関係した経験と知見について1990年代から振り返っていく、という内容でした。

1990年代はパソコン通信からインターネットの時代への移行が進み、LHAなどのフリーウェアの利用が一般的になりました。2000年代になると徐々にOSSが利用されるようになってきたことから「これからOSSの相談がどんどん増えてくるだろう」ということで、SE部門のOSS知財担当に大内さんが抜擢。そこで「SE部門の知財担当者がライセンスをきちんと理解できるように」とコーポレート（親会社）の知財担当者とライセンス文章の読み合わせを始めたそうです。

ところが、まずはBSDライセンスを読み始めてみると読み解くのが結構難しく、いくつもの疑問が。

「変更するかしないかを問わず」って、結局は変更を許諾するってこと？
条件一覧や免責などを「含める」って、どういうこと？ “⁠retain⁠”と“⁠reproduce⁠”で何か違う？
変更を許諾するのにソースコードは出さなくてもいいの？

では、他のOSSライセンスではどうかということでGPLについても調べてみたところ、GPLの伝播の範囲については、フリーソフトウェア財団（FSF）のサイトにあるFAQを見ても「これは法的な問題であり、最終的には裁判官が決めることです」と書かれているなど、結局はっきりした解釈を見つけることができなかったそうです。このため、パターンはあるにせよケースに応じて判断する形で対応されていたといいます。

2010年代になると社内コミュニティ活動が活発な時代となり、いよいよOSSの相談案件が増加してきたために社内にOSSのWGを立ち上げて相談対応のシステム化をすることに。OSS自己チェックシステムと呼ばれるものは、次のことを目指して開発されました。

SEが自らOSSのライセンス条件の遵守可否を判断できる
OSSの情報を顧客向けのドキュメントに記載できる
OSSの利用をお客さまとの契約に反映できる
責任者が上記の1～3の対応を確認できる
上記の1～4の記録を残せる

このシステムはOSSのライセンスに関するそれまでの知見などを蓄積しているのですが、DB化のためにライセンスの調査をしてみたところ、配布サイトと実際のソースコードで記載されているライセンスが違うなど一筋縄では行かず大変だったそうです。なお、このOSSのライセンスDBを作るためのツールは会社の偉い人がExcelマクロベースで作ったためにOSSにできていない、というこぼれ話も。

さらに問題なのは、ライセンスはFSFが決めるのではなく個々のOSSの開発者が決めるもの。それなのに開発者自身がライセンスをわかっていないことが多い、ということだそうです（たしかにそういう傾向はあるかもしれないなと思います⁠）⁠。

そして、コーポレート知財部門の担当者が他の部門へ異動されたため、大内さんはその後任としてIPAリーガルWGのメンバーになりました。その時に作成に関わったのが「OSSライセンス遵守活動のソフトウェアライフサイクルプロセスへの組込み」というレポートです（OSS ライセンス遵守活動（共通フレーム 2007 版）はかなり細かく書かれていて、現場でもかなり参考になる内容だと思います⁠）⁠。

さらに、大内さんのグループはSE部門からコーポレート部門へ組織ごと移りました。

OSSの社内システムを全社へ展開して管理し、社外コミュニティ活動が活発になると同時にOSSコミュニティへの投稿に関する社内ルールの明確化が必要となってきたため、「⁠OSSコミュニティ参加ガイドライン」を作成されたそうです（⁠「⁠【CEWG】OSSコミュニティ参加について」参照⁠）⁠。

この頃から大内さんはさらに、オープンソースライセンス研究所の活動にも参加をされています。2015年には「技術用語解説分科会」を立ち上げ、技術用語の用語集作成を始めました。こちらは「OSSライセンスを理解するための IT用語の基礎知識（⁠法務・知財部門向け）Ver.3」として2019年3月に公開されています。

また、2016年には「ライセンス深掘り勉強会」を立ち上げられて

著名なライセンス文書の読み込みを行う
お互いに疑問点について、意見交換をする
最後に一覧表にまとめる

といったことをされているそうです。

SOFTIC（ソフトウェア情報センター）で2015年にIoT時代におけるOSSの利用と法的リスクに関する検討委員会では、「⁠IoT時代における OSS の利用と法的諸問題Q＆A集」の作成にも参加されています。こちらの文書はこのMeetupの1回目でも紹介されていたのでご存知のかたもいらっしゃるかもしれませんが、OSSの利用についてのさまざまな知見がまとめられています。

現在はOpenChain Japan WGでの活動にも参加され、FAQサブグループで「OSSライセンス関連でよくある誤解v2」の作成に関わられています。

セッション2のまとめ

最後に、個人の意見としながらも

システム化で、工数をかけずにOSSを利活用できるようにしたい
優秀な技術者が事務作業で工数を取られるのはもったいない

ということを述べて、理想的なOSS管理システムの姿として

ライセンスや著作権情報を簡単に抽出できるようにする
OSS情報を記載した顧客向けドキュメント、ファイルを自動作成する
自社プログラムにOSSライセンスが伝播するなど、確認が必要な場合はアラームをあげる

ということを挙げられていました。またOSS開発者に対しては、OSSのソースコードにライセンス情報（SPDXの識別子）を記載する（配布時はライセンス文書を付けるのも忘れずに!!）というメッセージで、セッションを締めくくられました。

セッション3：（元）特許部門担当の視点から

3本目のセッションは、大崎さんから特許部門からOSSコンプライアンス部門に異動して得た知見を、「⁠（⁠元）特許部門担当の視点から」振り返るという内容でした。

特許というのは、

さまざまな段階で費用と検討が必要なため、管理が重要
1件1件について、特許庁の審査というフィードバックがある
スライドには示していない最大のコスト：評価コスト（出願・中間・権利化後……）

という特徴があり、それぞれの企業で組織として対応しているというお話でした。

コストの部分については、たとえば、特許は国ごとに取る必要があり、国ごとにお金がかかるという話の中で「中国で特許出願しても権利行使しないと、日本企業のお金で技術文書を中国語訳してあげるだけになるんですが、それをわかってもらうのがなかなか難しい」「⁠中国への出願を絞ったとしても、日本特許庁のサイトに一番アクセスがあるのは中国・韓国の企業」と話されていて、とても興味深かったです。

特許部門について

特許部門はお金をかけて特許を取りに行く部門なので、「⁠動けば『結果』が見えてくる仕事」という表現をされていました。ただし「結果」として取得した特許がビジネスで意味を持たせるかが難しい、とのコメント。

また、特許について他社とのやり取りを行うライセンス交渉については「いま、クロスライセンスはほとんどやっていません。必要なときは戦う。それを前提に、出すべき特許や使うべき特許はきちんと見定める。今から振り返ると、各社が毎年数千件の出願を行っていた、あのクロスライセンス全盛の時代はなんだったのかという話もあるのですが」と話されていて、時代の変化というのはこんなところにも及ぶのだなと思いました。

特許部門担当としてのおもしろさ

特許部門担当としてのおもしろさとしては、世の中に出ていない「研究・開発」に真っ先に触れられることや、1件ごとに審査結果というフィードバックがあること、「⁠特徴ある」方々との仕事ができることとのこと。また、特許部門担当として要求されること（やりがい・充実・辛さ）としては、相談内容を権利化するための勉強＆理解を常に行う必要があること、製品やサービスの発表やリリースに合わせて短手番での出願を行う必要があること、特許情報に基づく種々な分析を行うこと、出願する案件を判断するにあたっては、さまざまな意図（戦略・ノルマ・自己顕示 etc.）に応じた対応をする必要があること、だそうです。

ノルマとして管理されている特許出願について

特許出願がノルマとして管理されていることについては「数の勝負じゃない昨今、実がない感じなんですが、なくしてしまえば問題が解決するわけでもない。通常は、主力ではないエンジニアに特許出願のノルマが割り当てられるのですが、期末になり部門のノルマ達成が難しくなると部門のトップエンジニアが出てきて1、2日でいいもの書いて帰っていって、そういうのが有用な特許になったりする」と「決してノルマ＝悪という単純な話ではない」という興味深い意見が出ました。特許の価値については、「⁠出願件数やライセンス収入の額は価値の評価としてはわかりやすいが、数字を出すとそれが独り歩きしてしまう。けれども、それが会社の価値ではないことは各社の特許部門の人間はわかっていて、それぞれに工夫している」ともコメントされていて、エンジニアとは違う視点で見てみると特許というのはとてもおもしろいものだと思います。

OSSコンプライアンス部門について

コンプライアンス部門として、製品やサービスの出荷前に確認を行うことを「門番」と表現されており、「⁠門番」の難しさとして、チェックを確実にするほどビジネスのスピードを損なってしまうことを挙げられていました。また、コンプライアンス部門の活動はリスクを事前に防ぐことにあるのですが、活動結果が形となりわかりやすい特許部門と違い、OSSコンプライアンス部門が活動した結果は見えにくいことを「⁠『⁠事前に塞いだ穴』は見えにくい」と例えて説明されていて、わかりやすかったです。

OSSコンプライアンス部門担当としてのおもしろさ

OSSコンプライアンス部門担当としてのおもしろさとしては、OSSコミュニティに触れること、開発だけではないOSSへの関わりがあること、OpenChainやOIN（Open Innovation Network）というような複数企業が協力した活動があることを挙げられていました。また、OSSコンプライアンス部門担当としての要求（やりがい・充実・辛さ）としては、「⁠OSSへの取り組み」支援の価値について社内で理解をしてもらうことが難しいこと、特許と違い社外との協力を行いやすこと、だそうです。特に「OSSへの取り組み」支援の価値が評価されづらいというところは、聞いていて自分でも変えていかないといけないところだなと感じました。

社外の方々との協力としては大内さんと同様にOpenChainプロジェクトでの活動を挙げられ、理事会のメンバーとしてJapan WGで各企業の方々と共同検討・議論されているそうです。この活動でのおもしろさとしてOSSコンプライアンス推進もコミュニティ貢献であるとして

各社のOSSコンプライアンスへの取り組みを支援する活動は、OSSのコミュニティ全体に対する貢献
失敗事例（含ヒヤリハット）の共有が可能
共同で、対応策・教育・仕組みについて検討可能

といったことを挙げられていました。

セッション3のまとめ

知財の特許部門とOSSコンプライアンス部門のそれぞれで働いてみて共通すること、異なることとして

会社としての価値、個人としての貢献
個人としての取り組み、組織としての仕組み

と述べて、セッションを締めくくりました。

ディスカッション

イベントの後半は講演者の大内さんと大崎さんを交え、可知さんをモデレータに迎えてのディスカッションでした。会場から出された質問と回答、会場での議論を筆者からいくつかピックアップしておきます。

Q：開発者が外から持ってきたもののライセンスの話ではなく、社内からどのライセンスで出すか？という問い合わせはあるか？: A：問い合わせはある。一緒に使うソフトウェアなどとの組み合わせなどを考えて提案する。何も決めていない場合、Apache Licence 2.0をおすすめしている（Twitterでの中継で「GPLをお勧めしている」とあったものがありましたが、正しくはApache License 2.0です）
Q：OSSライセンスを使用したものについて、反社会勢力に使わないという条項を追加することで、使われても無関係を主張することはできるか？: A：ライセンスに利用目的の制限を付けた場合、OSIによるOSSの定義十ヶ条に「利用者を区別（差別）しない」というのがあり厳密なOSSではなくなってしまうので、反対されるかもしれない。; （会場から⁠）⁠：「反社会勢力はダメ」って書いてもそもそも法遵守する人ではないので、考えるだけ無駄かも。下手に書くと普通に使う人たちが迷ってしまう。
Q：「OSSの定義に沿わないけどマーケティング的にOSSと呼びたい」みたいな要求があったときは？: A：私たちの部署では、ライセンス条件を守って使ってくれ、を徹底するところが領分。フリーウェアであってもライセンス条件を守ることは同じ。なので、OSSの定義に沿わないものをライセンスは守らなければならないという点では変わりはない、という意味でOSSと呼ぶこともある。
Q：OSSを改変して使うときに、改変するコードに特許出願した発明が含まれる場合の整理事例などは？: A：OSSコミュニティ参加ガイドラインでは、各部門の知財担当者に了承してもらったうえで、改変したコードをコミュニティに還元する進め方を取っている。OSS活用と特許権の行使のどちらが会社としてメリットが大きいか考えてもらう。; A：修正コードをコミュニティに還元するかしないか現場判断。OSS活用の場合は、コミュニティに対して権利行使しないことをどうわかってもらうかにも配慮する。
Q：受託開発の契約書は大抵「著作権譲渡」と書いてある。OSSライセンスは著作権法に基づくから、組み合わせるとややこしいことが出てきそう。そういう話題は？: A：話題になったことはない。ただ著作権を全部譲渡とはしてなくて、既存のものを使うときはその著作権は残る契約にしている。
Q：開発者からすると知財部門は煙たい部署。CLAに同意するとFAXだのPDFだの前例のある手段に拘り交渉したくない。そう感じる開発者への歩み寄りは？: （会場から⁠）⁠：知財の弁理士ですが、できるだけ歩み寄るスタンスなのですが、どうすれば歩み寄れるでしょう？; A：大内さんの部門の動きを見ていて感心したのが、現場の巻き込み方。例えば、各部門に特許・OSS・契約などの教育を受けたリエゾンを育てている。知財部門は相談が来なければ動けないが、リエゾンの人たちが現場の担当から相談を受けたり、知財部門に相談すべきかをアドバイスしたり、というような、柔らかい窓口、クッションになってくれている。普段相談してる人が間に入ることで、うまくコミュニケーションが回り、手遅れになるまで相談しない状況を避けられる。; （会場から⁠）⁠：法務とかも同様な部署だと思う。法務の人が言ってくれたのが「ダメだ」ではなく「やっていいよ」を言う、そのために根拠を組み上げるのが自分たちと言ってくれて、うまくやれるようになった。
Q：Dockerイメージを使うときに、OSSのライセンス・その同梱物に対するライセンスなど、どう扱っていいか悩む。ベースイメージの扱いとかの議論はないか？: （会場より⁠）⁠：多分Linuxディストリビューションに似た問題。再配布については同じように捉えるのがスジがいいと思う。
Q：Dockerイメージは差分ファイルなので、OSイメージが含まれないので、再頒布に当たらないのでは？: （会場より⁠）⁠：そうなんですけどねえ、裁判所がそう判断してくれればいいのですけどねえ。; A：バンドルのライセンスを調べるの大変という相談は受けるのですが、でもやってくださいと言う。
Q：OSSも巨大化して人手で調べるのはなかなか難しい。例えばリスクの大小で自部門で判断か知財で判断かみたいな線引きは？: A：ビジネス面も合わせての判断なので一律の線引きはない; A：事前の質問では、「⁠企業ではGPLはNGでしょうから」というような質問もあったが、例えばソースコードも納品するSIではGPLでも問題はなく、個別案件の状況に応じた判断をしている。

逆に知財（講演者側）からエンジニアに聞いてみたいことも話し合われました（以降、Qは講演者、Aは会場）

Q：使うOSSをどう探しているのか？: A：「機能で探す。同等機能を実現しているものが使っているライブラリを調べる」「⁠トレンドを追う。GitHubのStarsとか⁠」⁠。; A：見つけたら、API見て、ソースコード見て、最悪自分でメンテナンスできるか考えたりする。
Q：そのときにライセンスは見ている？: A：一応見ている。; A：SCSKのOSSレーダースコープを参照している。; A：Debianのmainコンポーネントに入っているかを見ることがある。ライセンスが比較的クリアで、売っていいものしか入ってない。
Q：OSSには「利用する」「手元で改変する」「Upstreamに入れる」といった複数の段階があると思うが、その割合はどんな感じなのでしょう？: A：GitHubにてPull Requestした人は2桁、コントリビューターは1、2名ぐらい（これでも「会場は濃すぎ」との声⁠）⁠。; A：OSS Gateというコミュニティを運営しています。月数名のコントリビュータが生まれているけど、継続する人は稀。だからOSS利用企業は改変したらアップストリームに戻せ、という文化を醸成してほしい。; A：Upstreamに戻す、Upstream First。そうすることで最終的にはコストが低くなる。秘伝のタレ化してしまうと、Upstreamが方向性を変えたときにそれに追従するのに手間がかかってコストが非常に高くなる。; （会場より⁠）⁠：過去に法務などに「こう言われたのでやってやるか」という事例や言い回しがありますか？
Q：逆に、法務などに「こんなことを言われた」（のでやってられない）という事例がありますか？: A：OSSにしたいのだけど、と法務に相談したら「ライセンス？なにそれ？」と言われた。担当弁護士も同様。; A：OSSは「AS IS」とライセンスで規定されているように自己実施責任。それについて、エンジニアに「これ会社で使ったら会社の責任になるんやで」と言うと、なんでやらされるのか腹落ちしてやってくれたりした。; A：お互いに巻き込み、仲間作りが必要。1人ひとりが草の根で動く。両方が歩み寄る。; A：「部門 vs 部門」ではなく「問題 vs 我々」という考え方で取り組む。部門が違うと問題意識も言語も違うから、そこから揃えないと「我々」になれない。伝わる言語で相手に伝えてあげることが大切。

最後に講演者のお2人からの感想として

大内さんからは「こんなにライセンスに興味を持っている人がいるのにまずびっくりした。非常に勉強になった⁠」⁠、大崎さんからは「質問の中で『Dockerイメージに含まれるOSS全てについてライセンスを確認するのか』という話があったが、今は個別にライセンスを何とか確認していけても、5年後や10年後には、使用するOSSの数は今よりも格段に増えて、個別のライセンスを確認するいまのやり方ではうまくいかなくなるときがくる。そのときに先のやり取りにあった、知財部門と開発部門との間で協力をするような活動が重要になると思う」とお話をいただきました。

懇親会

今回のMeetupでの懇親会は、ディスカッションが非常に盛り上がったために少し短い時間で行われました。筆者は翌日の仕事があるため、懇親会には参加せずに帰りましたが、Twitterや他の方のブログなどでの反応を見る限り、いつもどおりソフトドリンクやスナック菓子を片手に参加者同士、あるいは発表者らとざっくばらんに語らう形で行われたようです。

あとがき

今回のMeetupに参加してみて、会社に戻って知財の人と話をしてみるまでがMeetupだと思いました。セッションもその後のディスカッションも、いつもどおりの濃い内容でとても良かったです。OSSのライセンスというテーマで、これだけの人が参加するのは、それだけ多くの人が関心があるけど、どうしていいかわからないと悩んでいる証拠なのではないかと感じます。OSSライセンスについてもっと多くの人に関心を持ってもらいたいですし、多くの人が知る機会を提供する場としてこのMeetupがこれからもより盛り上がっていくと良いなといいなと思いました。

最後になりましたが、講演者、スタッフ、参加者の皆さま、ありがとうございました！