こんにちは。caretの國澤です。
OSSにコントリビュートする記事はよく見かけるのですが、OSSの始め方の記事が少ないと思ったので、調査した結果をまとめようと思いました。
OSSとは
オープンソースソフトウェア(英: Open Source Software、略称: OSS)とは、利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称である[1]。
wikipedia
- OSD(OSSの定義)はOSIというOSSを促進する組織が管理している
- OSD(Open Source Definition):[https://opensource.org/osd-annotated]
- OSI(Open Source Initiative):[https://opensource.org]
- OSSの中で様々な考えがある中、OSDがデファクトスタンダード
- OSSにはライセンス(使用許諾書)が必要
- ライセンスに従って利用する必要がある
ライセンス
- OSIによって認められてライセンス一覧[https://opensource.org/licenses/alphabetica]
- ライセンス一覧の日本語訳(基本的にこっちを参照でいいと思う)[https://licenses.opensource.jp]
- 他にもライセンスがあるが、ライセンスとして認められない場合があったり、紛らわしいライセンスの使用を防ぐためにOSI認証のライセンスを使うのが良さそう
多くのライセンスの特徴
- 動作保証に対する免責条項を持っている
- 著作権表示の義務
- ライセンス表示の義務
- コピーレフト型、準コピーレフト型、非コピーレフト型
コピーレフト
コピーレフト(英: copyleft)は、著作権(英: copyright)に対する考え方で、著作権を保持したまま、二次的著作物も含めて、すべての者が著作物を利用・再配布・改変できなければならないという考え方である[1]。
wikipedia
- つまりコピーレフトのOSSを使って開発すると、作成したソフトもコピーレフトとなり、公開しないといけなくなる
- 非コピーレフトだと二次的著作物に利用・再配布・改変を求めないので、ソフトを公開しなくて良い。
- 世の中のライセンスの半分は非コピーレフト型
メジャーなライセンス
- MIT(非コピーレフト)
- Apach-2.0(非コピーレフト)
- GPL-2.0、GPL-3.0(コピーレフト)
MITを基準として、他のライセンスを比較して考える
MITライセンスの日本語訳
以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル(以下「ソフトウェア」)の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。
上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。
ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、および権利非侵害についての保証も含みますが、それに限定されるものではありません。 作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。
https://licenses.opensource.jp/MIT/MIT.html
Apach-2.0との違い
- 特許ライセンスの付与
- 当該のOSSを利用する人は特許を得て、好きに使ってくださいよという意味
- OSSの利用者に訴訟を起こした場合はライセンスが終了する
- 明示的に特許を得ているだけで、MITとそんなに変わらない。
- 企業はこのライセンスを好む
GPL-2.0、GPL-3.0との違い
・GPL ライセンスを利用して作成されたソフトウェアは頒布時にソースコードの公開義務あり(改変部分のソースコード公開を含む)
・GPL ライセンスが適用されたプログラムの全部あるいは一部を用いて作られたソフトウェアは GPL に従って頒布されること
・GPL ライセンスを適用したソフトウェアを頒布する際に GPL ライセンスで書かれている以上の条件を課すことは出来ない
https://yamory.io/blog/about-mit-License
公開場所
GitHub
GitHub以外もあるが、わざわざ別のものにしなくてもGitHubに公開で良いと思う。
OSSを始めるのに用意する物
- LICENSE(ライセンスが記載されたファイル)
- README.md(OSSの説明)
- CONTRIBUTING.md(コントリビュータに対するガイドライン):[https://docs.github.com/ja/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors]
- CODE_OF_CONDUCT.md(行動規範)[https://docs.github.com/ja/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project]
OSSの運用までの流れ
- OSDの理解
- OSSのガイドラインの理解
- 上記に基づいて、どんなOSSを作るか考える
- 作成したいOSSに沿ったライセンスを選ぶ
- GitHubの設定
- OSS作成
- Githubにソースコードを載せる
- OSSを始めるの必要な物を用意
- 広報
- OSS用ツールを駆使してOSSを管理
OSSに関するツール
OSSの運用ツールをまとめたサイトを元に一部抜粋[https://www.linuxfoundation.jp/resources/open-source-guides/tools-managing-open-source-programs]
ライセンスとコンプライアンスとセキュリティチェック
Black Duck[https://www.hitachi-solutions.co.jp/blackduck]
- ライセンス、コンプライアンス違反やセキュリティ脆弱性に関するリスクを洗い出す
- CI/CDに組み込める
FOSSA[https://fossa.com]
- Black Duckと似たサービス
バグトラッキング
Git Hub Issues
- フィードバックとバグ トラッカーを統合したシステム
- 言わずと知れたツール
Atlassian JIRA[https://www.atlassian.com/software/jira]
アーカイブとリリース管理
git hub release
- 言わずと知れたツール
Docker Hub
- 言わずと知れたツール
プロジェクトの健全性をトラッキングするツール
Grimoire Lab[https://chaoss.github.io/grimoirelab]
- git hubから情報を集めて可視化してくれるツール
CLA(コントリビューター ライセンス アグリーメント)関連
CLAとは
ソフトウェアへのコントリビューターがコードを貢献するときに署名する契約書
wikipedia
CLA Assistant[https://github.com/cla-assistant/cla-assistant]
コードの品質チェックツール
code climate[https://codeclimate.com/]
- コードの品質とテストカバレッジチェックとその可視化
その他
github/licensed
- 使用しているライブラリのライセンス一覧を出力してくれるツール
- CI/CDにも組み込める
- githubが社内用に作成したもので動作は保証されていない。
オープンソース管理ソリューション(HITACHI)
- コンサルとツールを使ってOSSを支援してくれる
オープンソース プログラム オフィス インボックス
- まだ完成していたないが、多くの有名な会社がコントリビューターでOSSの開発パッケージをを作ろうとしている。
GitHubを使ったOSSの管理をサポートするツールは様々ある。
ツールは適宜足していけばいいと思った。
参考になるサイト
- 概要の理解[https://future-architect.github.io/articles/20200821/]
- 下記二つは必須で見ないといけないと思う
- GitHubが提供しているOSSのガイドライン[https://opensource.guide/ja/]
- OSSを推進するLinux Foundationの日本語版のサイト[https://www.linuxfoundation.jp/resources/open-source-guides/]
- OSSの開発で参考になりそうな人気リポジトリをまとめたサイト[https://qiita.com/baby-degu/items/6c0c73a1e79644ebbb1a]
- ライセンスの人気まとめ[https://www.whitesourcesoftware.com/resources/blog/open-source-licenses-trends-and-predictions/]
- よくみるライセンスのまとめ[https://qiita.com/tukiyo3/items/58b8b3f51e9dc8e96886]
注意した方が良さそうなこと
- OSSを管理する上で、ソースの更新は最新の注意を払う。(バグがあったりすると利用者への影響が多いため)
- 品質を上げるために自動テストをを入れた方がいい、テスト管理ツールも入れた方がいい。
- ライセンスを正しく使うには法的に知識がいるそう。(エンジニアだけでは理解が難しいらしい)
最後に
OSSの始め方の記事は少なく、まとめるのに時間がかかりました。
実際作るとなるとまとめサイトを頼るのではなく、GitHubやLinux Foundationのガイドラインを参考に進めることになると思っています。
OSSが始まればまたどのように運用していくかなどの記事もまとめたいと思いました。
コメントを書く