はじめに
こんにちは。Open Source Program Office TFです。Linuxを中心としたオープンソース関連技術のコンソーシアムであるLinux Foundationでは、オープンソース管理のための標準規格を策定するOpenChainプロジェクトも運営しています。私たちは約2年間、OpenChainプロジェクトで策定された国際標準規格をLINEの開発組織へ適用する大型プロジェクトを進めてきました。このたび、オープンソース管理の国際標準であるISO/IEC 5230認証を取得しました。
今回の記事では、まずOpenChainプロジェクトについて紹介し、OpenChain規格をLINEに適用するためにどんな努力をしてきたのかをお話します。また、OpenChain規格を適用することにどのような意義があるのか、会社と開発者の観点で見てみようと思います。 LINEの経験を共有するこの記事が、開発者にはオープンソース管理の重要性を知るきっかけに、オープンソース管理業務をしている人には業務の参考資料になればと思います。

OpenChainプロジェクトとは
企業がソフトウェアを開発するとき、企業自らの力だけで開発するケースは稀です。外部のオープンソースやアウトソーシングを活用したり、商用ソフトウェアを購入したりするケースもあります。このような場合でもやはりコードは企業独自ではない場合が多く、一つの製品を開発する際には様々な経路で様々なコードが流入します。 これは、開発を終えて製品を頒布するときも同じです。顧客に直接ソフトウェアを納品するよりも、複雑な経路を経由して製品を届けるケースが多いわけです。 このようにソフトウェアを開発し、納品するまでの全プロセスを「ソフトウェアサプライチェーン」と呼びます。
OpenChainプロジェクトは「オープンソース管理の標準を定義し、複雑なソフトウェアサプライチェーンの中で企業が効果的にオープンソースを管理できるようにしよう」という目標を持っています。
まずはOpenChainプロジェクトの規格を紹介し、これを適用すると企業や各メンバーがどのような効果を得ることができるのか見てみましょう。
規格の紹介
OpenChainプロジェクトは、オープンソースコンプライアンスのための要件を定義し、それに準拠するためのガイドラインを提供しています。OpenChain規格は、企業の規模や業種に関係なくすべての企業に適用できるように設計され、現在はバージョン3.0まで策定されています。LINEでは、認証取得のプロジェクト進行当時に最新バージョンだったバージョン2.1を基準に規格を適用しました。
バージョン2.1の規格では、企業への6項目の要求事項を次のとおり定義しています。
- オープンソース管理プログラムの構築
- オープンソースをどのように利用すべきかというポリシーとその適用範囲や、参加者の責任と役割を明確に定義する
- 定めたポリシーとその目標および遵守しなかった場合の影響などをすべての参加者が認識できるように掲示する
- ライセンス義務や条件について確認し、判断するための意思決定プログラムを構成する
- 関連業務の定義と支援
- 外部からオープンソースに関する問い合わせがあった際に効果的に対応できるプロセスを構成する
- オープンソースプログラムがスムーズに運営されるように、十分なリソースを提供する
- 法律諮問などイシュー対応に必要な社内プロセスを構築する
- オープンソースコンテンツのレビューと承認
- 社内で提供されるソフトウェアを構成する各オープンソースコンポーネントのライセンス情報を含むBOM(Bill of Material)を作成し、管理するためのプロセスを構築すること
- オープンソース責任者を任命した上で、一般的なオープンソース使用事例を管理し、主要ライセンスの要件と注意事項を整理して社内で共有する
- コンプライアンス成果物の作成と周知
- オープンソースのライセンスが要求する義務事項を遵守し、コンプライアンス成果物(オープンソースに関する告知文、公開するソースコードのパッケージ)を作成し、保管および周知させる
- オープンソースコミュニティ活動への理解
- オープンソースプロジェクトに貢献するためのポリシーとプロセスを文書化する
- 規格要件の遵守
- OpenChain規格で要求されるすべての要件を満たし、OpenChainに準拠するプログラムがあると宣言する
オープンソースガバナンスを初めて開始する企業であっても、OpenChain規格の要件に一つずつ従えば、レベルの高い管理プロセスを構築できます。
LINEで特に気を遣った部分
上記の規格を適用する際、LINEという組織の特性に合わせて特に気を遣った部分があります。一つずつ見ていきましょう。
OpenChain規格と既存LINEポリシーの比較と把握
LINEがOpenChainプログラムを開始するまでは、それまでの経験と外部コミュニティを通じて学習した知見に基づいてオープンソースポリシーを策定し、運用している状況でした。そこで、LINEではOpenChainプログラムを適用する前に、当該プロジェクトで要求される事項は何であるかを把握してマイルストーンを整理する作業を進めながら、具体的に次ように項目を取り上げて整理しました。
- 規格と比較して、既にうまくやっていたことは何か
- 規格と比較して、不十分な部分は何か
- どんなものを新たに用意すべきか
- 他部署と協議すべき部分があるか
社内での周知方法の確立
OpenChain規格では、ポリシーをきちんと作成するだけでなく、そのポリシーと運営のプロセスを従業員がアクセスやすい場所で公表し、教育を通じて十分に説明したかどうかも重要な要素とされています。ポリシーをいくら上手く作成しても、開発者がそれを認知できなければ、十分に効果を発揮できないからです。 この部分は普段オープンソース管理業務を進めながら常に悩んで努力してきた部分でもあり、改修されたポリシーを効率的に周知する方法を模索しながらもう一度考えてみました。
私たちは、開発者がオープンソースポリシーの存在をいつでもきちんと認識できるように、共通開発ガバナンス規定に追加しました。 これに伴い、ソフトウェアのリリースのプロセスでのみ確認していたオープンソースポリシーは、開発のプロセスでも必ず確認する手続きになりました。こういった変化が既存の開発作業に大きな影響を及ぼさないよう、よく利用される代表的なオープンソースライセンスを分類して説明した文書を開発者自らが容易かつ迅速に判断できるように提供しています。もちろん、複数の社内チャンネルでオープンソースポリシーの改修について継続的に告知し、改修内容を周知する作業も着実に進めています。
OSRB(Open Source Review Board)の構成
OpenChainプログラムを進める上で最も難しかった課題の一つがOSRBを組織化することでした。 オープンソース管理業務の基本は、独自に開発したプログラムのオープンソースコンプライアンスですが、 LINEではOpen Source Program Officeにおいて、それ以外にもオープンソース活動をより活性化させるためのオープンソースの公開、貢献、イベントなどの多様な業務を共に担当していたため、関連部署との協業が不可欠でした。そこで、各チームの本来の業務とそれまでの協力の実績を参考にして、次のとおりOSRBを構成しました。
- Open Source Program Office:オープンソース関連業務をすべて担当し、他のOSRBメンバーとの協力において中枢的な役割
- 法務チーム:オープンソースライセンスまたは関連契約の法務レビューを支援
- 特許チーム:特許ライセンスに関するレビューを支援
- セキュリティチーム:オープンソースのセキュリティホール管理のための業務協力
- CTO Office:全社の開発組織でオープンソース関連プロセスを忠実に行うことができるように協力
- Developer Relationsチーム:社内外を対象とするオープンソース関連の技術コンテンツ制作のための業務協力
それまでも各部署と協業はしていたものの、明確なポリシーとして文書に明示して実務担当者を指定すると負担が増えるとと思いましたが、幸い、すべてのチームがプロジェクトの趣旨に共感し、快く担当者を指定して必要な責任と力量を定義してくれました。
ちなみに、OpenChain規格の例には、OSRBにCTO OfficeとDeveloper Realationsチームが含まれていませんが、LINEではイシューが発生したとき、多様な開発組織とすぐにコミュニケーションを取り、迅速に状況を把握して対応するためにCTO Officeを含めました。また、オープンソースをテーマに多様なコンテンツやイベントを企画するとき、オープンソースのライセンスイシューを確認したりオープンソースの魅力をさらに引き立てたりすることができる、私たちならではの視点を加えて効果を最大化したいと考え、Developer Realationsチームも含めました。
教育ポリシーの作成
オープンソースポリシーの教育を実施し、評価結果を保管することもOpenChainのルールの一つです。教育は、社内開発者向けの教育とOSRBメンバー向けの教育に分けて行いました。
開発者の教育は、グローバルを含むLINEグループの開発者全員を対象に行いました。開発者全員を対象とした初めてのオープンソース必須教育でした。多くの人が時間を費やして履修するだけに、効果的に内容を伝えるにはどのように構成するか、どの部分を強調し減らすかを悩んで、教育資料には開発者が必ず知っておくべき内容だけを選んで入れました。 この教育の最大の目的は、内容全体を熟知することではなく、オープンソースについて不明な点がある時に、どの文書を見てどのプロセスに従うべきか、どこに問い合わせればよいかを覚えるようにすることだったので、この点に集中して教育を構成しました。
評価もとても心配でした。試験が好きな人はいないからです。開発者からよく聞かれる質問をクイズ形式にしてその内容をもう一度読んでもらうように誘導し、ポリシーの中で特に強調したい内容はクイズの難易度を少し高く設定して評価しました。
OpenChain標準適用の意義
OpenChain標準を適用することにどんな意義があるのか、会社の立場と開発者の立場でそれぞれ見てみましょう。
企業の立場でのOpenChain標準適用の意義
国際レベルでのオープンソースガバナンスシステムの優秀性を検証
企業の視点で見ると、オープンソースのコンプライアンス領域は一つの不具合や見落としが組織の大きなイシューにつながるリスクがありますが、通常はオープンソースの利用が確実に管理されており、信頼できるコンプライアンスが確立されているを確認することは難しいというのが現状です。OpenChain認証を取得していれば、オープンソースライセンスをしっかりと遵守し、法/技術/組織の面で絶えず尽力し、オープンソースコンプライアンスシステムの構築が徹底されていることを社内外に証明できます。 これにより、第三者との協力およびパートナーシップを構築する際に、会社のオープンソース管理能力とコンプライアンスの面を強調し、信頼を得ることができます。
内部プロセスの一貫性の維持
OpenChain規格では、コンプライアンスによる成果物だけでなく、成果物を得るプロセスでも一貫した基準の必要性を強調しています。特定項目を判断する基準が明確であり、判断過程もすべてプロセスとして定義されていなければならないという意味です。たとえば、次のとおりです。
- 既存ガイド:オープンソースライセンス告知文を作成し、開発チームに周知します。
- OpenChain規格を適用して改善したガイド:オープンソースライセンス告知文を決まったフォーマットで作成し、作成過程は次のプロセスに従います。
OpenChain規格では、このように実務者が同じ状況においてそれぞれ別の選択をしないように実務過程の一つ一つを文書に定義しておきます。 これにより、会社はオープンソース管理やライセンス追跡、文書化、教育などの内部プロセスを誰が担当しても一貫した運営ができ、ヒューマンエラーの発生率を著しく下げることができます。
迅速かつ効率的なイシュー対応
OpenChain規格に従ってOSRBという課題対応の組織を構成し、各メンバーがどんな責任を担い、どんなプロセスに従って協力するかを定義しておくと、リスク発生時に迅速かつ効率的に対応できるシステムが整います。
開発者の立場でのOpenChain標準適用の意義
開発により集中できる環境づくり
OpenChain規格に従って、開発者はオープンソース教育を受け、オープンソースに関する基本知識を身につけることができます。教育を受けた開発者は、基本的な課題については会社がどんな判断をするか推測したり、自ら文書を探して確認したりすることができ、それ以外にもOpen Source Program Officeを通じてオープンソースコンプライアンス関連のサポートを受けることができます。したがって、OpenChain規格に準拠する会社の方針を信じて、オープンソースに関して何の不安を抱くこともなく、開発により集中できます。
オープンソースに関する基本知識と力量の習得
今回、OpenChainプロジェクトの認証プロセスを進めながら、開発者が直接的・間接的に参加して会社のオープンソースポリシーとプロセスを学び、これにより開発のプロセスからオープンソースライセンスを認識して開発に取り組むケースが増えたことが分かりました。開発を完了した後にオープンソースのコンプライアンス違反ケースが見つかると、これを修正するコストがかなりかかります。オープンソースに対する基本知識を身につけて開発に取り組むと、事前にオープンソースのコンプライアンスリスクを回避でき、より効率的に開発を進めることができます。
おわりに
要約すると、LINEはOpenChain認証取得のためのプロジェクトを通じてオープンソースガバナンスシステムをさらに強固にし、これにより内外の信頼を得ることができるようになりました。また、オープンソースイシューの発生率を著しく下げて、イシューが発生してもより効率的かつ徹底的に対応できるようになりました。
Open Source Program Officeでは、LINEが今回のOpenChainプロジェクトを通じて、オープンソースコンプライアンスを徹底して遂行するとともに、開発者のシステムにもうまく溶け込む企業として認識されたいと考えました。OpenChain規格は、これまで一部の非定型的だったLINEのオープンソースガバナンスの指針となり、内部のシステムをさらに徹底して補完するきっかけとなりました。
最初にOpenChain認証を受けるために規格を検討したときは、思っていたより要件が多くて果てしなく感じることもありました。少人数で既存の業務と並行して進めていたため、ほぼ2年という時間がかかりましたが、認証を受ける過程でどこに出しても誇らしいほどオープンソースに関するポリシーとプロセスがかなり改善されたことがとても嬉しく、大きなやりがいを感じています。