Skip to content

Latest commit

 

History

History
256 lines (171 loc) · 25.4 KB

oss.md

File metadata and controls

256 lines (171 loc) · 25.4 KB
Raw

OSSを探そう

OSSにフィードバックするということは、当たり前ですが、フィードバック先のOSSが必要です。

本章では、フィードバック先を思いつけない人のために、無理のないフィードバック先OSSの見つけ方を紹介します。すでに「このOSSにフィードバックしたい」という対象が決まっている・フィードバックしたい対象がOSSと分かっている場合、この章は斜め読みで飛ばしてもらってもおおむね問題ないです。

身のまわりにたくさんあるOSS

OSS Gateワークショップに来られた方に「フィードバックしたいOSSは何かありますか？」と聞くと、「Linuxカーネル」や「Docker」といった有名なプロジェクトの名前を挙げられることが度々あります。

もちろん、本当にLinuxカーネルをガッツリ読んでパッチを書きたい人もいるとは思うのですが、単に「OSSと言われてそれらの有名なプロジェクトくらいしか思い浮かばなかった」と見受けられるケースでは、筆者はなるべくもっと身近な・小規模のOSSへのフィードバックから始めるようお薦めしています1。

「身近なOSS」なんて思いつかない、という人でも、普段の仕事で使うアプリケーションやコマンドを作業の順番に従って思い浮かべてみると、恐らくOSSがいくつも見つかるはずです。たとえば以下の要領です。

  • インターネット上の情報を調べるためにChromeを起動した。
    • ChromeのベースとなっているChromiumはOSSです。
    • Chromiumが依存しているcrc32c、dom-distiller-js、enum34などの多数のライブラリ（ chrome://credits/ で確認できます）もOSSです。
    • Chromiumで使える拡張機能にもOSSが多くあります。
  • 作業を始めるために、ターミナルを起動して、Bashの上でgit cloneを実行した。
    • GitはOSSです。
    • BashもOSSです。
  • Ruby on Railsで構築されたサービスのユニットテストを走らせるため、bundle installしてrake testした。
    • Ruby on RailsはOSSです。
    • RubyもOSSです。
    • RailsやRailsアプリケーションのGemfileに従ってbundle installでインストールされた多くのGemもOSSです。
    • bundleコマンドを提供するBundlerもOSSです。
    • rakeコマンドを提供するRakeもOSSです。
  • ソースコードを編集するためにVisual Studio Codeを起動した。
    • VSCodeはOSSです2。
    • VSCodeのベースになっているElectronもOSSです。
    • ElectronのベースになっているChromiumもOSSです。
    • VSCodeで使えるプラグインにもOSSが多くあります。
  • Vue.jsで構築されたフロントエンドにファイルを追加し、ESLintでエラーがないことを確かめて、Babelでトランスパイルした。
    • Vue.jsはOSSです。
    • ESLintもOSSです。
    • BabelもOSSです。
    • ESLintやBabelのpackage.jsonに従ってインストールされた多くのNPMモジュールもOSSです。
  • 編集結果をコミットするとき、コミットメッセージの編集にVimを使った。
    • VimもOSSです。
    • VimのプラグインにもOSSが多くあります。

こうして見てみると、開発に使用しているフレームワーク自体やツールがOSSであったり、また、有名なOSSも名前を聞いたことのないような無数のOSSを利用して作られていたり、という状況であることが分かります。現代のソフトウェア開発の現場では、OSSを全く使わずにいられることはあまりないでしょう。

ソフトウェアがOSSかどうかを調べよう

ところで、いきなりたくさん例を挙げましたが、そもそも*「どうだったらOSSなのか？」*を説明していませんでした。

皆さんは、「GitHubにある物はみんなOSSなんだろう」「ソースコードを読める物はみんなOSSなんだろう」と思っていませんか？　だとしたら、それは大きな誤解です。

OSS（Open Source Software）とは、端的にはオープンソースイニシアティブ（OSI）という団体がオープンソースライセンスだと認定しているライセンス一覧に載っているいずれかのライセンスの元で配布されているソフトウェアのことを言います。

OSIの認定ライセンス一覧

多くのオープンソースライセンスは「何らかの形でライセンスを明記すること」を利用条件に含めているため、根気よく調べると何かしらの情報を見つけられるようになっているはずです。「OSSに何かフィードバックしてみたいが、具体的にはビッグネーム以外すぐに思いつけない」という場合には、まずは自分が直接的・間接的に使用しているソフトウェアの中からOSSを探してみるのがお薦めです。LinuxカーネルやDockerよりは、ずっと身近な所で見つけられるはずです。

確認方法を端的にフローチャートにまとめると、次のようになります。

ライセンスの確認手順

以下、それぞれについて詳しく説明しましょう。

ソフトウェア自体を操作してライセンス情報を見る

GUIを持つソフトウェアだと、「ファイル」や「ヘルプ」メニュー配下の「（ソフトウェア名）について」「ライセンス」のような項目からライセンスを情報を確認できる場合が多いです。

たとえば、テキストエディターのMicrosoft Visual Studio Codeでは、「Help」→「View License」で開かれるページの冒頭に「Source Code for Visual Studio Code is available at https://github.com/Microsoft/vscode under the MIT license agreement at https://github.com/Microsoft/vscode/blob/master/LICENSE.txt. （VSCodeのソースコードはMITライセンスの元で入手可能です）」と書かれています。MITライセンスは前述したOSIのオープンソースライセンス一覧に記載されているので、VSCodeはOSSだと言えます。

VSCodeのライセンスを確認する様子

WebブラウザーのMozilla Firefoxでは、「ヘルプ」→「Firefoxについて」で開かれるバージョン情報のダイアログに含まれている「ライセンス情報」のリンクをクリックすると、about:license というFirefoxに内蔵されたページが開かれます。この冒頭には「Binaries of this product have been made available to you by the Mozilla Project under the Mozilla Public License 2.0 (MPL).（この製品のバイナリはMozillaプロジェクトによってMPLで利用可能とされています）」と書かれています。MPL2.0もOSIのオープンソースライセンス一覧に記載されているので、FirefoxもOSSだと言えます。

Firefoxのライセンスを確認する様子

CLI（コマンドラインインターフェース）があるソフトウェアだと、必要な引数を何も指定しなかったり、そのコマンド自体に関する情報を出力する「--version」や「--help」、「/?」といったオプションを指定して起動したりすると、バージョン情報の一環としてライセンスに関する記述が出力される場合があります。たとえばUbuntu 18.04LTSの端末上でbash --versionを実行すると、以下のように出力されます。

$ bash --version
GNU bash, バージョン 4.4.20(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2016 Free Software Foundation, Inc.
ライセンス GPLv3+: GNU GPL バージョン 3 またはそれ以降 <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

GPL3も先の一覧に記載されているので、GNU bashはOSSと言えます。

CLIを持たないデーモンのような常駐型の物やライブラリなどでは、これらの方法は使えませんので、別の確認方法を使う必要があります。

パッケージの詳細ページでライセンス情報を見る

Node.js（JavaScript）のnpm、RubyのRubyGemsなど、開発言語によってはパッケージ管理システムのリポジトリが存在します。そこに掲載されているソフトウェアは、パッケージの詳細情報にライセンス情報が標示されている場合があります。

たとえば、Node.jsのnpmでは、パッケージの詳細ページの右側にライセンスが標示されます。

npmのMochaパッケージの場合

PythonのPyPI、PHPのPackagist、Rustのcrates.io、PerlのCPANなどでも同様の標示があります。

これらのライセンス情報は、開発者の自己申告でパッケージ自体に記載されたメタ情報に基づいて標示されています。開発言語ごとのパッケージのリポジトリは、開発者自身による「投稿サイト」のような性質を持つため、再配布の条件が不明瞭な場合や、パッケージによってはライセンス標示自体が無い場合もあります。

LinuxやBSDなどのOSディストリビューションのパッケージリポジトリでも、同様にライセンス情報が標示されている場合があります。たとえば、Debianパッケージの個別ページでは、右側にある「著作権ファイル」のリンクの遷移先でライセンスを確認できます。

Debianのrsyncパッケージの場合

OSディストリビューション向けのパッケージリポジトリでは、パッケージは各ソフトウェアの作者ではなく、「パッケージメンテナー」という専任の担当者が登録作業を行っています。これは「ソフトウェアの作者が許諾した条件の下で各ソフトウェアをパッケージ化して再配布している」形にあたり、ライセンスが不明瞭なままリポジトリに収録されることはあり得ません。よって、こちらの場合のライセンス情報の信頼性は高いと言えます。ただ、Fedoraのパッケージリポジトリのように、Web上ではライセンスが標示されていないケースもあり、やはり確実な確認手順とは言い辛いのが難点です。

プロジェクトの公式サイトを見る

信頼できる情報ソースという意味では、各ソフトウェアの開発プロジェクトの公式サイトを参照するのも良い方法に思えるでしょう。

しかし、実はこれは筆者としてはあまりお勧めできません。何故かというと、調べるのが大変なわりに不正確な情報である場合があるからです。

たとえばMariaDBの公式サイトでは、ページ最上部のメニューの「About」配下にライセンスの情報があり、「MariaDB Server is open source software and free to use as stated in the General Public License.（MariaDBサーバーはオープンソースソフトウェアで、GPLの条件下で無償/自由に利用できます。）」と書かれています。

MariaDBのWebサイトにあるライセンス情報

しかし、GPLのバージョンがいくつであるか記載されていません。GPLはバージョンによって条件が異なるため、バージョンを誤認して使うとトラブルの元になり得ます。

　

別の例として、Apache HTTP Serverの公式サイトを見てみましょう。こちらは左側のメニューに「License」という項目があり、ここからライセンスの情報を確認できそうに見えます。

Apache HTTP ServerのWebサイトにあるライセンス情報

ですが、実際にはこのリンク先はApacheライセンスというオープンソースライセンスそのものの説明になっています。ここからは、Apache HTTP Serverというソフトウェア自体がApacheライセンスのバージョンいくつに該当するかは、すぐには読み取れません。

このように、公式サイトから正確なライセンス情報を確認するのは意外と大変です。しかも、場合によっては不正確な情報にたどり着いてしまって、内容を鵜呑みにできるとは限りません。ハズレ情報を掴んでしまうと、労多くして実り無しということになってしまいます。

こういうことが起こってしまうのは、公式Webサイトが外部ドキュメントの一種として、ソフトウェア本体とは別に管理されている場合が多いためです。ソフトウェアだけ更新されてドキュメントが更新されていないのは、残念ですがOSSに限らずよくあることです。

ですので、筆者はソフトウェアのライセンスを確認する方法としては、次に紹介するソースコード自体に添付されたライセンス情報を確認する方法をお薦めしています。

ソースコードを見る

ソフトウェアのライセンスを知るには、ソースコードを確認するのが最も確実です。これは、多くのオープンソースライセンスでは、ソフトウェアをそのライセンスの元で配布する場合に、ライセンス情報を明示すること自体が利用条件の1つになっているためです3。

ソースコードを入手する方法が分からない場合、公式サイトのダウンロードページを参照してみましょう。インストール可能なパッケージと併せてソースコードのアーカイブがダウンロード可能になっていたり、ソースコードのリポジトリへのリンクが記載されていたりする場合があります。また、公式サイトに「Getting Started」や「開発に参加するには」といった標題の情報がある場合、そこにリポジトリの在処やソースコードの入手方法が記載されている場合もあります。

ソースコードを入手できるようになっていない場合は、そもそもそのソフトウェアがOSSではない可能性が高いです。OSSの中には「ソフトウェアを購入した人が要求した場合にソースコードが開示される」というような条件の物もあり得ます4が、ここまでに紹介した各種の方法でライセンスを確認できず、ソースコードも入手方法が分からないソフトウェアがOSSである可能性は、常識的に考えれば5相当低いでしょう。

　

さて、ソースコードを無事入手できても、安心するのはまだ早いです。ライセンスが設定されていない場合や、オープンソースではないライセンスが設定されている場合があるからです。

最悪の場合、もしかしたら「オープンソースじゃないのにソースコードを見たな！　あんたがその後に開発したこのソフトウェアは俺のソフトウェアを参考にしたに違いない！　賠償しろ！」と訴訟をふっかけられてしまう可能性も無いとは言いきれません。

なので、手当たり次第にファイルの中を覗くのではなく、ライセンス情報が記載されている可能性が高いファイルに絞って内容を確認していきましょう。

多くの場合、ライセンス情報は最上位階層の以下のような名前のファイルに記載されています。

  • LICENSE
  • LICENCE（「ライセンス」のイギリス英語での表記）
  • COPYING（「著作権情報」の意）
  • 著名なオープンソースライセンスの略称と同じ名前のファイル、たとえば GPL など

ファイル名は目立つように全て大文字になっていることが多いですが、もちろん小文字でも意味は変わりません。また、.txt や .md などの拡張子が付いている場合もあります。

ファイルではなくそのような名前のフォルダがある場合、その中にライセンス情報が詳しく書かれたファイルが置かれていることもあります。ライセンス名のファイルの場合、ライセンスのバージョン番号が末尾に付いている場合もあります（ GPL3.txt など）。

このような名前のファイルが見当たらない場合は、README （こちらも .txt や .md などの拡張子が付いている場合があります）を見てみます。README はソフトウェアの使い方や権利者名など重要な情報を端的にまとめて記載している場合が多く、ライセンス情報も含まれていることがあります。

ライセンスが明記されていない場合は？

ここまで、ライセンスを確認するための方法を色々とご紹介してきました。しかし、どこを探してもライセンス情報が見つからないという場合もあります。

その場合は安全のために、OSSではない可能性が高いと考えるようにするとよいでしょう。

また、ライセンス情報が見つかっても、そのライセンス名がOSIの認定するオープンソースライセンスの一覧に載っていない場合は、「OSSっぽいけれども、OSSではない」ということになります。

ただし、ライセンス情報を確認できなかった場合でも、作者はOSSのつもりだったもののライセンスを明示し忘れていた、ということは希にあります。GitHubなどでソースコードが公開されているのにライセンス情報が無い場合にはその可能性がありますので、「駄目でもともと」の精神で、イシュートラッカーに「ライセンス情報が明示されていない（明示して欲しい）」といった内容で報告をしたり、作者の連絡先として記載されているメールアドレスに「ライセンス情報が明示されていませんが、これはどのようなライセンスでしょうか？」と質問を送ったりしてみることをお薦めします6。そうすると、案外あっさりオープンソースライセンスを設定してもらえることもあります。

　

もちろん、「オープンソースでなければフィードバックしてはいけない」ということはありません。商用のソフトウェアでも、お客さま窓口から障害報告や要望をフィードバックすることはあります。

ただ、ソースコードを入手できる状態なのにオープンソースではないソフトウェアについては、無闇にソースコードの内容を読んで記憶に留めたりファイルを抽出したりして一部だけでも再利用してしまうと、下手すれば訴訟にもなりかねません。「問題無い」ということを確認できるまでは、くれぐれも慎重に取り扱うようにしましょう。

また、OSS同士であっても、ライセンス同士が矛盾するために、あるソフトウェアから引用したコードを別のソフトウェアに組み込めないケースもあります。これについては、第N章「ライセンスについてより正確に知る」で改めて詳しく述べます。

ライセンス情報は、開発者がそのソフトウェアをどのように利用してよいか、どのように利用して欲しいかを記した重要な情報です。すべてを最初から把握する必要はありませんが、普通にユーザーとして「使う」段階から、開発者として「理解する」段階へ一歩踏み込む際は、「ほう、このソフトウェアはGPL3なのか」「これはApacheライセンス2.0なんだな」といった具合に、まずは名前だけからでも構いませんので、必ずライセンスの種類を確認するようにしましょう。

Footnotes

  1. というのも、有名だったり大規模だったり歴史が長かったりするOSSは、「別に今の段階で何か具体的に使用上で困っているわけではない」という人がフィードバック先にするには色々とハードルが高い場合が多いからです。たとえば、メーリングリストが主な情報のやり取りの場だったり、独自のツールを独特の運用ルールに基づいて使っていたり、プルリクエスト形式ではなく伝統的なパッチの形で修正を送る必要があったりということがあります。 ↩

  2. 実際には、VSCodeの配布バイナリには公開されているソースコードには存在しないモジュールが含まれているらしく、「VSCodeはOSSだ」とは厳密には言いにくいようです。そのため、公開されているVSCodeのソースのみに基づいてビルドしたバイナリを提供するプロジェクトの「VSCodium」（ https://github.com/VSCodium/vscodium ）が有志の手により運営されています。 ↩

  3. 第三者がそのソースコードを受け取って、そのまま再配布したときにも、妥当なライセンス情報が含まれた状態になっている必要があり、そのためには最初に配布する時点で妥当な情報を含めておくのが効率が良い、ということ。 ↩

  4. 誤解されがちですが、OSSであってもソースコードを万人に開示する必要はありません。これは第N章「ライセンスについてより正確に知る」で改めて詳しく述べます。 ↩

  5. 手続きや管理の手間を考えると、「申請に応えてソースコードを提供する」運用にはそれなりにコストがかかります。それだけのコストをかけて厳密に「要求された場合だけソースコードを開示し、そうでない限りは開示しない」運用を徹底したいケースは希でしょう。 ↩

  6. 英語で聞く場合、端的に「Is this an opensource project? Which is the license?」と質問すればそれで十分通じます。 ↩