ISO/IEC 5230で変わる︖OSSコンプライアンス対策
はじめに
---------------------------------------
コロナ禍の2020年12月に施行された、OSSの国際標準、ISO/IEC 5230。一言でいうと「組織がライセンスを遵守してオープンソースソフトウエアを適切に利用するための仕組み」と言われます。あちこちで記事やニュースを見かけますし、経済産業省の「OSSの利活用及びそのセキュリティ確保に向けた管理手法に関する事例集」(R3年4月21日)に掲載される、企業のヒアリング集からも既に認証を取得している企業があることがわかり、避けて通れない標準のように見えます。
本記事の読者の中にも、既に名称をご存じの方はいらっしゃると思いますが、ご自身のOSS関連業務との関係については、検証済みでしょうか。場合によっては業務プロセスへの影響があるかもしれませんし、認証取得が急がれるかもしれません。この考察が本記事の趣旨になります。
1. まずは正体を明らかにする
---------------------------------------
最初に、本標準の内容は、それ自体がOSSコンプライアンス業務を完結させるものではないことを指摘しておきます。例えば、ISO9000シリーズなどの経験をお持ちであれば連想されると思いますが、ポリシーを定めて、それを守るための業務手順と指標を定め、その支援体制を決め、この一連の仕組みの評価と改善を行う流れは、OSSコンプライアンスの仕組みにおいても変わりはありません。
このうち、本標準では、仕組みにおける各項目の深堀ではなく、必要な項目が何で、そのような項目に対応ができているのかを判定するためのチェックリストと捉えられるものです。従って、本標準の使い方としては、新規に仕組みを構築する上で何を用意すればよいか判断したり、客観的に未対応の項目を見つけたりする根拠になりますし、全ての項目が網羅できていれば、(改善を進める必要はあるとしても)認証取得に邁進できることが明らかになります。以下、これら3つの場合に分けて皆さまがなすべきことを見て行きましょう。
2. 仕組みがない場合の対応
---------------------------------------
この場合、国際標準の有無にかかわらず、やることがあります。それは、上層部や関係者との間で、①自組織のOSSの利用方法や流入経路を理解した上で洗い出したリスク要因を共有し、②リスクを低減するルールを現場業務になじむようアレンジし、チェックゲートも設けた上で提案し、
③取引先等、自組織以外の経路からの協力も取り付けると共に、並行して契約等の別のリスク回避手段を取ることです。
国際標準化により、これらの実施内容は変わりませんが、これまで関係区に刺さりにくかった経験をお持ちの方ならば、今後はご自身の主張に裏付けを持たせ、進めやすくなると考えられます。(但し、「国際標準なのだから従え」というスタンスでは周りが付いて来ません。従来通り、現場に寄り添った進め方が必要です。)
3. 仕組みに不足する項目が見つかった場合の対応
---------------------------------------
この場合、今までは仕組みの見直し、業務改善において、客観的指標がなく、改善が進んだ項目もあれば、見落とされていた項目もあったはずです。本標準を活用することで、このような気づきが得られるものと期待できます。例えば、コンプライアンスの周知徹底に邁進する中、ISO/IEC5230にいう「OSSプロジェクトに対するコントリビューション」の対応が洩れていた、という可能性、あるいはOSSの管理に自社独自の部品表を使用して来たが、OSSの部品表についてSPDXという共通フォーマットがあることに気づいた、などが考えられます。
4. 全ての項目が網羅できていた場合
---------------------------------------
この場合、直ちに本標準の認証を取得することが必須というわけではありません。まずは認証取得のメリットをよく考えて、次の動きを決めましょう。例えば、サプライチェーン上流の取引先に対しても認証取得を促しやすくなり、予期せぬOSSの流入リスクを下げたり、サプライチェーン下流の取引先や市場からの信頼度を上げられることなどが考えられます。
5. 国際標準適応と並行してやりたいこと
---------------------------------------
本標準は、例えば「徹底解説︕OSSライセンスコンプライアンスの国際標準【ISO/IEC 5230】&お役立ちコンテンツのご紹介」(株式会社日立ソリューションズ)(*1)など、既に公知となっている参考資料にもある通り、認証取得時にはOSSコンプライアンスの仕組みとして最低限「ベースライン」があることを求めるもので、業界最高の「ベストプラクティス」を求めるものではありません。
それでも、仕組みの構築、あるいは改善を行う上で、同じく本標準の認証を受けた他社(他者)との情報交換を取入れることは有効な手段です。OpenChainには日本部会による活動が年々活発化しています。参加を検討されてはいかがでしょうか。
また、OSSのライセンス検出や国際標準仕様の部品表の出力については、昨今では現場の負荷を軽減するための自動化ツールが多数リリースされています。本標準への適応と同時に自動化による費用対効果の検討を行っても良いでしょう。
6. 最後に
---------------------------------------
タイトルに挙げた「ISO/IEC 5230で変わる︖OSSコンプライアンス対策」への答えですが、結論としては次のようにポジティブに捉えてよいのではないでしょうか。
- やるべきこと、あるべき姿は変わらない
- しかし、関係者による受け止めは、以前より好意的になることが期待できる
- 標準化により実務上の共通化も進むことで、現場の工数削減が期待できる
- ここで節約できた工数を、他の重要テーマに振り分けることができる
[引用]
(*1)徹底解説!OSSライセンスコンプライアンスの国際標準【ISO/IEC 5230】&お役立ちコンテンツのご紹介
https://event.ospn.jp/osc2021-online-spring/session/297746
※本文中記載の会社名、商品名、ロゴは各社の商標、または登録商標です。
Tips集のご案内
テクマトリックスでは、開発企業としてOSSと上手につきあうための「OSS活用Tips集 – シーズン2」を提供しています。
「資料ダウンロードはこちら」から、ホワイトペーパーを一括でダウンロードできます。
1.「OSS最新動向-コロナに負けないオープンソース」
2.「オープンソースSBOMが必要な理由とは!」
3.「ソフトウェアイノベーションはOSSから、コンテナ・AI技術がイノベーションを牽引」
4.「OSSと上手に付き合う方法~攻めは最大の防御なり~」
5.「OSSと上手に付き合う方法~サプライチェーンを安全に~」
6.「ISO/IEC 5230で変わる?OSSコンプライアンス対策」
7.「著作権トロールとは?」