記)ライセンスの理解

[shari-sushi]

#169
にて、ライセンス明示のご提案をいただいた。
ライセンスの意味と必要性、どう対応すべきかを理解する。

GitHub Docs リポジトリのライセンス

ライセンスの選択は義務ではありませんが、 ライセンスがない場合はデフォルトの著作権法が適用されます。つまり、ソースコードについては作者があらゆる権利を留保し、ソースコードの複製、配布、派生物の作成は誰にも許可されないということです。

ベスト プラクティスとして、プロジェクトにはライセンス ファイルを含めることをお勧めします。

---

• 4/8 最終的に同じ方に教えてもらった。Xポスト
  解決策
  神か天使なんだと思う。

[shari-sushi]

ライセンスで制限すべきもの

V-karaでライセンスを明記する意義は、不特定多数によるV-kara開発を円滑にすることであると考える。
学習等に使ってもらうのは構わないが、そのままコピって(多少手を加えたとしても)お金稼ぎとかはやめていただきたい。

出典:HITACHI OSSライセンスとは（種類、確認方法、違反リスクなどについて）

• 複製・再頒布・改変
  フレームワークやライブラリの類ではないので、コピーしたもの無制限に使用可にする意味は無いと思う。
• OSS部分のソースコード開示
  上述の理由により指定する意味無し
• 独自プログラムのソースコード開示
  上述の理由により指定する意味無し

となると

明記すべきは

• 複製、改変 :可
• 再頒布: 条件付き？
• V-karaにmergeしたコードは著作権を譲渡

---

自分にはこっちの方が分かりやすかった
コピーレフト、準コピーレフト、非コピーレフトの３択ならV-karaにはコピーレフト型ライセンスが最適かな。

出典: とほほのライセンス入門

---

具体的なライセンス選定とか似たような記事

• Qiita たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ
• Zenn OSSライセンスの要点について

[shari-sushi]

一般的なOSS（言語そのものやライブラリやフレームワークのように二次利用するためのもの？）のためのLICENSEは見つかった。
V-karaみたいに二次利用は好ましくないもののためのLICENSEは見つからない。
といっても、あまり理解できてなくて解釈が間違ってるかも知れない。

---

NEC様より
自作プログラムにどのライセンスを付ける？~ライセンスの選択方法

ほぼ世界中で、著作者に独占的権利が与えられている
OSSライセンスを付与するということは、
著作者である開発者が、公開したプログラムを受領した人に対して
主に再頒布をどういう条件で許諾するかということ

「頒布」は複製物の譲渡または貸与です
♦著作権法第二条第一項第十九号　の定義
頒布 有償であるか又は無償であるかを問わず、 複製物を公衆に譲渡し、又は貸与することをいい
（以下、映画については省略)
♦「複製物」ではない本体の「譲渡」は「頒布」ではない。
■複製権を行使していないし、譲渡権は消尽している。
■弁護士監修の某教科書P54の記述「OSSを入手し、誰か他の人に渡す人(もちろん法人を含めます)は
すべてここで言う頒布する人になります」は、上記条文を引用しているにも関わらず、
内容を理解しているのだろうか？
■複製物を作成していない、つまり、複製権の行使をしていないならば、頒布にならない。

---

今のところの認識と希望

単語	自分の解釈	自分の希望	LICENCE
複製	ローカルにコピー	OK	不要
改変	コードをいじること	OK	不要
再頒布	二次配布	V-karaへのmerge, request：ok 別の製作物に組み込んで公開するのは：NG	不要?

疑問点

• 改変してV-karaにmergeしたときにその部分の権利をこっちに譲渡してもらうのはLICENSEではどう表現すればよい？

[shari-sushi]

改めてこれらを確認

• Qiita:ライセンスをつけないとどうなるの？

Choose an open source license

GitHub上でソースコードを公開するとき、明示的にライセンスが設定されていないのであれば、それは依然として「ライセンスなし」の状態のままです。
ただし、そのプログラムを公開したユーザーはGitHubの利用規約に同意しているはずですから、その中に含まれる「他のユーザーへの許可」の条項が適用されます。

(他ユーザーへの許可を要約すると)

パブリックリポジトリに公開されたプログラムは、他のGitHubユーザーが閲覧・フォークすることができるようになっています。

(フォークされたものについて)

権利のみが他ユーザーに付与され、「GitHub上以外での複製」や「改変」に関する許可は行われない点です。
文字通りに解釈すると、ライセンスのないリポジトリをフォークすることはできても、そのリポジトリをgit cloneコマンドなどで自分のマシンにダウンロードしたり、修正を加えてプルリクエストを送ったりすることは(GitHubの利用規約上では)一切許可されていないということになります。3

これでは、GitHub上にプログラムが公開されていたとしても、ただソースコードが読めるというだけでソフトウェアに組み込んだりすることもできず、実質的にはほとんど何にも利用できませんね。

LISENCEを明示しない＝githubの規約に同意しただけの状態では以下のようになる。
・第３者はフォークやフォークしたもの変更はok(GitHub上での複製：変更はok)
・git cloneはNG（自分のマシンにダウンロードしたり、ダウンロード後に変更を加えてプルリクはNG）
・第３者からプルリクをもらい、それをmergeした場合。そのmerge部分は私とプルリクした人の著作物となる。
以降、私、プルリクした人、第三者の誰がコードに手を加える際も、著作物全員の許可が必要になる。

この３点を回避したい。
(すでにプルリクをもらってるし)

---

ここまで各ライセンスを調べてて、他人に使用してもらう(ossとして別のソフトウェアの一部となる)場合の制限はわかった。
しかし、他人のプルリクをmergeした場合の著作権の扱いについては全くわからなかった。

[shari-sushi]

実際に第三者のコードを受け取っているOSSのLICENSEを確認してみる

使ったフレームワーク、ライブラリは全部MITだった。

• api
  • goそのものは後述
  • gin/LICENSE：MIT 2014
  • gorm/LICENSE：MIT 2013
  • godotenv/LICENCE：MIT 2013
  • ozzo-validation/LICENSE：MIT 2016
• app
  • facebook/react: MIT LICENSE
  • vercel/next.js: 沢山ある…?
    • 
  • react-hook-form: MIT 2019 LICENSE
  • react-select : MIT LICENSE
  • react-table = TanStack/table/LICENSE : MIT 2016
  • react-youtube/LICENSE: MIT 2020
  • react-player/LICENSE.md: MIT

ginのLICENSEの原文と和訳

The MIT License (MIT)

Copyright (c) 2014 Manuel Martínez-Almeida

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

DeepL先生の和訳

MITライセンス (MIT)

著作権 (c) 2014 Manuel Martínez-Almeida

本ソフトウェアおよび関連文書ファイル（以下「本ソフトウェア」という。
本ソフトウェアおよび関連文書ファイル（以下「本ソフトウェア」といいます）の複製物を入手した者は、本ソフトウェアを無制限に使用することができます。
本ソフトウェアの使用、複製、変更、統合、変更、削除を含むがこれらに限定されない。
本ソフトウェアのコピーを使用、複製、変更、マージ、公開、頒布、サブライセンス、および/または販売する権利。
本ソフトウェアのコピーを使用、複製、変更、結合、公開、頒布、サブライセンス、および/または販売する権利、および本ソフトウェアを提供された者に許可する権利を含む。
また、本ソフトウェアを提供された者は、以下の条件に従い、本ソフトウェアを使用することができます：

上記の著作権表示および本許諾表示は、本ソフトウェアのすべての複製物または相当部分に含まれるものとします。
本ソフトウェアは「現状のまま」提供されます。

本ソフトウェアは「現状のまま」提供され、明示または黙示を問わず、いかなる種類の保証もありません。
本ソフトウェアは「現状のまま」提供されます、
本ソフトウェアは「現状のまま」提供されます。いかなる場合においても
著作者または著作権所有者は、契約上の行為であるか否かを問わず、いかなる請求、損害賠償またはその他の責任についても責任を負いません。
本ソフトウェアを使用する前に、本ソフトウェアを使用する前に、本ソフトウェアを使用する前に、本ソフトウェアを使用する前に、必ず本ソフトウェアの使用許諾を確認してください、
本ソフトウェアの使用またはその他の取引に起因または関連して発生した、いかなる請求、損害賠償、またはその他の責任についても、契約、不法行為、その他を問わず、著作者または著作権者は一切責任を負いません。
本ソフトウェアの使用またはその他の取引に起因、起因、または関連するいかなる請求、損害賠償、またはその他の責任についても、契約行為、不法行為、その他を問わず、著作者または著作権者は一切責任を負いません。

golangはGoオリジナル…？
でも気にする必用はなさそう。ginのコードに手を加えて頒布してはいけない。バイナリファイルにしてうんぬん。は自分は問題無い。

• go/LICENSE

golangのLISENCE原文

Copyright (c) 2009 The Go Authors. All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

• Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above
  copyright notice, this list of conditions and the following disclaimer
  in the documentation and/or other materials provided with the
  distribution.
• Neither the name of Google Inc. nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

DeepL先生の和訳

Copyright (c) 2009 The Go Authors. 無断複写・転載を禁じます。

改変の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用は許可されています。
改変の有無にかかわらず、以下の条件を満たす場合に限り、ソースおよびバイナリ形式での再配布および使用が許可されます。
を満たしていることを条件とします：

   * ソースコードの再配布は、上記の著作権表示、この条件リスト、およびこの条件を保持する必要があります。
この場合、本ソフトウェアは、本ソフトウェアに付属しているすべてのドキュメントに適用されます。
   * バイナリ形式での再配布は、上記の著作権表示、この条件リスト、および以下の免責事項を複製しなければなりません。
バイナリ形式での再配布は、上記の著作権表示、この条件一覧、および以下の免責事項を、文書および/またはバイナリとともに提供されるその他の資料の中に再現しなければなりません。
バイナリ形式で再配布する場合は、上記の著作権表示、この条件
バイナリ形式で再配布する場合は、上記の著作権表示、本条件一覧、および以下の免責事項を、配布物とともに提供される文書やその他の資料に記載しなければなりません。
   * Google Inc.の名前およびその貢献者の名前は、Google Inc.
の名前およびその貢献者の名前は、事前に書面による特別な許可を得ることなく、本ソフトウェアに由来する製品を推奨または宣伝するために使用することはできません。
本ソフトウェアは、Google Inc.

本ソフトウェアは、著作権所有者および貢献者によって提供されています。
本ソフトウェアは「現状のまま」提供されます。
本ソフトウェアは、著作権者および貢献者によって「現状のまま」提供されます。
を含むがこれに限定されないいかなる明示的または黙示的な保証も否認される。いかなる場合においても、著作権所有者
著作権所有者または貢献者は、いかなる場合においても、直接的、間接的、偶発的、特別、懲罰的、または結果的な責任を負いません、
特別損害、懲罰的損害、または派生的損害（代替品の調達を含むが、これに限定されない。
代替品またはサービスの調達、使用、データ、または利益の損失、または事業の中断を含みますが、これらに限定されません、
または事業の中断を含みますが、これらに限定されません。
契約、厳格責任、または不法行為（過失またはその他を含む）のいずれに基づくものであるかを問いません。
(本ソフトウェアの使用に起因する、契約、厳格責任、不法行為（過失、その他を含む）のいずれに
本ソフトウェアの使用に起因する、契約、厳格責任、不法行為（過失、その他を含む）の如何を問わず、また、たとえそのような損害の可能性を知らされていたとしても。

※All rights reserved.が複製禁止と訳されているが、「（著作権者が、著作権法で規定されている）全ての権利を留保している」なので、以上のコピペは多分問題無し。

[shari-sushi]

これ良さげでは(加筆：ちょっと違った)
open_source_project_policy/faq_ja.md

↓一部抜粋

	自作のソフトウェアにライセンスをつけて頒布する局面	ライセンスがついた他人のソフトウェアを利用して自己のソフトウェアを制作する局面
MIT	・著作権表示をソフトウェアのパッケージ（複製物）又は重要な部分に記載しなければならない。 ・無保証である旨の免責条項あり。 ・ソフトウェアを受け取った者に無償で無制限の使用権を与えることになる。 ・バイナリコードのみの配布が可能。 ・商用利用禁止は可能。	・二次的著作物については、商用利用禁止を含め、自由な条件をつけることができる。

というか基本的に商用利用の可不可は任意っぽい？
というか(その２)、V-kara公開にあたり、

・頒布する場合はライセンスの写しを添付する必要あり。

使用したフレームワークがMITライセンスを採用してるから、V-karaにもMITを記述する必要があったってことか。

Q: 非商用の利用に関してはできるだけ広く使ってもらいたいと思いますが、商用利用に関しては別途商用のライセンスを設けたいと考えています。その場合にもこの利用規約は使えますか？

A: はい。非商用の利用を許諾するライセンスを付与した場合に、別途商用ライセンスを設けることは可能です。例えば、非商用の利用を許諾するCC BY-NCライセンスを付与した場合、このCCライセンスはあくまで権利者に無断で利用する場合の条件ですので、利用者が別途権利者に対して連絡を取り、商用の許諾を得ることは可能ですし、権利者は予め非商用ライセンスと商用ライセンスを併置することも可能です。商用利用を考える場合には、ソフトウェアやデータを単に公開するだけでなく、商用ライセンスをわかりやすく設計したり、商用の場合の連絡先を表示したり等、商用の用途にも開かれていることを示すことがポイントとなるでしょう。

• CC BY-NCライセンスを調べよう
  また、抜けてたけど使ったことによる責任は負わないの文言も必須だね。

[shari-sushi]

OSSを目指してはいけなかった

The Open Source Definition (Annotated)の和訳

1. 無料再配布
   このライセンスは、いかなる当事者も、複数の異なるソースからのプログラムを含む集合ソフトウェア配布のコンポーネントとしてソフトウェアを販売または譲渡することを制限するものではありません。

つまりOSSのLISENCEを調べても自分の求めるものは見つかるわけが無かったのかもしれない。

目指すべきはフリーソフトウェア?
https://ja.stackoverflow.com/questions/40861/商用と非商用でライセンスを分けることは可能か

MITライセンスを改変して「非商用に限って許可する」という条項を付け加えたライセンスと、商用ライセンスの二者択一にするのが良いでしょう。オープンソースでは無くなりますが、フリーソフトウェアを名乗ることはできます。

GNU.org:自由ソフトウェアとは?

そのソフトウェアを、実行、コピー、配布、研究、変更、改良する自由を利用者が有することを意味します

自由ソフトウェアは商用にできる
「自由ソフトウェア」が意味するのは、「非商用」ということではありません。逆に、自由なプログラムは商用利用や商用開発、商用配布することができなければなりません。このポリシーは基本的な重要事項の一つであり、これなしでは、自由ソフトウェアはその目的を達しえないでしょう。

以上、フリーソフトウェアは目指す姿では無かった。

https://wa3.i-3-i.info/word19160.html
目指すべきはフリーウェア…？
wikipedia:フリーウェア

フリーウェア (freeware) または無料ソフトウェア[1]とは、オンラインソフトの中で、無料で提供されるソフトウェアのことである。フリーソフト、フリーソフトウェアとも呼ばれる。

間違ってないけど、別に目指すものでもないというか、どうでも良い気がする。

[shari-sushi]

https://docs.github.com/ja/site-policy/github-terms/github-terms-of-service#5- 他のユーザへのライセンス許可

CC(creative comons)

---

1. ライセンス要約(ハイライト)

• 表示 —
  あなたは 適切なクレジット を表示し、ライセンスへのリンクを提供し、 変更があったらその旨を示さ なければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。
• 非営利 —
  あなたは 営利目的 でこの資料を利用してはなりません。

以下、重要と思った部分

ライセンスする方のための留意事項：

著作権その他一定の権利により制限されている方法によるマテリアルの利用を公衆に対して許諾する権限を持つ方によって使われることを意図しています。クリエイティブ・コモンズのライセンスは取消すことができません。

また、長くなるので引用は避けるが、「法的に許されている部分を制限することはできない」(当然)
例: 私的利用(コピー可変更不可のものを自分の手元で変更すること。→他人に見せたらアウトだけど、自分だけならokなはず)

---

2. BY-NCライセンス
   英語：概要のSee the legal codeのOther formats Plain Text
   日本語：概要のSee the legal code

BY-NCライセンスで気になったところ抜粋

原文→和訳(DeepL)

非商業用の定義

• 第2条　範囲
  • ライセンス付与 .
    • 本パブリック・ライセンスの条項に従い、許諾者はあなたに対し、ライセンス対象物について、以下に掲げるライセンスされた権利を行使できる全世界的な、無償、再許諾不可、非排他的、かつ取消不可なライセンスを付与します：
      • ライセンス対象物の全部または一部を、複製および共有すること、ならびに
      • 翻案物を作成、複製および共有すること

効果範囲

1. 本パブリックライセンスの条件に従い、ライセンサーはお客様に対し、ライセンス対象物に関する以下の権利を行使するための、
   ワールドワイド、無償、サブライセンス不可、非独占的、取消不能のライセンスを付与します：
   a. 非商業目的に限り、ライセンス対象物の全部または一部を複製し、共有すること。
   b. 非商業目的に限り、翻案素材を制作、複製、および共有すること。

ライセンス期限

• 第6条　期間および終了
  本パブリック・ライセンスは、ここでライセンスされた著作権およびそれに類する権利が有効な期間、適用されます。しかし、もしあなたが本パブリック・ライセンスに違反すると、本パブリック・ライセンスに定めるあなたの権利は自動的に終了します。
  ライセンス対象物をあなたが利用する権利が第6条(a)の事由により終了した場合でも：
  • あなたが違反を発見してから30日以内に違反を是正した場合に限り、違反を是正したその日に、自動的に復活します。
    または、
  • 許諾者により権利の復活を明示された場合に、復活します。

第5条　無保証および責任制限

要は、これを使ったことで何か問題が起きても提供者は一切の責任は負いませんよ。という意味かな。

第5条　無保証および責任制限
許諾者が別途合意しない限り、許諾者は可能な範囲において、ライセンス対象物を現状有姿のまま、現在可能な限りで提供し、明示、黙示、法令上、その他に関わらずライセンス対象物について一切の表明または保証をしません。これには、権利の帰属、商品性、特定の利用目的への適合性、権利侵害の不存在、隠れた瑕疵その他の瑕疵の不存在、正確性または誤りの存在もしくは不存在を含みますが、これに限られず、既知であるか否か、発見可能であるか否かを問いません。全部または一部の無保証が認められない場合、この無保証はあなたには適用されないこともあります。
可能な範囲において、本パブリック・ライセンスもしくはライセンス対象物の利用によって起きうる直接、特別、間接、偶発、結果的、懲罰的その他の損失、コスト、出費または損害について、例え損失、コスト、出費、損害の可能性について許諾者が知らされていたとしても、許諾者は、あなたに対し、いかなる法理（過失を含みますがこれに限られません）その他に基づいても責任を負いません。全部または一部の責任制限が認められない場合、この制限はあなたには適用されないこともあります。
上記の無保証および責任制限は、可能な範囲において、全責任の完全な免責および免除に最も近いものとして解釈するものとします

---

3. cc BY-NC 導入の効果

• 結論
  以下の点がokになる

  • git cloneやそのローカルファイルの変更、公開
    ただ、
  • 第３者はフォークやフォークしたものの変更

• 不明点

  • 第３者からプルリクをもらい、それをmergeした場合。そのmerge部分は私とプルリクした人の著作物となる。
    以降、自分、プルリクした人、第三者の誰がコードに手を加える際も、著作物全員の許可が必要になる。

↑注意

---

4. cc BY-NC 導入方法

ブラウザ上でdevelopブランチに直接コミットしてしまった…。
専用ブランチ作るべきだった。修正するほどのリスクはないのでいいけど。
消すことになったので失敗でした。

GitHub上でccを取り入れた作業ログ

1. GitHubのブラウザ上で+
2. create a new file
3. LICENSEと入力、choose a lisence template
   の項目が出現するのでクリック
4. [Creative Commons Zero v1.0 Universal](https://github.com/sharin-sushi/subscribe-site/community/license/new?branch=main&filename=LICENSE&template=cc0-1.0)→Review and submit
5. 上述の自分がやりたいLICENSEのleagalcote.txtを全文コピペ
6. コミット

消し方
shari-sushi/0015Laboratory#13
(今回、マージ無しの直コミットなのでこれでok。マージしていればおそらくgit filterが必要)

commit履歴のビフォーアフター

成功してる

消した作業ログ

PC上でコピーを作る
(push前のコミット沢山あって、git stashで避けれるのかよくわからんから)。
コピー元本で

> git pull origin develop
remote: Enumerating objects: 12, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 4), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), 9.27 KiB | 249.00 KiB/s, done.
From https://github.com/sharin-sushi/0016go_next_relation
 * branch            develop    -> FETCH_HEAD    
   19f6a2a..bf709b3  develop    -> origin/develop
Updating 19f6a2a..bf709b3
Fast-forward
 LICENSE   | 407 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 README.md |  23 +++-
 2 files changed, 426 insertions(+), 4 deletions(-)
 create mode 100644 LICENSE

> git log
commit bf709b3bb69e600f6fff5e95c3d23647c98e5c3b (HEAD -> develop, origin/develop, origin/HEAD)
Author: sharin-sushi <127638412+sharin-sushi@users.noreply.github.com>
Date:   Sat Apr 6 15:34:38 2024 +0900

    Create LICENSE
    
    create commons CC BY-NC 4.0 (plaintext)
    https://creativecommons.org/licenses/by-nc/4.0/legalcode.txt

commit f79f337fcc2bc64472761a95fdf30aa38ca70af9
Merge: 19f6a2a d381a01
Author: sharin-sushi <127638412+sharin-sushi@users.noreply.github.com>
Date:   Wed Mar 6 00:09:24 2024 +0900

    Merge pull request #168 from sharin-sushi/architecture_figure
    
    Update README.md

> git reset --hard f79f337fcc2bc64472761a95fdf30aa38ca70af9
HEAD is now at f79f337 Merge pull request #168 from sharin-sushi/architecture_figure
PS C:\Users\kawai tatuya\SESESE\0016go_next_relation> git log
commit f79f337fcc2bc64472761a95fdf30aa38ca70af9 (HEAD -> develop)
Merge: 19f6a2a d381a01
Author: sharin-sushi <127638412+sharin-sushi@users.noreply.github.com>
Date:   Wed Mar 6 00:09:24 2024 +0900

    Merge pull request #168 from sharin-sushi/architecture_figure

    Update README.md

commit d381a010e3681feece7681c12fed64b845cd814a
Author: sharin-sushi <127638412+sharin-sushi@users.noreply.github.com>
Date:   Wed Mar 6 00:08:47 2024 +0900

    Update README.md

commit 19f6a2ade3f11389f2591b6c066d183f7e666fe2 (github-desktop-sharin-sushi/develop, github-desktop-sharin-sushi/HEAD, refactor/db-url, pr/167)
Merge: 8e7f516 1f2f0f6
Author: sharin-sushi <127638412+sharin-sushi@users.noreply.github.com>
Date:   Tue Mar 5 20:13:39 2024 +0900

    Merge pull request #165 from sharin-sushi/issue/71-delete-comment

> git push -f origin develop
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: This repository moved. Please use the new location:
remote:   https://github.com/sharin-sushi/V-Kara-Lists.git
To https://github.com/sharin-sushi/0016go_next_relation.git
 + bf709b3...f79f337 develop -> develop (forced update)

このあと、PC上で
未pushのcommitがあるフォルダの.gitに、上述操作をしたファイルの.gitを置き換えして完了

---

4. やっぱりダメかも
   F&Qを眺めていたら、オススメしないってはっきり書かれてた。

[shari-sushi]

追記

Xでポストしたところ、改めてアドバイスいただいた。

どこを目指しているのか把握していませんが、mastodonやmisskeyの採用しているagplがメジャーなライセンスの中では一番求めているものに近いかもしれませんね
あるいは商用利用について許可したくないのであれば oss ライセンスより creative commons の方が良いかもしれません（一般的にソフトウェアの頒布に使われるのは少ないですが、問題なく利用できたはず）

ということでccにする考え方は合ってた様子。
しかしせっかくなのでmastodon、misskeyのライセンスを見てみる。
そういったソースが公開されてる、要はv-karaと似たようなことしてるソフトを探そうと思っていたので渡りに船でありがたかった。

• mastodon
• misskey

どっちも長すぎてやばい…
少なくとも素人が片手間で真似するのは怖い

よく見たらGitHubの機能なのか、掻い摘んだ情報が表示されてた。

[shari-sushi]

コピーレフト、コピーライトの理解

- コピーレフト

https://cloudear.jp/blog/?p=896

Webサービスだったらユーザー全員にソースコード公開しなくちゃいけないのでは？

答えはノーです。

ソースコードを公開する義務があるのはソフトウェア自体の配布先に対してのみです。WebサービスのユーザーはたしかにWebサービスを利用していますが、ソフトウェアはサーバーにしかなく、ユーザーにソフトウェアを配布しているわけではないからです。

- コピーライト

[shari-sushi]

まとめ

（上述にない、口頭で人から聞いた話が多い）

• MITライセンスを導入する

• 商用利用不可については

  • 設定するデメリット
    • 文化的には「なんで？」 となる。（歴戦のエンジニア４人中４人）
    • プルリクに対して心理的ハードルが上がるかも
  • 設定するメリットが薄い
    • 法的効力はないので、ちょっと民事で有利になるかなくらい
    • コードのコピーは勝手にやられたら発見不可。
      仮に発見しても民事でややこしい(しかもちょっとしか有利にならない)。
  • 設定しなくても
    • V-karaという名前で他の人がサービスを始めたらそれは著作権侵害にあたる
      →著作権は発生しない。名称は商標権なら権利を主張できるが申請が必要である。
      10年有効で28200円。(+弁護士費用？)
      なお、先使用権は自然発生するため、先に使っていることを証明できればで他人に商標権を取られても自分は使えるっぽい。

[shari-sushi]

記載したMITライセンス

英文原文

MIT License

Copyright (c) 2024 sharin-sushi

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

和訳

MITライセンス

著作権 (c) 2024 しゃりん寿司

本ソフトウェアおよび関連文書ファイル（以下「本ソフトウェア」）の複製物を入手する者に対し、
以下の条件に従い、本ソフトウェアの使用、複製、変更、結合、公開、頒布、サブライセンス、
および／または販売する権利を含むがこれらに限定されない、本ソフトウェアを無制限に取り扱うこと、
および本ソフトウェアを提供される者にこれを許可することを、無償で許可する：

本ソフトウェアは「現状有姿」で提供されます。

本ソフトウェアは「現状のまま」提供され、明示または黙示を問わず、商品性、特定目的への適合性、
および非侵害の保証を含むがこれに限定されない、いかなる種類の保証もありません。
いかなる場合においても、著作者または著作権所有者は、契約、不法行為、その他を問わず、
本ソフトウェア、または本ソフトウェアの使用またはその他の取引に起因、関連、または関連して生じる
いかなる請求、損害、またはその他の責任についても責任を負いません。

DeepL訳

• 現状有姿について
  https://home.jeita.or.jp/upload_file/20190416165841_IrRVTQ3y0s.pdf　より

現実的に困難であり非常に酷であるため、現状有姿（権利
侵害や稼動について無保証）で引き渡すことをこれらソフトウェア等の引渡しに係る契約の条件とすることが妥当である。

[shari-sushi]

商標の区分について

第42類
https://www.jpo.go.jp/system/laws/rule/guideline/trademark/ruiji_kijun/document/ruiji_kijun11-2019/42.pdf