ロボットシステム学2016第9回

Thu Nov 10 15:45:27 JST 2016 (modified: Fri Nov 29 17:22:47 JST 2019)
views: 1274, keywords:

ロボットシステム学

第9回

上田 隆一

2016年11月30日@千葉工業大学

今日の内容

• フリーソフト、オープンソース、著作権、ライセンス
  • 背景
  • 適当に人のものを使っていませんか？
  • 怖がって使わずに効率の悪い開発をしていませんか？
  • 我々はどう付き合うべきか？
  • コピペは善なのか悪なのか？

大学生と著作

• ブログやGitHub等で誰でも自身の著作物を公開する機会
  • 作文、コード、ロボットのデモムービー等
  • コミュニティーや同人活動への参加
    • こういうところでは、むしろ作品を公開しないと存在しない人扱いを受けるという勢い（いいか悪いかは別）

インターネット上での活動

• インターネットはアバウトな部分と容赦ない部分が同居
  • 著作権やライセンスへの理解がないと生きていけない
  • あからさまに違反して反省もしないと大炎上
  • 悪徳ハッカソンに著作権を取られる等、被害にも遭う
  • 自身を売り出すためにはさらに深く理解が必要

インターネット上の著作物の流用

• ロボットを扱うときに使うオープンソース
  • ROSやOpenCV等、それらの上で動くもの
• オープンソースを使った自身の著作物やコードは公開していいの？売っていいの？
• そもそも何でオープンソースは公開されている？
  • Unixの話の時にした通り

コードの公開

• コードを公開することによる恩恵（例:  Unix）
  • 普及する
  • バグを第三者が見つけてくれる
  • 改良法を第三者が考えてくれる
• コードを公開する場合の困った点
  • 商売難しい
  • 誰のもの？
  • プログラマーの世界の外で理解が得られない
• コード公開の判断
  • 工・法・商・歴史様々な視点が入り乱れる

リチャード・ストールマン（RMS）

• コードは公開されるべきという立場の急先鋒
• Emacs, GCC等の作者
  • 1971年〜MITのハッカー
  • 逸話
    • パスワードに反対して破る→メンバーにパスワードを空白にするように促す
    • コピーライトへの批判
    • アンチ携帯電話
    • 講演で座禅を組んで「フリーダム」と一言だけ
    • ASCIIに招かれた時に廊下に座ってプログラミング
    • 他、膨大な逸話

ハッカー

• （技術的な定義は別として、文化的には）ヒッピー的な考え方を継承した腕のあるプログラマ
  • ヒッピー（1960年代〜）
    • love and peaceな人たち
      • ・・・と書くと平和そうだが、反戦、反体制、フリーダム、フリーセックス、マリファナ、LSD、ビートルズ、東洋思想、嫌儲厨な人たち （注意: いろいろ非合法）
• 今も「ハッカー気質」の人は多い
  • 「技術を独占するよりも広く共有して、皆で大いに楽しみたいとする奔放さ」
• ライセンス: ヒッピー的な考えとビジネス的な考えの妥協点

コピーレフト

• 著作物は利用・再配布・改変できなければならない （つまりフリーダムであるべき）
  • Copyleft: all rights reversed
• ただし、著作権は放棄しない
  • 放棄すると他者がそれを拾って著作権を主張するようになる
  • ストールマン自身が被害に遭った経験から
• 左図: コピーレフトのマーク （パブリックドメイン）

GPL（GNU General Public license）

• コピーレフトの考え方を ライセンス化したもの
• ストールマンの立ち上げたFSF （Free Software Foundation）が策定
•  基本的なルール
  • GPLで頒布されたプログラム （コードやバイナリ）について、ユーザは実行、再配布、改変、調査できる権利を保持
  • ただし、再頒布の際は再度GPLで頒布する義務
  • バイナリのユーザが要求した場合にコードの公開義務

GPLの効果

• 人のコードを持ってきた人（企業・団体）が改変部分を隠してコピーを売ることを抑制できる。
•  ソフトウェアの特性を損なわない
  • 1人が作ればみんな使える。そこから改良できる。
• 具体的な例
  • Linuxのデバイスドライバのコードが隠れない
    • カーネルのデバッグ時に有益
  • LinuxがGPL→動的リンクするドライバも基本はGPL
    • GPL（と何かのデュアルライセンス）でないと警告

 

LinuxとGPL

• Linuxカーネルに付属するコマンド等ソフトウェアの多くは「GNU」由来
• GNU（GNU’s not UNIX）
  • FSFで開発されているOS
  • LinuxはGNUの付属ソフトウェア（coreutils等）を使っている →GPLになる
• FSFは、LinuxはGNU/Linuxと名乗るべきと主張

GPLの効果（？）の例

• 知らないうちにGPLのコードをちょっと使ってバイナリを配布してしまった→コード全部にGPL適用
• GPLのライセンスは連鎖していく
  • 「感染」とも
• 動的・静的にリンクしたライブラリも対象
  • GPLのコードにはGPL互換でないライブラリが使えない
  • GPLでないコードにGPLのライブラリが使えない

LGPL（GNU lesser general public license）

• GPLでないプログラムにリンクして良いライセンス
  • 他のプログラムがGPL化しない
• 当初はGNU library general public licenseだった
  • ライブラリGPL → 劣GPL
• 主な利用例
  • GNU Cライブラリ, OpenOffice.org, …

GPLを適用する方法

• 正確な情報はこの文章から
• ソフトウェアにCOPYING or LICENSEというファイル名でライセンス全文を同梱
  • Gitならリポジトリのトップディレクトリに置く
• 各ソースファイルの頭にも書くのが望ましい
  • というより書く
  • copyrightとGPL/LGPLである旨。COPYINGの場所
• 例: https://github.com/torvalds/linux

考えてみましょう

• ロボカップで使ったコードをGPLで配布するとどうなる？
  • 他のチームに与える影響は？
• 企業でコードが使われるだろうか？
  • 企業と共同研究できる？
• ROSやOpenCVの何かと一緒に配布できる？
• LGPLだったら？

BSD/BSDライセンス

• BSD（Barkeley software distribution）
  • UCBで開発されたUNIXの一種（1977年〜）
  • AT&T由来のコードを含む
  • ライセンスに関する様々な問題を回避しながら開発
  • 最寄りのBSDオジサンに聞いてみよう！
• BSDライセンス
  • その名の通りBSDのためのライセンス
  • もともとGPL以前の話なので別のライセンス体系
  • 企業との悲喜こもごもの中で生まれた

旧BSDライセンス （4条項、廃止）

• 正式なもの
  • 要約
    • コピーライト、ライセンス全文、免責事項の明記
    • コードを公開せずバイナリ配布する時も1を遵守
    • 貢献者・支援した団体等のリストを明記（宣伝条項）
    • 貢献者の名前をソフトウェアの宣伝に勝手に使わない
• 宣伝条項がいろいろと問題
  • リスト巨大化
  • GPLのコードへBSDライセンスのコードを混ぜられない（非互換）
  • （注意: 書いた人については著作権者なので明記）

その後の修正

• 宣伝条項の廃止
  • 修正BSDライセンス（3条項BSDライセンス）
    • OpenCV, ROS等で採用されている
  • GPLと互換に
    • GPLのプロジェクトにROSのコードを混ぜてGPLで配布可能
• 4番目の条項のないものも整備
  • 2条項BSDライセンス
    • FreeBSD等で採用
• 現在の*BSDとLinuxの競争はライセンスの話が深く関係

「BSDライク」な ライセンス

• BSDライセンスに似たライセンスが多く存在
  • 似ているだけなので注意
• 例: MITライセンス
  • 個人的によく使う
  • 全文
    • 著作権とライセンスの表示の義務づけ
    • 免責

MITライセンスの適用

• ソフトウェアにライセンスの全文を同梱
  • LICENSEというファイル名が一般的
• ソースファイルの頭に
  • 著作権表示
  • MITライセンス全文あるいはMITライセンスである旨とLICENSEへのリンク

{フリー,オープンソース} ソフトウェア

• 使い分けは慎重に
  • フリーソフトウェア
    •  FSFの主張する文脈で使う用語
      • GPL周辺
  • オープンソースソフトウェア
    • open source initiativeの主張する文脈で使う用語
      • ビジネス寄り

プロプライエタリソフトウェア/商用ライセンス

• プロプライエタリソフトウェア
  • 知的所有権が保持されて使用者が制限を受けるソフト
  • LinuxやMacの上で動かすのは問題ない
    • ライブラリやドライバレベルだとGPL等で問題になる
• 商用ライセンス
  • 所有権者が決めるので様々
  • 通常は使用者がコードを見られないようになっている

ライセンスの選択について補足

• 何かにフリーなライセンスを選択しても著作権は守られているので著作権者はライセンスを選べる
  • 他のライセンスで守られているコードがなければ
• 同じものをGPLで配布したり商用ライセンスで配布したり
  • MySQLの例
  • デュアルライセンス
• 何かをゼロから作ったら自身にとって一番良い方法を選択

クリエイティブ・コモンズ

• ウィキペディアでよく見かけるとおもいます
• 以下を目的とした国際プロジェクト・非営利団体
  • 著作物を著作権を守りながら人に使ってもらえないか？
  • 「all rights reserved」以外の方法を模索
  • コードではないので公開・非公開という話とは少し違う
• 「クリエイティブ・コモンズ・ライセンス」を策定・管理
  • マーク、コモンズ証、リーガルコード、メタデータ等を提供
  • ライセンスではないが、パブリックドメインについてもCC0の策定

クリエイティブ・ コモンズ・ライセンス

• 略してCCライセンス
•  以下の条件の組み合わせで著作者が発行
  • 表示（BY）
    • 著作権者の表示、ライセンスへのリンク、変更がある場合の説明
  • 継承（SA） or 改変禁止（ND） or 条件なし
    • 継承: 改変時、貢献部分に同じライセンスを適用
    • 改変禁止: 改変したものの頒布禁止
  • 非営利（NC） or 条件なし
    • 非営利: 営利目的利用の禁止

有り得る組み合わせ

• 表示（BY）、継承（SA） or 改変禁止（ND）、 非営利（NC）が互いに矛盾しないのは以下の6通り
  • CC BY
  • CC BY-SA, CC BY-ND,
  • CC BY-NC, CC BY-NC-SA, CC BY-NC-ND

CCライセンスの発行

• 手続き
  •  著作物にマークをつける
  • 「コモンズ証」へのリンク
• クラウドサービスではプルダウンメニューで選べるようになっているものも
  • slideshare, GitHub等
  • GitHubはソフトウェアのライセンスも選べる
  • ソフトウェアの場合は免責事項の関係でソフトウェアのライセンスを

既存の著作物の利用

• あくまで私見ですが・・・
•  ライセンスの仕組みを理解して責任を持って積極的に
  • 勉強以外の目的ではなるべく自分で作らないこと
    • コードを書くなということではないのは注意
  • 目的を最短時間で終わらせること
  • 車輪の再発明をしない。
    • 褒めてもらえると思った人がブチ切れられるという事例が上田研で・・・

自分でコードを書くときの基準

• 車輪の再発明でない場合
  • まだ世の中にない
• 既存のものにライセンスの問題、入手困難
• 既存のコードに手を入れるのが難しい
  • だいたい難しいのでコードを読む力をつける
• 衝動・勉強・同人活動
  • 良いが、付加価値が無く終わることがないよう実験的に

レポート等での流用・コピー

• どういう解釈になるんでしょうか？
  • だた「先生がダメって言うから」という解釈から卒業を
• 人の文章等を流用した場合
  • 何の引用もなくコピペすると著作権の侵害・訴えられたら有罪
  • 著作権の問題をクリアしていても詐欺になる可能性
  • 講義での課題の場合はそもそも学習効果がないと0点
• 人の文章は基本、引用で済ます
  • このスライドのようにリンクを多用
  • 論文なら引用の作法を守る

まとめ

• オープンソースのライセンス、CCライセンスの仕組み
  • 作った人が著作権を保ったまま他の人が作った物を使う仕組み
• 積極的に使いこなす重要性はますます増している
  • 不可避と思いましょう
  • 車輪の再開発は趣味
• 次回
  • GitとGitHub