修行のために何かを作る話（リポジトリ作成）

この話の続き

webデベロッパーとは思えない開発速度の遅さで進めているこのシリーズ。
今回はリポジトリを作ったよ。

リポジトリ is

別にプログラミング解説noteじゃ無いので細かいことは書かないが、後段のライセンスの話の整理ためにちょっと残す。

ここでのリポジトリはGitHubでのソースコードの管理単位の話。
リポジトリという単語自体はバージョン管理システム（この場合はGit）での管理単位。

もはや手癖で何か開発を開始するタイミングでとりあえずリポジトリを作っている。

リポジトリの公開

GitHubではリポジトリの公開/非公開が選べる。
数年前（2018年くらいだったかな）は非公開にするにはGitHubの有料会員になっている必要があったが、今は無料会員でも非公開にできる。素敵。

公開されたリポジトリは誰でも内容が閲覧でき、コピーし、内容に修正を加えたりできる。

ライセンスとの関連

（ここは自分の推測が多分に含まれる）

webの開発者が何かを開発しようとした時、ゼロからモノを作ることは無い。
OSや更に下層の技術からアプリケーションフレームワークまで、必ず誰かが作った技術の上に自分の成果物を構築する。
つまり他人の制作物を「利用」する。

他人の制作物には制作者が設定したライセンスがあり、ライセンスに則って権利が守られている。
このため「他人の制作物を自分の名前で公開し再頒布を許可する行為」はライセンスとの整合性を確認しないと容易に制作者の権利を侵害してしまう。

そこで冒頭に戻ると、リポジトリを公開すると、他人の制作物と入り混じった自分の制作物を公開し、再頒布することになるので、ライセンスの取り扱いを慎重に考えなければならない。

非公開でいいのでは？

多分YES。
公開しなければ恐らく再頒布にはあたらない…んだと思っているが、ここは自信がない。OSS活動をしておらず会社が設定したポリシーにしたがって作業をしているだけだとこういう時に正しい答えが導き出せなくて不安だ。

リポジトリは非公開でも作ったサービスは公開できる（商用サービスは大体そう）ので、それで良いのだと思われる。

が、せっかく作るので公開しておいた方がまあその内誰かが見に来ることも有ろうから、公開しておきたい気持ちがある。

ライセンスの話

大体以下の２つの説明を読んだ。

OSSのライセンスを理解する（「使用」と「利用」の違い、知っていますか？） - Qiita

地味ながら、Ruby on Railsのライセンスをチェックしてみた | オープンソース・ライセンスの談話室

後者は今回の開発でRuby on Railsを利用する予定だから。

その上での結論は以下の通り。

RubyのライブラリであるGemのソースコードは通常リポジトリの管理に含めず、再頒布しない。
サービスを稼働させる環境に直接インストールするものであり、再頒布には当たらないはず。
このため、GemのライセンスについてはOSSライセンスで有れば問題がなさそう。

Ruby自体も複雑なライセンス（Rubyライセンスというもので、GPLとBSDのライセンスが並存しているらしい。）だが、こちらも環境に直接インストールするだけなのでリポジトリの公開とは関係がない。

一方で、主に利用する予定のRuby on Railsのソースコードは、リポジトリ上に公開される。
このため、今回のリポジトリのライセンスはRuby on Railsのライセンスと整合したものであることが求められる。

つまり、リポジトリのライセンスはRuby on Railsと同一のMITとし、以下の制約を守らなければいけない。

著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載

幸いなことにGitHubではリポジトリの初期構築をweb画面から行うと初回にライセンスの設定を質問してくれる。
そこでMITを選択すると、初期構築時点でリポジトリルートディレクトリにLICENSEという名前のファイルを作成してくれる。中身は以下の通り。

MIT License

Copyright (c) 2021 Tetsushi FUKABORI

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ライセンスの制約は守られている事になるんだろう。
これで枕を高くして眠れるようになり、GitHubには足を向けて寝られなくなったのであった。

余談

Gemの中にはGit管理対象（＝GitHubリポジトリ公開対象）のディレクトリに設定ファイルなどを生成し、Git管理対象としてもらうことを意図したものがあるが、そちらのライセンスとの整合性はどう考えれば良いんだろうか。
設定ファイルはライセンスの保護対象外…とは言えない程度に複雑なファイルを生成するツールがある気がするが…。

余談２

リポジトリは初期設定のブランチを「main」にした。
旧来の開発文化だと初期作成のリポジトリは「master」なのだが、世界的な反差別の潮流にのりmaster-slaveの関係を想起させるmasterは過去の物へ。

個人で作成しているサービスでどっちの名前で困ることもなかろうと思いGitHubオススメの「main」にしました。

余談３

リポジトリはこれ

次は「公開するAWSのサービス選定」か「rails newする話」のどっちかになると思う。
果たして記事がポストされる日が来るんだろうか。