この記事の執筆現在で、3.0版に向けた検討が始まっています。利用を推奨する取組も見られます。関連する情報を抽出します。ページが参考になると思います。関連する情報を抽出します。検出アルゴリズムが異なることに伴う検出結果の違いから、使い分ける利用者もいるようです。始めとする各種ツールを連携し、SBOM管理を効率化するためのカタログツールとして開発されたものです。公開してくれているので、興味のある方はご一読ください。ツール群で構成されています。お役立ち情報まとめ・下」です。引き続き僕が担当します。情報収集やネットワーキングに役立つイベントや、書籍や文書など知識を得るのに利用したものを紹介しようと思います。以下は、本稿執筆時点のものになります。知的財産やコンプライアンス関連の業務に従事しています。コミュニティメンバーとして参加しています。企業知財に関する調査研究に参加しています。前職は通信会社で研究開発部門に長くいました。ためのサービス試作開発などに従事していました。page.はじめにこんにちは。Groupになります。本日の担当させて頂く遠藤雅人です。SWGのリーダーとして今回のアドベンドカレンダー企画のサポートもさせて頂いています。Chairを拝命しております。趣味は旅行、ガジェット、スポーツ観戦(主にサッカー)です。下記のサイトからML登録することでWGに参加することができます。https://groups.io/g/openchain-automotive-work-group他のOSSコミュニティ同様、自動車業界の方でなくても活動に関心があれば誰でも参加可能です。日米欧韓の12の自動車メーカの方々が既にメンバーになっています。その他にも自動車部品サプライヤ、電機メーカ、半導体メーカ、システムベンダ、ツールベンダ、弁護士、コンサルの方など多岐に渡る100名以上の方にMLに登録頂いています。これまでの活動コミュニティ設立から1年は、情報共有のベースの形成や参加者のニーズの把握をすることに力をいれています。Shopを開催しました。上記の3つの目的を確認しました。Europe時に併催され、Scania、富士通、デンソーテン、Boschが各社のOSSコンプライアンスに取り組みを紹介しました。Shopを実施予定です。同時期にラスベガスで行われるCESの会場の近くで実施する予定ですので、CESに参加される方で興味ある方は是非MLに登録の上エントリーください。Chainのコラボレーション企画として、OpenChainのミニブースをAGLブース内に設置予定ですのでこちらもよろしくお願い致します。2020デモ展示を発表AGLとOpenChainの関係については、本カレンダーの19日に登場予定の日下部さんに詳細を語って頂く予定です。お役立ち情報まとめ」になります。WGにWeb系の世界から彗星のごとく現れ、Projectの中で目覚ましいご活躍を頂いている忍頂寺さんになります。WGのアドベントカレンダー、本日は13記事目になります。本アドベントカレンダーは、OSSコンプライアンスに関わる取り組み「OpenChain」プロジェクトの日本ワーキンググループのメンバーが日替わりで記事を書いています。参考:FacebookやGoogleも参加するOSSコンプライアンスのプロジェクト、「OpenChain」とは今回は「OSSの利用に伴う特許侵害リスク」について書いてみたいと思います。国内外のIT関連分野について、特許や現地メディアを通じて技術動向の調査をしたり、それらをまとめた記事を書いたりしています。Japanは2019年夏に存在を知って、全体会合に一度参加しただけのまだまだ初心者です。Japanでは、OpenChainやOSSコンプライアンスの普及を担うPromotionグループに参加しています。OSSと特許権侵害あるOSSが第三者の特許権を侵害している場合、OSSの提供元だけでなくそのOSSを利用した製品やサービスも特許権侵害の対象となります。損害賠償金を請求されたり、特許ライセンス費用を要求されたりする可能性があります。過去には、スマホ用OSとしてOSSの代表格であるAndroidが特許権侵害をしているとして、提供元のGoogleだけでなくAndroidスマホの開発企業が訴えられる事例も発生しています。Microsoft、Android端末の特許侵害でMotorolaを提訴Android関連の特許訴訟が相次いだGoogleは、上記ニュースでも話題になっているモトローラを買収。その後、多くの特許を保有したまま携帯事業部門を中国・レノボに売却したことから、訴訟に耐えうる特許取得が目的の企業買収と話題になりました。Network)特許によってOSSの円滑な利用が阻害される状況を懸念して、その問題を解決しようとするコミュニティ活動も同時に始まりました。Defenders」の活動を紹介します。引用OINは「OSSに関する特許のクロスライセンス」を促進するコミュニティ活動です。OINはLinuxに関連する特許を保有し、「Linux関連技術を利用する企業に特許訴訟を行わないこと(自社特許を開放すること)」に同意した参加企業に対して無償でライセンス提供を行います。2018年にはマイクロソフトがOINに参加、OSSと特許訴訟を巡る状況の1つの転換点となりました。Defenders」という活動が行われています。Activities:特許審査が適切に行われるように関連技術資料を提供、OSSコミュニティのリスクとなる特許の再審査を推進などがあります。エンジニア以外の専門家もOSSへ関わることが不可欠な時代へ知財部門の仕事の1つとして、「自社の事業を円滑に進めるために、他社の特許にどう対処するか」が挙げられます。「他社の特許を調査して、問題となる特許を把握する」「問題となる特許について回避方法を検討する、無効化を仕掛ける」「回避案が見つからないときのために、他社との交渉材料となる特許を仕込んでおく」といった業務が中心になりますが、今後はそれらに加えてこういったコミュニティ活動への対応も必要になっていきます。引用ウェブサービスやスマホアプリだけでなく、家電や自動車など全てのものにソフトが組み込まれる時代。OSSの導入はますます加速していきます。エンジニアだけではなく知財関係者など様々な専門家がOSSコミュニティに貢献していくことが、国や企業の競争力に繋がっていく(そして、その人自身のキャリアにも繋がっていく)。そんな時代になっていくのかなと最近考えています。Japan内で知財関連のワーキンググループが出来たらぜひ参加したいと思ってます。明日は本記事内で紹介した資料の作成者でもあるトヨタ自動車の遠藤さんが担当。WGについて紹介いただく予定です。Featuredはじめにこんにちは。二度目ましての方も、おいででしょうかね。オープンソース(OSS)の利活用コンサルをしています、渡邊歩です。今回は本業のテーマで、「OSS管理のベストプラクティス」の必須要素である「組織」、「ポリシー」、「(正しい)知識」、「ツール」について書かせていただこうと思います。OSSコンプライアンスって何から始めればいいの?OSS管理ツールってたくさんあるけどそれぞれどう違うの?というような方のお役に立てれば幸いです。TODOグループのオープンソースプログラムの作成では、OSPOは「オープンソースをサポートし、育成し、共用し、説明し、成長させていくために企業内で中心となる組織」と定義されています。組織、というととても専門的で大規模なものを想像するかもしれませんが、少人数だったり他の業務との兼務だったりと、その形態は企業・組織によって様々です。これまで多くの企業・組織のOSPOの設立をご支援してきた中で、その成立ちを大きく分類すると下図のようになります。どのモデルにもそれぞれメリット・デメリットがありますので、それらを意識しながら推進していくことが重要です。成功するOSPOの共通点というと、必要であれば会社の規則を変えたり製品の出荷を止めたりできるような「権限」があることと、企業・組織としてコンプライアンスを推進するのだという「使命」があることでしょうか。ルール主導にならないよう、開発チームと密に連携して無理のないプロセスを構築していくことも、成功の秘訣です。ポリシーについてOSS管理って何から手をつければ良いんですか?という質問をいただくことがありますが、私はまず「OSSポリシーを作りましょう」とご提案します。OSSポリシーとは、企業または組織がOSSとどのように関わっていくかという指針を定めたもので、様々なシーンで判断をする際の拠り所になります。OSSポリシーにも色々な形式、粒度がありますが、私が一般的におすすめしているのは下記の形式です。ポリシーで定めた内容を詳細化し読み物の形にした「ガイドライン」や、組織のメンバーに理解・浸透させるための「教育資料」の形に転用することもできます。正しい知識について今年は、たくさんの会社様からOSS教育のご依頼をいただきました。OSSの活用そのものが増えてきていることに加え、「正しく基礎的な知識を全員が持っていること」が重要視されてきているように思います。WGでは、関係する方々全員に正しい理解をしていただくためのリーフレット「オープンソースソフトウェアライセンス遵守のための一般公衆ガイド」を作成しました。(詳しくは12月8日のSat_Uさんの記事をご覧ください!)このガイドは、日本語版が作成された後、英語や中国語などに翻訳されています。海外の取引先にOSSコンプライアンスについて知って貰いたい方は是非この翻訳版のガイドを活用してください。ツール(OSS管理ツール)についてここでは、ソフトウェアを解析し、内包するOSSを検出するツールのことをOSS管理ツールと呼びます。OSS管理ツールも様々なものがありますよね。結局のところ、どれがいいの?と迷われる方も多いと思いますので、選ぶ際の観点とおすすめツールを纏めてみました。観点その1:OSSを改変して使っているかOSS管理ツールの基本的なアプローチは、解析対象ファイルから算出したハッシュ値と、予め算出して蓄えてあるOSSのハッシュ値とを比較する「ファイルマッチング」という方法です。ほとんどのツールには「あいまいマッチ検出」の機能があるので、軽微な改変であれば検出することができますが、改変の度合いと検出率は相反関係になります。改変されたOSSの検出を可能にするため、いくつかのOSS管理ツールでは「スニペットマッチング」というアプローチをとっています。これは、ファイルの一部分だけが似ているようなOSSを特定することができ、OSSの意図しない混入(コンタミネーション)を検出することができます。as-isのOSSのライブラリを参照しているだけ、というような方であればファイルマッチングができるOSS管理ツールで十分ですし、組込み開発などでOSSの改変が必須の方であれば、スニペットマッチングができるOSS管理ツールを選んでください。Source(ファイルマッチング)観点その2:独自ビルドのバイナリファイルを解析する必要があるかOSSのバイナリファイルをas-isで使用している場合であれば、上述の「ファイルマッチング」でカバーできますが、独自ビルドのバイナリファイルは、ビルド環境やオプション等によりハッシュ値が変わりますので、特別なアプローチが必要です。元にしたソースファイルが手元にある場合はもちろん、ソースファイルを解析すれば良いのですが、外部からの購入品などでバイナリファイルしか手元にない場合もありますので、そのような方は独自ビルドのバイナリファイルを解析する機能を持ったツールを選んでください。取り込んだOSSが更に別のOSSを取り込んでいて、突き詰めていくとGPLライセンスのライブラリが入っていた・・・という「あるある」を経験したことのある方も多いのではないでしょうか。License」と呼びます。Licenseを調べるには、パッケージ毎の依存関係(どのパッケージが、どのパッケージを内包しているか)を調べなければなりません。Licenseを詳しく調べたい方は、パッケージマネージャの依存関係を示すファイルを解析しパッケージの依存関係を可視化してくれる機能を持ったツールを選んでください。明日の担当は、tech_nomad_さん。「OSSと特許侵害」という、とても気になる!でも難しくて解らない!というテーマを語ってくださいます。控えめに言ってもめっちゃためになります。明日もお楽しみに!!お役立ちリンクこの投稿を読んでくださった方から「これも参考になるよ!」と教えていただいた情報を載せておきます。コード解析→SPDXファイルの出力が可能です。コードを送信、解析、SPDXファイルを出力する環境の構築方法をまとめてみました。今回、構築する環境は、以下のような感じです。Linux)など、dockerが使えれば何でもよいです。青枠がdockerコンテナです。FOSSologyやYoctoビルド環境をdockerコンテナで構築し、Yoctoビルド環境のdocker上にFOSSologyとアクセスするためのfossdriverをインストールします。※FOSSologyやYoctoビルド環境についての説明は割愛します。dockerイメージを取得します。最新版は3.6.0版ですが、fossdriver経由で動作しないので、3.5.0版を取得します。追記:fossdriverが、FOSSology-3.6.0に対応したようです。dockerを起動します。8081:80は、外部アクセスされるポート番号:dockerコンテナ側のポート番号を指定します。-dは、バックグラウンド実行です。logsで起動状況(--tail=20で、最新ログ20行だけ)を表示します。FOREGROUNDのログが出ていれば、起動できています。fossdriverのインストールYoctoビルド環境のdockerコンテナ上にインストールします。16.04のdockerイメージより作成しており、そのdockerイメージにはPython3.5をインストールしましたが、Python3.6でも動作可能なことは確認済です。ディレクトリ上で作業します。/home/yocto/fossdriverインストールされたか確認します。★インストールできている:fossdriverの設定ファイルを作成します。冒頭で説明した環境の通り、dockerホストのポート8081経由でFOSSologyにアクセスできるので、そのように設定します。コードを置いたので、動作確認用にご利用ください。<SPDXファイル出力パス>meta-spdxscannerレイヤ追加と設定ファイル更新Yoctoビルド環境に、meta-spdxscannerレイヤを追加します。以降、pokyディレクトリ以下での作業を想定しています。https://github.com/dl9pf/meta-spdxscannerYoctoのリリース版数にマッチするブランチがありますが、Sumo以降であれば、masterブランチで動作することを確認済です。ディレクトリ配下のレイヤ設定ファイル(conf/bblayers.conf)に、meta-spdxscannerを追加します。コードのスキャン&SPDXファイル出力できるよう、記述を追加します。コードがFOSSologyへ送信され、スキャン&SPDXファイル出力まで自動で行われます。出力ディレクトリを確認すると、以下のようにSPDXファイルが出力されます。一例ですが、出力されるSPDXファイル(zlib-1.2.11)は以下の通りです。コードを送信することが可能です。API利用編で記述します。Declaredフィールドが”NOASSERTION”になる、etc...)に関する回避策なども、別記事で記述します。Workgroupで開催している全体会合について紹介します。subgroupのリーダーを担当している福地と申します。subgroupは毎回全体会合を企画しています。workgroupでは、2、3か月に1回の割合で全体会合を開催し続けています。誰でも参加できるオープンな会合です。workgroupに参加されている企業が自発的にホストを申し出て下さり、2017年12月のworkgroup開始時から2019年9月までに11回の会合を開催することができました。Hoc会合も3回開催しています。workgroupの紹介、サブグループ活動の紹介、ゲストスピーカーによる講演、ライトニングトークを中心にした全員参加の議論などを行なっています。各回およそ50~60名の方が参加され、フレンドリーな雰囲気の中で熱のこもった議論が行われています。全国に広がっています。Kobe.多くの企業にホストしていただくのは重要なことだと私は考えています。企業としてホストすることで、担当者個人の活動から企業の活動に相変化が起きることが多くあります。実際に準備作業に参加したり、他企業の活動や担当者の熱心さを自分自身で感じることで、改めて自分たちの活動を振り返る良い機会になります。これを起点として組織の活動を再検討されるようです。オープンソースに対する企業の姿勢を社内外へ発信する良い機会でもあります。workgroupはオープンソースの活動ですから、日本に閉じて孤立したものにならないように、英語でグローバルに情報発信することを心がけています。全体会合は日本語で行われますが、使われた資料は英語に翻訳してwikiやGitHubに掲載されます。trust全体会合は、活力あるコミュニティを形成し維持していくために非常に重要な活動です。メンバー間の信頼関係を作るのに重要です。いうのも、信頼関係は、オープンソースと言えども、直接会うことで構築されていくと考えているからです。自分の考えをお互いに共有し合い、議論をし、新しいアイディアを生み出していくことができます。この過程を通して相手への信頼が生まれます。other.サプライチェーンは信頼関係の上にこそ成り立つ仕組みです。信頼できるサプライチェーンの実現を目指すOpenChainプロジェクトにとって、信頼関係を作る仕組みは根幹であると思います。同じ考えを持つ他社の方々と語り合うのは楽しく有意義な時間です。この時間を共有することで信頼関係は深められていくと思います。短い間隔で全体会合を開催しているのも、強い信頼関係を維持するのに必要だと考えているからです。communicationサプライチェーンは海外にも広がっているのですから、信頼関係の構築は国内だけに限りません。workgroupのメンバーが中国、台湾で開催されるWorkshopに参加して自分たちの経験を発表することもあります。して、海外とも相互の関係が深まっています。power継続することで、活動に活力と慣性が生まれます。活力と慣性が、活動を広げるエネルギーとなり、新しい人を呼び込み、更に新しい交流が生まれていくと私は考えています。workgroup活動の雰囲気を自分自身で体験し、活動の輪に加わって頂ければ幸いです。新しく参加された方が会合での発言をきっかけに活動に深く関わられることも多いです。workgroupの活動を通じて、信頼できるサプライチェーンが実現されていくことを願っています。theme:明日は富士通コンピュータテクノロジーズの芦塚さんから、Yocto環境にmeta-spdxscannerを適用しSPDX出力環境を構築する手順を紹介してもらいます。WG「役割ごとの教育資料」SWGについて紹介します。コンプライアンスにかかる教育の状況について議論しました。OpenChain設立前から、OSSに関する教育を実施している会社もある。これから、教育を実施する会社は、どういう教育内容、対象者からスタートすべきか、検討が必要。OSSに関わる必要なビジネスフローは異なる。OSSに関わる上で、役割ごとに本当に必要最小限な教育観点は異なっている。全て教育内容に盛り込むと、分量が多すぎる。Curriculumとの整合性も考慮が必要。(※:SpecificationはOpenChainの一連の要件を定義している仕様書、CurriculumはOpenChainのSpecificationを下支えするトレーニング教材)進め方の方針コンプライアンスにかかる教育の状況を踏まえ、進め方の方針について検討しました。e-learning、資料閲覧、他)、タイミング、英語版有無を、可能な範囲で事例として提示。a.に関して、各教育がビジネスフロー上で、どの対象者をカバーしているかを明示。各教育の目次、章/節の概要程度まで、可能な範囲で提示。cの事例を元に、下記を整理する。ステップ1として、4社の事例の分析からスタートしました。OpenChainのSpecificationに準拠する。次にステップ2として、4社の事例の分析結果を基に、共通教育資料の案の作成を行っています。製品ベンダーのソフトウェア開発者向け共通教育資料のコンプライアンスプログラム・バージョンの案の提案を行う。a.のi.~iii.は必須項目とし、iv.の共通内容を重点的に、iv.の一部内容は概略的に、説明する方向で詳細化を図る。OSSを使用して製品を開発するために、製品ベンダーのソフトウェア開発者向けというターゲットを設定した。役割ごとの分担と責任の明確化の例示Specification上での役割の必須要件の例示を行う。WG内のレビューを行う。WG「役割ごとの教育資料」SWGについて簡単に紹介しました。教育資料の事例の拡充や、共通教育資料案の紹介とレビューを行う予定です。皆様の参加をお待ちしています。CertifiedParticipateResourcesFAQPartnersNewsAbout。