2019.2.21 サイオス株式会社 ラウンジにて開催された、OSSライセンスMeetup vol.2のディスカッションパートの資料です。 ディスカッションの種というものなので、資料そのものにはあまり情報はないですが、一応公開しておきます。 実はスライドの順番が（議論の順番と）入れ違っており、本スライドの8枚目が議論としては最後にしたものになります。お詫びして訂正します。（slideshareはスライドの上げ直しできなくなっちゃったんですよねえ）

1. OSS ライセンス Meetup vol.2
ディスカッションパート
2019.2.21
#sios_tech

2. 2
Who am I
●
小笠原 徳彦（ Naruhiko Ogasawara)
●
（元）某事務機器ベンダーにて開発・技術企画
●
OSS 向け印刷技術標準化団体の日本支部
OpenPrinting Japan メンバー
– 宮田さんとはそのときからの知り合いです
●
今はソフトウェアの自動テスト技術者
●
メインで活動している OSS は LibreOffice

3. 3
Disclaimer
●
前回（ vol.1 ）のようなカンペキな仕切りは無理です
●
過去・現在問わず所属組織とは（略）
●
過去の非開示情報については（略）

4. 4
質問その 1. みなさん自身について
●
ソフトウェアの開発者
●
ハードウェアの開発者
●
インフラエンジニア
●
プロダクト・プロジェクトマネージャー
●
法務・知財
●
学生
●
その他

5. 5
質問その 2. 所属組織の業種について
●
Web サービス
●
自社パッケージ
●
ハードウェア（組み込み）
●
システムインテグレーター
●
その他

6. 6
それを受けまして
●
隣の席の人と自己紹介して
– 自分と OSS の関わり、とか……
●
さきほどの宮田さんのお話を受けて
– 気になったこと
– 質問してみたいな？と思ったこと
– などなど……
●
話し合ってみてください（ 10 分）

7. 7
ではお待ちかねの
●
会場からの質問タイム
●
おれにも一言言わせろというコメントも welcome
●
（あまり生々しくない話でお願いします ;)

8. 8
事前にいただいたご質問からいくつか抜粋
トラブルがあるたび、管理を強化するという話になりが
ち。適切な管理と OSS への貢献を両立させるにはどうし
たら良いか？
●
ここはぜひ皆さんに聞いてみたい！

9. 9
事前にいただいたご質問からいくつか抜粋
JavaScript の minify や concat 時における
GPLv3 の扱い。

10. 10
事前にいただいたご質問からいくつか抜粋
JavaScript の minify や concat 時における
GPLv3 の扱い。
●
参考： GNU オペレーティングシステム
「 JavaScript の罠」
●
https://www.gnu.org/philosophy/javascript-trap.ja.html
Appendix A: 自由な JavaScript プログラムをリリースする慣習
対応するソースコードのリファレンスとして、わたしたちは、下記を推
奨します。（略）

11. 11
事前にいただいたご質問からいくつか抜粋
JavaScript の minify や concat 時における
GPLv3 の扱い。
●
参考： GNU オペレーティングシステム
「 JavaScript の罠」
●
https://www.gnu.org/philosophy/javascript-trap.ja.html
Appendix A: 自由な JavaScript プログラムをリリースする慣習
対応するソースコードのリファレンスとして、わたしたちは、下記を推
奨します。（略）
補足：↑の翻訳の原文のサイトは、今は更新されて二つに分割されています。
https://www.gnu.org/philosophy/javascript-trap.html.en
https://www.gnu.org/software/librejs/free-your-javascript.html
後者のほうが以前の Appendix A の内容を含んで拡充されたもので、
こちらの翻訳をするとよいのでは……というご意見がありました by @taku_eof さん
補足：↑の翻訳の原文のサイトは、今は更新されて二つに分割されています。
https://www.gnu.org/philosophy/javascript-trap.html.en
https://www.gnu.org/software/librejs/free-your-javascript.html
後者のほうが以前の Appendix A の内容を含んで拡充されたもので、
こちらの翻訳をするとよいのでは……というご意見がありました by @taku_eof さん

12. 12
事前にいただいたご質問からいくつか抜粋
FSF 等の慎重なプロジェクトではパッチ提供時に権利の放棄を求
められるのに対し、プルリクエストベースで変更を取り込む場面で
はそのようなやりとりがなされにくく、権利の所在が分散したまま
になりがちで、将来的にライセンスを変更しにくくなるなどのリス
クがあるように思われる。企業が公開するプロダクトに外部からの
貢献を受け入れる際に、カジュアルに貢献を受け入れつつそういっ
た問題が起こらないようにする良い方法は無いものか。

13. 13
事前にいただいたご質問からいくつか抜粋
FSF 等の慎重なプロジェクトではパッチ提供時に権利の放棄を求
められるのに対し、プルリクエストベースで変更を取り込む場面で
はそのようなやりとりがなされにくく、権利の所在が分散したまま
になりがちで、将来的にライセンスを変更しにくくなるなどのリス
クがあるように思われる。企業が公開するプロダクトに外部からの
貢献を受け入れる際に、カジュアルに貢献を受け入れつつそういっ
た問題が起こらないようにする良い方法は無いものか。
●
古典的には Contributors License Agreement
だが、カジュアルさとは相反する……かも？

14. 14
事前にいただいたご質問からいくつか抜粋
FSF 等の慎重なプロジェクトではパッチ提供時に権利の放棄を求
められるのに対し、プルリクエストベースで変更を取り込む場面で
はそのようなやりとりがなされにくく、権利の所在が分散したまま
になりがちで、将来的にライセンスを変更しにくくなるなどのリス
クがあるように思われる。企業が公開するプロダクトに外部からの
貢献を受け入れる際に、カジュアルに貢献を受け入れつつそういっ
た問題が起こらないようにする良い方法は無いものか。
●
古典的には Contributors License Agreement
だが、カジュアルさとは相反する……かも？
補足：権利の所在……ということに引っ張られて、 CLA 的な「権利を譲渡する」話を
切り出してしまいましたが、ちょっとミスリードでした。すみません。
ライセンスの議論としては、コントリビューションについてのライセンス同意を
README などで記載しておく、ライセンスのバージョンアップについては or later な
どとして予め考慮しておく、といった意見が出ました。
補足：権利の所在……ということに引っ張られて、 CLA 的な「権利を譲渡する」話を
切り出してしまいましたが、ちょっとミスリードでした。すみません。
ライセンスの議論としては、コントリビューションについてのライセンス同意を
README などで記載しておく、ライセンスのバージョンアップについては or later な
どとして予め考慮しておく、といった意見が出ました。

15. 15
活発な意見交換
ありがとう
ございました！