Download to read offline
Uploaded byNaruhiko Ogasawara
OSS License Meetup vol.2 ディスカッションパート資料
2019.2.21 サイオス株式会社 ラウンジにて開催された、OSSライセンスMeetup vol.2のディスカッションパートの資料です。 ディスカッションの種というものなので、資料そのものにはあまり情報はないですが、一応公開しておきます。 実はスライドの順番が（議論の順番と）入れ違っており、本スライドの8枚目が議論としては最後にしたものになります。お詫びして訂正します。（slideshareはスライドの上げ直しできなくなっちゃったんですよねえ）
Law◦
OSS License Meetup vol.2 ディスカッションパート資料
- 1. OSS ライセンス Meetupvol.2 ディスカッションパート 2019.2.21 #sios_tech
- 2. 2 Who am I ● 小笠原徳彦（ Naruhiko Ogasawara) ● （元）某事務機器ベンダーにて開発・技術企画 ● OSS 向け印刷技術標準化団体の日本支部 OpenPrinting Japan メンバー – 宮田さんとはそのときからの知り合いです ● 今はソフトウェアの自動テスト技術者 ● メインで活動している OSS は LibreOffice
- 3.
- 4.
- 5. 5 質問その 2. 所属組織の業種について ● Webサービス ● 自社パッケージ ● ハードウェア（組み込み） ● システムインテグレーター ● その他
- 6. 6 それを受けまして ● 隣の席の人と自己紹介して – 自分と OSSの関わり、とか…… ● さきほどの宮田さんのお話を受けて – 気になったこと – 質問してみたいな？と思ったこと – などなど…… ● 話し合ってみてください（ 10 分）
- 7.
- 8.
- 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.
- 13.
- 14. 14 事前にいただいたご質問からいくつか抜粋 FSF 等の慎重なプロジェクトではパッチ提供時に権利の放棄を求 められるのに対し、プルリクエストベースで変更を取り込む場面で はそのようなやりとりがなされにくく、権利の所在が分散したまま になりがちで、将来的にライセンスを変更しにくくなるなどのリス クがあるように思われる。企業が公開するプロダクトに外部からの 貢献を受け入れる際に、カジュアルに貢献を受け入れつつそういっ た問題が起こらないようにする良い方法は無いものか。 ● 古典的には ContributorsLicense Agreement だが、カジュアルさとは相反する……かも？ 補足：権利の所在……ということに引っ張られて、 CLA 的な「権利を譲渡する」話を 切り出してしまいましたが、ちょっとミスリードでした。すみません。 ライセンスの議論としては、コントリビューションについてのライセンス同意を README などで記載しておく、ライセンスのバージョンアップについては or later な どとして予め考慮しておく、といった意見が出ました。 補足：権利の所在……ということに引っ張られて、 CLA 的な「権利を譲渡する」話を 切り出してしまいましたが、ちょっとミスリードでした。すみません。 ライセンスの議論としては、コントリビューションについてのライセンス同意を README などで記載しておく、ライセンスのバージョンアップについては or later な どとして予め考慮しておく、といった意見が出ました。
- 15.