脱GPLを目指すFreeBSD、FreeBSD 10ではC++標準ライブラリも脱GPL 77
ストーリー by headless
free-from-free-but-still-free 部門より
free-from-free-but-still-free 部門より
あるAnonymous Coward 曰く、
GPLのコードをベースシステムから取り除く試みを続けているFreeBSDプロジェクトだが、FreeBSD 10では標準C++ライブラリをGPLフリーにする見込みが立ったとのこと(マイコミジャーナルの記事、 The FreeBSD Foundationのブログ記事)。
従来、標準CライブラリはFreeBSD独自のlibc、標準C++ライブラリはGCCのlibstdc++を使用していた。しかし、GCCのライセンスはGPLv3に移行しており、ベースシステムにGPLv3のコードを取り込まない方針のFreeBSDでは最新版へのアップグレードができない状態になっている。そのため、libstdc++に代わる標準C++ライブラリとしてLLVMのlibc++を移植することが検討されていた。現在、libc++の移植に必要なxlocale APIの実装はほぼ完了しており、FreeBSD上でビルドしたlibc++によるテストも順調のようだ。
そのLLVMですが (スコア:5, 参考になる)
LLVM3.0のリリーススケジュールのアナウンスがありました。
The LLVM Compiler Infrastructure Project [llvm.org]
ゃゃ、オフトピ気味
脱GPLの理由 (スコア:5, 参考になる)
原則的には、ソフトウェアからの出力結果は、たとえ使用したソフトウェアがGPLライセンスでも、ライセンスには縛られない(http://www.gnu.org/licenses/gpl-faq.ja.html#CanIUseGPLToolsForNF 参照)から、
GCCでコンパイルしたソフトウェアがGPLの縛りを受けるなんて、ないはずなんだけど。
だったらなんで脱GPL化する必要があるのかと思ってググってみたら http://www.wdic.org/w/TECH/GPLv3 [wdic.org] によると
特許
GPLのコードを使用し、特許が含まれるコードを作成したとする。そのコードはGPL条項に基づいてGPLで公開されなければならない。
GPLv2では、そこに含まれる特許については、特許を持っている人間の裁量に任されており、つまりソースは公開はされるが、特許があるため厳密な意味で自由には使えないソース、という微妙なものが世に出ることになっていた。
(以下略)
GPLv3以降
GPLv3では、特許について、そのコードを利用した第三者を訴える権利の放棄を要求している。つまり、そのコードに含めた特許は全て放棄せねばならないということになる(含めていない特許はもちろん放棄する必要はないが)。
特許は持ったまま、コスト削減のためにGPLのコードを使いたいという要求は、GPLv3では通らない。
このため、元々「GPL汚染」などと呼ばれるほどばい菌扱いされていたGPLが、さらに企業から嫌われることになった。GPL排除の動きが、以降、本格化することになった。
企業にとって代替は、「ソースの公開を要求されない」ライセンスが最も無難ということになり、結果として「BSDライセンス」あるいはその類似ライセンスへと移行が進んでいる。
BSDの動向
FreeBSDはじめBSDはBSDライセンスでライセンスされている。
しかし、BSDはLinuxと違って業務用途で広く使われているため、企業からGPLv3のコードの混ぜないで欲しいとの要望が強く、FreeBSDも、ベースシステムにはGPLv3コードを混ぜない方針とした。この方針は、おそらく永久に変更されることはないだろう。
そんなBSDも、GPLのコンパイラGCCに大きく依存していた。GPL排除で最も難しいだろうと考えられてきたのはこのGCCの代替だが、ここへ来てclang/LLVMが実用化されたため、ついにGPL排除も現実のものになってきた。
FreeBSDでは、FreeBSD 9.0からclang/LLVMを試験的に利用し、FreeBSD 10.0から本格的にclang/LLVMに移行する計画を立てているようである。
ということらしいです。
1を聞いて0を知れ!
Linux向けアプリのコンパイル (スコア:2)
ユーザーとしては、Linux向けアプリケーションのコンパイルや移植で問題がないのかが心配です。
FreeBSDって、とても使いやすやすいOSだと思います。
GPLフリーになることで商業利用が進んで一般向けに普及が進むのか、ライブラリなどのLinuxとの互換性低下で移植などに支障が出るのかが、が問題ですよね。
Re:Linux向けアプリのコンパイル (スコア:3, 興味深い)
clangってコンパイラーはじめて聞いたので早速試してみたけど、
Makefile の CC=gcc を clangに書き換えただけで適当にダメ元で試したら、
意外と動くのが多くて驚いた。
__attrubute__(aligned((16))); みたいなGCC方言が入っててもコンパイル通ったけど、インラインアセンブラでSSEのアライメント依存の命令を使ってるのだと正常に動作しないのがあった。
__sync_fetch_などのアトミック操作のGCC方言も普通に使われてるけど、これは動いた。
よくわからないけど、予想以上に多くのソースが無難に通った。
あとコンパイル速度がGCCより倍ぐらい速く感じた。
あとvoid main() がエラーになる。警告じゃなくて。
f(int a){ return a; } だと警告になる。gccよりくちうるさい。
GCC方言使ってても通るってのが意外すぎて驚いた。アップルすごい。
Re:Linux向けアプリのコンパイル (スコア:1)
LLVMなんだから、
・コンパイルの速度は速くなる
・バイナリのサイズは小さくなる
・実行時の速度は遅くなる
のは、原理的に当たり前では？MacはGCCを4.2で止めているから、世代的な意味で速度でもいい勝負になるかもってだけで。ただ、中間コードのせいでバイナリ互換性がでたりすると恐ろしいとは思うけど、現状では開発でclangを使ってチューンと製品用にはgccを使うのがいいと思う。
Re:Linux向けアプリのコンパイル (スコア:1)
clangはただのC/C++/Obj-Cコンパイラですから、GCCなどと同じ.oファイル吐きますよ。元のコメントに「Makefile の CC=gcc を clangに書き換えただけ」と書いてあることから、リンクには（ldを呼び出す）gccが使われていることと思います。
Re: (スコア:0)
移植性については個々の問題になるから置いとくとしても、商業利用は広がる可能性ありますね。
ただLinuxをみてもFreeBSDをみてもGPLフリーになったからといって一般向けに普及が進むとはとても思えないんですが。。
Re:Linux向けアプリのコンパイル (スコア:2)
>>ただLinuxをみてもFreeBSDをみてもGPLフリーになったからといって一般向けに普及が進むとはとても思えないんですが。。
そうですか？例えばAndroidのGPLフリーカーネルとしては魅力的だと思うんですが。
あと、MacOS/XはMachのMach的な部分は殆ど殺しているので、カーネルとユーザーランドの両方をFreeBSDにすることは技術的な困難は（比較的）少なそう。
Linuxは、GCCやGLIBCとカーネルの間に依存関係があるという特異な状況からみて、リデザインの手本にはなるのでは？（ぃゃこの程度が手本になるのでは、こんな状況にはならないな）
Re:Linux向けアプリのコンパイル (スコア:2)
Re: (スコア:0)
FreeBSDでARMをMPで動かすとかどういう苦行を課すつもりなのかと。
＃ARM自体Tier2だしな。
Re:Linux向けアプリのコンパイル (スコア:2)
Jeniperはそれに近いことをMIPSでやってますね。ルーターだけど。
それにARM/MPで動いているのはMacOS/XでなくiOSかと。
Re: (スコア:0)
でもやっぱり携帯系はアンドロイドつかうんじゃないの？
iphoneほど一社が尖ってなくても参入できるし、独自OSだとよっぽどしっかりした会社じゃないとアプリ側が安心して入れないし
Re:Linux向けアプリのコンパイル (スコア:2)
>>でもやっぱり携帯系はアンドロイドつかうんじゃないの？
なのでAndroidのカーネルをGPLv2なLinuxから、BSDLなFreeBSDに差替るのも現実的じゃないかなという話です。
DalvikVMが走ればカーネルなんて何でもいい状況を Google は目指して、ある程度成功しているように観えます。
Re: (スコア:0)
たしかに、そうすればRMSから批判されたり、Androidを採用しているメーカーがソースコードを公開しないと言う不満もせずにすみますからね。それに、Linuxから金を巻き上げるMicrosoftから逃れられるかもしれない。
ただ、そこまでしてAndroidのカーネルをLinuxからBSDにする必要があるとGoogleが考えるかは疑問。
Re:Linux向けアプリのコンパイル (スコア:2)
いくつかある選択肢の１つに考えているというのはありそうですが、短期的にBSDカーネルをAndroidに採用する動機は薄いですね。
独自開発カーネルも含め、Linux以外のOSカーネルの選択肢も少なく無いですし、Android Marketのアプリケーション/サービスに支障が出ない範囲でなら色々な可能性があると思います。
Re: (スコア:0)
> 例えばAndroidのGPLフリーカーネルとしては魅力的だと思うんですが。
も読んでね。
Re: (スコア:0)
え？JuniperってIntel x86でしょ、と思って調べたら、T/Mはx86だけど、EXはARMなんですね。
Re:Linux向けアプリのコンパイル (スコア:4, 参考になる)
Juniper はMIPS64なCavium Octeon を使っており、移植参照コードを寄贈しています。
FreeBSD Daily Topics：2007年12月28日 Juniper NetworksからFreeBSD ProjectへFreeBSD/MIPS移植参照コードを寄贈｜gihyo.jp … 技術評論社 [gihyo.jp]
ソース公開縛り (スコア:1)
GPLのソース公開縛りが無くなるだけでも、知的財産権保護に敏感な組織にとって使いやすくなると思います。
まあ、コミニュティに見返りが無くなるから、それをどうするのかという問題が出てくると思いますが・・・。
Re: (スコア:0)
>コミニュティに見返りが無くなるから、それをどうするのかという問題が出てくると思いますが・・・。
BSDLはただ乗り推奨ライセンスなんだから、しかたないですよ。それを分かった上で許諾しているのですから。
「見返り」を「必ず」要求するのは（他にもありますが、一番きついのは）GPLぐらいしかないので、見返りがほしいと思うならライセンス変えればいいだけ。
どうするもこうするもありません。
ソース以外の見返りってなんですかね？
GPLの自由 (スコア:2)
GPLの自由はエンドユーザーの自由。プログラマじゃ無いよ。
プログラマの得られる見返りは名声ぐらいじゃない？
Re: (スコア:0)
GPLは趣味以外の製造する自由を極端に奪いますよ。
そして、これがGPLの問題点であり、嫌われる点だと考えています。
親会社から製造を委託されているような、ソースコードを公開したくないクローズド場合だってあるのですから、
ライブラリをリンクしただけで無条件に汚染されてしまうのは、意外に不都合は多いものです。
GPLは
自分の成果を他人に取られたくない人達の思いが元のGPLを生み、
他者の成果を食い物にしたいと考えるハゲタカどもが、GPLの性質をどんどん強化するように仕向けていき、
今のひねくれたライセン
Re:GPLの自由 (スコア:2)
GPLって、どうも誤解が多いというか、怖がられすぎなんだよな。
GPLはあくまで、著作物の利用契約。なにも特別なことはない。
自分自身の著作物の利用許諾を得る必要はないのだから、いわゆる「GPL感染」していないソフトウェアの著作者は、それがGPLであっても、次バージョンから勝手にライセンスを変更しても構わない。
「GPL感染」していたとしても、その著作者に相談し、GPL以外のライセンスで使用させてもらえるよう交渉することはできる。
たとえ、GPLを無視してバレても、強制的にGPL適用とはならない。ライセンスなしでソフトウェアを利用していることになり、著作権違反として扱われる。
公開を強要というのも違う。むしろ逆。
公開したなら、その相手に対し、GPLで保障された権利を認めないといけないし、それができないなら公開してはいけない。
1を聞いて0を知れ!
Re:GPLの自由 (スコア:1)
GPLの自由を理解するには、アイザイア・バーリンの有名な分類法を知っておく必要があると思うの。
消極的自由： 縛るものがないこと。○○からの自由。
積極的自由： 望んだ方向へ進んでゆくことができること。○○への自由。
BSDLは消極的自由だと思うの。
誰かに「○○をしなければならない」と命令されることは、自由じゃない。
だから、そういうものをどんどん取り除いていこう。
その先にあるものこそが自由だ…という考え方をしている。
一方、GPLは積極的自由だと思うの。
意図的にルールを決めることで、かえって自由な発展を目指すことができる。
交通ルールがなくなると、大混乱が発生するだろうし、そうすると道路が使い物にならなくなる。
そういう混乱してどうにもならない状況と、交通ルールが守られてどこにでも行こうと思えばいける状況、
どちらが自由だと思う？ …という軸の上で自由を考えている。
ところで、社会のめざすものは消極的自由であるほうが望ましい、というのがバーリンの主張だ。
つまり、個人のレベルではGPLでもBSDLでもどっちでも好きなのを選べばいいし、
社会としては両者を許容する（消極的自由）のが望ましいということだ。
GPLのようなものを許容できないような体制（法律や制度、慣習など）というのは危険だと思うな。
# mishimaは本田透先生を熱烈に応援しています
Re:GPLの自由 (スコア:2)
ユーザになるが実行するという意味であればv3には以下のように明示的に許可されています。
入手できるなどの意味であれば別です。
また、GPLではありませんが、フリーソフトウェアの定義 [gnu.org]には0番目の自由として実行する自由が挙げられています。
“The freedom to run the program, for any purpose (freedom 0).”
Re:GPLの自由 (スコア:1)
GPL汚染が懸念されるのは、他人が取り込むことを前提にしたライブラリの類でのGPLの採用だよ。
一人で作って完結する世界では確かに問題ないけれど、そんな世界ばかりじゃないからね。
それと「たとえ、GPLを無視してバレても、強制的にGPL適用とはならない。ライセンスなしでソフトウェアを利用していることになり、著作権違反として扱われる」筈なのに、強制的にGPL適用しろと主張する勢力がそこらじゅうに存在するのが問題なんだよ。
GPL違反がバレたあと、謝罪と差し替えで解決した例は確かにあるけれど、GPL乞食が騒いだ挙句に半ば強制的にGPL適用となった事例も少なくない。
GPLの何が怖いかって、GPLを肯定する人々の考え方が怖いんだよ。
強制的にGPLを適用させようとする事もそうだし、LGPLを認めない考え方も同じ。
恐ろしい事に、FSFはLGPLを「GPL汚染に使えないから非推奨(意訳)」なんて言っているからね。
挙句の果てにGPLv3だ。GPLを推進する人々の考え方はかなり危ういものだと思う。
にもかかわらず、あまり深く考えずにオープンソース＝GPLって考えでGPLライセンスを適用する人は多い。
この安易なGPLの利用って現状と、FSFの危うさと、GPL乞食の存在。
GPLは怖いライセンスだといわざるを得ないと思う。
Re:GPLの自由 (スコア:1)
んなもん、法的根拠がなけりゃほっときゃいい。
1を聞いて0を知れ!
Re:ソース公開縛り (スコア:2)
>ソース以外の見返りってなんですかね？
開発への寄付。
The FreeBSD Foundation [freebsdfoundation.org]
The NetBSD Foundation [netbsd.org]
The OpenBSD Project [openbsd.org]
そういえばそろそろ年末の募金呼びかけがありそうな時期だな
Re:ソース公開縛り (スコア:1)
わかりやすいドキュメントを作ることかな？
各国語版で。
Re: (スコア:0)
GPLから脱したら「利用はするけどコードをコミットしてくれなくなる」って利用者増えるし
FreeBSDだって奴隷じゃねーんだからちょっとは見返りが欲しいでしょ
なんで、それで「さもしい」ってはなしになるんだ？
しかもGPLから脱した時の話のなのにGPLが嫌われちゃってるよ
GPL憎しだと「GPLから脱した団体が成果物に見返りを求めることの算段をする」ことは
さもしくもGPLのせいみたいだね
しかも下の方じゃ共産主義呼ばわりだよ
Re: (スコア:0)
おもちゃ呼ばわりして見下していたLinuxにあっさり追い抜かれた
FreeBSD信者の積年の恨みを晴らすときが来たってことだよ
察してあげて生暖かく見守っていてあげてください
Re: (スコア:0)
コミュニティの成果を使用するなら、お前の成果もコミュニティに還元しろって
極めて対等かつ合理的でドライな考え方だと思うが違うのか？
MSがKerberosでやったことを止められなかったように
BSDライセンスは頭の中がお花畑だ
Re: (スコア:0)
共産主義はすべてを国家がコントロールするが
GPLはすべてを1個人がコントロールできる
Linuxが流行りだした頃にグゥの音も出ないほど反論されつくしたのに
今さら共産主義とか引っ張り出してくる親コメはバカなの
Re: (スコア:0)
お前無知だな。
>共産主義はすべてを国家がコントロールする
それは社会主義。
共産主義というのは経済体制の１つだぞ、と。
Re: (スコア:0)
他者の成果を自分が利用するのは当然であり
自分の成果を他者に提供するのは嫌だとダダをこねる
他者のしていることに想像力が及ばないのは完全にガキの思考
いい歳してドヤ顔しているお前の方がよほど気持ち悪い
Re: (スコア:0)
共産主義が気持ち悪いと言っている訳でGPLが気持ち悪いと言う訳ではないのだが。
しかし、共産主義国家で「気持ち悪い」と思わない国家があるのだろうか。
# あんまり共産主義に深入りすると監視されるぞ。
Re:Linux向けアプリのコンパイル (スコア:1)
商業利用が増えるのかと言われればちょっと疑問です。
たとえばFreeBSDで、Oracleが利用できるようになったら確実に増えてくれるんじゃないかと思うのですがね。
さすがにライセンスが変わったくらいだと増える見込みはすくないかなーと。
FreeBSDの利用は提案したことありますが
さすがに、DBサーバーだけLinuxにするという選択肢はないらしい。
(どうせSQL*Netでつなぐだけなのに。)
せっかく、多機能なパケットフィルタとかJailとかあるのに残念。
#ZFSは、商用だとちょっと微妙。
#障害復旧のノウハウがないし、まだ安定していないイメージ
Re:Linux向けアプリのコンパイル (スコア:1)
かなり昔 (まだ RedHat Linux が RHEL になる前) の Oracle for Linux なんかだと、FreeBSD の linuxulator 使ってあっさり動いたりしてたので、周辺含めて環境整えるのは (慣れてる) FreeBSD の方が圧倒的に楽だった……なんて事はありました。
# color ls の設定をオフにしたり……とかいうレベルまで含めての「周辺含めての環境整備」。
開発向けに内部で使う分にはこれでもいいのかな、という感じでしたね。その時は実際それで開発作業やってましたし。
さすがに商用サポートなしはありえないので、運用環境に FreeBSD + Oracle Database Server とか無理ですけど。
Re: (スコア:0)
コンパイルできるならばあまり問題にならないような（最悪独自コーディングすればいいのだし）。
問題は「コンパイル済みでソースがないバイナリ」って商用製品ですが、それも問題あるかどうか始まってみないと分からない。
いままでもLinuxABIとかがあったはずなので、「今迄も」「これからも」変わらないような気がする。
#OpenBSD/Ubuntu/Debian使いより。
Re: (スコア:0)
ports/packageの対応状況が参考になるかもしれませんね。
core 以上に雑多な世界ですし。
Re:Linux向けアプリのコンパイル (スコア:4, 参考になる)
ports/packagesをClangでビルドしてみると、GCC独自拡張を使っているという意味でのGCC依存はありますね。
GNU-toolchain というと gcc/binutils(含むgas etc)/gdbを思い浮かべますが、automake/autoconf/libtool あたりも含めて対応しないとcoreはともかく、ports/packagesは色々問題に遭遇します。
64bit対応の時も様々な問題に遭遇しましたが、先を見通していないコード探しという意味で似た特徴を持っています。
Re: (スコア:0)
OpenBSDはlibtoolを独自実装していたはずだし
Makefile/configureは再生成しなけりゃいいと考えると
残る問題はbinutilsぐらいじゃないでしょうか
Re:Linux向けアプリのコンパイル (スコア:2, 興味深い)
binutils相当品はllvmに含まれてると言っていい
http://llvm.org/docs/CommandGuide/index.html [llvm.org]
やっぱり (スコア:2)
BSDならBSDライセンスじゃないとね！（根拠なし）
GPLライセンスを取り除く取組み＝BSDライセンスに統一する取組み
という理解でいいのかな？
どちらにしろ、新しいかつ優秀なコンパイラに変わるのは良いことだね。
＃ただ、マニュアルの日本語化とか、参考文献の少なさが問題になりそうだけど。。。
Re:やっぱり (スコア:1)
> GPLライセンスを取り除く取組み＝BSDライセンスに統一する取組みという理解でいいのかな？
ちがう。
MIT Licenseとか、緩めのライセンスは普通に使われてる。
他にも、例えばタレコミ文にもあるLLVMなんかはUIUC Licenseだったり。
これは (スコア:1)
これはオープンソースのGPL離れ
Re:これは (スコア:1)
#2027924 [srad.jp]にもあるように、脱・GPLがトレンドとなるだろうね。
少なくとも危険でデメリットしかないGPLv3を選ぶ企業は皆無だし。
ソフトウェアは産業であって、その産業を牽引している者は企業が大多数なんだよね。
それら企業の活動を妨げるライセンスなんて、到底受け入れられる訳がない。
結局のところ (スコア:0)
FreeBSD=SYSTEM
Linux=Kernel
GNU Tools=UserLand
これらの区別すら出来ない人々が、何を言っても説得力は無い。
Re: (スコア:0)
> Linux=Kernel
確かにそうなんだけど、Linuxカーネルを中心としたSYSTEMとして扱っていいんでは？
※ディストリビューションは色々あるけどね
スラドの記事でも"Linux"はカーネル自体を指すよりSYSTEMとして"Linux"って言ってることが多いし、実際問題としてKernelに限定する必要は無いと思うよ。
Re:結局のところ (スコア:1)
だからSYSTEMとして見るならGNU/Linuxってことでしょ. 同様にGNU/kFreeBSD [debian.org]だってあるんだから.