2013-10-31

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

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

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

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

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

5 comments:

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

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

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

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

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

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

    ReproducibleBuilds - Debian Wiki

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

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

    ReplyDelete

You can use some HTML elements, such as <b>, <i>, <a>, also, some characters need to be entity referenced such as <, > and & Your comment may need to be confirmed by blog author. Your comment will be published under GFDL 1.3 or later license with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.