アカウント名:
パスワード:
ユーザーとしては、Linux向けアプリケーションのコンパイルや移植で問題がないのかが心配です。FreeBSDって、とても使いやすやすいOSだと思います。GPLフリーになることで商業利用が進んで一般向けに普及が進むのか、ライブラリなどのLinuxとの互換性低下で移植などに支障が出るのかが、が問題ですよね。
clangってコンパイラーはじめて聞いたので早速試してみたけど、Makefile の CC=gcc を clangに書き換えただけで適当にダメ元で試したら、意外と動くのが多くて驚いた。
__attrubute__(aligned((16))); みたいなGCC方言が入っててもコンパイル通ったけど、インラインアセンブラでSSEのアライメント依存の命令を使ってるのだと正常に動作しないのがあった。
__sync_fetch_などのアトミック操作のGCC方言も普通に使われてるけど、これは動いた。
よくわからないけど、予想以上に多くのソースが無難に通った。あとコンパイル速度がGCCより倍ぐらい速く感じた。
あとvoid main() がエラーになる。警告じゃなくて。f(int a){ return a; } だと警告になる。gccよりくちうるさい。
GCC方言使ってても通るってのが意外すぎて驚いた。アップルすごい。
LLVMなんだから、
・コンパイルの速度は速くなる・バイナリのサイズは小さくなる・実行時の速度は遅くなる
のは、原理的に当たり前では?MacはGCCを4.2で止めているから、世代的な意味で速度でもいい勝負になるかもってだけで。ただ、中間コードのせいでバイナリ互換性がでたりすると恐ろしいとは思うけど、現状では開発でclangを使ってチューンと製品用にはgccを使うのがいいと思う。
clangはただのC/C++/Obj-Cコンパイラですから、GCCなどと同じ.oファイル吐きますよ。元のコメントに「Makefile の CC=gcc を clangに書き換えただけ」と書いてあることから、リンクには(ldを呼び出す)gccが使われていることと思います。
移植性については個々の問題になるから置いとくとしても、商業利用は広がる可能性ありますね。ただLinuxをみてもFreeBSDをみてもGPLフリーになったからといって一般向けに普及が進むとはとても思えないんですが。。
>>ただLinuxをみてもFreeBSDをみてもGPLフリーになったからといって一般向けに普及が進むとはとても思えないんですが。。
そうですか?例えばAndroidのGPLフリーカーネルとしては魅力的だと思うんですが。
あと、MacOS/XはMachのMach的な部分は殆ど殺しているので、カーネルとユーザーランドの両方をFreeBSDにすることは技術的な困難は(比較的)少なそう。
Linuxは、GCCやGLIBCとカーネルの間に依存関係があるという特異な状況からみて、リデザインの手本にはなるのでは?(ぃゃこの程度が手本になるのでは、こんな状況にはならないな)
FreeBSDでARMをMPで動かすとかどういう苦行を課すつもりなのかと。#ARM自体Tier2だしな。
Jeniperはそれに近いことをMIPSでやってますね。ルーターだけど。それにARM/MPで動いているのはMacOS/XでなくiOSかと。
でもやっぱり携帯系はアンドロイドつかうんじゃないの?iphoneほど一社が尖ってなくても参入できるし、独自OSだとよっぽどしっかりした会社じゃないとアプリ側が安心して入れないし
>>でもやっぱり携帯系はアンドロイドつかうんじゃないの?
なのでAndroidのカーネルをGPLv2なLinuxから、BSDLなFreeBSDに差替るのも現実的じゃないかなという話です。DalvikVMが走ればカーネルなんて何でもいい状況を Google は目指して、ある程度成功しているように観えます。
たしかに、そうすればRMSから批判されたり、Androidを採用しているメーカーがソースコードを公開しないと言う不満もせずにすみますからね。それに、Linuxから金を巻き上げるMicrosoftから逃れられるかもしれない。
ただ、そこまでしてAndroidのカーネルをLinuxからBSDにする必要があるとGoogleが考えるかは疑問。
いくつかある選択肢の1つに考えているというのはありそうですが、短期的にBSDカーネルをAndroidに採用する動機は薄いですね。
独自開発カーネルも含め、Linux以外のOSカーネルの選択肢も少なく無いですし、Android Marketのアプリケーション/サービスに支障が出ない範囲でなら色々な可能性があると思います。
> 例えばAndroidのGPLフリーカーネルとしては魅力的だと思うんですが。も読んでね。
Juniper はMIPS64なCavium Octeon を使っており、移植参照コードを寄贈しています。
FreeBSD Daily Topics:2007年12月28日 Juniper NetworksからFreeBSD ProjectへFreeBSD/MIPS移植参照コードを寄贈|gihyo.jp … 技術評論社 [gihyo.jp]
Juniper gives FreeBSD/MIPS current - 2007年12月25日(米国時間),Juniper NetworksはThe FreeBSD Projectに対してFreeBSDのMIPSアーキテクチャへの移植版を寄贈しました。FreeBSDのMIPS移植に対する参照実装として扱われるようになります。参照実装はこちらのサイト [freebsd.org]にて閲覧できます。今のところリリースはi386,amd64,ia64,pc98,powerpc,sparc64アーキテクチャ向けが用意されています。今回Juniper NetworksからMIPS移植の参照実装が提供されたことで,移植作業が進めばプロジェクトのサポートアーキテクチャにMIPSが追加されることになります。
current - 2007年12月25日(米国時間),Juniper NetworksはThe FreeBSD Projectに対してFreeBSDのMIPSアーキテクチャへの移植版を寄贈しました。FreeBSDのMIPS移植に対する参照実装として扱われるようになります。参照実装はこちらのサイト [freebsd.org]にて閲覧できます。
今のところリリースはi386,amd64,ia64,pc98,powerpc,sparc64アーキテクチャ向けが用意されています。今回Juniper NetworksからMIPS移植の参照実装が提供されたことで,移植作業が進めばプロジェクトのサポートアーキテクチャにMIPSが追加されることになります。
GPLのソース公開縛りが無くなるだけでも、知的財産権保護に敏感な組織にとって使いやすくなると思います。まあ、コミニュティに見返りが無くなるから、それをどうするのかという問題が出てくると思いますが・・・。
>コミニュティに見返りが無くなるから、それをどうするのかという問題が出てくると思いますが・・・。BSDLはただ乗り推奨ライセンスなんだから、しかたないですよ。それを分かった上で許諾しているのですから。「見返り」を「必ず」要求するのは(他にもありますが、一番きついのは)GPLぐらいしかないので、見返りがほしいと思うならライセンス変えればいいだけ。どうするもこうするもありません。
ソース以外の見返りってなんですかね?
GPLの自由はエンドユーザーの自由。プログラマじゃ無いよ。プログラマの得られる見返りは名声ぐらいじゃない?
GPLって、どうも誤解が多いというか、怖がられすぎなんだよな。GPLはあくまで、著作物の利用契約。なにも特別なことはない。
自分自身の著作物の利用許諾を得る必要はないのだから、いわゆる「GPL感染」していないソフトウェアの著作者は、それがGPLであっても、次バージョンから勝手にライセンスを変更しても構わない。「GPL感染」していたとしても、その著作者に相談し、GPL以外のライセンスで使用させてもらえるよう交渉することはできる。たとえ、GPLを無視してバレても、強制的にGPL適用とはならない。ライセンスなしでソフトウェアを利用していることになり、著作権違反として扱われる。
公開を強要というのも違う。むしろ逆。公開したなら、その相手に対し、GPLで保障された権利を認めないといけないし、それができないなら公開してはいけない。
GPLの自由を理解するには、アイザイア・バーリンの有名な分類法を知っておく必要があると思うの。
消極的自由: 縛るものがないこと。○○からの自由。積極的自由: 望んだ方向へ進んでゆくことができること。○○への自由。
BSDLは消極的自由だと思うの。誰かに「○○をしなければならない」と命令されることは、自由じゃない。だから、そういうものをどんどん取り除いていこう。その先にあるものこそが自由だ…という考え方をしている。
一方、GPLは積極的自由だと思うの。意図的にルールを決めることで、かえって自由な発展を目指すことができる。交通ルールがなくなると、大混乱が発生するだろうし、そうすると道路が使い物にならなくなる。そういう混乱してどうにもならない状況と、交通ルールが守られてどこにでも行こうと思えばいける状況、どちらが自由だと思う? …という軸の上で自由を考えている。
ところで、社会のめざすものは消極的自由であるほうが望ましい、というのがバーリンの主張だ。つまり、個人のレベルではGPLでもBSDLでもどっちでも好きなのを選べばいいし、社会としては両者を許容する(消極的自由)のが望ましいということだ。GPLのようなものを許容できないような体制(法律や制度、慣習など)というのは危険だと思うな。
GPLのコードを使わなければ良いだけでは? 他人の作ったコードは、基本的に勝手には使えないものです。本来使えない物がある制限の下で使わせてもらえると言うだけですから、何も損はしていません。
あと、GPLはユーザーがソースコードにアクセスできる(=プログラマとして振る舞える)自由です。ユーザーになれる自由は保証していません。(v3は知りません)
自分の成果を他人に取られたくない人達の思いが元のGPLを生み、 他者の成果を食い物にしたいと考えるハゲタカどもが、GPLの性質をどんどん強化するように仕向けていき、
今、GPLを担いでいる人に対する印象ってのはまあ人それぞれだろうから色々思う人がいても不思議はないけれど、 元のGPLは「ベンダーが利用者に不便を押し付けてはいけない」って思いで出来たんだから、逆でしょう。 「ベンダーがさぼってても利用者がどんどん成果を共有してみんなでハッピーになろうぜ」っていう思想ですよ。 (ここでの「利用者」は、エンドユーザのこと)。
話が
GPLのコードを使わなければ良いだけでは?
だから使わないようにする(脱GPL)って話ですよ、元々
「公開」という言葉で成果物の配布と、ソースの開示が混同されませんか?
ユーザになるが実行するという意味であればv3には以下のように明示的に許可されています。
2. Basic Permissions.(中略)This License explicitly affirms your unlimited permission to run the unmodified Program.
入手できるなどの意味であれば別です。
また、GPLではありませんが、フリーソフトウェアの定義 [gnu.org]には0番目の自由として実行する自由が挙げられています。“The freedom to run the program, for any purpose (freedom 0).”
GPL汚染が懸念されるのは、他人が取り込むことを前提にしたライブラリの類でのGPLの採用だよ。一人で作って完結する世界では確かに問題ないけれど、そんな世界ばかりじゃないからね。
それと「たとえ、GPLを無視してバレても、強制的にGPL適用とはならない。ライセンスなしでソフトウェアを利用していることになり、著作権違反として扱われる」筈なのに、強制的にGPL適用しろと主張する勢力がそこらじゅうに存在するのが問題なんだよ。GPL違反がバレたあと、謝罪と差し替えで解決した例は確かにあるけれど、GPL乞食が騒いだ挙句に半ば強制的にGPL適用となった事例も少なくない。
GPLの何が怖いかって、GPLを肯定する人々の考え方が怖いんだよ。強制的にGPLを適用させようとする事もそうだし、LGPLを認めない考え方も同じ。恐ろしい事に、FSFはLGPLを「GPL汚染に使えないから非推奨(意訳)」なんて言っているからね。挙句の果てにGPLv3だ。GPLを推進する人々の考え方はかなり危ういものだと思う。にもかかわらず、あまり深く考えずにオープンソース=GPLって考えでGPLライセンスを適用する人は多い。この安易なGPLの利用って現状と、FSFの危うさと、GPL乞食の存在。
GPLは怖いライセンスだといわざるを得ないと思う。
んなもん、法的根拠がなけりゃほっときゃいい。
> GPLの自由はエンドユーザーの自由。プログラマじゃ無いよ。
どっちかというと、
GPLの自由 = ソースコードの自由BSDの自由 = 利用者の自由
の方が正確かも。
何で?GPLだって他人に渡さなきゃソースコードを開示する必要はないし、ソースコードの自由といわれても納得いかんな。BSDの方がロックインすることもできるしエンドユーザーには不便だぜ?
私はGPLを自由なライセンスとは認識していません。GPLは反独占ライセンスです。
>ソース以外の見返りってなんですかね?
開発への寄付。The FreeBSD Foundation [freebsdfoundation.org]The NetBSD Foundation [netbsd.org]The OpenBSD Project [openbsd.org]
そういえばそろそろ年末の募金呼びかけがありそうな時期だな
わかりやすいドキュメントを作ることかな?各国語版で。
GPLから脱したら「利用はするけどコードをコミットしてくれなくなる」って利用者増えるしFreeBSDだって奴隷じゃねーんだからちょっとは見返りが欲しいでしょなんで、それで「さもしい」ってはなしになるんだ?
しかもGPLから脱した時の話のなのにGPLが嫌われちゃってるよGPL憎しだと「GPLから脱した団体が成果物に見返りを求めることの算段をする」ことはさもしくもGPLのせいみたいだねしかも下の方じゃ共産主義呼ばわりだよ
おもちゃ呼ばわりして見下していたLinuxにあっさり追い抜かれたFreeBSD信者の積年の恨みを晴らすときが来たってことだよ察してあげて生暖かく見守っていてあげてください
コミュニティの成果を使用するなら、お前の成果もコミュニティに還元しろって極めて対等かつ合理的でドライな考え方だと思うが違うのか?
MSがKerberosでやったことを止められなかったようにBSDライセンスは頭の中がお花畑だ
GPLが見返りを強制して「極めて対等かつ合理的でドライ」と豪語するのは勝手だけれどそういう態度を取らない(価値観の違う)BSDを「頭の中がお花畑」なんてけなす必要があるのか?
共産主義はすべてを国家がコントロールするがGPLはすべてを1個人がコントロールできる
Linuxが流行りだした頃にグゥの音も出ないほど反論されつくしたのに今さら共産主義とか引っ張り出してくる親コメはバカなの
お前無知だな。>共産主義はすべてを国家がコントロールするそれは社会主義。共産主義というのは経済体制の1つだぞ、と。
他者の成果を自分が利用するのは当然であり自分の成果を他者に提供するのは嫌だとダダをこねる
他者のしていることに想像力が及ばないのは完全にガキの思考いい歳してドヤ顔しているお前の方がよほど気持ち悪い
共産主義が気持ち悪いと言っている訳でGPLが気持ち悪いと言う訳ではないのだが。しかし、共産主義国家で「気持ち悪い」と思わない国家があるのだろうか。
# あんまり共産主義に深入りすると監視されるぞ。
かなり昔 (まだ RedHat Linux が RHEL になる前) の Oracle for Linux なんかだと、FreeBSD の linuxulator 使ってあっさり動いたりしてたので、周辺含めて環境整えるのは (慣れてる) FreeBSD の方が圧倒的に楽だった……なんて事はありました。
# color ls の設定をオフにしたり……とかいうレベルまで含めての「周辺含めての環境整備」。
開発向けに内部で使う分にはこれでもいいのかな、という感じでしたね。その時は実際それで開発作業やってましたし。 さすがに商用サポートなしはありえないので、運用環境に FreeBSD + Oracle Database Server とか無理ですけど。
某メーカの組み込み屋ですが、商業利用シーンではGPL v3で盛り込まれた特許やDRM関連条項によってBSDライセンスなどのGPL以外のOSSの見直しが行われているところで、Androidの脱GPLライセンスの動きや今回の件の動きもある意味その一貫と見えてます。
> ライセンスが変わったからといって、> 商業利用が増えるのかと言われればちょっと疑問です。
第三者がライセンス変更により乗り換えるかどうかは問題じゃなくって、そもそも商業利用したい連中がライセンスを変えようとしているのでは?# 「原因と結果」というよりも、「手段と目的」というか。
少なくとも目的に対して悪くない手段だと私は思ってますよ。
コンパイルできるならばあまり問題にならないような(最悪独自コーディングすればいいのだし)。問題は「コンパイル済みでソースがないバイナリ」って商用製品ですが、それも問題あるかどうか始まってみないと分からない。いままでもLinuxABIとかがあったはずなので、「今迄も」「これからも」変わらないような気がする。
#OpenBSD/Ubuntu/Debian使いより。
ports/packageの対応状況が参考になるかもしれませんね。core 以上に雑多な世界ですし。
ports/packagesをClangでビルドしてみると、GCC独自拡張を使っているという意味でのGCC依存はありますね。
GNU-toolchain というと gcc/binutils(含むgas etc)/gdbを思い浮かべますが、automake/autoconf/libtool あたりも含めて対応しないとcoreはともかく、ports/packagesは色々問題に遭遇します。
64bit対応の時も様々な問題に遭遇しましたが、先を見通していないコード探しという意味で似た特徴を持っています。
OpenBSDはlibtoolを独自実装していたはずだしMakefile/configureは再生成しなけりゃいいと考えると残る問題はbinutilsぐらいじゃないでしょうか
binutils相当品はllvmに含まれてると言っていいhttp://llvm.org/docs/CommandGuide/index.html [llvm.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
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)
いくつかある選択肢の1つに考えているというのはありそうですが、短期的に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: (スコア:0)
GPLのコードを使わなければ良いだけでは? 他人の作ったコードは、基本的に勝手には使えないものです。本来使えない物がある制限の下で使わせてもらえると言うだけですから、何も損はしていません。
あと、GPLはユーザーがソースコードにアクセスできる(=プログラマとして振る舞える)自由です。ユーザーになれる自由は保証していません。(v3は知りません)
Re: (スコア:0)
今、GPLを担いでいる人に対する印象ってのはまあ人それぞれだろうから色々思う人がいても不思議はないけれど、 元のGPLは「ベンダーが利用者に不便を押し付けてはいけない」って思いで出来たんだから、逆でしょう。 「ベンダーがさぼってても利用者がどんどん成果を共有してみんなでハッピーになろうぜ」っていう思想ですよ。 (ここでの「利用者」は、エンドユーザのこと)。
話が
Re: (スコア:0)
GPLのコードを使わなければ良いだけでは?
だから使わないようにする(脱GPL)って話ですよ、元々
Re: (スコア:0)
公開を強要というのも違う。むしろ逆。
公開したなら、その相手に対し、GPLで保障された権利を認めないといけないし、それができないなら公開してはいけない。
「公開」という言葉で成果物の配布と、ソースの開示が混同されませんか?
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: (スコア:0)
> GPLの自由はエンドユーザーの自由。プログラマじゃ無いよ。
どっちかというと、
GPLの自由 = ソースコードの自由
BSDの自由 = 利用者の自由
の方が正確かも。
Re: (スコア:0)
何で?
GPLだって他人に渡さなきゃソースコードを開示する必要はないし、
ソースコードの自由といわれても納得いかんな。
BSDの方がロックインすることもできるしエンドユーザーには不便だぜ?
Re: (スコア:0)
私はGPLを自由なライセンスとは認識していません。
GPLは反独占ライセンスです。
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が見返りを強制して「極めて対等かつ合理的でドライ」と豪語するのは勝手だけれど
そういう態度を取らない(価値観の違う)BSDを「頭の中がお花畑」なんてけなす必要があるのか?
Re: (スコア:0)
共産主義はすべてを国家がコントロールするが
GPLはすべてを1個人がコントロールできる
Linuxが流行りだした頃にグゥの音も出ないほど反論されつくしたのに
今さら共産主義とか引っ張り出してくる親コメはバカなの
Re: (スコア:0)
お前無知だな。
>共産主義はすべてを国家がコントロールする
それは社会主義。
共産主義というのは経済体制の1つだぞ、と。
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)
某メーカの組み込み屋ですが、商業利用シーンではGPL v3で盛り込まれた特許やDRM関連条項によって
BSDライセンスなどのGPL以外のOSSの見直しが行われているところで、Androidの脱GPLライセンスの動きや
今回の件の動きもある意味その一貫と見えてます。
> ライセンスが変わったからといって、
> 商業利用が増えるのかと言われればちょっと疑問です。
第三者がライセンス変更により乗り換えるかどうかは問題じゃなくって、
そもそも商業利用したい連中がライセンスを変えようとしているのでは?
# 「原因と結果」というよりも、「手段と目的」というか。
少なくとも目的に対して悪くない手段だと私は思ってますよ。
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]