前回までLinux kernel developmentを読んでましたが、ちょっと著作権とか微妙だったので、以下のThe Linux Kernel documentationを読んでいくことにしました。GNU General Public Licenseなので大丈夫でしょう。
というか、下手な本買うより、オフィシャルドキュメント読んだ方が早いというのは、ちょっと聞く話です。
Linux kernel licensing rules
ライセンスの部分ですが、こういうところって結構重要なことが書いてあったりするので、見逃せなかったりします。
The Linux Kernel is provided under the terms of the GNU General Public License version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0, with an explicit syscall exception described in LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file.
Linux Kernelは、COPYING fileに記述されているように、LICENSES/exceptions/Linux-syscall-noteに記述されている明示的なシステムコールの例外とともに、LICENSES/preferred/GPL-2.0に提供されているように、GNU General Public License version 2（GPL-2.0)のみの条項で提供されています。
なんか微妙な訳になってしまいましたが、
ここに記述されている内容ですね。GNU General Public Licenseで提供されているようです。システムコールって前やったんですが、ユーザーアプリケーションとカーネルのインターフェースっぽいところにあるやつですね。
This documentation file provides a description of how each source file should be annotated to make its license clear and unambiguous. It doesn’t replace the Kernel’s license.
このドキュメンテーションは、それぞれのソースファイルをどのように注釈付けして、ライセンスをどのように明確で、曖昧でなくするか、を記述しています。これは、カーネルのライセンスを置換するものではありません。
結構ライセンス問題って重要で、ソースコードがどのように扱われるべきかを書いていることになります。GNU汚染とか聞いたことありますが、（詳しいことは理解してない）世の中のシステムがどのように構成されるべきかというのに影響してきます。
The license described in the COPYING file applies to the kernel source as a whole, though individual source files can have a different license which is required to be compatible with the GPL-2.0:
COPYINGファイルに記述されたライセンスは、カーネルのソース全体に適応される必要があります。つまり、それぞれのソースファイルは違ったライセンスを持ちながらも、GPL-2.0と互換性を持つ必要があります。
つまり、憲法が日本の法律や条例の頂点にあるように、GPL-2.0と互換性を持たないライセンスはカーネルのソースには適応してはいけないということになりますね。
GPL-1.0+ : GNU General Public License v1.0 or later
GPL-2.0+ : GNU General Public License v2.0 or later
LGPL-2.0 : GNU Library General Public License v2 only
LGPL-2.0+ : GNU Library General Public License v2 or later
LGPL-2.1 : GNU Lesser General Public License v2.1 only
LGPL-2.1+ : GNU Lesser General Public License v2.1 or later
これは、ライセンスの略記になりますね。わかりやすいです。
Aside from that, individual files can be provided under a dual license, e.g. one of the compatible GPL variants and alternatively under a permissive license like BSD, MIT etc.
それは別として、それぞれのファイルはデュアルライセンスで提供することができます。GPL派生と互換のライセンスの一つ、または、BSD、MITのようなよりゆるいライセンスです。
デュアルライセンスは、マネタイズの時に使われるということを聞いたことがあります。BSDやGPLとMITが互換性を持つというのは、実はあんまり理解してないですが、本当なんでしょうか。
The User-space API (UAPI) header files, which describe the interface of user-space programs to the kernel are a special case.
ユーザープログラムとカーネルのインターフェースを記述した、ユーザー空間のAPI(UAPI)のヘッダーファイルは特別なケースです。According to the note in the kernel COPYING file, the syscall interface is a clear boundary, which does not extend the GPL requirements to any software which uses it to communicate with the kernel.
カーネルのCOPYINGファイルの記述によれば、syscallインターフェースは明確な境目です。それは、カーネルとコミュニケーションするいかなるソフトウェアに対するGPLの要求も拡張されません。
なるほど、ユーザーアプリケーションがGPLライセンスに変わってしまうことを明確に防ぐために、APIのヘッダーファイルについては、特別な処理をするんですね。どういう処理なんでしょうか。
Because the UAPI headers must be includable into any source files which create an executable running on the Linux kernel, the exception must be documented by a special license expression.
なぜなら、UAPIヘッダーは、Linuxカーネルを走る実行する要素を作成するいかなるソースファイルにもインクルードされる必要があるからです。この例外は、特別なライセンス表現によってドキュメントされるべきです。
UAPIヘッダーは何も考えずにインクルードされてしまうと、上に書いたようにGPL汚染がされてしまうようです。なので、特別なライセンスになるようです。
The common way of expressing the license of a source file is to add the matching boilerplate text into the top comment of the file.
ソースファイルのライセンスの表現の一般的な方法は、ファイルのコメントに定型的に挿入されたテキストです。
ソースコードの一番上にあるやつ。あれですね。
Due to formatting, typos etc. these “boilerplates” are hard to validate for tools which are used in the context of license compliance.
フォーマットやタイポにより、これらの定型文は、ライセンスのコンプライアンスという文脈に使われるツールでは検証するのが難しいです。
そういうツールが存在するということは初めて聞きましたが、まあ、このフォーマットでは難しいんだろうなとは思います。
An alternative to boilerplate text is the use of Software Package Data Exchange (SPDX) license identifiers in each source file.
代替的な定型テキストは、それぞれのソースファイルにSoftware Package Data Exchange (SPDX)ライセンス識別子を使う方法です。
なるほど、SPDXというツールを使っているんですね。結構面白いです。
SPDX license identifiers are machine parsable and precise shorthands for the license under which the content of the file is contributed.
SPDXライセンス識別子は、ファイルの内容がどのライセンスによって貢献されたかによって、機械によってパースすることができ、正確に省力化することができるツールです。
結構便利なものがあるんですね。機械によってパースすることによって、ライセンスの処理が行われるようです。そういうツールであの巨大なLinuxカーネルがメンテされているんですね。
SPDX license identifiers are managed by the SPDX Workgroup at the Linux Foundation and have been agreed on by partners throughout the industry, tool vendors, and legal teams. For further information see https://spdx.org/
SPDXライセンス識別子は、LinuxファンデーションのSPDXワークグループにより管理されており、産業、ツールベンダー、法律条項を通じたパートナーに合意されています。詳しい情報はhttps://spdx.org/ をみてください。The Linux kernel requires the precise SPDX identifier in all source files.
Linuxカーネルは、全てのソースファイルにおいて、SPDX識別子を必要とします。
Linuxカーネルに貢献するときは、覚えておかないとまずそうですね。全てのソースファイルにおいて、SPDX識別子を必要とする。
The valid identifiers used in the kernel are explained in the section License identifiers and have been retrieved from the official SPDX license list at https://spdx.org/licenses/ along with the license texts.
カーネルに使用されている有効な識別子は、License Identifierセクションに説明されていて、https://spdx.org/licenses/ にある公式なSPDXライセンスリストにライセンスのテキストとして、検索することができます。
なんか微妙な訳でしたが、結構勉強になりました。このドキュメンテーションは結構な量なので、翻訳しながら勉強していくと能率が良さそうです。