なぜ会社の単位で OSS を管理するのか
OSS の使い方を案件ごと・チームごとに決めると、同じ部品でも答えがばらばらになります。受託でお客さまへ渡す・SaaS で動かす・画面やアプリで配る、と使い方が変わると、守ることも変わります。決まり・台帳・窓口・確かめの記録を、会社で 1 つにします。
ライセンスの種類と義務
義務は、ライセンスの名前ではなく、何をしたか（配る・ネット越しに使わせる・直す）で生まれます。新人向けの基本（MIT・Apache・GPL・AGPL の違い）は、Stack Map「OSS ライセンス」にあります。ここでは、会社として、どの行いで義務が生まれ、何を作って渡すかを、ライセンスの本文で確かめます。公開されたモデルの重みのライセンスも、同じ台帳で扱います。ライセンスの読み方の実際の判断は、専門家や公式の情報で確かめてください。
どの行いで、義務が生まれるか
ライセンスの型と、作って渡す物
公開されたモデル・OSS のモデルのライセンス
組み合わせ
1 つのプログラムの中で、ライセンスの違う部品がぶつかることがあります。一緒に配れるかを、ライセンスの両立（互換性）と呼びます。どうつなぐか（別のプログラムか、ライブラリか、ソースに写すか）と、どう使うか（社内・SaaS・受託で渡す・配る）で、守ることが変わります。下の道具で選ぶと、当たりそうな義務と、確かめる先が出ます。判定は目安で、言い切りません。実際の判断は、専門家や公式の情報で確かめてください。
道具: この使い方で、何を守る？（組み合わせの判定） 考え方のヒント
5 つの問い（押すと、答えを変えられます）
10 の例の、いまの判定（行を押すと、上に出ます）
管理の体制
決まりは、回す人と場が無いと守られません。OSS の管理を回す窓口を OSPO（Open Source Program Office）と呼びます。国際規格の ISO/IEC 5230（OpenChain）は、ライセンスを守る仕組みの要件を「何を」と「なぜ」に絞って決めています。要件と、みなと開発の体制の見本を並べます。
みなと開発の OSPO（見本・作り物） 考え方のヒント
貢献の決まり
OSS に直しを送る・自社のコードを公開するのは、会社の権利（著作権・特許）を外に出すことでもあります。だれの名で・どの許可で・何を約束して出すかを、会社で決めます。発信の名義と時間の決まりは、技術の文化と社外への発信「登壇・ブログ・OSS への貢献」にあります。CLA の署名や特許の許諾の判断は、専門家や公式の情報で確かめてください。
貢献の段階（みなと開発の見本・作り物） 考え方のヒント
決めたことを残す形
ライセンスの決まりの表・確かめの記録・貢献の申請の記録・OSPO の体制表です。確かめの記録には、「組み合わせ」の道具でいま選んでいる例が入ります。そのままコピーして、表計算や文書に貼って使えます。
ライセンスの決まり（使ってよい・確かめる・使わない） 考え方のヒント
ライセンスの確かめの記録（Markdown） 考え方のヒント
OSS への貢献の申請と記録（Markdown） 考え方のヒント
OSPO の体制表 考え方のヒント
落とし穴
OSS の管理で、よくはまる所です。
AI 時代の OSS の管理（AI に任せてはいけない判断）
AI がコードを書き、AI のモデルを部品として使う時代には、部品の入口が増えます。AI が書いたコードに OSS のコードが混ざっていないか、モデルの出力をどう扱うか、だれが最後に決めるかを決めます。全社の AI の決まりは、全社の AI の体制とルール「全社のルール」にあります。
チェックリスト
自分の会社の OSS の決まりと体制を見直したら、チェックを付けてください（この端末にだけ残ります）。考え方のヒント