2013-10-31

CiscoのH.264コーデックについて一言

どうも、あれは、Ciscoの提供するバイナリ(主要なプラットフォーム向けに提供されている)を使うときのみ、Ciscoが特許料を肩代わりするというものらしい。

ソースコードは公開されている。もちろん、ソースコードにはビルドスクリプトなども含まれる。当然ビルドできる。しかし、自前にビルドしたバイナリは、x264でエンコードしたりffmpegでデコードするのと同じだ。特許料の支払いを免除されたければ、Ciscoの公開するバイナリを使わなければならない。

つまり、CiscoはH.264の特許料免除と引き換えに、自前の得体の知れないバイナリを主要なプラットフォームにばらまく土壌を作り出そうとしているわけだ。はたしてそのバイナリは、公開されているソースコードからそのまま生成されたものであろうか。なにか悪意ある秘密の機能が含まれていないだろうか。

このことからも分かるように、もはや自由なソフトウェアは著作権だけを考慮するわけには行かない。特許権も考えなくてはならない。すなわち、著作権だけではなく特許権にも対応したGPLv3が重要となる。

5 comments:

Anonymous said...

特許問題だけなら、別に、非コピーレフトなApache License v2.0でも解決できますけどねー。

Kazuo Moriwaka said...

ビルド手順公開して同じバイナリになると確認できたらそれなりに信頼できるんじゃないですかね

江添亮 said...

たいていの環境で、バイナリ完全一致のビルド、すなわちdeterministic compilationというのは、とても難しいのです。

たとえば、以下はTrueCryptのWindows用の公式バイナリが、公開されているソースコードからそのまま生成されたかどうかを検証しています。

How I compiled TrueCrypt 7.1a for Win32 and matched the official binaries

これはWindows環境だけでなく、GNU/Linux環境でも、大差ありません。
Debianでも、ビルド結果がバイナリ一致になることは、様々な点で信頼性向上のためによいとして、取り組んでいます。

ReproducibleBuilds - Debian Wiki

Anonymous said...

VisualStudioでコンパイルすると、するたびにバイナリが変わりますね。
多分生成時間とかを埋め込んでいるせいですかね?

Kazuo Moriwaka said...

ビルド環境の維持は大変ですね。私の勤めている会社でもかなりの労力が割かれています