# 01. License & IPR ________________________________________ ## 1. GPLとライセンス ________________________________________ GPLv3クイック・ガイド - GNUプロジェクト - フリーソフトウェアファウンデーション https://www.gnu.org/licenses/quick-guide-gplv3.ja.html GPL v3 ```text コピーレフト 1. 著作権表示 2. ライセンス条文・免責条項文 3. ソースコードが公開されており、無制限の改変・複製・再配布が出来ること 4. インストール手順、コンパイラ入手方法等がわかり、入手可能であること 5. GPLを含むプログラム全体もまたGPLである事 考え方 1. プログラム実行　　　の自由を妨げてはならない 2. プログラム解析と改変の自由を妨げてはならない 3. プログラム再配布　　の自由を妨げてはならない 4. 改変プログラム発表　の自由を妨げてはならない 補足 [GPL v2]と[GPL v3]は互いに互換性がない [GPL v2またはそれ以降]なら、[GPL v3]として扱える 販売・課金しても良い（再配布や改変は無制限許可する必要がある） 改変作業に対して報酬請求しても良い [GPL v3]では、Tivoizationや難読化も禁止された GPLとLGPLの違い LGPLライブラリ自体(一般にはDLLやEXE)(甲)を改変しないのであれば、 甲をリンクするアプリケーション(乙)は以下の制約を除いて自由にライセンスを定義可能 (LGPL v2.1 第6項 または v3 全文を参照の事) 1. 乙のリバースエンジニアリングの許可 2. 乙の改変の許可 3-1. 甲を動的リンクし一緒に配布しない場合、特にそれ以外はなし 3-2. 甲を動的リンクし一緒に配布する場合、 甲のソースコードやLGPLライセンスがあるURLを明示せよ 3-3. 甲を静的リンクする場合、乙全体のソースコードを公開する （いずれも、無制限な複製・再配布は許可しなくてよい） （甲自体はコピーレフトであるから、上記を満たせば自由に再配布・バンドル可能） LGPLとGPL Classpathの違い GPL Classpathは、「リバースエンジニアリング/アプリケーション改変の許可」をしなくてよい （GPL > LGPL > GPL Classpath。GPL Classpathの方がLGPLより緩い。） ``` GPLv2互換あり（GPLv2ライブラリと統合してGPLv2として公開できる） ```text MIT 　 : 著作権&License明示&免責表示 修正BSD : 著作権&License明示&免責表示、作者名濫用禁止 LGPL v2 : 著作権&License明示&免責表示、やや緩いCL ``` GPLv3互換あり（GPLv3ライブラリと統合してGPLv3として公開できる） ```text MIT 　 : 著作権&License明示&免責表示 修正BSD : 著作権&License明示&免責表示、作者名濫用禁止 LGPL v2 : 著作権&License明示&免責表示、やや緩いCopyLeft LGPL v3 : 著作権&License明示&免責表示、やや緩いCopyLeft GPL Classpath : LGPL v3よりほんの少し緩いCopyLeft Apache v2 : 著作権&L&免責表示、特許明文化 MPL v2 : 著作権&L&免責表示、緩いCopyLeft、特許 AGPL v3 : GPL3 + ASP loophole対策 ``` ________________________________________ ## 2. IPR ________________________________________ 著作権 | 文化庁 https://www.bunka.go.jp/seisaku/chosakuken/index.html 著作物 | 文化庁 https://www.bunka.go.jp/seisaku/chosakuken/seidokaisetsu/gaiyo/chosakubutsu.html 知的財産権制度の概要 | 経済産業省 特許庁 https://www.jpo.go.jp/system/design/gaiyo/seidogaiyo/index.html スポーツと知的財産 https://system.jpaa.or.jp/patents_files_old/201404/jpaapatent201404_066-076.pdf 将棋や囲碁の棋譜に著作権（著作物性）はないという傾向である https://www.mc-law.jp/kigyohomu/25984/ 著作権、商標権、意匠権、特許権の違い ```text 著作権：自然・死後50年。表現を守る。私的利用OK。Copyright 商標権：国家・更新制。商標を守る。私的利用NG。Trademark 意匠権：国家・更新制。信用を守る。私的利用NG。Design right 特許権：国家・出願から20年。アイディアを守る。私的利用NG。Patent 実用新案権：特許よりも判定基準がゆるい。6年 知的財産権：産業財産権、著作権、肖像権等の総称 産業財産権：特許権、実用新案権、商標権、意匠権の総称 ``` 著作権の考え方 ```text 著作権の目的と概要 ・著作者の権利を守ることで、文化発展を促す ・著作物とは、「思想又は感情」を「創作的」に「表現」した「文芸・学術・美術・音楽の範囲に属する」もの ・著作権者ではない第三者による、著作物に関する無断の複製・翻案・その他各権利の行使を防ぐ ・第十条2より：事実の伝達に過ぎない記事や報道は含まない ・第十条3より：プログラムにおいて、規約やアルゴリズムは含まない 著作権が発生しない例 ・単なるデータ（思想又は感情ではない） ・アイデア/ルール/方針（表現されたものではない。※ 特許権として出願することは可能） ・単なる模倣（創作的ではない） ・工業製品等（文芸，学術，美術又は音楽の範囲に属さない） スポーツに関する専門家の見解 ・フィギュアスケート等の振り付けは舞踊の著作物に含まれると解する余地があるとする見解が有力 ・競技（技術の優劣を争うこと） ・「競技大会において高得点を取るための構成」が，一定の知的活動の所産という側面があるにせよ， 「文芸，学術，美術又は音楽」に象徴される文化的な所産に含まれるとすることには躊躇を覚える 棋譜に関する専門家の見解 ・棋譜は事実の記録である ・俳句は文章（表現）自体がより面白みのあるものにするという目的があります。 将棋の指し手（棋譜）はそれぞれが相手に勝つという目的があります。 文芸の範囲かどうか，というところが大きく違います。 この点からも棋譜が著作物として扱われることの違和感が生じます。 ``` 著作権の分類 ``` 著作人格権 ・公表権、氏名表示権、同一性保持権 著作権（財産権） ・基本　　　：複製権、公衆送信権・公の伝達権、翻訳権・翻案権など、二次的著作物の利用権 ・映像関連　：上映権、頒布権 ・映像以外　：譲渡権、貸与権 ・音楽や劇　：上演権・演奏権 ・小説や美術：口述権、展示権 ``` 著作権とソースコード ```text ・開発会社に著作権が帰属する ・ソースコードに著作権があり・侵害されていることを主張するには以下を示す必要がある ・具体的なソースコードに創作性がある ・十分に膨大なソースコード量で具象実装に十分な幅がある ・その具体的なソースコードを盗用している ・前述の実装表現の幅が十分にあるにもかかわらず、ソースコードが一致する ・変数名やフォーマットの改変だけでは実質的に同一とみなされる ・逆にコーディングルール（≒アイデア）は著作物であると認められない ・そのままでは、著作権者以外が変更を加えることができない ・「利用許諾」「権利放棄」「譲渡」が定番締結内容 ・契約書をよく見るべし ``` ________________________________________ ## 3. 特許出願 ________________________________________ 初めてだったらここを読む～特許出願のいろは～ | 経済産業省 特許庁 https://www.jpo.go.jp/system/basic/patent/index.html ［CEDEC 2017］ゲーム特許とはなにか？　効果的なゲーム特許の取得方法 - GamesIndustry.biz Japan Edition https://jp.gamesindustry.biz/article/1709/17090503/ 気軽に出願 1. 遊び・アイディア・UX 2. アイディアの見える化(仕様のフローチャート化) 3. Google patentと特許検索で既存の特許を確認 4. 概念は他の特許を侵さない程度に広く! 5. 書類作成・出願の代行依頼！ ________________________________________ ## 4. Microsoftライセンス ________________________________________ Microsoft ライセンス条項 https://www.microsoft.com/ja-jp/useterms .NET の概要 | Microsoft Docs https://docs.microsoft.com/ja-jp/dotnet/core/introduction .NET is free | Open-source. No licensing costs. https://dotnet.microsoft.com/platform/free 要約 1. クライアントOSをサーバOSであるかのように本番利用はやめて 2. アクセスする人 or デバイスの数だけお金払ってください。ただし以下はOKです - コーポレートWebサイト - 自社の物理製品を販売するためのWebサイト 3. ユーザーCALとデバイスCALは後から切り替えたりできません。買うときは気を付けてね 4. サービスを公開する場合、（ほぼ確実に）SPLAが必要になります。料金試算はSPLA代行店にお気軽に！ 5. .NET Core系（ASP.NET Core、Kestrel等含む）は全てMIT。.NET 5 はCoreのリネームにつきMIT - 情勢によっては、OracleのJavaみたいなことになるかもしれないけどご了承お願いね！ - そんなことになっても、.NET 5をフォークするOSSが出るから、事実上問題ないと思うよ！ ________________________________________ ## 5. iOS開発ライセンス ________________________________________ Apple Developer Program https://developer.apple.com/programs/ iOSライセンス＆配布方法まとめ https://qiita.com/isaac-otao/items/126bced83d9af86c7ce5 ADEPの契約ができないパターン集 https://www.micss.biz/2019/12/06/1092/ ADEP(Apple Developer Enterprise Program)はもう取得することができないと諦めたほうが良い理由 https://www.micss.biz/2020/06/19/1774/ Apple Developer Program ```text アプリリリース手順 1. AppleID、Mac、XCodeを用意。OrganizationIDはメールアドレス 2. アプリを開発し、完成させる - 実機検証機へのインストールは、USB接続なら可能 3. Apple Developer Program に enroll - Apple Developer Program > enroll - AppleIDをApple Developer AgreementでSubmit（2ファクタ認証設定が必要） - 個人開発の場合： Individual/Sole Proprietor/Single Person Business - 各種情報の登録 - 年会費 > Purchase(支払う) - 最大48時間待つ - 完了するとApple Developer Programの全機能が管理できるようになる - Certificates, Identifiers & Profiles - TestFlight 4. App Store Connectで口座情報等を登録 6. App Store Connectでアプリ情報を登録 7. 証明書等の設定 7.1. XCodeでValidate App > Automatically manage signing > Generate an iOS Destribution certificate > Export Sigining Certificate > キーチェーン > Validate 7.2. Distribute App > iOS App Store > Upload > すべてチェック > Automatically manage signing 8. 数時間待ってから、App Store Connectに戻り提出 signingを手動でやる場合 1. ビルド環境のキーチェーンアクセスを使い、鍵ペア(秘密鍵とCSR(SSL公開鍵+申請者情報))の生成 - ユーザメールアドレスはADPの情報と揃える 2. ADP上に、CSR(SSL公開鍵+申請者情報)を登録 3. CSR(SSL公開鍵+申請者情報)を元にCER(証明書)を生成 4. ビルド環境のXCodeに証明書を登録 5. ADP上に、AppID、ビルド機Deviceも登録 6. AppID, ビルド機Device, Cer情報をまとめる（プロビジョニングファイル生成） 7. プロビジョニングファイルをビルド環境に設定 リジェクト例 - WebViewガワだけアプリは当然NG - デザインがひどくてもNG - 個人情報を収集しようとしたらNG AdHoc & TestFlight? - App Storeを介さずに、最大100台のデバイスまでアプリ配布可能 - インストールを許可するデバイスのUDIDをProvisioning Profileに登録する必要がある - デバイス追加の都度、UDID登録、Provisioning Profile更新、リビルド等の作業が必要 - Provisioning Profileの有効期限が切れるとアプリが起動できなくなる - アプリの署名に使った証明書が無効になるとアプリが起動できなくなる - TestFlightは、Web経由で複数デバイスに対して一斉に開発機やAdHoc配布できるサービス ABM? - 要調査 引き換えコード? - 要調査 ``` Apple Developer Enterprise Program ```text 大原則 - 組織内の人だけが利用できる事（代理店、商業イベント、グループ会社等も不可。顧客も当然不可） - 実質的に端末管理（MDM番号(UDID)&証明書インストール）が必要 - 証明書Revokeは即死。極めて危険 AdHocとの違い - 端末台数が無制限 - UDID管理等が不要（だが実質やらないとBANされる） - In-House版アプリが関係者以外にインストールされないよう厳重管理が必要 - In-House版アプリの利用者はADEP契約主体法人の従業員に限る ``` 技術的な話 ```text - XCodeのパッケージマネージャはSwiftPM(公式) か CocoaPods(昔からあるやつ) - KeyChainAccessは、いわゆるブラウザにあるIDPassの保存機能の汎用版。Mac/iOSで標準搭載 - Touch ID/Face IDは成否だけしか返さない。成否をもとに保存済みの情報をKeyChainから取り出す - 別アプリの起動はURIスキーマ形式が定番。考え方はiOSもAndroidもWinRTも一緒 - WebViewは単なるブラウザレンダリング機能の転用。サイトはレスポンシブ or モバイル or SPA必須 ``` ________________________________________ ## 6. Java(JDK)ライセンス ________________________________________ 要約 1. 2017年にJDKが有償化 2. 2021年に再び限定的に無償化（無償メンテナンス期間を半年のみ） 3. 2023現在、公式の導線に従うとJRE8がインストールされる。ただしJenkinsなどはJDK17前提になっている 経緯と意図 1. 2016年、.NET Coreが登場しプラットフォーム優位性がなくなった。そのため高速な進化 & アップデート強要する必要性が出てきた 2. 2017年、JDK9。有償-OracleJDK、GPL-OpenJDKのライセンス体系刷新。ソースほぼ1本化 GPL Classpathの解釈が判然とせず、Oracleの腹積もりもわからないためJava離れが加速 3. 2019年、JDK8のメンテナンス期間が終了 4. 2021年、AWS、Microsoftが相次いで長期サポートOpenJDKディストリビューションを公開。これを受けてJDK17から、再び無償化 別件：Google訴訟問題の争点と判決 OracleとGoogleのJava著作権侵犯裁判の現状を知る（2018年版） https://www.orangeitems.com/entry/2018/03/28/173616 Javaをめぐるオラクルのグーグル提訴--サン時代に撒かれた不満の種 https://japan.cnet.com/article/20418412/ Java著作権侵害訴訟でGoogle勝利、Oracleは判決後もGoogleを非難 - CIOニュース：CIO Magazine https://project.nikkeibp.co.jp/idg/atcl/19/00002/00205/ - Android市場に噛みたいOracleがGoogleに提訴しようとするも材料がない - モバイルOpenJDKはGPL（クラスパス例外がない）だったため、ライセンス料を支払う必要があった - Googleはそれを回避するため、かつて存在し死んだOSS「Project Harmony」を再利用してJavaを独自実装した - 仕方なく、「APIの著作権」というかなり無理筋なナンセンスなものを争点にした - Googleが直接盗用したと認定されたのはコード約1万1500行。ただしその分量が286万行から成るAPI全体の0.4％かつフェアユースに則る - ゆえに、「API仕様そのもの」を争点にするしかなかった