ソフトウェアライセンス2019/05/29法務統制本部 & OSS推進チーム
View Slide
理想▌他者のソフトウェアを使うときのリスクを考慮できる▌OSS 関連活動を適切に行える2/32
この講義のゴール▌ソフトウェアライセンスの法的背景がわかる▌OSS ライセンスがどんなものかわかる▌業務での OSS との関わり方がわかる3/32
目次▌ソフトウェアとライセンス▌OSS ライセンス▌サイボウズの OSS ポリシー▌他者ソフトウェア (OSS) を使うとき▌OSS を公開するとき4/32
ソフトウェアとライセンス5/32
ソフトウェアと著作権▌ソフトウェア = 著作物↓著作権法が適用される▌他人の著作物の無断利用は、著作権侵害になる6/32
「利用」と「使用」の違い▌著作権違反になるのは、著作物を「利用」したとき▌プログラムの「利用」に該当する行為⚫ ユーザー環境にインストールさせるためにプログラムを提供する⚫ パッケージ製品に組み込んで提供する⚫ ダウンロードサイトに置く⚫ プログラムを改変する▌プログラムの「使用」に該当する行為⚫ ローカルでプログラムを実行して自分で使う⚫ サーバー上でプログラムを実行し、ユーザーにその機能を使わせる（クラウドサービス）7/32
ライセンス▌ライセンスとは、著作権法に基づく利用許諾条件⚫ 「私が権利を持っている著作物を利用させてあげる代わりに、これを守ってね」というもの▌条件を守らないと、ライセンス違反 = 著作権侵害 となる可能性がある8/32
ライセンス違反で起こり得ること▌著作権の行使⚫ 派生（対象のソフトウェアを組み込んだ）製品の販売停止（差止め）⚫ ソフトウェアの利用料の請求（損害賠償請求）▌許諾条件の強制⚫ 派生製品のソースコードの開示▌レピュテーションリスク⚫ ライセンスビジネスをしている企業としてのブランド価値の低下⚫ オープンソースコミュニティで炎上9/32
OSS ライセンス10/32
OSS ライセンスとは▌OSS とは⚫ ソースコードが無償で公開され、誰でもその改変と再配布が自由に行えるソフトウェアのこと⚫ Linux, MySQL, Java, Nginx, ...▌OSS ライセンスとは⚫ OSS を利用する際のライセンス⚫ 色々な種類があり、それぞれ条件が違う11/32
OSS ライセンスに共通する主な条件▌同一条件での再配布⚫ 再配布の際は、同じライセンスにする▌無保証⚫ 利用については、全て自己責任（脆弱性や不具合など）▌特許の無償ライセンス⚫ ソフトウェアに関連する特許がある場合でも、特許ライセンスを求められない12/32
OSS ライセンスの類型OSS ライセンスの類型改変部分のソースコード開示他のソフトウェアのソースコード開示コピーレフト型ライセンス（代表： GPL）要 要準コピーレフト型ライセンス（代表： MPL）要 不要⾮コピーレフト型ライセンス（代表： BSD License）不要 不要13/32
コピーレフト型▌特徴⚫ 派生製品のソースコードも開示させる→ 自由に使えるソフトウェアを広げていく、という考え⚫ 製品に組み込んだ場合、製品全てのソースコード開示が必要となる▌主な OSS ライセンス⚫ GPL, AGPL, EUPL▌コピーレフト型の OSS⚫ Linux, MySQL, WordPress14/32
準コピーレフト型▌特徴⚫ 改変した場合、その改変部分を開示させる▌主な OSS ライセンス⚫ MPL, LGPL▌準コピーレフト型の OSS⚫ Mozilla (Firefox, Thunderbird)15/32
非コピーレフト型▌特徴⚫ ほぼ何も気にしない▌主な OSS ライセンス⚫ BSD, Apache, MIT▌非コピーレフト型の OSS⚫ Nginx, Apache, React16/32
サイボウズの OSS ポリシー17/32
ドキュメント▌ポリシー⚫ 権利帰属についてや、OSS 関連活動をどのように行うべきかが書かれた内規▌ガイドライン⚫ 業務に沿った手引き18/32
策定の背景▌サイボウズでは製品・サービスにおいて数多くの OSS が利用されており、従業員も業務や個人活動で OSS 関連活動の機会が増えている▌そこで、以下を目的に策定された⚫ OSS 関連活動を過大な負担なく行えるよう支援するため⚫ オープンソースコミュニティにおける良き一員であるため19/32
著作権の帰属▌サイボウズの著作物① 当社の極秘情報を含むもの② 上長の明示的な指示または承認のもと作成されたもの↓それ以外は個人の著作物となる▌著作権の譲渡⚫ 条件に従って承認されれば、著作権が譲渡される20/32
努力義務とライセンス違反への対応▌他者 OSS を利用するなかで不具合を発見した場合、速やかに当該不具合を報告するよう努める▌ライセンスに違反する事実を発見した場合、速やかに OSS 管理組織に報告しなければならない21/32
何かあったらOSS 管理組織（現 OSS 推進チーム）まで22/32
他者ソフトウェア(OSS) を使うとき23/32
ライセンスを確認する24/32
ライセンスの確認（優先順）1. ソースコード中のライセンス原文の記載⚫ プログラムファイルのヘッダに記載されたライセンス名とリンクも同様2. アーカイブに配置されたライセンスファイル3. アーカイブ内の README ファイルの記載4. DLサイト上の記載（根拠としては弱い）⚫ DLサイト上の記載と、アーカイブ内のライセンスファイルが異なる場合もある。。。25/32
気を付けるポイント▌ライセンスが明確ではないソフトウェアを使わない▌パッケージ製品に、コピーレフト型のソフトウェアを使わない▌クラウド製品に、AGPL を使わない⚫ AGPL は、クラウド製品に OSS を「使用」した場合に、その製品のソースコード開示を求める条件がある⚫ クラウド製品に OSS を組み込んでサービスとして提供する行為は「利用」ではなく、AGPL 以外のライセンスではソースコード開示は求められない26/32
利用までの流れ1. 使いたい OSS のライセンスが「OSS license リスト」にあるか確認⚫ リストにあれば、利用条件に従って利用2. リストになければ、「オープンソースライセンス確認アプリ」で過去に利用可能判断がされているか確認⚫ リストにあれば、利用条件に従って利用3. 過去の判断が無ければ、「OSS推進チーム依頼箱」でライセンスの確認を依頼27/32
OSS を公開するとき28/32
気を付けるポイント▌著作権が自分に帰属している場合⚫ OSS を公開する際に「Copyright YEAR Cybozu」のようにサイボウズの著作物として表示することはできない▌著作物が会社に帰属している場合⚫ 公開のルールに従う29/32
自社 OSS を社外に公開する流れ1. GitHub にリポジトリを作成する2. OSS ライセンスを選択し、必要なファイルを配置する3. 選択した OSS ライセンスに従って著作権の年号や著作権者を表記する30/32
まとめ31/32
▌ソフトウェアを利用する際は、ライセンスに気を付けましょう▌OSS ポリシーを守りましょう▌困ったら、法務統制本部か OSS 管理組織に相談しましょう32/32
cybozuinsideout
ritou
nktamago
sadonosake
nishiharatsubasa
keio_smilab
yosuke_furukawa
picardparis
bumptakayuki
takumakume
sheep_san_white
ramimac
minorun365
destraynor
jeffersonlam
swwweet
deanohume
sachag
lara
sugarenia
myddelton
addyosmani
maggiecrowley
sonatard
mraible