はじめに

この記事では、Open Source Compliance に取り組む上で、役に立った情報や、役に立つよと紹介頂いた情報をまとめます。この記事にあるものだけが全てではありませんが、いくらかでもお役に立てば幸いです。
なお、本稿中の OSS はとくに断りがなければ Open Source Software を意味します。

この記事は全体で上下2部構成になっています。

Open Source Compliance のお役立ち情報まとめ・上 (前の記事)　

• Open Source & Compliance
• Open Source Software
• Open Source Software License
• ツールなど

Open Source Compliance のお役立ち情報まとめ・下 (この記事)

• 業界的な集まりなど
• イベントや会合など
• ニュースや書籍など

Open Source Compliance のお役立ち情報まとめ・下

業界的な集まりなど

Open Source Compliance について、特定の業種による団体や、特定の目的のための団体が知られています。

Fintech Open Source Foundation (FINOS)

金融業界を中心としてOSSの利用を促進する団体です。”Open Source License Compliance Handbook” などを公開しています。

Open Invention Network (OIN)

OIN参加企業同士は Linux Stystem として定義される OSS について自社が保有する関連特許に関して争わないとするコミュニティです。設立当初は Microsoft 対 Linux 陣営の構図でしたが、2018年10月にMicrosoftが加入したことで、この構図は NPEs* 対 OIN参加企業に変わっていくのかも知れません。
(*: Non-Practicing Entities、いわゆるパテントトロール)

参考： Steven J. Vaughan-Nichols , “Open Invention Network comes to GNOME’s aid in patent troll fight“, ZDNet, 2019.

Unified Patents

NPEsへの各種対抗措置として、先行技術調査、訴訟の分析、USPTO(米国特許庁)の審判部(Patent Trial and Appeal Board: PTAB)に当事者レビュー(Inter Partes Review: IPR)を提出するなどで特許無効化を図ったり、NPEと交渉するなどのサービスを提供します。2019年には対象とする技術領域に Open Source が追加されました。
活動状況のダッシュボードとして PORTAL があり、そのページの最下部に “Daily Update Email Archive” へのリンクがあります。また、PATROLL では、先行技術調査のコンテストに関する情報が得られます。

イベントや会合など

会ってでないと話せないこと、会ってコミュニケーションが深まるきっかけになったり、参加したから知ることができること、などがあります。都合がつけば、こうした集まりに足を向けてはどうでしょうか。 会合によっては Chatham House での情報交換の取り決めに由来する Chatham House Rule に従うことを求めるものがあります。

When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.
(参考訳：会議あるいはその一部であっても Chatham House Rule に従う場合、会議参加者はその会議で集まった情報を自由に利用できる。しかし、(情報提供者となる)発言者については勿論のこと、他のいかなる会議参加者についても、その身元(素性)や所属を漏らしてはならない。)

このルールについては Chatham House Rule FAQ も読んでおくと良いでしょう。信頼できる仲間だからこそ話せることもある、といったところでしょうか。

Linux Foundation events

Linux Foundation が開催する次のイベントでは、セッションのトピックや、会合それ自体が Compliance をテーマとするものがあります。

Open Source Summit

毎年、Japan、North America、Europe などの各地域で開催されます。スピーチやセッションによっては、講演ビデオや資料が公開されます。Compliance をトピックとするセッションがありますが、Keynote やそれ以外のセッションでは実に様々なトピックが扱われ、エンジニアに限らず様々なバックグラウンドの参加者が集まるので、 情報収集やネットワーキングに有益です。2019年はすべて終わり(Japan(7月), North America(8月), Europe(10月))、2020年の開催がすでに案内されています(North America(6月), Japan(9月), Europe(10月))。

Open Compliance Summit

名称が示すとおり、Compliance を主テーマとするイベントです。毎年日本で開催されます。招待状を申し込む必要があり、その参加には “Chatham House Rule” に同意する必要があります。 本稿執筆時点で次回は 2019年12月17-18日に開催されます。

オープンソースライセンス研究所

ほぼ毎月、次の勉強会や分科会が開催されています。新着情報に開催案内があります。資料の共有範囲は参加者に限定されるので、興味がある方は参加してみてください。

ライセンス深掘り勉強会

OSSライセンスを一文ずつ読み、参加者同士で知見を共有したり議論する集まりです。弁護士も参加されるので法的な視点でのお話を伺うことも出きます。議論を通じて理解が曖昧な部分が浮かび上がる時は、これまでの自身の実務でどうだったかを振り返るよい機会になります。

OLL技術用語解説分科会

OSSライセンスに関わる法務や知財の担当者向けに、技術用語の理解のための補助資料を作成する集まりです。

OpenChain Japan Work Group (JWG)

再掲になりますが、JWG にはいくつかの Sub Work Group の活動があります。関心があれば気軽に参加頂ければと思います。 　

ニュースや書籍など

近年、Open Source Software の提供元がそれまでのライセンスを変更して新たなライセンスを作成する事例が見られます。そうした情報の収集にはインターネットの利用が欠かせません。

技術系のニュースサイトは見ていても良いと思います。二つ以上のサイトを利用されていれば、Open Source Compliance で話題になりやすいライセンスについては時期に差があるもののおそらく記事として目に触れるのではないかなと思います。とくにお薦めできるサイトというのは気にしたことがないのですが、英語圏のものが早いかなとは思います。なお、日本語で読めるものの例だと OSDN Magazine の ライセンスカテゴリの記事などがあります。

僕自身は、Google アラートを “open source” や “OSS” などのキーワードで活用しています。

一方で、必ずしも最新の話題がないとしても、まとまった情報をざっと読み通せるということで書籍を利用する方もいるでしょう。一部、僕が未読のものもありますが、僕が参加する集まりで話題に挙がったものも含めて紹介します。出版元を見つけられなかったもの以外は、リンク先を出版元にしています。お手数ですがご購入の際はご利用されている販売店やそのサイトでお求めください。

OSSライセンスの教科書

著： 上田理、監修： 岩井久美子
出版社： 技術評論社　
2018年に出版なので、今回紹介する日本語書籍の中では新しいものです。主な Open Source Software License の特徴と、企業が Open Source Software を活用する上でのポイントを解説しています。冒頭の岩井弁護士による解説記事は、エンジニアが法務・知財部門のスタッフとコミュニケーションを取る前の読み物としてお勧めできます。
なお、著者の上田さんは先に紹介した 「オープンソースソフトウェアライセンス遵守に関する一般公衆ガイド (pdf)」 の作成のリーダーです。

ところで、僕は JIPA ソフトウェア専門委員会にも参加しているのですが、そこに参加する他企業の知的財産部員でも読んでいる方が多いです。読者の近くに知財部員の方がいれば、JWG に一度顔を出してみてはどうかと案内して頂けると幸いです。

角川インターネット講座２ ネットを支えるオープンソース ソフトウェアの進化

監修： まつもと ゆきひろ、他著
出版社： KADOKAWA/角川学芸出版
(恐縮ながら僕は未読です。JWG で話題に出たことがあったので紹介します)

2014年に出版で、それまでのオープンソースとそれを取り巻くソフトウェア開発の歴史を俯瞰できるようです。
第2部では、ライセンス、ブラウザ開発動向、企業におけるオープンソースとの付き合い方、などの話題を扱っています。

なお、著者の一人のやまねさんは、企業所属エンジニアかつ Debian JP Project のコミッターとして双方の視点で JWG に知見を与えてくれる貴重な存在です。ただ、やまねさんのような方は貴重すぎて JWG の各活動でなかなかお会いできないので、読者の中で我こそはと思う方は JWG に参加ください。もちろん OpenChain に興味があるというところからの参加も大歓迎です。

知る、読む、使う！ オープンソースライセンス

著： 可知豊
出版社：達人出版会
2011年に出版で、電子書籍として購入出来ます。
Open Source Software License で利用例が多いと思われる MIT、BSD系、MPL-2.0、GPL系などを概要を掴むには便利です。

Understanding Open Source and Free Software Licensing

Author: Andrew M. St. Laurent
Publisher: O’Reilly Media (July 2008)

著者は米国弁護士です。米国著作権法に関連した知識を踏まえて OSS ライセンスを理解するのに利用しました。
Open Book版 もあります。

Open Source for Business: A Practical Guide to Open Source Software Licensing 2nd edition

Author: Heather Meeker
Publisher: CreateSpace Independent Publishing Platform; 2nd edition (April 4, 2017)
著者は TLDRLegal にも参加している米国弁護士です。こちらも米国著作権法に関連した知識を踏まえて OSS ライセンスを理解するのに利用しました。

Open Source Compliance in the Enterprise (2nd edition)

Author: Ibrahim Haddad, PhD
Open Source の利用に当たって必要となる、それが何かを具体的に識別(Identification)し、 どのようなものかを監査(Audit)し、問題点の整理等々に始まる一連の工程において、そこでのプロセスや注意点、また、ツールや参考情報などが得られます。

Assessment of Open Source Practices as Part of Due Diligence in Merger and Acquisition Transactions (2nd edition)

Author: Ibrahim Haddad, PhD
Merger and Acquisition（M&A）での Due Diligence で Open Source 関連事項を評価する時のポイントが整理されています。

明日のテーマは

「オリンパスとOpenChainとの関わり」です。
担当の小泉さんは、JWG で4つの SWG に参加されるなど八面六臂に活躍されています。オリンパス社はグループとしてグローバルに Open Source Program Office の体制を構築し運用されているので、その一端を垣間見ることが出来るかもしれません。お楽しみに！

おまけ：自己紹介

忍頂寺です。所属等は別記事「Open Source Compliance のお役立ち情報まとめ・上 (12/14公開記事)」を参照ください。

The OpenChain Reference Tooling Work Group held its 17th meeting on the 17th of June.

You can find the recordings of the morning and the afternoon sessions as well as the presentation slides here:

https://github.com/Open-Source-Compliance/Sharing-creates-value/tree/master/Tooling-Landscape/Meeting-Material/Meeting-20200617

Catch up on minutes from all previous meetings

• https://github.com/Open-Source-Compliance/Sharing-creates-value/tree/master/Tooling-Landscape/Meeting-Material

ISO Standard Imminent

This is a guest post from Matthew Jacobs, Esq., Director, Legal Counsel at Synopsys Software Integrity Group. The views in this guest post are those of the author alone.

The goal of the Linux Foundation’s OpenChain Project, and the specification it maintains, is to promote predictability and uniformity in the management of open source. It aims to also create consistency in how critical open source compliance information is collected and retained so that it may be properly communicated to others.

The specification is gaining momentum and will likely be adopted by the International Organization for Standardization by mid-2020. With open source use on the rise and more and more demanding proof of compliance becoming mainstream, this is a perfect time to reevaluate how you address compliance. But first, let’s explore an illustrative analogy.

The automotive supply chain.

Car recalls are costly and time-consuming events. However, considering the complexity of today’s vehicles and the number of components found in the average vehicle, recalls often seem strikingly well organized. In particular, the level of detail and granularity in the typical recall notice speaks to the information that must be obtained by automotive manufacturers from their multitudes of suppliers, and then maintained and stored regarding the elements composing the bill of materials (BOM) of each car.

The very fact that recalls are successful at keeping the public safe is a testament to the incredible level of information sharing from supplier to customer and the standards and trust between the parties. Parts from different tiers of the automotive supply chain, and the component sub-elements of those parts (and so on), must be identified and important information about those parts shared up and down the supply chain. Given the sheer volume and complexity of this, and the rapid evolution of the industry, an automotive manufacturer must rely heavily on their suppliers to provide comprehensive and accurate information concerning that supplier’s respective elements. The final BOM for a given vehicle is dependent on comprehensive information communicated in a common language by members throughout the vast supply chain.

Contrast this to software.

Much like assembling a vehicle, modern software development involves software components from a wide variety of sources. This may be third-party commercial code, “homegrown” code or, as is very often the case, significant amounts of open source code. Tracking the provenance of the multitude of software parts and pieces that make up the modern software programs that we interact with and rely upon is often murky at best.

This challenge is clearly compounded by the fact that each component of software, with its own constituent elements, is then rolled up into a more complex assembly with other software elements. Further, since an ever-growing amount of this software is open source which, by design, is the product of often many mostly anonymous contributors, it quickly becomes easy to see how assembling a reliable BOM for today’s software programs is a daunting challenge.

Open source challenges.

Developers are encouraged to reuse open source to do their jobs better, faster and cheaper. There are around 8,000 source forges housing over 500 billion (and growing) lines of open source code to use. Importantly, those reusing open source must confirm initially, and on an ongoing basis, that they are reusing that open source in compliance with the governing open source license terms and conditions. Given that there are approximately 2,700 different flavors of open source licenses, a real challenge arises in (1) managing these compliance risks at an enterprise scale and pace, and (2) effectively communicating to third parties what open source is being used, what license applies and if the user is complying with the applicable license.

Given the critical nature of open source in software development, and the large and growing amount of open source in use, the need to be able to express what open source is being used (the BOM) and any license compliance obligations associated with that use, in addition to the need to be able to communicate that information in a standardized way is key to the free flow of software components in the software supply chain. And, to avoid “garbage in, garbage out” customers need to have confidence in the information received from suppliers based on trust in the compliance processes employed upstream. The OpenChain Project has emerged as the leading voice in bringing organization and certainty to the tracking and communication of open source reuse.

The OpenChain Specification (now in version 2), as described by the OpenChain Project, defines “the key requirements of a quality Open Source license compliance program. The objective is to provide a benchmark that builds trust between organizations exchanging software solutions comprised of Open Source software”. The specification sets forth a basic set of open source management best practices and methods for communicating open source component information, all aimed at furthering that trust.

Managing open source risk.

The value of this trust cannot be understated. Again, much like the automotive supply chain, the software supply chain is highly interdependent and complex. Historically, customers attempted to mitigate their risk during the contract negotiation process by forcing their suppliers to make certain disclosures, representations and warranties concerning that supplier’s software product and the supplier’s compliance with any open source licensing requirements for the open source in that supplier’s product. Supplier’s often don’t have the requisite insight into the composition of their own code, especially as it relates to open source, to make these types of representations and warranties with certainty but bow to economic and time pressure to close a deal.

Occasionally, customers will enlist firms like Synopsys to perform an independent audit of their supplier’s code to confirm that the disclosures made by the supplier concerning the open source in their products is accurate. The purpose of an audit is to identify the open source in the supplier’s code and determine which one of the many open source licenses apply to that code to evaluate the supplier’s compliance with the obligations of the applicable license. It also, by implication, gives customers a sense for how well the supplier is managing compliance. This “trust but verify” approach is certainly warranted in some situations. But, given the pace of commerce, there is often little time for comprehensive due diligence in many of the routine day to day transactions.

Elements of the OpenChain specification and compliance.

The OpenChain specification short-cuts much of the negotiation around a supplier’s open source compliance by offering a basic set of understandings around how each member of the supply chain uses and tracks what open source is present in their products. The specification is comprised of two basic elements: First, an ongoing open source license compliance process (which may include the use of automated open source management tools) for identifying what open source is in that member’s code and verifying that the use of that open source complies with the applicable license for that code. Second, the specification requires an organizational commitment to adherence to the first element by establishing areas of responsibility within an organization for compliance and an organizational commitment to training, process and open source compliance support.

Executing on these two basic elements of OpenChain compliance requires effort. Just because open source software may be freely available does not mean there are no obligations. However, many companies lack the basic process and software tools for identifying what open source their engineers are reusing in the first place. Without that visibility, there is no opportunity to manage the use.

Next, after properly identifying what open source their developers are using and how that open source is being used, compliance requires accurately identifying what license applies to that code, understanding the requirements of that license and taking the necessary steps to adhere to those requirements. Based on the nature of the open source license, this may include something as simple as providing attribution to something more complicated such as having to disclose source code.

A supplier’s ability to certify OpenChain compliance affords their customer comfort and removes open source compliance-related friction from the supply chain. Downstream customers can enjoy a level of comfort that, by incorporating the supplier’s code with their own, they won’t be inadvertently exposing themselves, any further upstream members of the supply chain or, ultimately, the end user to compliance-related litigation or remediation risk and expense.

There are third parties available to help you through your license compliance journey. Law firms that can assist with training, tools and services. Vendors such as Synopsys can audit your code or provide software tools to support in identifying and tracking open source reuse during software development.

OpenChain compliance as a competitive edge.

While compliance is an important goal, and while companies are keen to steer clear of potential litigation, an exceptionally important element of OpenChain compliance is as a competitive differentiator. Companies that have achieved OpenChain compliance are encouraged to advertise that fact and leverage that status in the marketplace as an asset.

Influential companies such as Toyota, Hitachi, Panasonic, Qualcomm, and Bosch are putting top-down pressure on their vendors, and in turn on suppliers to those vendors to demonstrate open source management consistent with the OpenChain Specification. This results in lower tier vendors, who may have never considered open source compliance as an urgent priority, now finding themselves under increasing pressure from other members of the supply chain.

Hans Malte Kern, Head of the Center of Competence Open Source at Bosch underscores this point. “We’re excited to join the OpenChain project, as it reflects the importance of compliant open source usage, distribution and contribution. Instead of negotiating the open source requirements with all our partners and suppliers, Bosch will leverage OpenChain as an open standard that provides common approaches and understanding for open source collaborations – not only in the automotive industry but also the connected world of IoT. We are convinced the OpenChain standard will replace bilateral negotiations, educations and open source risk mitigation discussions.”

OpenChain as an ISO standard.

The value of being able to tout compliance will take on additional importance as by mid-2020 it is expected that OpenChain Specification version 2.1 will be adopted by the International Organization for Standardization and certified as an ISO standard. Many suppliers are familiar with the experience of responding to customer requests for proposals or quotes. These requests are often multi-part questionnaires requiring the supplier to report on various elements of the supplier’s business concerning such aspects as privacy, security and compliance-related matters.

Given the time pressure often associated with closing deals, making the open source management and compliance discussion short is highly valuable. The ability to reply affirmatively to open source compliance questions and confirm compliance with the pending ISO standard will, in the words of one observer, “take the issue off the table.”

We had five speakers over two events covering a range of global and regional topics:

Let’s start with overall satisfaction, 1 being satisfied and 5 being extremely satisfied:

Let’s dive into how people felt about the relevance of the talks, 1 being low relevance and 5 being extremely relevant:

Let’s get more specific on relevance per topic, which shows global talks having global relevance, and regional talks have substantial but not blanket relevance:

This results map to our expectations and will help shape future events. We also asked for general written feedback as an option and got some encouraging messages:

The OpenChain Korea Work Group will hold its 6th meeting via UberConference on the 16th of June at 2pm Seoul time. This event will be held in the Korean language and will provide an excellent opportunity to learn what companies like Kakao and SK Telecom are doing around open source compliance.

• How to join on PC
  (1) PC에서 https://uberconference.com/openchainproject 접속
  (2) Settings 에서 마이크와 스피커 설정 확인
  (3) Name 입력 후, “Join Now” 클릭하여 입장 
• How to join on Phone
  (1) 핸드폰에서 02-6022-2388로 전화
  (2) 855 889 3011 # 입력

Learn More

• https://openchain-project.github.io/OpenChain-KWG/meeting/6th-meeting-online/

はじめに

この記事では、Open Source Compliance に取り組む上で、役に立った情報や、役に立つよと紹介頂いた情報をまとめます。この記事にあるものが全てではありませんが、いくらかでもお役に立てば幸いです。
なお、本稿中の OSS はとくに断りがなければ Open Source Software を意味します。

この記事は全体で上下2部構成になっています。

Open Source Compliance のお役立ち情報まとめ・上 (この記事)　

• Open Source & Compliance
• Open Source Software
• Open Source Software License
• ツールなど

Open Source Compliance のお役立ち情報まとめ・下 （次の記事)

• 業界的な集まりなど
• イベントや会合など
• ニュースや書籍など

Open Source Compliance のお役立ち情報まとめ・上

Open Source & Compliance

Open Source やその Compliance が大切とされる背景を把握したい場合は、OpenChain Japan Work Group (JWG) による 「オープンソースソフトウェアライセンス遵守に関する一般公衆ガイド (pdf)」 が足がかりになるかもしれません。

このガイドは English(pdf) や 中国語(繁体字(pdf)と簡体字(pdf)) に翻訳されています。Open Source Summit 2019 (North America (8月)、Europe (10月))にて印刷媒体で配布したところ、各国のエンジニアたちが手にし、オフィスや取引先で配りたいと複数部を持って帰った方もいました。

Open Source Compliance

Open Source Compliance について、”ORGANIZATIONS“、”PROJECTS“、”DEVELOPERS” などのカテゴリに分かれて整理されているので、興味のあるところから見てみると良いかも知れません。　

Open Source Guides For The Enterprise

上記のコンテンツよりも、より企業向けに Open Source を適切に活用するために必要となることを網羅的に整理しています。Open Source を管理運用するための機関として Open Source Program Office (OSPO) の導入、Open Source プロジェクトの運営、情報入手のための web サイト、参考書籍など、ほぼ揃っています。日本語版 もあります。
作成は後述する TODO Group によるものです
(この記事の役割は上記のサイトの紹介でほぼ達成している…かも知れません)

Open Source Guides

OSS 開発者向けのガイドです。Open Source プロジェクトを新しく始める場合、コミュニティの運営、プロジェクトの Metrics、そして法的な観点などで注意すべきことなど、一通りの内容を含むので、個人、コミュニティ、企業のいずれの立場でも参考にできるかと思います。

OpenChain project

Open Source License Compliance をサプライチェーンで一貫して果たすために必要となる、教育用の資料、企業内の体制や運営のための仕様、そして、先に挙げた仕様について企業や事業又は製品における適合性などを確認する手段、などを策定し普及を図るプロジェクトです。OpenChain Specification の最新版は v2.0 (pdf) で、若干の改訂を経た v2.1 をもって ISO Joint Technical Committee 1 (JTC-1) での Publicly Available Specification (PAS) としての規格化に向けて取り組んでいます。wiki サイトでは、各 Work Group の活動サマリ、参加方法、会合の開催案内などがあります。

Japan Work Group (JWG) の活動については、このAdvent Calendar 2019 の 12/1-9までの記事 をご覧ください。JWG には Linux Foundation の会員ではなくてもコミュニティメンバーとして参加や貢献できるため、興味や悩みがある人はメーリングリストやSlackに参加して、JWG の総会や各 Sub Work Group (SWG) の会合に足を運んでみてください。

TODO Group

企業で Open Source プロジェクトをよりよく運営するために、企業間で経験、ベストプラクティスやツールなどに関して情報交換するグループです。TODO Guides として提供されている情報もありますが、冒頭で紹介した Open Source Guides For The Enterprise が網羅的なので見てみてください。参加者は、主に企業の Open Source Program マネージャーが想定されています。

CHAOSS project

Open Source Project の健全性について、その Metrics や計測方法などの実現を図るプロジェクトです。Open Source Software を対象とした評価手法に関心がある方は見てみると良いかも知れません。例として Risk WG が策定する Metrics を挙げると、Business Risk、Code Quality、Licensing, Transparency などがあります。

LINUX FOUNDATION: SECURITY, COMPLIANCE & PROJECT HEALTH

OpenChain Project、TODO Group、CHAOSS project のいずれも Linux Foundation の取組です。これら以外にも関連するカテゴリのプロジェクトが紹介されています。OpenChain と特に関連するプロジェクトに SPDX や FOSSology があります。

企業事例

他社がどのように取り組んでいるのかを見るのは、とても参考になります。企業名と “open source” といった用語を組み合わせて検索すると、いろいろと見つかるでしょう。また、GitHub にある企業のレポジトリを見るのも良いでしょう。その中には、OSSを活用するための取り組み方を紹介するものもあります。そうした例には次のようなものがあります。

• Google 社の Google Open Source にある Docs は社内向け資料を元にしているらしく、”License” など参考になる内容があります。
• Microsoft 社は Open Source Blog などで取組を紹介していますが、FAQ 形式で OIN への加入について紹介する記事(1)が投稿されていたりします。また、Open Source Security では脆弱性対策などのセキュリティに関する記事や、AI や IoT の発展に欠かせない Sharing Data については Removing barriers to data innovation で4種類の Data Use Agreement を提案しています。 ((1): Microsoft joins OIN: FAQs with Erich Andersen)

Open Source Software

利用したい OSS について調べる時、ライセンスは何か、いつ頃公開されたもので活動はどの程度なのか、などを把握する必要があります。
ソースコードを見るのも大切ですが、ひとまずざっくりと知りたい時もあります。そうした時、npm, maven (例として MVN repositroy), cocoapds, あるいは OS の distribution の例だと debian の packages や、プログラミング言毎にあるパッケージ管理システムやそのサイトから情報を得たり、GitHub で公開されている場合は Star 数や Commit 動向などの統計情報も活用することがあるでしょう。
ここでは、先に挙げた以外でそうした調べ物に役に立つサイトを紹介します。

Open Hub

OSS の個別プロジェクトについて、開発者、ライセンス、公式サイト、アクティビティ、コミュニティなどの概況を把握するのに便利なサイトです。必ずしも全ての OSS を網羅していませんが、ここで出てこない OSS の利用は注意する、とする方針の企業があると聞いたことがあります。

OSS Radar Scope

独自のレーティングに基づいての OSS　の評価を、ランキングとレーダーチャートで見られるので、類似する OSS を探したり、比較するのに便利なサイトです。こちらも全ての OSS を網羅していませんが、OSS 選定で参考にする企業があると聞いたことがあります。

Libraries.io

“その OSS が 依存する OSS” 又は “その OSS に 依存する OSS” を把握したい時に便利なサイトです。
こちらも同じく、必ずしも全ての OSS について検索できるものではないです。

Software Heritage

ソフトウェアのソースコードを文化遺産として保存する事業によるもので、以前は公開されていたソフトウェアが見つからない場合に便利なサイトです。似たようなサイトに、Internet Archive による Wayback Machine がありますが、そちらよりもソフトウェアに特化して収集しているのが特徴です。

ClearlyDefined

FOSS (Free Open Source Software) の活用で重要となるライセンス情報や脆弱性情報を明確にするために、コミュニティでそうした情報の確からしさを向上させる取組です。OSS が見つかっても情報が不足している場合、記載事項として提案できることがあれば貢献すると良いかも知れません。

Open Source Software License

たいてい、OSS には利用許諾条件としてのライセンスが宣言されています。そして、ライセンスでは、どのような目的でどのような使い方が許諾されているのか、また、そのために利用者が果たすべき義務などが明記されていることでしょう。そうしたライセンスについて理解を深めたい時に参考となるサイトを紹介します。

ライセンスの解釈では、条文(原文)、その条文(原文)が作成された背景、その OSS にそのライセンスが宣言された背景、コミュニティの動向などが重要な要素になるかと思います。場合によっては作成や宣言に至る議論やその議論への影響が想定される国又はそのOSSを利用するであろう国における法令や判例の動向にも気をつけることがあるかも知れません。法務部や知財部、弁護士、弁理士等の法律の専門家に相談するのは大変重要な手段で、そうした時でも、先に挙げた要素を整理検討しておくと良い時があります。ライセンスによっては公式の翻訳版があっても、原文のみを有効と宣言しているものもあるので注意すると良いでしょう。

ところで、OSS プロジェクトが GitHub に登録されている場合、issues で “is:issue license” などを検索してみると、場合によってはそのプロジェクトがライセンスを選択する過程を見ることができるかもしれません。気になるときは試してみてください。

---

その前に: OSS ライセンスの特徴をざっくりと掴みたい

原文等の一次情報は重要ですけど、ざっくりとでもよいので、ライセンスの概要を把握したい時ってありますよね。
そういう時は、次のサイトや情報が参考になるかも知れません。

TLDRLegal

ライセンスについて “Can”、”Cannot”、”Must” の項目に分けて特徴を整理しています。
その内容について弁護士や専門家などによるレビュー済みの場合はそのことが明示されます。
レビュワーの一人の Heather Meeker さんは、別記事で紹介する Open Source For Business の著者です。

chooselicense.com

Open Source Project で宣言したいライセンスを選ぶ際のお助けサイトです。
利用を許諾したい条件に応じて、近しいライセンスを見つけることが出来ます。
ライセンスについて “Permissions”、”Conditions”、”Limitations” の項目に分けて特徴を整理しています。

Open Source Automation Development Lab (OSADL)

OSS を自動化などの産業活用を推進することを目的とする組織で、その観点で様々な取組をしています。
この記事では、Open Source License Checklistsと、Open Source License Checklists – Access to raw data とを紹介します。とくに、raw data はライセンスの内容について、”USE CASE” とそれに応じた義務を構造的に整理しています。試しに、MIT と Apache-2.0 と GPL-3.0 とを見比べてみてください。

---

Open Source Initiative

OSS の普及促進を目指す組織で、”Open Source Definition” などの取組で知られています。OSI が認定するライセンスのリストにあるかを確認することに利用される方も多いようですが、License Review や License Discuss などのメーリングリストのアーカイブから個々のライセンスの議論を追うのもライセンスへの理解を深めるために参考になるでしょう。 最近は、News のページで月毎のサマリが配信されるので便利です。

GNU Licenses

GNU Public License（GPL）の最新版は GPL-3.0で、その派生である GNU Lesser General Public License の最新版は LGPL-3.0, GNU Affero General Public License の最新版は AGPL-3.0 です。それら以前のライセンスを宣言する OSS も多く見られます。

GPL の解釈では、次のコンテンツを話題にすることが多いように思います：

• Frequently Asked Questions about the GNU Licenses
• The LGPL and Java
• License Compatibility and Relicensing
• Various Licenses and Comments about Them

詳細に触れませんが、GPL に関しては、違反時の回復条件に関する動きも知っておくと良いかも知れません。

• Linux Kernel Enforcement Statement
• GPL Cooperation Commitment

こうした動きの背景に関心がある方は “copyright troll” などの情報を調べてみてください。

APACHE LICENSE

正しくは APACHE LICENSE, VERSION 2.0 (Apache-2.0) です。
ライセンスの原文と同様に FREQUENT QUESTIONS ABOUT APACHE LICENSING も参考になります。

近年、コントリビューションの際に Contributors License Agreement (CLA) への同意を求める OSS が見られますが、Apache Software Foundation (ASF) が作成した CONTRIBUTOR LICENSE AGREEMENTS と比較してみると良いかも知れません。あわせて、FREQUENT QUESTIONS ABOUT ASF CONTRIBUTION AGREEMENTS も参考になりそうです。

Mozilla Public License

最新版は MPL-2.0 です。 MPL 2.0 FAQ も参考になります。それ以前の版は Mozilla Public License Version 1.1 (MPL-1.1) で MPL 1.1 FAQ- HISTORICAL USE ONLY も公開されていますが、その改訂の経緯に関する Historical Licensing Documents も参考になるでしょう。

Eclipse Public License

正しくは Eclipse Public License – v 2.0 (EPL-2.0) です。
ライセンスの原文と同様に Eclipse Public License (EPL) Frequently Asked Questions も参考になります。それ以前の版は、Eclipse Public License – v 1. (EPL-1.0) で Eclipse Public License 1.0 (EPL) Frequently Asked Questions もあります。

Eclipse Foundation も Eclipse Contributor Agreement と Eclipse Contributor Agreement (ECA) FAQ とを公開しています。また、Eclipse Foundation Project のもとで OSS プロジェクトを再配布(redistribution)する時は、Third Party Content Licensesにも注意すると良いでしょう。

Creative Commons License

Creative Commons は創作物や知見などの共有や再利用の促進を目的として、いくつかのライセンスを定義しています。ライセンスは “Attribution (by)”、”ShareAlike (sa)”、”NonCommercial (nc)”、”NoDerivatives (nd)” などのLicense Condition の組合せで構成され、最新版は4.0です。また、”Public Domain” を宣言するためのものとして CC0 を定義しています。Frequently Asked Questions もあります。

“NonCommercial (nc)” の定義や解釈については、次の参考情報も提供されています。

• [Defining Noncommercial](https://wiki.creativecommons.org/wiki/Defining_Noncommercial
• NonCommercial_interpretation

ところで、質問 “What are Creative Commons licenses?” に対する回答の中に次の一文があります。

The only categories of works for which CC does not recommend its licenses are computer software and hardware.
(参考訳：CC (ライセンス) をお薦めしないカテゴリの創作物はコンピュータソフトウェアやハードウェアです。)

僕は CC BY-NC-SA を宣言する OSS に遭遇して驚いたことがあるのですが、最初の公開から数年後に BSD 2-Clause “Simplified” License (BSD-2-Clause) に変更されていました。

さて、上記以外で、OSS での CC ライセンスの利用事例にどのようなものがありそうでしょうか。

先に国毎の法令等の違いに注意が必要な場合があると述べましたが、”Public Domain” は著作権法などの関係でそうした話題の一つとして知られています。そこで、OSS の著作権者が著作権等を行使しないことを宣言する手段として CC0 を用いる事例が見られます。

また、開発者同士で情報交換するサイトで、書き込みを CC BY-SA で扱うとする利用規約のものを見たことがあります。そうしたサイトで紹介されているコードを snippet として拝借する時は注意が必要そうですね。

サーバーサイドで利用するソフトウェアのライセンスについて

サーバサイドでの利用を対象とした OSS ライセンスに AGPL などがありますが、近年はクラウドによるサービス提供を意識したライセンスが見られるようになってきました。ここでは、例を幾つか挙げておきます。

• Server Side Public License (SSPL) (MongoDB など)
  
• Business Source License 1.1 (MariaDB など)

---

補足: Open Source License に関する議論など

ライセンスについてどのようなことが問題となりそれをどう検討するのかは、専門家や先達の知見が参考になります。
OSS ライセンスに関わる法令等で国毎に違う部分があるかも知れません。そうした点も考慮しながら、ライセンスの条文や、次に紹介する議論や検討を読むと良いでしょう。

copyleft.org

copyleft.org は copyleft ライセンスに関する情報提供を目的とするプロジェクトです。Copyleft と GPL についてまとまった文書に次があります。

• Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide

Software Freedom Law Center (SFLC)

SFLC は Free, Libre and Open Source Software (FLOSS) プロジェクトに対して法的アドバイスなどで支援することを目的とする組織です。代表者は Columbia Law School で Professor of Law を務める Eben Moglen 氏です。
GPL に関する文書が多くありますが、僕がとくに参考にしたものを紹介します。

• Software Freedom Law Center Guide to GPL Compliance 2nd Edition (2014)
• A Legal Issues Primer for Open Source and Free Software Projects (2008)
• A History of the GPLv3 Revision Process (pdf)

SOFTIC: IoT 時代におけるOSSの利用と法的諸問題Q&A集

一般財団法人 ソフトウェア情報センター (SOFTIC) が立ち上げた 「IoT 時代における OSS の利用と法的リスクに関する検討委員会」 での検討結果を Q＆A 集として纏めたものです。委員会メンバーは法律専門家と企業実務担当者で、OSS を利用する上での法的諸問題やビジネスを展開する上での疑問点について、提供者や利用者の立場での論点が取り上げられています。序文に各執筆者の総意を纏めたものではないとある通り、そういう見解もある、として検討材料にするのが良い使い方のように思われます。

IPA： OSSライセンス関連情報

独立行政法人 情報処理推進機構 (IPA) が過去に取り組んだ調査事業にOSSライセンスを対象としたものがあります。
過去に国内であった議論や検討を把握したい時に参考になる情報が得られます。
たとえば、次のような文書が公開されています。

• GNU GPL v3 解説書
• GNU 一般公衆利用許諾書 （日本語訳）
• OSSライセンスの比較、利用動向および係争に関する調査

専門誌など

日本弁理士会(JPAA)の会誌である「月刊パテント」は非会員でも閲覧出来る記事があります。例えば、2006年06月号に 「オープンソースソフトウェアのライセンスと特許権」という記事があります。

日本知的財産協会（JIPA）は、知的財産に関する諸制度の活用や改善を図って国内産業の発展への寄与を目的として国内企業が参加する団体です。企業知財部門らが企業の枠を超えて調査研究する場になっています。機関誌「 知財管理」を全て読みたい場合は会員企業であっても購入する必要がありますが、国会図書館などで閲覧することも出来ます。たとえば、バックナンバーを検索してみると、68巻(2018年)/5号に「OSSライセンス遵守のための基礎知識」と題した論文が掲載されているようです。

---

ツールなど

OSS がどのライセンスに基づいて提供されているのか、OSS が依存する他の OSS にどのようなものがあるのか、は、重要な情報です。ここでは、情報の定義や情報交換のためのフォーマット、そうした情報を検出するための OSS などを紹介します。

なお、AyumiWatanabe さんの記事「OSS管理のベストプラクティス＆OSS管理ツールの選び方 (12/11公開記事)」 では商用製品へのリンクがあるので、興味のある方はそちらもご覧ください。

SPDX

“Software Data eXchange Package” は、SBOM (Software Bill of Materials) について情報交換するための仕様であり、コンポーネント、ライセンス、著作権、セキュリティ等々の情報を扱えるようになっています。最新の仕様は2.1版で、 Frequently Asked Questions (FAQ) があります。SPDX License List で “Full name” や “Identifier” が見られます。なお、この記事の執筆現在で、3.0版に向けた検討が始まっています。

先の “Identifier” は正しくは “SPDX short-form identifiers (SPDX ID)” と呼びますが、人やスキャンツールなどでも判別しやすいように、SPDX ID の利用を推奨する取組も見られます。興味がある方は REUSE SOFTWARE をご覧ください。

FOSSology

ソースコードをスキャンして、ライセンス、著作権表示、輸出管理(Export Control: EC) に関連する情報を抽出します。
倣うより慣れろな方は Get Started With FOSSology と Hands-On Training Support Page などのページが参考になると思います。

利用事例に興味がある方は、y-ashiduka さんの記事「Yocto環境にmeta-spdxscannerを適用し、SPDX出力環境を構築する（fossdriver利用編）(12/10公開記事)」 もご一読ください。

ScanCode

ソースコードをスキャンして、ライセンス、著作権表示、依存に関連する情報を抽出します。
FOSSology とは検出アルゴリズムが異なることに伴う検出結果の違いから、使い分ける利用者もいるようです。

参考までにですが、ライセンス情報のスキャン精度に関する考察に Thomas Wolter による “A Comparison Study of Open Source License Crawler” という論文があります。

SW360

FOSSology や ScanCode を始めとする各種ツールを連携し、SBOM管理を効率化するためのカタログツールとして開発されたものです。
K-Hama さんが、「OSS管理ツール SW360 – オープンソースをオープンソースで管理しよう （1.1 新バージョンインストール編）」という記事や、利用方法を記したドキュメント を公開してくれているので、興味のある方はご一読ください。

OSS Review Kit (ORT)

OSS のレビュープロセスを支援するため、”Analyzer”、”Downloader”、”Scanner”、”Evaluator”、”Reporter” などのツール群で構成されています。

明日のテーマは

「Open Source Compliance のお役立ち情報まとめ・下」です。
引き続き僕が担当します。情報収集やネットワーキングに役立つイベントや、書籍や文書など知識を得るのに利用したものを紹介しようと思います。お楽しみに！

おまけ：自己紹介

忍頂寺毅と申します。
以下は、本稿執筆時点のものになります。

所属は株式会社ディー・エヌ・エー システム本部 CTO室です。
主に知的財産やコンプライアンス関連の業務に従事しています。
2019年2月から OpenChain Japan Work Group にコミュニティメンバーとして参加しています。
同年4月より JIPA ソフトウェア専門委員会にて2019年度テーマとして OSS と企業知財に関する調査研究に参加しています。
前職は通信会社で研究開発部門に長くいました。インターネット構築運用、HCI、移動機端末開発や関連する標準化、モバイル AR といった PoC (Proof of Concept) のためのサービス試作開発などに従事していました。

The OpenChain Japan Work Group hosted its 15th meeting (2nd virtual) at 2pm local time on the 18th of June. The majority of the meeting was held in Japanese but as always foreign guests were welcome to join and ask questions or share news in English.

Review the Slides

第2回オンライン全体会合 Virtual all member meeting #2 from Shane Coughlan

Learn More About Japan Work Group Activities

• https://openchain-project.github.io/OpenChain-JWG/index.html

The OpenChain China Work Group held its fourth meeting on the 17th of June. This meeting covered two topics

Agenda

• A briefing on Patrick McHardy and related activities in 2020 (Chatham House Rule, not part of the recording).
• Production use of software bill of materials and an update on US Government activity around software bill of materials.

You can access the English summary in the lower part of the page.

はじめに

こんにちは。
本日はJapan WGと同じくOpenChainのWork Groupの一つである
Automotive WGをご紹介します。
Japan WGは国別のWork Groupであるのに対し、
Automotive WGは産業別のインターナショナルなWork Groupになります。

自己紹介

本日の担当させて頂く遠藤雅人です。
Japan WGには設立時から参加させて頂いているほか、
Promotion SWGのリーダーとして今回のアドベンドカレンダー企画の
サポートもさせて頂いています。
本年7月には、本日ご紹介するOpenChain Automotive WGを立ち上げ、
OpenChain Project全体のAutomotive Chairを拝命しております。
趣味は旅行、ガジェット、スポーツ観戦（主にサッカー）です。

Automotive WG

Automotive WGはOpenChain Projectの自動車業界におけるWork Groupであり、
以下の3つを目的としています
①自動車業界内のベストプラクティスの共有
②OSS SCM(Supply Chain Management)の自動車業界標準の検討
③OSSコンプライアンスの重要性の業界内での周知活動

WGの参加とメンバー

下記のサイトからML登録することでWGに参加することができます。
https://groups.io/g/openchain-automotive-work-group
他のOSSコミュニティ同様、自動車業界の方でなくても活動に関心があれば
誰でも参加可能です。
本WGは本投稿時点で設立から5か月ほどですが、
日米欧韓の12の自動車メーカの方々が既にメンバーになっています。
その他にも自動車部品サプライヤ、電機メーカ、半導体メーカ、
システムベンダ、ツールベンダ、弁護士、コンサルの方など多岐に渡る
100名以上の方にMLに登録頂いています。

これまでの活動

コミュニティ設立から1年は、情報共有のベースの形成や
参加者のニーズの把握をすることに力をいれています。
MLでの情報共有の他、日本及び欧州でWork Shopを開催しました。

・2019年7月19日 第1回Work Shop
記念すべき初回のWork Shopは東京で行われたAutomotive Linux Summit時に併催され、
上記の3つの目的を確認しました。
OpenChain Automotive Work Group – A Global Solution for a Global Market

・2019年10月29日　第2回Work Shop
第2回目のWork ShopはLyonで行われたOpen Source Summit Europe時に併催され、
Scania、富士通、デンソーテン、Boschが各社のOSSコンプライアンスに取り組みを紹介しました。
OpenChain Automotive Work Group Meeting #2 – Outcomes

今後の活動

来る2020年1月9日に日本、欧州に続いて米国ラスベガスにて第3回Work Shopを実施予定です。
同時期にラスベガスで行われるCESの会場の近くで実施する予定ですので、
CESに参加される方で興味ある方は是非MLに登録の上エントリーください。
また、CESでは自動車向けLinuxの開発プロジェクトであるAutomotive Grade Linux(AGL)とOpen Chainの
コラボレーション企画として、OpenChainのミニブースをAGLブース内に設置予定ですのでこちらも
よろしくお願い致します。

OpenChain and AGL Collaborate to Facilitate Open Source Compliance in Automotive Production
Automotive Grade Linux、18社のメンバー企業によるCES 2020デモ展示を発表

AGLとOpenChainの関係については、本カレンダーの19日に登場予定の日下部さんに詳細を語って頂く予定です。
もちろん、日本でのイベントや企画を2020年も進めていきたいと考えていますので、
興味のある方は、是非ともMLにご登録ください！

明日のテーマは・・・

明日のテーマは「Open Source Compliance のお役立ち情報まとめ」になります。
ご担当頂くのは、組み込み系が多いJapan WGにWeb系の世界から彗星のごとく現れ、
Projectの中で目覚ましいご活躍を頂いている忍頂寺さんになります。
乞うご期待！

English Summary

This article introduces outline of OpenChain Project Automotive WG.
Automotive WG is the first industrial work group of the OpenChain Project.

The WG’s purpose are as below.
1) Share information to support best practices in the industry
2) Build a future industry standard for OSS SCM
3) Raise awareness about the importance of OSS compliance in the industry

You can join this community to submit our Mailing List.
https://groups.io/g/openchain-automotive-work-group

Already, we had 2 face to face meetings at Tokyo and Lyon.
OpenChain Automotive Work Group – A Global Solution for a Global Market
OpenChain Automotive Work Group Meeting #2 – Outcomes

And, we are planning 3rd meeting at Las Vegas in CES2020 season.
OpenChain and AGL Collaborate to Facilitate Open Source Compliance in Automotive Production
AGL Announces CES 2020 Demos by 18 Members