はてなブックマーク

証明書そのものを見てみる。 * ドメイン認証SSL 証明書詳細のSubject(サブジェクト)で CN = ドメイン名 O = ドメイン名 ドメイン名(サーバ名)を証明している。 * 実在証明SSL 証明書詳細のSubjectで CN = ドメイン名 O = 組織名 L = 市区町村(locality) ST = 県(stateOrProvince) C = 国 OU = 部門名のはずだが適当な値が入ってることが多い (さらに追加パラメータで町名や番地があることも) 組織を証明している。 なおかつ、Extensons(拡張)のCertificate Policies(証明書ポリシー)に 証明書ポリシーOID(と参照URL)がある * EV-SSL 実在証明SSLと同じだが、証明書ポリシーOIDがブラウザに登録されている。 --- ただのSSLと実在証明SSLの違いは、 証明書のSubjec

「グーグルがゼロからつくったブラウザ」というコピーでChromeを宣伝してるのだが、WebKitベースだし「ゼロから」は言い過ぎじゃないか？ ちなみに英語だと「Get a fast, free web browser」(高速でフリーなwebブラウザを入手しよう) なので日本のみのキャンペーンか？ Chromeのメニューから「Google Chromeについて」を選ぶと とあり、ゼロからではなく「その他のオープンソースソフトウェア」のおかげであることを明言している。「オーブンソースソフトウェア」をクリックすると「about:credits」が開き、使用しているOSSの一覧が出る。(Mac版やLinux版でしか使われてないであろうコードの表示がWindows版にも含まれるのはご愛嬌) ところで(L)GPLのコードを利用するときは、ドキュメントだけでなくこのようにプログラム上で表示する義務がある

「Caesium」は特殊なアルゴリズムで劣化を最小限に抑えつつ、サイズを圧縮できるツールだ。 「Caesium」は高性能な画像圧縮ツール。通常のビューワーとは違ったアルゴリズムを採用しており、 ほかのツールと比べて画質を維持したままサイズを小さくできるのが長所。 Caesium reduces the size of your picture up to 90%, preserving the original quality. Caesium uses a special compression algorithm that allows you to save a lot of space and easily upload your pictures on the web (on sites like Facebook, MySpace etc) in a moment. The s

まとめ：ソースコードでは一見問題ないライセンスでも、バイナリ配布時に奇妙なライセンスに化ける可能性があるので注意(特にWindows) 前回 これはプロプラやプラグインの問題に限らず、GPL非互換のFLOSSライセンスを混ぜる時も同様で、例えばOpenSSLをリンクするGPLソフトには一般にこのような例外が付く。 vsftpd: vsftpd is licensed under version 2 of the GNU GPL. As copyright holder, I give permission for vsftpd to be linked to the OpenSSL libraries. This includes permission for vsftpd binaries to be distributed linked against the OpenSSL libr

例えばプロプラソフト用のプラグインがGPLで公開されているとする。 GPLはGPL(互換)以外とのリンクを禁じてるので、自己矛盾していて誰も守れない(*)。 LGPLならいいかというと、LGPLは「改変禁止」や「リバースエンジニアリング禁止」ライセンスのコードとのリンク禁止なのでダメ。（これは違うかも。コメント参照） 正解(FSF推奨)は、「特別な例外として、プロプラFOOとリンクする許可を与える」などを明記した例外つきGPLにすること。(あるいはデュアルライセンス等) しかし、そこまで考えてライセンスを決める作者は少ないので、FLOSSには誰も守れない奇妙なライセンスがいっぱいで、利用者がライセンスを華麗に無視することで成り立ってる。 参考: KDE のコピーライトおよびライセンス問題に関するDebian のスタンス (現在は解消) (*) 動的リンクを結合物とみなすFSFの見解なら こ

Open Source initiatie は現時点で 73種類のライセンスを approve しています。(略) しかし 73種類もライセンスがあるということは問題です。これらのライセンスの多くが、互いに 対して非互換 (incompatible) なものになっていて、一つのプログラムの中に一緒にこれらのラ イセンスの二つに基づくソフトウェアを混ぜ込むことの法的な implications を理解するために は、なんと 5256 種類の組み合わせを学ぶ必要があるのです! GPLは事実上そのままでは使いものにならないライセンスです。 100% pure GPL(またはGPL互換)のソフトウェアのみで構成された世界ならともかく、現実で使うには、適切に例外を設定するか、別ライセンスとのデュアルライセンス等にする必要があります。 このような例外規定がないと（ライセンスを守ったなら）誰も利用できな

何らかの方法(フルスクラッチまたはBSDベース等)でOSをつくり、一部(ドライバなど)にLinuxカーネルのコードを使った場合、 (1) 全てGPLになる (2) GPLにならない。パクった部分だけGPLで混ぜて使える のどちらか。 「OS」というのがキモ。一般論は当てはまらない。 GPLv2(LinuxはGPLv2なので)にはOS例外条項がある。 しかし特別な例外として、そのコンポーネント自体が実行形式に付随するのでは無い限り、 頒布されるものの中に、実行形式が実行されるオペレーティングシステムの主要なコンポーネント(コンパイラやカーネル等)と通常一緒に(ソースかバイナリ形式のどちらかで)頒布されるものを含んでいる必要はないとする。 GPLv2(和訳) However, as a special exception, the source code distributed need no

初耳です。HTTP1.1仕様であるRFC2086には「サーバやプロキシへ最大で 2 接続」とありますが ドメインは無関係です。（サーバとドメインの違いについてはココでは解説しません） リンク先記事 の元ネタは Yahoo!パフォーマンスチーム、最新高速化ルール20を発表 Split components across domains - Maximize parallel downloads - But not more than 2-4 domains, because of the DNS lookup penalty - www.example.org - HTML content - static.example.org - HTML components とあるので、ここでいう「domains」は所謂「ドメイン」ではなく、サブドメイン含む「サーバ」のことだと思います。（原文も悪い