Our friends from OPPO have updated the OpenChain Specification 2.0 in Simplified Chinese.
This is useful if you want to check out the details of our International standard for open source compliance.
Get this translation
Check out all our translations
この記事では、Open Source Compliance に取り組む上で、役に立った情報や、役に立つよと紹介頂いた情報をまとめます。この記事にあるものが全てではありませんが、いくらかでもお役に立てば幸いです。
なお、本稿中の OSS はとくに断りがなければ Open Source Software を意味します。
この記事は全体で上下2部構成になっています。
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 について、”ORGANIZATIONS“、”PROJECTS“、”DEVELOPERS” などのカテゴリに分かれて整理されているので、興味のあるところから見てみると良いかも知れません。
上記のコンテンツよりも、より企業向けに Open Source を適切に活用するために必要となることを網羅的に整理しています。Open Source を管理運用するための機関として Open Source Program Office (OSPO) の導入、Open Source プロジェクトの運営、情報入手のための web サイト、参考書籍など、ほぼ揃っています。日本語版 もあります。
作成は後述する TODO Group によるものです
(この記事の役割は上記のサイトの紹介でほぼ達成している…かも知れません)
OSS 開発者向けのガイドです。Open Source プロジェクトを新しく始める場合、コミュニティの運営、プロジェクトの Metrics、そして法的な観点などで注意すべきことなど、一通りの内容を含むので、個人、コミュニティ、企業のいずれの立場でも参考にできるかと思います。
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) の会合に足を運んでみてください。
企業で Open Source プロジェクトをよりよく運営するために、企業間で経験、ベストプラクティスやツールなどに関して情報交換するグループです。TODO Guides として提供されている情報もありますが、冒頭で紹介した Open Source Guides For The Enterprise が網羅的なので見てみてください。参加者は、主に企業の Open Source Program マネージャーが想定されています。
Open Source Project の健全性について、その Metrics や計測方法などの実現を図るプロジェクトです。Open Source Software を対象とした評価手法に関心がある方は見てみると良いかも知れません。例として Risk WG が策定する Metrics を挙げると、Business Risk、Code Quality、Licensing, Transparency などがあります。
OpenChain Project、TODO Group、CHAOSS project のいずれも Linux Foundation の取組です。これら以外にも関連するカテゴリのプロジェクトが紹介されています。OpenChain と特に関連するプロジェクトに SPDX や FOSSology があります。
他社がどのように取り組んでいるのかを見るのは、とても参考になります。企業名と “open source” といった用語を組み合わせて検索すると、いろいろと見つかるでしょう。また、GitHub にある企業のレポジトリを見るのも良いでしょう。その中には、OSSを活用するための取り組み方を紹介するものもあります。そうした例には次のようなものがあります。
利用したい OSS について調べる時、ライセンスは何か、いつ頃公開されたもので活動はどの程度なのか、などを把握する必要があります。
ソースコードを見るのも大切ですが、ひとまずざっくりと知りたい時もあります。そうした時、npm, maven (例として MVN repositroy), cocoapds, あるいは OS の distribution の例だと debian の packages や、プログラミング言毎にあるパッケージ管理システムやそのサイトから情報を得たり、GitHub で公開されている場合は Star 数や Commit 動向などの統計情報も活用することがあるでしょう。
ここでは、先に挙げた以外でそうした調べ物に役に立つサイトを紹介します。
OSS の個別プロジェクトについて、開発者、ライセンス、公式サイト、アクティビティ、コミュニティなどの概況を把握するのに便利なサイトです。必ずしも全ての OSS を網羅していませんが、ここで出てこない OSS の利用は注意する、とする方針の企業があると聞いたことがあります。
独自のレーティングに基づいての OSS の評価を、ランキングとレーダーチャートで見られるので、類似する OSS を探したり、比較するのに便利なサイトです。こちらも全ての OSS を網羅していませんが、OSS 選定で参考にする企業があると聞いたことがあります。
“その OSS が 依存する OSS” 又は “その OSS に 依存する OSS” を把握したい時に便利なサイトです。
こちらも同じく、必ずしも全ての OSS について検索できるものではないです。
ソフトウェアのソースコードを文化遺産として保存する事業によるもので、以前は公開されていたソフトウェアが見つからない場合に便利なサイトです。似たようなサイトに、Internet Archive による Wayback Machine がありますが、そちらよりもソフトウェアに特化して収集しているのが特徴です。
FOSS (Free Open Source Software) の活用で重要となるライセンス情報や脆弱性情報を明確にするために、コミュニティでそうした情報の確からしさを向上させる取組です。OSS が見つかっても情報が不足している場合、記載事項として提案できることがあれば貢献すると良いかも知れません。
たいてい、OSS には利用許諾条件としてのライセンスが宣言されています。そして、ライセンスでは、どのような目的でどのような使い方が許諾されているのか、また、そのために利用者が果たすべき義務などが明記されていることでしょう。そうしたライセンスについて理解を深めたい時に参考となるサイトを紹介します。
ライセンスの解釈では、条文(原文)、その条文(原文)が作成された背景、その OSS にそのライセンスが宣言された背景、コミュニティの動向などが重要な要素になるかと思います。場合によっては作成や宣言に至る議論やその議論への影響が想定される国又はそのOSSを利用するであろう国における法令や判例の動向にも気をつけることがあるかも知れません。法務部や知財部、弁護士、弁理士等の法律の専門家に相談するのは大変重要な手段で、そうした時でも、先に挙げた要素を整理検討しておくと良い時があります。ライセンスによっては公式の翻訳版があっても、原文のみを有効と宣言しているものもあるので注意すると良いでしょう。
ところで、OSS プロジェクトが GitHub に登録されている場合、issues で “is:issue license” などを検索してみると、場合によってはそのプロジェクトがライセンスを選択する過程を見ることができるかもしれません。気になるときは試してみてください。
原文等の一次情報は重要ですけど、ざっくりとでもよいので、ライセンスの概要を把握したい時ってありますよね。
そういう時は、次のサイトや情報が参考になるかも知れません。
ライセンスについて “Can”、”Cannot”、”Must” の項目に分けて特徴を整理しています。
その内容について弁護士や専門家などによるレビュー済みの場合はそのことが明示されます。
レビュワーの一人の Heather Meeker さんは、別記事で紹介する Open Source For Business の著者です。
Open Source Project で宣言したいライセンスを選ぶ際のお助けサイトです。
利用を許諾したい条件に応じて、近しいライセンスを見つけることが出来ます。
ライセンスについて “Permissions”、”Conditions”、”Limitations” の項目に分けて特徴を整理しています。
OSS を自動化などの産業活用を推進することを目的とする組織で、その観点で様々な取組をしています。
この記事では、Open Source License Checklistsと、Open Source License Checklists – Access to raw data とを紹介します。とくに、raw data はライセンスの内容について、”USE CASE” とそれに応じた義務を構造的に整理しています。試しに、MIT と Apache-2.0 と GPL-3.0 とを見比べてみてください。
OSS の普及促進を目指す組織で、”Open Source Definition” などの取組で知られています。OSI が認定するライセンスのリストにあるかを確認することに利用される方も多いようですが、License Review や License Discuss などのメーリングリストのアーカイブから個々のライセンスの議論を追うのもライセンスへの理解を深めるために参考になるでしょう。 最近は、News のページで月毎のサマリが配信されるので便利です。
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 の解釈では、次のコンテンツを話題にすることが多いように思います：
詳細に触れませんが、GPL に関しては、違反時の回復条件に関する動きも知っておくと良いかも知れません。
こうした動きの背景に関心がある方は “copyright troll” などの情報を調べてみてください。
正しくは 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 も参考になりそうです。
最新版は 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 – 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 は創作物や知見などの共有や再利用の促進を目的として、いくつかのライセンスを定義しています。ライセンスは “Attribution (by)”、”ShareAlike (sa)”、”NonCommercial (nc)”、”NoDerivatives (nd)” などのLicense Condition の組合せで構成され、最新版は4.0です。また、”Public Domain” を宣言するためのものとして CC0 を定義しています。Frequently Asked Questions もあります。
“NonCommercial (nc)” の定義や解釈については、次の参考情報も提供されています。
ところで、質問 “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 などがありますが、近年はクラウドによるサービス提供を意識したライセンスが見られるようになってきました。ここでは、例を幾つか挙げておきます。
ライセンスについてどのようなことが問題となりそれをどう検討するのかは、専門家や先達の知見が参考になります。
OSS ライセンスに関わる法令等で国毎に違う部分があるかも知れません。そうした点も考慮しながら、ライセンスの条文や、次に紹介する議論や検討を読むと良いでしょう。
copyleft.org は copyleft ライセンスに関する情報提供を目的とするプロジェクトです。Copyleft と GPL についてまとまった文書に次があります。
SFLC は Free, Libre and Open Source Software (FLOSS) プロジェクトに対して法的アドバイスなどで支援することを目的とする組織です。代表者は Columbia Law School で Professor of Law を務める Eben Moglen 氏です。
GPL に関する文書が多くありますが、僕がとくに参考にしたものを紹介します。
一般財団法人 ソフトウェア情報センター (SOFTIC) が立ち上げた 「IoT 時代における OSS の利用と法的リスクに関する検討委員会」 での検討結果を Q＆A 集として纏めたものです。委員会メンバーは法律専門家と企業実務担当者で、OSS を利用する上での法的諸問題やビジネスを展開する上での疑問点について、提供者や利用者の立場での論点が取り上げられています。序文に各執筆者の総意を纏めたものではないとある通り、そういう見解もある、として検討材料にするのが良い使い方のように思われます。
独立行政法人 情報処理推進機構 (IPA) が過去に取り組んだ調査事業にOSSライセンスを対象としたものがあります。
過去に国内であった議論や検討を把握したい時に参考になる情報が得られます。
たとえば、次のような文書が公開されています。
日本弁理士会(JPAA)の会誌である「月刊パテント」は非会員でも閲覧出来る記事があります。例えば、2006年06月号に 「オープンソースソフトウェアのライセンスと特許権」という記事があります。
日本知的財産協会（JIPA）は、知的財産に関する諸制度の活用や改善を図って国内産業の発展への寄与を目的として国内企業が参加する団体です。企業知財部門らが企業の枠を超えて調査研究する場になっています。機関誌「 知財管理」を全て読みたい場合は会員企業であっても購入する必要がありますが、国会図書館などで閲覧することも出来ます。たとえば、バックナンバーを検索してみると、68巻(2018年)/5号に「OSSライセンス遵守のための基礎知識」と題した論文が掲載されているようです。
OSS がどのライセンスに基づいて提供されているのか、OSS が依存する他の OSS にどのようなものがあるのか、は、重要な情報です。ここでは、情報の定義や情報交換のためのフォーマット、そうした情報を検出するための OSS などを紹介します。
なお、AyumiWatanabe さんの記事「OSS管理のベストプラクティス＆OSS管理ツールの選び方 (12/11公開記事)」 では商用製品へのリンクがあるので、興味のある方はそちらもご覧ください。
“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 をご覧ください。
ソースコードをスキャンして、ライセンス、著作権表示、輸出管理(Export Control: EC) に関連する情報を抽出します。
倣うより慣れろな方は Get Started With FOSSology と Hands-On Training Support Page などのページが参考になると思います。
利用事例に興味がある方は、y-ashiduka さんの記事「Yocto環境にmeta-spdxscannerを適用し、SPDX出力環境を構築する（fossdriver利用編）(12/10公開記事)」 もご一読ください。
ソースコードをスキャンして、ライセンス、著作権表示、依存に関連する情報を抽出します。
FOSSology とは検出アルゴリズムが異なることに伴う検出結果の違いから、使い分ける利用者もいるようです。
参考までにですが、ライセンス情報のスキャン精度に関する考察に Thomas Wolter による “A Comparison Study of Open Source License Crawler” という論文があります。
FOSSology や ScanCode を始めとする各種ツールを連携し、SBOM管理を効率化するためのカタログツールとして開発されたものです。
K-Hama さんが、「OSS管理ツール SW360 – オープンソースをオープンソースで管理しよう （1.1 新バージョンインストール編）」という記事や、利用方法を記したドキュメント を公開してくれているので、興味のある方はご一読ください。
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) のためのサービス試作開発などに従事していました。
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はOpenChain Projectの自動車業界におけるWork Groupであり、
以下の3つを目的としています
①自動車業界内のベストプラクティスの共有
②OSS SCM(Supply Chain Management)の自動車業界標準の検討
③OSSコンプライアンスの重要性の業界内での周知活動
下記のサイトから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の中で目覚ましいご活躍を頂いている忍頂寺さんになります。
乞うご期待！
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
OpenChain Japan WGのアドベントカレンダー、本日は13記事目になります。本アドベントカレンダーは、OSSコンプライアンスに関わる取り組み「OpenChain」プロジェクトの日本ワーキンググループのメンバーが日替わりで記事を書いています。
参考：FacebookやGoogleも参加するOSSコンプライアンスのプロジェクト、「OpenChain」とは
今回は「OSSの利用に伴う特許侵害リスク」について書いてみたいと思います。（セキュリティの話も一緒に書こうと思ったんですが構成がうまくまとまらず…今回は特許の話に特化して書かせていただきます）
国内外のIT関連分野について、特許や現地メディアを通じて技術動向の調査をしたり、それらをまとめた記事を書いたりしています。
OpenChain Japanは2019年夏に存在を知って、全体会合に一度参加しただけのまだまだ初心者です。OpenChain Japanでは、OpenChainやOSSコンプライアンスの普及を担うPromotionグループに参加しています。
あるOSSが第三者の特許権を侵害している場合、OSSの提供元だけでなくそのOSSを利用した製品やサービスも特許権侵害の対象となります。つまり、損害賠償金を請求されたり、特許ライセンス費用を要求されたりする可能性があります。
過去には、スマホ用OSとしてOSSの代表格であるAndroidが特許権侵害をしているとして、提供元のGoogleだけでなくAndroidスマホの開発企業が訴えられる事例も発生しています。
Microsoft、Android端末の特許侵害でMotorolaを提訴
Android関連の特許訴訟が相次いだGoogleは、上記ニュースでも話題になっているモトローラを買収。その後、多くの特許を保有したまま携帯事業部門を中国・レノボに売却したことから、訴訟に耐えうる特許取得が目的の企業買収と話題になりました。
・モトローラ買収とグーグルの法的戦略の方向性–特許ポートフォリオ強化に至る背景
特許によってOSSの円滑な利用が阻害される状況を懸念して、その問題を解決しようとするコミュニティ活動も同時に始まりました。今回はその1つとして「Open Invention Network（OIN）
」およびその関連組織である「Linux Defenders」の活動を紹介します。
OINは「OSSに関する特許のクロスライセンス」を促進するコミュニティ活動です。
OINはLinuxに関連する特許を保有し、「Linux関連技術を利用する企業に特許訴訟を行わないこと（自社特許を開放すること）」に同意した参加企業に対して無償でライセンス提供を行います。2018年にはマイクロソフトがOINに参加、OSSと特許訴訟を巡る状況の1つの転換点となりました。
マイクロソフト、オープンソース特許ネットワーク（OIN）に加盟、特許6万件を開放
さらに、OSSに関して不当な特許が発生するリスクを減らすべく、OINの下部組織として「Linux Defenders」という活動が行われています。
主な取り組みとしては
Defensive Publications：既存の技術を積極的に公開し、不当な特許の成立を防ぐ材料とする
Prior Art Activities：特許審査が適切に行われるように関連技術資料を提供、OSSコミュニティのリスクとなる特許の再審査を推進
などがあります。
知財部門の仕事の1つとして、「自社の事業を円滑に進めるために、他社の特許にどう対処するか」が挙げられます。
「他社の特許を調査して、問題となる特許を把握する」「問題となる特許について回避方法を検討する、無効化を仕掛ける」「回避案が見つからないときのために、他社との交渉材料となる特許を仕込んでおく」といった業務が中心になりますが、今後はそれらに加えてこういったコミュニティ活動への対応も必要になっていきます。
ウェブサービスやスマホアプリだけでなく、家電や自動車など全てのものにソフトが組み込まれる時代。OSSの導入はますます加速していきます。
エンジニアだけではなく知財関係者など様々な専門家がOSSコミュニティに貢献していくことが、国や企業の競争力に繋がっていく（そして、その人自身のキャリアにも繋がっていく）。そんな時代になっていくのかなと最近考えています。
p.s.
OpenChain Japan内で知財関連のワーキンググループが出来たらぜひ参加したいと思ってます。
明日は本記事内で紹介した資料の作成者でもあるトヨタ自動車の遠藤さんが担当。自動車業界でのOSSコンプライアンスをテーマとして2019年7月に設立されたOpenChain Automotive WGについて紹介いただく予定です。
The OpenChain Reference Tooling Work Group held its 16th meeting on the 3rd of June.
You can find the recording of the session as well as the presentation slides here:
Catch up on minutes from all previous meetings
こんにちは。あるいは、はじめまして。二度目ましての方も、おいででしょうかね。
オープンソース（OSS）の利活用コンサルをしています、渡邊歩です。好きなOSSライセンスは、Beerware Licenseです。
今回は本業のテーマで、「OSS管理のベストプラクティス」の必須要素である「組織」、「ポリシー」、「（正しい）知識」、「ツール」について書かせていただこうと思います。
OSSコンプライアンスって何から始めればいいの？OSS管理ツールってたくさんあるけどそれぞれどう違うの？というような方のお役に立てれば幸いです。
Linux Foundation TODOグループのオープンソースプログラムの作成では、OSPOは「オープンソースをサポートし、育成し、共用し、説明し、成長させていくために企業内で中心となる組織」と定義されています。組織、というととても専門的で大規模なものを想像するかもしれませんが、少人数だったり他の業務との兼務だったりと、その形態は企業・組織によって様々です。
これまで多くの企業・組織のOSPOの設立をご支援してきた中で、その成立ちを大きく分類すると下図のようになります。どのモデルにもそれぞれメリット・デメリットがありますので、それらを意識しながら推進していくことが重要です。
成功するOSPOの共通点というと、必要であれば会社の規則を変えたり製品の出荷を止めたりできるような「権限」があることと、企業・組織としてコンプライアンスを推進するのだという「使命」があることでしょうか。また、ルール主導にならないよう、開発チームと密に連携して無理のないプロセスを構築していくことも、成功の秘訣です。
OSS管理って何から手をつければ良いんですか？という質問をいただくことがありますが、私はまず「OSSポリシーを作りましょう」とご提案します。OSSポリシーとは、企業または組織がOSSとどのように関わっていくかという指針を定めたもので、様々なシーンで判断をする際の拠り所になります。
OSSポリシーにも色々な形式、粒度がありますが、私が一般的におすすめしているのは下記の形式です。
ポリシーで定めた内容を詳細化し読み物の形にした「ガイドライン」や、組織のメンバーに理解・浸透させるための「教育資料」の形に転用することもできます。
今年は、たくさんの会社様からOSS教育のご依頼をいただきました。OSSの活用そのものが増えてきていることに加え、「正しく基礎的な知識を全員が持っていること」が重要視されてきているように思います。
OpenChain Japan WGでは、関係する方々全員に正しい理解をしていただくためのリーフレット「オープンソースソフトウェアライセンス遵守のための一般公衆ガイド」を作成しました。（詳しくは12月8日のSat_Uさんの記事をご覧ください！）
このガイドは、日本語版が作成された後、英語や中国語などに翻訳されています。海外の取引先にOSSコンプライアンスについて知って貰いたい方は是非この翻訳版のガイドを活用してください。
ここでは、ソフトウェアを解析し、内包するOSSを検出するツールのことをOSS管理ツールと呼びます。
OSS管理ツールも様々なものがありますよね。結局のところ、どれがいいの？と迷われる方も多いと思いますので、選ぶ際の観点とおすすめツールを纏めてみました。
観点その1：OSSを改変して使っているか
OSS管理ツールの基本的なアプローチは、解析対象ファイルから算出したハッシュ値と、予め算出して蓄えてあるOSSのハッシュ値とを比較する「ファイルマッチング」という方法です。ほとんどのツールには「あいまいマッチ検出」の機能があるので、軽微な改変であれば検出することができますが、改変の度合いと検出率は相反関係になります。
改変されたOSSの検出を可能にするため、いくつかのOSS管理ツールでは「スニペットマッチング」というアプローチをとっています。これは、ファイルの一部分だけが似ているようなOSSを特定することができ、OSSの意図しない混入（コンタミネーション）を検出することができます。
as-isのOSSのライブラリを参照しているだけ、というような方であればファイルマッチングができるOSS管理ツールで十分ですし、組込み開発などでOSSの改変が必須の方であれば、スニペットマッチングができるOSS管理ツールを選んでください。
このカテゴリのおすすめツール：
・Black Duck（ファイルマッチング・スニペットマッチング）
・White Source（ファイルマッチング）
観点その2：独自ビルドのバイナリファイルを解析する必要があるか
OSSのバイナリファイルをas-isで使用している場合であれば、上述の「ファイルマッチング」でカバーできますが、独自ビルドのバイナリファイルは、ビルド環境やオプション等によりハッシュ値が変わりますので、特別なアプローチが必要です。元にしたソースファイルが手元にある場合はもちろん、ソースファイルを解析すれば良いのですが、外部からの購入品などでバイナリファイルしか手元にない場合もありますので、そのような方は独自ビルドのバイナリファイルを解析する機能を持ったツールを選んでください。
このカテゴリのおすすめツール：
・Black Duck
・Insignary Clarity
観点その3：依存関係の解析
取り込んだOSSが更に別のOSSを取り込んでいて、突き詰めていくとGPLライセンスのライブラリが入っていた・・・という「あるある」を経験したことのある方も多いのではないでしょうか。このような「入れ子構造」になっているライセンスのことを「Deep License」と呼びます。このようなDeep Licenseを調べるには、パッケージ毎の依存関係（どのパッケージが、どのパッケージを内包しているか）を調べなければなりません。
Deep Licenseを詳しく調べたい方は、パッケージマネージャの依存関係を示すファイルを解析しパッケージの依存関係を可視化してくれる機能を持ったツールを選んでください。
このカテゴリのおすすめツール：
・FOSSA
明日の担当は、tech_nomad_さん。「OSSと特許侵害」という、とても気になる！でも難しくて解らない！というテーマを語ってくださいます。控えめに言ってもめっちゃためになります。明日もお楽しみに！！
この投稿を読んでくださった方から「これも参考になるよ！」と教えていただいた情報を載せておきます。こういうやりとりもコミュニティの良さですよね！
・Open Source Program Offices: The Primer on Organizational Structures, Roles and Responsibilities, and Challenges
OSSライセンス スキャナーであるFOSSologyを利用すると、OSSパッケージ毎のソース コード解析→SPDXファイルの出力が可能です。
しかし、ソース コードをパッケージ毎にWeb UIからFOSSologyへ送るのは手間がかかるため、meta-spdxscannerを利用して、Yoctoでビルドしながら、FOSSologyへソース コードを送信、解析、SPDXファイルを出力する環境の構築方法をまとめてみました。
今回、構築する環境は、以下のような感じです。
ホスト環境は、Ubuntu 18.04やAWS（Amazon Linux）など、dockerが使えれば何でもよいです。
青枠がdockerコンテナです。
FOSSologyやYoctoビルド環境をdockerコンテナで構築し、Yoctoビルド環境のdocker上にFOSSologyとアクセスするためのfossdriverをインストールします。
※FOSSologyやYoctoビルド環境についての説明は割愛します。
FOSSology のdockerイメージを取得します。
最新版は3.6.0版ですが、fossdriver経由で動作しないので、3.5.0版を取得します。
追記：fossdriverが、FOSSology-3.6.0に対応したようです。（https://github.com/fossology/fossdriver/commit/efbbd51ae407e78cd8f969b2cdc3c243b31ade2a）
$ sudo docker pull fossology/fossology:3.5.0
FOSSology dockerを起動します。
$ sudo docker run -d -p 8081:80 --name fossology-3.5.0 fossology/fossology:3.5.0
-p 8081:80は、外部アクセスされるポート番号:dockerコンテナ側のポート番号を指定します。-dは、バックグラウンド実行です。
docker psで、dockerコンテナが起動したことは確認できますが、念の為、docker logsで起動状況（--tail=20で、最新ログ20行だけ）を表示します。
$ sudo docker logs --tail=20 fossology-3.5.0 ： YYYY-MM-DD hh:mm:ss scheduler [PID1] :: NOTE: ******************************************** YYYY-MM-DD hh:mm:ss scheduler [PID1] :: NOTE: *** FOSSology scheduler started *** YYYY-MM-DD hh:mm:ss scheduler [PID1] :: NOTE: *** pid: PID1 *** YYYY-MM-DD hh:mm:ss scheduler [PID1] :: NOTE: *** verbose: 3 *** YYYY-MM-DD hh:mm:ss scheduler [PID1] :: NOTE: *** config: /usr/local/etc/fossology *** YYYY-MM-DD hh:mm:ss scheduler [PID1] :: NOTE: ******************************************** AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.X. Set the … AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.X. Set the … [………] [mpm_prefork:notice] [pid PID2] AH00163: Apache/2.4.25 (Debian) configured … [………] [core:notice] [pid PID2] AH00094: Command line: '/usr/sbin/apache2 -D FOREGROUND'
※YYYY-MM-DD⇒年-月-日、hh:mm:ss⇒時:分:秒、PID1⇒FOSSologyスケジューラのpid番号[………]⇒apacheの起動年月日と時間、PID2⇒apacheのpid番号
最後のapache2 -D FOREGROUNDのログが出ていれば、起動できています。
Yoctoビルド環境のdockerコンテナ上にインストールします。
今回、Yoctoビルド環境のベースとなったdockerコンテナは、Ubuntu 16.04のdockerイメージより作成しており、そのdockerイメージにはPython3.5をインストールしましたが、Python3.6でも動作可能なことは確認済です。
以下、dockerコンテナにyoctoユーザを作成し、ホーム ディレクトリ上で作業します。
$ git clone https://github.com/fossology/fossdriver.git $ pip3 install -e /home/yocto/fossdriver
インストールされたか確認します。
$ pip3 list beautifulsoup4 (4.7.1) bs4 (0.0.1) certifi (2019.6.16) chardet (3.0.4) command-not-found (0.3) fossdriver (0.0.2, /home/yocto/fossdriver) ★インストールできている ：
fossdriverの設定ファイルを作成します。
冒頭で説明した環境の通り、dockerホストのポート8081経由でFOSSologyにアクセスできるので、そのように設定します。
$ vi ~/.fossdriverrc
{
"serverUrl": "http://172.17.0.1:8081",
"username": "fossy",
"password": "fossy"
}
fossdriver経由で、FOSSologyへソース コードを送信してSPDXファイルを出力するテスト コードを置いたので、動作確認用にご利用ください。
使用例：
$ ./fossdriver-test.py <source-code.tar.gz> <SPDXファイル出力パス>
Yoctoビルド環境に、meta-spdxscannerレイヤを追加します。
以降、pokyディレクトリ以下での作業を想定しています。
$ git clone https://github.com/dl9pf/meta-spdxscanner
Yoctoのリリース版数にマッチするブランチがありますが、Sumo以降であれば、masterブランチで動作することを確認済です。
（MortyやPyroなど、古いYocto環境だと、動作しない可能性があります）
ビルド ディレクトリ配下のレイヤ設定ファイル（conf/bblayers.conf）に、meta-spdxscannerを追加します。（xxxは任意のパス）
：
BBLAYERS ?= "\
：
/xxx/poky/meta \
/xxx/poky/meta-poky \
：
/xxx/poky/meta-spdxscanner \ ★追加
ビルド ディレクトリ配下のYocto設定ファイル（conf/local.conf）に、fossdriverを経由して、ソース コードのスキャン＆SPDXファイル出力できるよう、記述を追加します。（xxxは任意のパス）
： # Use spdxscanner INHERIT += "fossdriver-host" SPDX_DEPLOY_DIR = "/xxx/SPDX" ★事前に作成しておいたディレクトリをfull-pathで指定
パッケージングされないOSSパッケージ（*-nativeパッケージなど）をソース コードのスキャン＆SPDXファイル出力対象外にする場合は、meta/classes/nopackages.bbclass に以下を追加します。
： deltask do_spdx ★最下行に追加
ここまで設定が終わったら、あとはbitbakeすると、パッチ適用されたソース コードがFOSSologyへ送信され、スキャン＆SPDXファイル出力まで自動で行われます。
出力ディレクトリを確認すると、以下のようにSPDXファイルが出力されます。
$ ls -l /xxx/SPDX/ total 232200 -rw-rw-r-- 1 <user> <group> <size> <MM DD xxxx> acl-<version>.spdx ： -rw-rw-r-- 1 <user> <group> <size> <MM DD xxxx> zip-<version>.spdx -rw-rw-r-- 1 <user> <group> <size> <MM DD xxxx> zlib-<version>.spdx
※<user> <group>ファイル所有のユーザ/グループ属性、※<size>⇒ファイル サイズ、
<MM DD xxxx>⇒年月日/月日時、<version>⇒ソース スキャンしたパッケージ版数
一例ですが、出力されるSPDXファイル（zlib-1.2.11）は以下の通りです。
zlib-1.2.11.spdx
今回は、fossdriverを利用する方法について記述しましたが、REST API（fossdriver無し）経由でFOSSologyへソース コードを送信することが可能です。こちらについては、REST API利用編で記述します。
また、FOSSologyの問題（大きいサイズのソース コードを送ると応答がなくなる、出力されるSPDXファイルのPackage License Declaredフィールドが”NOASSERTION”になる、etc…）に関する回避策なども、別記事で記述します。
English translation throughout by Fukuchi San. Thank you Fukuchi San!
本日はOpenChain Japan Workgroupで開催している全体会合について紹介します。私は、Planning subgroupのリーダーを担当している福地と申します。Planning subgroupは毎回全体会合を企画しています。
My name is Hiro Fukuchi, I am the leader of the planning subgroup. This article introduces the all member meeting held by the OpenChain Japan workgroup. The planning subgroup plans the meeting every time.
OpenChain Japan workgroupでは、2、3か月に1回の割合で全体会合を開催し続けています。誰でも参加できるオープンな会合です。workgroupに参加されている企業が自発的にホストを申し出て下さり、2017年12月のworkgroup開始時から2019年9月までに11回の会合を開催することができました。この間には、小規模のAd Hoc会合も3回開催しています。
The OpenChain Japan workgroup have been continuing to hold an all member meeting every two to three months since its beginning. Everyone can join the meeting. Member companies of the Japan workgroup hosted the meetings. From December 2017 to December 2019, we had 12 meetings and 3 ad hoc meetings.
全体会合では、OpenChainプロジェクトおよびJapan workgroupの紹介、サブグループ活動の紹介、ゲストスピーカーによる講演、ライトニングトークを中心にした全員参加の議論などを行なっています。各回およそ50~60名の方が参加され、フレンドリーな雰囲気の中で熱のこもった議論が行われています。
At the all member meetings, there are sessions such as, introduction to the OpenChain project, the Japan workgroup and the subgroup activities, a keynote speech by a guest speaker, lightning talk. Every time, we received 50 to 60 attendees. We have successfully made the meetings friendly and inclusive.
各参加企業がオフィスを会場として提供して下さり、開催場所は品川、新宿、蒲田、八王子、川崎、大阪、名古屋、神戸と全国に広がっています。
The venues of the meeting are spread over Japan, such as Tokyo (Shinagawa, Shinjuku, Kamata, Hachioji), Kawasaki, Osaka, Nagoya, Kobe.
多くの企業にホストしていただくのは重要なことだと私は考えています。企業としてホストすることで、担当者個人の活動から企業の活動に相変化が起きることが多くあります。実際に準備作業に参加したり、他企業の活動や担当者の熱心さを自分自身で感じることで、改めて自分たちの活動を振り返る良い機会になります。これを起点として組織の活動を再検討されるようです。更に、オープンソースに対する企業の姿勢を社内外へ発信する良い機会でもあります。
Hosting a meeting by a member company is very important for Japan workgroup to promote our activity in Japan. Hosting a meeting needs an organizational support from a company. In many cases, throughout the preparation of a meeting or watching other companies’ activities, the company had a significant recognition of the importance of our activity. Sometimes, we saw a personal activity changed to an organizational activity. Hosting a meeting is a good opportunity to show a company’s attitude toward open source.
Japan workgroupはオープンソースの活動ですから、日本に閉じて孤立したものにならないように、英語でグローバルに情報発信することを心がけています。全体会合は日本語で行われますが、使われた資料は英語に翻訳してwikiやGitHubに掲載されます。
Japan workgroup is regional and global activity. We discuss in Japanese language, but we are publishing our outcomes in Japanese and English language via the website and the GitHub site.
全体会合は、活力あるコミュニティを形成し維持していくために非常に重要な活動です。特にメンバー間の信頼関係を作るのに重要です。というのも、信頼関係は、オープンソースと言えども、直接会うことで構築されていくと考えているからです。自分の考えをお互いに共有し合い、議論をし、新しいアイディアを生み出していくことができます。この過程を通して相手への信頼が生まれます。
The all member meeting is of critical importance for the Japan workgroup to foster an active and inclusive community, because meeting in person builds trust between members in an open source community. A physical meeting gives an opportunity to share thoughts and feelings, discuss honestly and create a new idea. This process builds trust each other.
サプライチェーンは信頼関係の上にこそ成り立つ仕組みです。信頼できるサプライチェーンの実現を目指すOpenChainプロジェクトにとって、信頼関係を作る仕組みは根幹であると思います。同じ考えを持つ他社の方々と語り合うのは楽しく有意義な時間です。この時間を共有することで信頼関係は深められていくと思います。割と短い間隔で全体会合を開催しているのも、強い信頼関係を維持するのに必要だと考えているからです。
The OpenChain Project aims to build the trusted supply chain. The supply chain requires trusted relationship between suppliers and recipients. For the OpenChain Project, building trust is of critical importance.
サプライチェーンは海外にも広がっているのですから、信頼関係の構築は国内だけに限りません。私たちは、海外のゲストを全体会合に招待して講演してもらいますし、Japan workgroupのメンバーが中国、台湾で開催されるWorkshopに参加して自分たちの経験を発表することもあります。こうして、海外とも相互の関係が深まっています。
The supply chain extends globally, so that we need to build trust with the global community. The Japan workgroup invited guest speakers from Europe, Korea and Taiwan to our all member meetings. The Japan workgroup members visited workshops held in China and Taiwan to share our experiences.
継続することで、活動に活力と慣性が生まれます。活力と慣性が、活動を広げるエネルギーとなり、新しい人を呼び込み、更に新しい交流が生まれていくと私は考えています。
Continuing meetings gives power and momentum to the activity. Power and momentum give energy to our activity, and to invite new people. Meeting with new people begins a new relationship, so that our activity will be able to continue to expand.
全体会合に参加してJapan workgroup活動の雰囲気を自分自身で体験し、活動の輪に加わって頂ければ幸いです。新しく参加された方が会合での発言をきっかけに活動に深く関わられることも多いです。OpenChain Japan workgroupの活動を通じて、信頼できるサプライチェーンが実現されていくことを願っています。
It is our pleasure if we can provide an opportunity for newcomers to join our all member meeting and experience the active and inclusive atmosphere by themselves.
ご興味のある方はこちらから是非ご参加ください：
OpenChain Japan WG wiki
OpenChain Japan WG ML
OpenChain Japan WG slack
Please visit our resources:
OpenChain Japan WG wiki
OpenChain Japan WG ML
OpenChain Japan WG slack
明日は富士通コンピュータテクノロジーズの芦塚さんから、Yocto環境にmeta-spdxscannerを適用しSPDX出力環境を構築する手順を紹介してもらいます。
Ashizuka-san from Fujitsu Computer Technologies explains the meta-spdxscanner, that is a tool to output SPDX files in a Yocto environment.
株式会社日立製作所 岩田吉隆
今回は、OpenChain Japan WG「役割ごとの教育資料」SWGについて紹介します。
ソニー、オリンパス、日立（リーダ）
先ず、コンプライアンスにかかる教育の状況について議論しました。
a. OpenChain設立前から、OSSに関する教育を実施している会社もある。
b. これから、教育を実施する会社は、どういう教育内容、対象者からスタートすべきか、検討が必要。
c. 会社毎のビジネス形態により、 OSSに関わる必要なビジネスフローは異なる。
d. OSSに関わる上で、役割ごとに本当に必要最小限な教育観点は異なっている。
e. Curriculum※ を全て教育内容に盛り込むと、分量が多すぎる。
f. Specification※, Curriculumとの整合性も考慮が必要。
(※：SpecificationはOpenChainの一連の要件を定義している仕様書、CurriculumはOpenChainのSpecificationを下支えするトレーニング教材)
コンプライアンスにかかる教育の状況を踏まえ、進め方の方針について検討しました。
a. 既に各社実施されている教育の体系、対象者、形態(講演会、集合研修、e-learning、資料閲覧、他)、タイミング、英語版有無を、可能な範囲で事例として提示。
b. a.に関して、各教育がビジネスフロー上で、どの対象者をカバーしているかを明示。
c. 各教育の目次、章/節の概要程度まで、可能な範囲で提示。
d. a, b, cの事例を元に、下記を整理する。
①最初にsmall startするための必要最小限の項目は？
②役割ごとに、教育資料として必要な項目は？共通項目、役割ごとの独自項目は？
③ライセンス関連で必要な項目は？
④SPDXの活用方法は？
⑤役割ごとの共通教育資料の案を作成
先ずステップ１として、４社の事例の分析からスタートしました。
a. 各社のOSSに関する教育の例を収集
| No. | 会社 | 事例数 |
|---|---|---|
| 1 | 製品ベンダー1 | 9 |
| 2 | 製品ベンダー2 | 5 |
| 3 | 製品ベンダー3 | 1 |
| 4 | 製品ベンダー4 | 2 |
b.下記の分析観点について、分析、報告
i. OSSに関する教育のニーズ
ii. OpenChainのSpecificationに準拠する。
iii. Curriculumの過不足を考慮
iv. 役割ごとの教育の検討 (４社のケーススタディ)
⇒ GitHubへアップ
次にステップ２として、４社の事例の分析結果を基に、共通教育資料の案の作成を行っています。
a. ４社の事例の分析結果を元に、共通教育資料の検討を実施
i. Specificationを満たすためにコンプライアンスプログラムの記載は必須
ii. Curriculumの過不足を配慮
iii. リーフレットで使用されている語彙、表現を考慮
iv. 各社の一般向け基礎教育の共通内容を考慮
b. 製品ベンダーのソフトウェア開発者向け共通教育資料のコンプライアンスプログラム・バージョンの案の提案を行う。a.のi.～ⅲ.は必須項目とし、ⅳ.の共通内容を重点的に、ⅳ.の一部内容は概略的に、説明する方向で詳細化を図る。OSSを使用して製品を開発するために、製品ベンダーのソフトウェア開発者向けというターゲットを設定した。
c. 役割ごとの分担と責任の明確化の例示
Specification上での役割の必須要件の例示を行う。
d. 案作成の検討を通して、下記章立てにて作成中
e. d.の各章毎に、GitHub上でJapan WG内のレビューを行う。
以上、OpenChain Japan WG「役割ごとの教育資料」SWGについて簡単に紹介しました。更に、教育資料の事例の拡充や、共通教育資料案の紹介とレビューを行う予定です。皆様の参加をお待ちしています。
We have had some great feedback on the procurement document. Before we head into release I want to put out a final call for comments and suggestions. We close this and move towards release May 7th Close of Business Pacific.
Check Out The Document
Get this guide and many more documents in the OpenChain Reference Library: https://github.com/OpenChain-Project/Reference-Material
© 2024 OpenChain. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page. Linux is a registered trademark of Linus Torvalds. Privacy Policy and Terms of Use