オープンソース規制には、成功のための珍しい要件があります。オープンソースの弁護士が雇用主が前進可能な道を見つけるのをどのように支援できるかを学びましょう。
この 2 部構成のシリーズの第 1 部で共有したように、私は Red Hat のオープンソース弁護士です。私の仕事の重要な部分は、Red Hat がエンタープライズグレードの製品を構築するために完全なオープンソース開発モデルをどのように採用しているかについて、社内弁護士を含む他の企業に情報を提供し、オープンソースのライセンスに関する一般的な質問に答えることです。 Red Hat の成功について聞いた後、これらの弁護士と私との会話は、彼らの組織がよりオープンソースを認識し、より有能な組織にどのように進化できるかということになり、オープンソースの提供をより熟練するためにどのように業務を改善できるかを私に尋ねることがよくあります。組織の従業員に対する法的アドバイス。これら 2 つの記事では、これらのトピックに関して私が社内の顧問に通常伝えている内容を共有します。
常に実現可能な道を見つける
私の雇用主である Red Hat のオープンソース ソフトウェアの使用がユニークなのは、当社の開発モデルが何千人もの貢献者が参加するオープンソース コミュニティから始まり、試行、テストされ、信頼できる最終製品が完成するという点です。具体的には、独自の開発モデルを通じて、コミュニティが作成したオープンソース ソフトウェアから始めて、各プロジェクトに取り組み、セキュリティの強化、バグの修正、脆弱性のパッチ、新機能の追加を行っています。その後、これらの改善がオープンソース コミュニティ全体に利益をもたらすように、各プロジェクトに貢献します。このアプローチの利点は重要であり、次のとおりです。
- 内部チームと組織外のチームとのコラボレーションを通じて外部イノベーションを活用します。
- 既存または潜在的なコミュニティがあなたと同じ問題に取り組んでおり、協力できる場合、オープンソース ソリューションを自分で開発および保守するコストと非効率性を回避できます。
- パートナーや上流プロジェクト コミュニティとの生産的なコラボレーションを通じて、メイン プロジェクトの下流ブランチのコストのかかるメンテナンスを回避できます。
- 一部の企業は、特定のユースケースを解決する手っ取り早い方法であるため、またはコミュニティでの共同作業に消極的であるという理由で、上流コードの非公開ブランチを作成することに魅力を感じています。ただし、そのようなブランチの長期的なメンテナンスの負担は、開発コストの増加、相互運用性の喪失、その他の理由により法外に大きくなる可能性があります。対照的に、元の上流コミュニティに開発を集中させると、開発コストがすべての参加者に分散されます。
いくつかの例外 (Red Hat など) を除き、オープン ソース ソフトウェアを使用しているほとんどの組織は、独自のソフトウェア ライセンス モデル (または SaaS と同等) を採用しており、ビジネスの一環として独自のソフトウェアにライセンスを供与している可能性があります。これらの組織は、自社が何らかの競争上の優位性をもたらすソフトウェア コンポーネントを持っていると信じており、これらのコンポーネントがオープン ソース条件に基づいて他者に利用可能になることを望んでいません。これは理解できます。ただし、このような問題について相談を受けたオープンソース弁護士には、特に未差別で一般的なすべてのソフトウェアについて、オープンソース開発モデルを採用するようクライアントに促すことをお勧めします。
たとえば、会社が携帯電話用のアプリケーションを開発しており、PNG 画像ファイルを読み書きするためのソフトウェア モジュールが必要な場合は、GitHub で人気のあるオープン ソース PNG ソフトウェア モジュールの 1 つを使用する方がはるかに安価です。ビジネスにとって PNG 画像のエンコードとデコードは区別できないかもしれませんが、貴重なエンジニアリング時間を費やして独自のバージョンを作成する必要はありません。さらに、この機能用に独自のモジュールを作成すると、一般に入手可能なオープン ソース モジュールを使用する他のソフトウェアとの互換性の問題が発生する可能性があります。どうしてこれなの？モジュールおよびオープン ソース モジュールは、公開された PNG 仕様をエンコードおよびデコードするように作成されている可能性がありますが、場合によっては仕様が異なって解釈され、実装エラーが発生する可能性があります。全員が同じモジュールを使用してこの機能を実行することで、大部分のユーザーの互換性が確保され、開発およびメンテナンスのコストが削減されます。
また、一部のソフトウェアをプロプライエタリのままにし、オープンソース条件の影響を受けないようにする必要がある場合があることを認識することも重要です。システムのソフトウェア アーキテクチャと使用されているオープン ソース ライセンスによっては、(この記事の範囲を超える) 特定の手段が講じられない限り、独自仕様のままにすることを目的としたソフトウェア コードがオープン ソース ライセンスの条件に従う可能性があります。この場合、ライセンスの選択とアーキテクチャに関してクライアントにコンサルティング サービスを提供すると便利です。
柔軟なソリューションを見つける
以前は主にプロプライエタリ ソフトウェアのライセンスを取得していた組織は、オープンソース ソフトウェアの使用を徐々に増やしていますが、レビューと承認の要件は (私の経験では指数関数的にさえ) 増加する可能性があります。このような組織は、リソースの制約により苦戦する可能性があります。導入できる柔軟なソリューションをいくつか紹介します。
他の人に承認して委任する
弁護士は門番になることはできませんし、そうすべきではありません。これは非効率的であり、間違いなく開発とリリース時間のボトルネックにつながり、フラストレーションと収益の損失を引き起こします。代わりに、承認権限は製品またはプロジェクトの管理およびエンジニアリングの有能な個人に与えられるべきです。これにより、組織は効果的に柔軟性を保つことができます。これを成功させるには、顧客を教育することが重要です (次のセクションを参照)。
私がとっているアプローチの 1 つは、エンジニアリング組織全体にオープンソース トレーニングを提供して、基本的なライセンス モデルとアーキテクチャの選択ができるようにすると同時に、ソフトウェア開発者にはより複雑なガイダンスと意思決定を提供できるようにするためのより専門的なトレーニングを提供することです。また、どのような種類の問題や決定をオープンソース弁護士としてエスカレーションする必要があるかなど、各レベルでの権限の明確な制限も検討してください。組織の特定の承認レベルは、チームのオープンソースに関する経験と、特定のオープンソースの問題に対する敏感度によって異なります。
顧客を教育する
トレーニングは、組織をよりオープンソース志向の組織に移行するための最も効果的なツールの 1 つであることがわかりました。ソフトウェア エンジニアとプロダクト マネージャーのトレーニングは非常に重要です。詳しく説明しましょう。
ソフトウェア エンジニアは最先端の立場にあり、一般にオープンソースの問題やソフトウェア ライセンスについての知識が豊富ですが、組織固有の要件に基づいてトレーニングすることが依然として重要です。たとえば、会社では寛容なオープン ソース ライセンスの使用のみを許可し、著作権表示とソース コードの可用性に関して特定の要件を設けている場合があります。開発中に後から修正する必要がある問題 (コストと時間がかかる行為) を回避するには、特に開発プロセスの開始時に、不適切な動作の可能性を最小限に抑えるようにエンジニアをトレーニングすることが最善です (次のセクションを参照)。
プロダクトマネージャーもトレーニングを受ける必要があります。多くの企業では、プロダクト マネージャーはマーケティングの古典的な 4 つの側面 (製品、価格、ポジショニング、プロモーション) を担当し、製品のゆりかごから墓場までのライフサイクル全体に責任を負います。オープンソース ソフトウェアの使用は、プロダクト マネージャーの仕事のあらゆる側面に影響を与える可能性があります。上で述べたのと同じ理由で、オープンソース ソフトウェアを使用するための要件を理解することは有益です。さらに、より重要なことは、プロダクト マネージャーが組織内で大きな影響力を持っているということは、プロダクト マネージャーがプロセスやポリシーに必要な変更を加えることができることが多いことを意味します。プロダクト マネージャーは、オープン化に向けたプロセス変更の強力な支持者の 1 人になることができます。
早期発見
開発プロセスの終わり近くでオープンソースのライセンス問題を解決するのは難しく、コストがかかります。ソフトウェアのリリース日が近づくと、アーキテクチャとオープンソース ソフトウェア モジュールが選択され、変更するのが難しくなります。プロプライエタリなソフトウェア モジュールに埋め込まれた「コピーレフト」ソフトウェアなどの問題が検出された場合 (そのプロプライエタリなモジュールがオープンソース条件の対象となることが意図されていない場合)、開発のこの段階でアーキテクチャまたはモジュールを変更するのは困難でコストがかかる可能性があります。高い。代わりに、アーキテクチャ分析とオープンソース モジュールの選択のプロセスは、より低コストでより効果的な修正を行えるように、開発プロセスの早い段階で行う必要があります。
オープンソース規制の「報酬」
オープンソース規制の実践は、組織に「オープン」な方向に影響を与える能力に大きなメリットがあるため、やりがいのあるキャリアです。成功は、組織が成長し成熟するにつれて、実現可能で柔軟なソリューションを見つけられるかどうかにかかっています。
著者について: Jeffrey R. Kaufman は、オープンソース ソフトウェア ソリューションの世界的プロバイダーである Red Hat のオープンソース法務チームの上級ビジネス法務顧問であり、ノースカロライナ大学の非常勤法学教授も務めています。 Red Hat に入社する前は、Jeffrey は Qualcomm で特許およびオープンソースの顧問を務めていました。
翻訳者プロフィール: Xue Liang 氏、Jihuizhijia Intellectual Property Consulting Company のインターネット ビジネス部門ディレクター。特許分析、特許レイアウト、競合他社追跡、FTO 分析、オープンソース ソフトウェアの知的財産リスク分析を得意とし、インターネット企業への提供に尽力しています。知的財産コンサルティング サービスを提供するハイテク企業。
