アカウント名:
パスワード:
ベータリリースの時点で,そのために社内のリソースをさく余裕が無いってのは,わかる気がします。
そう。よくわかります。
> 「後で公開するよ」と言いつつ、旬を過ぎてから公開。 ランセンス上の是非は別にして、私はそれでも十分かなと思うのです。
多くのフリーソフトウェア作者があまり深く考えずにライセンスを選択してるであろう状況なので、まぁテキトーでえ~やんみたいな感じ
このへん [geocities.co.jp]かな? もっといい用語集があった気もするけど、詳しくないのでこれで許して。
ところで上のコメント [srad.jp]、Funny!(^^
GPLの下にあるもの(例えばLinuxカーネルのコード)を使ったら、 そこから派生したものはGPLに基づかなくてはいけません。
GPL原理主義的立場で言えば、「free software」を「open source software」と言い換えたことは、ある意味「甘やかし」だと思いますよ。
だから、後でちゃんと出すって言ってんだから勘弁してやれと思うわけです。 出さないなんて言ってないし、GPLでも「ソース出せ」とは書いてあっても、 「すぐ出せ」とか「○日以内に出せ」とは書いてないんだし。
ふーん。 じゃあ「百万年後に出すからそれまで待ってね」でもいいのか。
一方、開発事情で、βでは使い慣れた社内謹製ライブラリを使用しているが、社外に出したくないので正式版では簡易版を使うことにしよう、でも今は手が回らない!とかあるかもしれない。 ここで、そのライブラリが使い慣れた市販品のライブラリだった場合、それを販売している会社にソースを出せとは言えないのではないか。そして、その市販品というのが実は自社が販売している商品だとしたら。 結局は「混ぜるな、危険!」な結論になりそうだが。
ソースのコメントも、余分なコメントという印を付けておいて、 awk で一括削除とかすればいいし。スタイルもこれは結局慣れだから、GPL で公開する予定ならば、最初から BSD スタイルで書く、 とか実行すれば結構馴染めてしまうものだ。
現在仕事で書いているソースを明日公開するからね、と言われて、まずいよ待って下さい、という要素は僕の場合は皆無です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
しっかし・・・ (スコア:2, 参考になる)
「現在のリリースは試作品であり、 最初のリリースは今年の半ばだと思う。そのときには、全てのGPLコードは 正しく配布される」
この段階でGPLに著しく違反してるように思えるのは僕だけでしょうか?
一応GPLってバイナリーを入手したユ
気持ちはわかる (スコア:0, 興味深い)
でも、会社で開発したソフトウェアって、権利関係を別にしても、ソースを公開するのって、なかなか大変です。簡単に言えば、「他人様に見せられるように整理する」ってのは楽じゃない。自作のソフトウェアを適当にftpに置くのとは、違った手間もか
Re:気持ちはわかる (スコア:1)
ホットワイアードの記事,『コーレルLinux』のライセンス条件に抗議の声」 [hotwired.co.jp]で,同様のトラブルが報告されています。
この例では「既存のLinuxコードに付け足した、同社独自のコードの配布を予防するため」の措置が誤解を生んで顰蹙を買った。ということらしいんですが,そうじゃなくて「同社独自のコードを配布しない」のが,不届き千番,つうことなのかな?
斜点是不是先進的先端的鉄道部長的…有信心
Re:気持ちはわかる (スコア:1, 参考になる)
そう。よくわかります。
ベータ版だろうがバイナリを公開したらソースも公開しなきゃいけない [gnu.org]んだから、ソース公開のためのリソースがなければベータリリースしなきゃいいだけですよね。仕事のコードだと (スコア:1)
だから、後でちゃんと出すって言ってんだから勘弁してやれと思うわけです。出さないなんて言ってないし、GPLでも「ソース出せ」とは書いてあっても、「すぐ出せ」とか「○日以内に出せ」とは書いてないんだし。
Re:仕事のコードだと (スコア:0)
Re:仕事のコードだと (スコア:1)
> #思いますか?(^^;
うーむ。「素晴しい洞察」 B)
FSFって、ある種「厨房」なところが存在意義でもあるので、FSFの態度としては正しいのでしょうね。ただ、その尻馬に乗ってソースソースと、この世界の連中が厨房化するのはどうしたものか。Linusはそーゆー「厨房さ加減」を持ってなかったからLinuxがここまで普及したとも言えるわけで。
> 「後で公開するよ」と言いつつ、旬を過ぎてから公開。
ランセンス上の是非は別にして、私はそれでも十分かなと思うのです。いかにGPLだとは言え、オリジナルからforkするのはなかなか容易ではないから、「参考にするためのコード」があれば十分なこともあるわけで。もちろん新鮮な方が嬉しいですけど、腐ってしまうよりはいいかなと。
Re:仕事のコードだと (スコア:0)
多くのフリーソフトウェア作者があまり深く考えずにライセンスを選択してるであろう状況なので、まぁテキトーでえ~やんみたいな感じ
Re:仕事のコードだと (スコア:0)
Re:仕事のコードだと (スコア:1)
(オフトピ:-1)
Re:仕事のコードだと (スコア:0)
>> 少なくとも俺ならそういうのを許すくらいなら最初から GPL を選択しないです。GPL 以外にも選択肢があるわけですからねぇ。
という風な立場でBSDとか別のライセンスを選んでいる、という印象がありますね。僕の気のせいかもしれませんが、GPLを選択しているのって、
Re:仕事のコードだと (スコア:0)
このへん [geocities.co.jp]かな?
もっといい用語集があった気もするけど、詳しくないのでこれで許して。
ところで上のコメント [srad.jp]、Funny!(^^
ライセンスを変えることはできません (スコア:0)
GPLの下にあるもの(例えばLinuxカーネルのコード)を使ったら、 そこから派生したものはGPLに基づかなくてはいけません。
それがいやなら・・・最初からフルスクラッチで書くことですな。Re:仕事のコードだと (スコア:0)
本当にGPLを読んでますか?
3項(訳文4項)の(a)および(b)を読む限り((c)は今回のケースでは関係なし)、バイナリの頒布を開始した時点でソースコードの配布が可能になっていなければならないとしか解釈できませんよ。
Re:仕事のコードだと (スコア:1)
一見厳密に見えて、よく見るとそういった細かい穴があるのがGPLだったりするわけ。契約文書と言うよりは、「紳士協定覚え書き」のレベルだから、いろいろと思ったりやったりはあるでしょうよ。
今回の例で言えば、「どっちもどっち」ではないかな。個人的意見としては、GPLって言ってんだから、さっさと出してよと思うけど、それよりは早く品質上げろよとも思う。でも、「解釈」はそれとは別のこと。
Re:仕事のコードだと (スコア:2)
だから、「配布が可能になっている」と「実際にすぐ配布出来る」とは、厳密に同じじゃないでしょ。「可能なんだけど、今手が回りません」なことだってあるのだし。
一見厳密に見えて、よく見るとそういった細かい穴があるのがGPLだったりするわけ。契約文書と言うよりは、「紳士協定覚え書き」のレベルだから、いろいろと思ったりやったりはあるでしょうよ。
今回の例で言えば、「どっちもどっち」ではないかな。個人的意見としては、GPLって言ってんだから、さっさと出してよと思うけど、それよりは早く品質上げろよとも思う。でも、「解釈」はそれとは別のこと。
それもふまえて準備する必要性がLindows側にあったのではないでしょうか?
バイナリーは準備出来てSourceが準備出来ないと言うのはただの言い逃れにしか思えません。
その部分はogochanさんならわかると思うのは私だけでしょうか?
また、GPLのライセンスの部分は確かに紳士協定に近いものかもしれません。
ただ今回のことのような事が悪い例となり、他の企業まで同じ事をやり始めないかちょっと心配です。
やはり人間の心情としてわかる部分であってもLindowsは企業体で行っているわけですから、企業側を甘やかす言い分は見ていて気持ちのいいものではありません。
企業体は何らかの収益をあげる団体であるわけですから、自分らの都合のいいように何事も解釈しがちです。
が、それを許す事はGPLの意味において良いことにはならないだろうと思います。
Re:仕事のコードだと (スコア:1)
やってくれたら嬉しいじゃん。ベータの時は我慢するにしても、配布版が出たら、ソースソースと言えるんだから。
> 企業側を甘やかす言い分は見ていて気持ちのいいものではありません。
ちょっと甘やかすだけで得るものがいっぱいあるなら、私は甘やかす方を取るけどな。まぁこれはGPL云々とは関係ない話だったりしちゃうけどね。
GPL原理主義的立場で言えば、「free software」を「open source software」と言い換えたことは、ある意味「甘やかし」だと思いますよ。だけど、それでコミュニティが得たものは大きいです。GPLを厳密に云々ということを離れれば、それも戦略だと思います。
Re:仕事のコードだと (スコア:1)
Re: 仕事のコードだと (スコア:0)
ふーん。
じゃあ「百万年後に出すからそれまで待ってね」でもいいのか。
Re: 仕事のコードだと (スコア:1)
こんな無駄なことやってる間にコードを書こうよ、プログラマ諸君。
GPL とはそういうもんです (スコア:0)
GPL をよく読んで、まさしく FSF の考える通りの意図で GPL を
選択したオリジナル作者さんとか、GPL だからパッチを寄贈しようと思った方が、もしこのような事例にあったらどうします?悪しき前
Re:GPL とはそういうもんです (スコア:1)
「なんでもかんでも」というつもりはありません。猶予期間として半年、あるいは一年、が妥当かという議論なら全然有意義でしょうけどね。「百万年」とか言い出すのは単なるガキです。現実問題として誰も「百万年後にソース公開」と言ってる人はいない。それは認めるでしょ?そして、
>GPL のそういう性質を嫌って(中略)という事の意味を考えたほうがいいんじゃないですかね。
非常に同感です。GPLを運用する際に「大人の対応」をすればもっと嫌う人は減るんじゃないかな、とは思うんですけどね。
Re:GPL とはそういうもんです (スコア:1)
それは思わないでもないのだけど、GPLってのは「理念」で、その理念を徹底させるためには、厨房と言われようが何だろうが、強く主張するという態度が、少なくとも源流には必要であるのも事実です。周囲は適当に「大人の理解」をしながら、ソフトランディングを目指せばいいのですけどね。
他人事的に見れば、件の騒動は「いいところで争っているな」と思います B)
Re:気持ちはわかる (スコア:1)
でもさ、せっかく(?)のGPLなんだから、
「これはベータ版だ。てめぇら覚悟してダウソしろ」
と一言言いそえたうえで公開すればそれで良いというか、
そうして公開されたものにイチャモンつけるのは
フリーソフトならば逆に変なわけで、
つまりは、既存の「商習慣」とは違うノリだけど、皆さんよろしくね、
ということでしかないと思うんです。
#GPLの性質からして、ベータ版であっても、それにGPL汚染に耐えられないコードが
#混入してるという心配は、する必要がない(心配が必要なようだったらそれはすでに破綻してる)ので、
#結局「どの時点ででも」公開に「問題」は無いはずだったりしますよね。
なつかしいな (スコア:1)
TOWNSのgccの時のことだったら、当事者でした。開発中のlibcを公開するのせんのとゆーことで、あの時もGPL厨房が騒いだものでした。
その時はRMSにメールしてみたら、「無理に開発途中のものを公開せんでええ」という意味の返事でした(既にバイナリの配布はしてました)。その頃、インターフェイス誌にGNUのことを引地さんが書いた時も、それを援護するようなことを書いて下さったものです。だから、今回の話を読んだ時には、「FSFって方針変わったのか?」と思いました。
もっともそれは、LGPLなんてものが出来る前でしたし、ftpなんちゅーものも一般的ではない時代なので、今回と同じ条件では論じれないでしょうね。
Re:なつかしいな (スコア:1)
β版につき再配布禁止、みたいな制限つけてたのがGPL的にどうよ?
という話で、RMSに聞いたら不可とのことで、制限はずしたようです。
当時lhaなどもβ版は再配布禁止だったりして、niftyではそーゆー形態はめずらしくなかった。
Re:気持ちはわかる (スコア:1)
今時そんなにコストがかかりますかね。ベータといえど、バイナリを公開できたのだから、同様な方法でソースも公開すれば。ftp サーバーにコピーするだけなのではないかと。
テープ配布だからその媒体代と製造の為の人件費を請求しますよ、というのも GPL は否定していないと思った。
一方、開発事情で、βでは使い慣れた社内謹製ライブラリを使用しているが、社外に出したくないので正式版では簡易版を使うことにしよう、でも今は手が回らない!とかあるかもしれない。
ここで、そのライブラリが使い慣れた市販品のライブラリだった場合、それを販売している会社にソースを出せとは言えないのではないか。そして、その市販品というのが実は自社が販売している商品だとしたら。
結局は「混ぜるな、危険!」な結論になりそうだが。
ソースのコメントも、余分なコメントという印を付けておいて、 awk で一括削除とかすればいいし。スタイルもこれは結局慣れだから、GPL で公開する予定ならば、最初から BSD スタイルで書く、 とか実行すれば結構馴染めてしまうものだ。
現在仕事で書いているソースを明日公開するからね、と言われて、まずいよ待って下さい、という要素は僕の場合は皆無です。