Red HatがGPL違反？ 54
タレコミ by おやおやまあまあ
おやおやまあまあ 曰く、
情報元へのリンク
Planet CentOSに2011年3月8日付でJohnny Hughes氏が投稿した内容によるとRHEL6に関する Kernel Source Code (SRPM)の公開を行っていないようだ。
心情的には氏のあげた記事の中にもあるが、会社規模がRed Hatより上のOracleにRed Hatの成果物の丸コピーで顧客を奪われるのは、Red Hatとして許せないだろうというのは理解できるが、Linuxで商売する以上GPLの遵守は絶対だし、何よりOSに金をかけたくない企業はこのままCentOS6が出なければ、いずれサーバ版を用意していてLTS版を抱えるUbuntuなどに流れていくだろうから、RHEL系ディストリが衰えそうな気がするのだが、どうであろうか？
情報元へのリンク
Debianの動きとは対照的かな (スコア:2, 興味深い)
最近ソースの配布形式を更新 [debian.org]して、バニラソース以外をゴチャ混ぜにしたdiffから、独自のファイル群をtarで固める形になった。これまでは、直接関係のないdebパッケージ作成のためのファイルやスクリプトなんかも含めた単一のdiffで提供されていたから、当てられているパッチの確認とかが面倒だったんだよね。生diffを覗いて針山から針を探すか、バニラソースにパッチとして当ててから覗く必要があったから。
これまた最近、Patch Tracking System [debian.org]というサービスが非公式から公式に昇格した。これは当てられているパッチの確認とか、欲しいパッチの個別ダウンロードができるサービスなんだけど、非deb系ディストリの人はこっちを漁ったほうがわかりやすいかな。
Re: (スコア:0)
.specからrulesの世界に入って不便になったなと思ってた箇所だったのに
まさか逆転するとはなぁ
一応 (スコア:1)
別に公開してないわけじゃないと思うが...
ここら辺が詳しい
http://osdn.jp/magazine/11/03/07/0841207 [osdn.jp]
http://mkosaki.blog46.fc2.com/blog-entry-1151.html [fc2.com]
Re:一応 (スコア:1, 興味深い)
パッチの小分け公開はしなくなりましたが、
パッチ適用済みのソース tar.gz は公開しているので
GPL 違反ではないわけですね。
しかし GPL のそもそもの精神に反しているのは否めず、
グレーに近いシロとして叩かれている、ということかな。
GPL も、主義からスタートしたとはいえ、ビジネス界に入れば
背景を無視し単なる文章として扱われるのですね。
Re:一応 (スコア:4, すばらしい洞察)
> しかし GPL のそもそもの精神に反しているのは否めず、
GPLな A を元に、 B を作ったので、BをGPLとして公開する
という状況を「GPLの精神に反している」というのはかなりひどい言いがかりだと思いますね。
そんなことを言ったら、元のプロジェクトからフォークして別のプロジェクトを立ち上げることも、元のコードとの交流が無くなった時点で「GPL のそもそもの精神に反している」ってことになってしまいますよ。
使う側からすると「小分けされたパッチが無い」というのは不便なのはわかりますけど、
作る側からすると「小分けされたパッチを作る」のってすごい面倒なんですよ。
修正を小分けにするためには、修正間の依存関係を考えなければなりませんから、
修正規模が大きくなると、小分けパッチにするのは手間がかかるようになります。
「わざわざ手間をかけて敵に塩を送るぐらいなら、面倒なことはやめる」というのはしかたないでしょう。
で、全部ひっくるめて一個のパッチだけを提供するのなら、修正版のソースを公開しても同じことでしょう。
Re:一応 (スコア:1)
> しかし GPL のそもそもの精神に反しているのは否めず、
GPLな A を元に、 B を作ったので、BをGPLとして公開する
という状況を「GPLの精神に反している」というのはかなりひどい言いがかりだと思いますね。
ええ、別物としてforkするだけなら構わないんですが、
自分の手元にはメンテしやすいパッチ集があるのに、
「再利用しづらいようにするために」パッチ適用後のソースだけを公開する
というのは、GPL のそもそもの精神に反しているのではないかなぁ、と思いました。
事実誤認であれば、ごめんなさい。
Re:一応 (スコア:1, すばらしい洞察)
よくいますよね。OSS=すべてがオープンなものでなければいけない、的な勘違いの人。
OSSは所詮ライセンスであって、道具立てとしてのソースコードの問題に過ぎないのに。
そのライセンスが性質上、オープンな運営に向いているというだけの話なんですが。
クローズドな開発でOSSなものもあれば、オープンな開発でも（ソースは）OSSでないものもあるし。
Re:一応 (スコア:1, すばらしい洞察)
GPLの精神って、GPL条文こそがGPLの精神の表れじゃないの？
GPL条文に書かれていないことに精神なんて言っても…
条文を守る限り自由であるはずなのにタダ乗りだと叩いたりパッチをまとめたら精神に反すると言われたり…
なんだかなぁ
Re: (スコア:0)
> というのは、GPL のそもそもの精神に反しているのではないか
それは誤認も甚だしい。RMSと一度話をしてみるといい。彼は典型的なパラノイアであり、
すべての電子デバイスは政府による監視、トラッキングの道具となりえると考えている。
その懸念をユーザの立場で払拭するためにGPLが必要なのだ、と彼は考えている。
それを真顔でスーツどもに語る彼を見て俺は笑ったよ。もう10年も前の話だけど。
話をもどすと、動作しているプログラムのソースコードがあれば、RMSは満足するし、GPLの精神に
則ったものといえる。
Re:一応 (スコア:1)
動作しているプログラムのソースコードがあれば、RMSは満足するし、GPLの精神に則ったものといえる。
なるほど、今回はまあソースコードだから良いってことですね。
そうすると、(今回が以下の条件に合うかどうかはわかりませんが)
個別のパッチをそれぞれ別個のものとみなすなら話が変わってきそうです。
なぜそのようにみなす人がいるのかというと、
#1915679 や #1915838 のあたりの話になってくるのでしょう。
こうなってくると微妙すぎて私にはわかりません。
ちなみに、RMS の意見としては
( http://www.gnu.org/philosophy/javascript-trap.html [gnu.org] )
難読化されたコードは real source code とは認めないようです。
今回の件は狭義の難読化ではありませんが、
読むのを難しくしようという意図はあるので「グレー」ではないか、
という人がいてもおかしくありませんね。
Re:一応 (スコア:3, すばらしい洞察)
と、言う事にしたいのですね。
というのは置いといて
まず「配布しているバイナリのソースを配布しなければならない」という要件は100%満たしています。
GPLは「改変される前の状態を取得できなければいけない」だとか「どこを改変したのか明記しなければいけない」なんてルールは一切もっていません。
難読化についても全くしていません。
意図的に読みづらく改変したコードではありません。当たるべき場所に当たるべき修正（パッチ）があたったコードです。
可読性という意味であれば別体のパッチよりむしろ読みやすいぐらいです。
これに「グレー」などと言う人は単にケチをつけたいだけの人でしょう。
Re:一応 (スコア:2, すばらしい洞察)
> 今回の件は狭義の難読化ではありませんが、
> 読むのを難しくしようという意図はあるので「グレー」ではないか、
> という人がいてもおかしくありませんね。
これで難読化でグレーとか言われたら、いろんなとこが真っ青ですよ。
同意できません。
Re: (スコア:0)
> 読むのを難しくしようという意図はあるので「グレー」ではないか、
> という人がいてもおかしくありませんね。
居てもおかしくはないが、頭がおかしい人です。
また、GPLライセンスを勝手に解釈して変更するのも、GPL違反です。
言っても無駄でしょうが、一応。
Re: (スコア:0)
なんと。ではうちの会社で作成したコードはどう頑張ってもreal source codeにはなれないですね。
#標準で人的難読化機能が備わっているって悲しい
Re:一応 (スコア:2, すばらしい洞察)
>可読性という意味であれば別体のパッチよりむしろ読みやすいぐらいです。
難読がGPL的に否定するものであれば、当てたら難読になっちゃうパッチを罰するべきであって、当たった後のモノについて言うべきではないよね。
Re:一応 (スコア:1)
>「どこを改変したのか明記しなければいけない」なんてルールは一切もっていません。
2-a) あなたがそれらのファイルを変更したということと変更した日時が良く分かるよう、改変されたファイルに告示しなければならない。
You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
Re: (スコア:0)
/*
* r8169.c: RealTek 8169/8168/8101 ethernet driver.
*
* Copyright (c) 2002 ShuChen <shuchen@realtek.com.tw>
* Copyright (c) 2003 - 2007 Francois Romieu <romieu@fr.zoreil.com>
* Copyright (c) a lot of people too. Please respect their work.
*
* See MAINTAINERS file for support contact information.
*/
これのことを言ってるだけです。
Re:一応 (スコア:1)
うんだから「改変されたファイル」にそれがなくChangeLogやCommitLog等別のファイルに告示するのはライセンス違反だと思うんだ
Re: (スコア:0)
申し立ててみてはいかがでしょうか？
Re: (スコア:0)
今回パッチ適用済みのソースからコメントが削除されてるん？
Re: (スコア:0)
> ええ、別物としてforkするだけなら構わないんですが、
正に、別物(EL)としてforkしてるんじゃないですか。
Re: (スコア:0)
>自分の手元にはメンテしやすいパッチ集があるのに、
バージョン管理ツールを使っていると、パッチ集はないと思いますが？
ハッチ集を作る元データはあっても、どんなツールを使っても、やっぱり手間がかかると思います。
自動化しておけってことかもしれませんがね。
Re:一応 (スコア:1)
概ねそのような話ですが、Red Hatに同情的な意見が多いという感じです。
というか、元コメ時点では元記事読んでなかったのですが、このタレコミ人はちゃんと読んだのかと言いたい...
> The other question that people seem to have is will the new method of the kernel delivery somehow impact CentOS and its ability to get the releases out.
> It should have no impact on the main CentOS distribution at all.
> We have built the EL6 kernels for testing and there is no impact.
とか、
> I certainly understand why Red Hat is taking the action they are taking,
> it is fully GPL compatible, and it should have minimal impact on the main CentOS distribution.
とか書いてあるわけで。
Re:一応 (スコア:1)
Re: (スコア:0)
Oracleも、RHEL上のRDBに下手に高いサポート料とってるので、OSか製品が区分が付かないトラブルをかなり押しつけられた上、CentOSで動かすムチャな客も多いのである程度事情はあるんですけどね。32bitの頃はPAEやmmapとか邪魔くさいこと多かったから。j2eeは平気で2GB使い潰すし。
いまや、そのJ2EEも自分トコの責任になっちゃいましたけどね。
いずれにせよ、Oracleは内部が相当汚い実装になってて下手に手を入れられないんじゃないだろうかと推測。
SPARC / Itenium / x64 と、64bit環境が色々あったし・・・
Re:一応 (スコア:1)
SPARCのOracleは安定性が、win32やLinux-i686よりはるかに高かったので、64bitはまともな実装になっていると信じたい。
Re: (スコア:0)
Oracleは、ほんとオープンソースと相性が悪いな。
というか、オープンソースへの貢献がその利用に対して少ない印象があるな。
相互互助が求められる世界では強欲すぎるんだろうな。
# btrfsを捨てて、ZFSをGPLで前面に出して行ってくれれば少しだけは見直す。
# というか、俺が知らないだけで貢献って結構してたりするの？(Sunと一緒に買った物を除く)
Re:一応 (スコア:1)
Linuxカーネルについてなら、以下の13page以降に各社の貢献度が載ってます(PDF注意)。
http://www.linuxfoundation.org/docs/lf_linux_kernel_development_2010.pdf [linuxfoundation.org]
Red Hatの1/6ぐらいですかね。
Re: (スコア:0)
Googleも利用の割りに少ないな。
貢献した人の欄に日本人っぽい名前が乗ってるけど両方苗字のような感じでどんな人なのか気になる。
Re: (スコア:0)
記載箇所によってTakahashi Iwaiになっているけど、正しくはTakashi Iwaiさんですね。
サウンドドライバのメンテナの方ですね。
Re: (スコア:0)
Googleは配布しているわけではありませんからね。パッチを公開する義務も無い。
GPLの精神の行間を一生懸命読んでいる人からしたら、これもGPL違反かもしれませんね。
Re: (スコア:0)
利用する側からすれば本家を尊重したいのでしょうがそれはGPLとは別の話かと
Re: (スコア:0)
尊重云々の話ではなく、どのパッチでどういう改版をしたのかの
履歴がわかることが重要ということではないかと…
コミュニティのカーネルを追う場合も、gitツリーで追っていけるのは
かなり重宝します。
それがある日突然履歴を追うことができなくなりますというのは、
インパクトが大きいのですよ。
残念だ (スコア:1, フレームのもと)
これで、馬鹿パッチの犯人は籔の中。
Oracle もこれで、「無理矢理おばかパッチ内蔵」の互換 Kernel しか作れなくなったのですね。
笑えるような、笑えないような。
Re:残念だ (スコア:2, 興味深い)
最近、reininn先生の「おばかなサーバ管理」を見られないのですが、次回作はいつですか？
# 笑えねえ
Re: (スコア:0)
Fedoraでサーバ公開している人の言うことは違うね。
おばかはおまえだ。
Re: (スコア:0)
ID取ると閾値を設定できる。
つまりACでいくら罵倒しても無駄、どうせ見てない。
そしてIDで発言しても見たくない奴のコメントは沈められる。
罵詈造語運を浴びせるのが目的なら、本人が見るところへ行ってやってくれ。
悪文推敲 (スコア:0, オフトピック)
一文が長い。
「理解できる。」で一回切って、「だが、Linuxで商売」と続けるように推敲したほうがいい。
Re:悪文推敲 (スコア:1)
アレたまのこの記事は、ACの投稿が禁止されていたので、IDで投稿しました。ご了承下さい。
Re: (スコア:0)
こらっ。みんな仲良く
「理解できる。」とくくって、改行をいれると読みやすいですね。
* * * * *
心情的には氏のあげた記事の中にもあるが、会社規模がRed Hatより上のOracleにRed Hatの成果物の丸コピーで顧客を奪われるのは、Red Hatとして許せないだろうというのは理解できる。
だが、Linuxで商売する以上GPLの遵守は絶対だし、何よりOSに金をかけたくない企業はこのままCentOS6が出なければ、いずれサーバ版を用意していてLTS版を抱えるUbuntuなどに流れていくだろう。
このままだとRHEL系ディストリが衰えそうな気がするのだが、どうであろうか？
* * * * *
それは以前から。 (スコア:0, 荒らし)
もう、10年近く前にですが、まだRTLinuxがGPL(ｗ)の頃、にカ～ネルが
2.0から2.2になった時に、
「2.2へパッチをあてたいのですが」とRedHatに聞いた返答が
「自社の2.0から2.2へは独自拡張ですので公開・返答できません」
との返答をもらった事が･･･。
RT(今はIBM?)のパッチをあてたかっただけですｗ
あの当時はRedHatはバイナリとソ～スは一致してませんでした。
今はどなのだろう。
まぁ、組込みLinuxが一般的でない頃の話ですけど。
# 都市伝説かもｗ(なわけない！)
# OSSの何所かに書きたかったけど、なかなかぶら下げられなかったけどココへ;;
#具体的になってるけど、オフトピ覚悟でID
閑話休題
Re: (スコア:0)
どうやって確かめたんですか？
まさかとは思いますが、自分でコンパイルしたアウトプットと公式のブツをバイナリで比較したとか？
企業やコミュニティがソースから再構築してバイナリ互換をうたうくらいですし、とくにカーネルのようなGPLのもので別物だけ配布したりしたらライセンス違反ですから、普通に考えたらむかしも今もおよそ考え難いんですけれども。
Re: (スコア:0)
カーネルいじりたい人は、みんなさっさとrpm -ivh kernel-source-2.2-xxx.rpmとかしてたみたいですよ。
カーネルの再構築するのにいちいち問い合わせする暇な人も少ないでしょうから、redhatの係りの人も適当に答えちゃったんじゃないでしょうか。とにかく、あまりに無茶なデマを流すのはやめましょう。
Re: (スコア:0)
dodongaだからしかたない。
＃そろそろdodongaのデフォルトスコアを下げるべきではないのか？
diff (スコア:0)
競合に嫌がらせしたいなら、高度なソース難読化アプリを開発して、めちゃくちゃに難読化して公開しようぜ。善意のパッチ提供も無くなるだろうけど
Re:diff (スコア:1, すばらしい洞察)
それで得られるパッチは、Red Hatが当てた複数のパッチの複合なわけで。
個別のパッチを得たり、Red Hatのソースから取り消すみたいなことができなくなってるっていう点で意味があるかと。
Re: (スコア:0)
Re: (スコア:0)
そこのところが、重要だったりする。
某大手での話だけれど、RedHatが出してきたErrata kernelのソースを内部で再レビューしていたところがあるそうです。
自分たちが提供したパッチが取り込まれているのかどうかとか、自分たちのハードやアプリに影響がある修正があるかどうかとかね。
で、RHEL6がアルファだった頃から文句を言っているわけだ。
外野から見ていると、そんなにディストリビュータがが信じられないのかと、呆れています。
WindowsのErrataでやっているように、互換性確認のテストセット流すだけでいいのではないかと……。
そんなことしているから、人員削減や下請け切りしなきゃならない様になるんだろうけどね。いい迷惑だ。
Re:diff (スコア:1, すばらしい洞察)
日常的に高負荷条件下での高信頼運用を求められてるような分野を担当している人達が、
本質的に机上の空論でしか作っていないディストリビュータごときを信用するわけねえだろ。
そしてそういう分野ではそもそも網羅性の高いテストパターンを作ることが非現実的で、
だからこそ「過去の実績」というものが重要になる。Windowsだとソースを簡単には
見られない（直せない）から「仕方なく」そうしてないだけ。
>そんなことしているから、人員削減や下請け切りしなきゃならない様になるんだろうけどね。いい迷惑だ。
複雑系では設計と実装に差異がでるなんて常識。問題でないようにチェックして修正してくれる
実装屋に感謝するならともかく、迷惑とか何様だお前。土下座して謝ってこい。
Re:diff (スコア:1)
そこにそのベンダーの製品を選ぶ価値がある訳ですが
異常終了やデッドロックした客に対して書いたパッチが、RedHat側で取り込まれなかったりエンバグしていて、そのまま左から右へ流してデグレしましたとか笑えない
# 別に関係ない分野だけど余りに不憫なのでID