アカウント名:
パスワード:
この辺りのコメント [srad.jp]を見ると、何か「オープンソース活動家」や「オープンソースソフトウェアの開発者」に分類されることを忌避する人がいるようなのですが、何故なのでしょうか?
私の持っている「オープンソース活動家」のイメージは、「オープンソースにするとこんないいことがあるんだよ~」という宣伝をする人、という感じでマイナスイメージは無いんですが、そうは思わない人も世の中にはいるということなのだと思います。つまり、「オープンソース活動家」を(極端な単語で言えば)排除すべき、と考える人がいる(だから「オープンソース」の関係者には分類されたくない)ということです。
では、その人たちにとって「オープンソース活動家」とはどういうものなのでしょう?そして、何故排除されるべきと考えるのでしょう?
ESRの手による文章 [oreilly.co.jp]によれば、「オープンソース」という単語は、FSFのいう「フリーソフトウェア」という単語が当時既に持っていた(持たされてしまっていた、という方が正しいかもしれません)負のイメージを断ち切るために、新たに生み出された単語だったはずです。にも関わらず、現状の日本においては、このストーリーのいくつかのコメントに散見されるように、結果として負のイメージを持っている人が少なくないようです。
一人の「オープンソース」ファンとしては、「オープンソース」という言葉の正しい理解が広まるのはもちろん歓迎しますが、逆に何故こうした負のイメージを抱かれるようになってしまったのかについても考察すべきではないかと考えます。
負のイメージの形成過程を追うことにより、正しい理解をより広く広める方法が見えてくるような気がします。
オープンソースと分類されることで、実際に積極的に活動してるかどうか/活動に肯定的か否定的かどうかは関係なくその類の人だとみなされることを憂慮しています。
オープンソースだからライセンスを採
独自の変なことをライセンスで主張しようとしつつオープンソースブランドを利用しようとするから苦労するわけで、
そうしたら、上記 ★1 のメリットさえ、消えてしまいます。 これは利用者、開発者、配布者、全員にとって大変困ることです。
開発者は困らない。 なぜならば、実際に開発者として既存の成果に関与する際にはそれが「オープンソース」と表記されているか否かに関わらず、いずれにせよライセンスに当たるからです。
ソースは公開しています。自由に転載しても構いません。 何かを変更して公開する場合にはあなたの名前で行ってください。
良かれと思ってソースを公開する→ソースを公開していることを示すために「オープンソースとします」と書いておく→そもそもライセンスをどうのこうのというほどのコードでもないから曖昧に→晒される
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
メリットを考えろというコトか。 (スコア:1)
というか、件のページの目的は、「これからはなるべくオープンソースって言葉を使わないようにしよう」と思わせることに有るようにしか思えない。
それぞれにそれぞれのポリシーが有って、OSIの定義から外れたオープンソースもどきを作っているワケで、それをオープンソースの定義に合わせて変更しようと思うほうがおかしい。
期待されているのは、オープンソースもどきが「オープンソース」を名乗らないということだ。
「オープンソース」ブランドは魅力的だ。
少しは流行ったから、自分好みに改造してやろうとか、なにかサンプルはないか といった人間を比較的簡単に誘導できる。
でも、ブランドへの加入条件は厳しい。
ソースを利用する人間にもライセンス条項を理解し吟味することを要求させる。
コミュニティによるチェック機構もあるわけだ。
自分の5000行も無いようなコードを「オープンソース」にするには負担が重過ぎる。
コミュニティと喧嘩する気もない。
だから、
これからはオープンソースという言葉を使わないようにしよう。
# osdev-jはとりあえず「オープンソースもどきに修正して晒されるのを回避
よくわからない (スコア:2, すばらしい洞察)
ソースを公開していることを示すには「ソースを公開しています」と書くのが一番だと思うのですが、なぜわざわざ「オープンソースとします」なんて書きたくなるのでしょう?
ライセンス条項を理解し吟味したくないのでライセンスは使わないという一方で、オープンソースという言葉の内容については何も考えず使えるのはなぜなんでしょう?
>ソースを利用する人間にもライセンス条項を理解し吟味することを要求させる。
「オープンソースとします」だけ書いてあとは曖昧になっている場合、ソースの利用者に利用条件を確認するために作者に連絡を取ることを要求することになるのですが、どちらが大変ですか?
>自分の5000行も無いようなコードを「オープンソース」にするには負担が重過ぎる。
>コミュニティと喧嘩する気もない。
どんな負担がありますか?
なぜコミュニティと喧嘩する必要があるんですか?
Re:よくわからない (スコア:0)
ソースを公開するのはあなたとは異なる人間だからでしょう。
Re:よくわからない (スコア:0)
だから、その理由が知りたいのです。
Re:メリットを考えろというコトか。 (スコア:2)
(ライセンスに関する話は既に行われていますよね。
G7さんの「あなたは何も失わない」というのが
一つの答えだと思います)
某所に提出した申請文に書いた通りの事をやっている
と思うのですが、その osdev-j というのは何か反する
様な事をしていましたっけ?
まずいことをしていないのであれば、そもそも隠れよう
とする理由がわかりません。
指摘に対する対応や議論は可能だと思いますよ。
まずいことをしているのであれば、「もどき」を付け
れば回避できるというものではありません。
良い機会かと思いますので、ご検討を願います:)
#申請文書いた人より
Re:メリットを考えろというコトか。 (スコア:1)
一つは、あのサイト [osdev.info]をやっていく上で、いつか制限を設ける必要が有るからです。
例えば、何らかのアクセス制限機構をつけた段階でそれは平等ではなくなり、オープンソース的なモノでは無くなるワケで。
オープンソースという看板を背負うために最善の選択を行うのではなく、dev-jを運用していくために最善の選択をして行こうということです。
たとえ一時的にオープンソースの定義から外れたとしても。
もう一つは、別のコメントでも引いていますが、オープンソースジャーナリズムのような言葉がどう思われているかというのがいまいち分からないからです。
OSDをソフトウェアやそのソースコード以外のものに適用しようとするからかもしれませんが。
オープンソースという言葉がオープンソースコミュニティというかOSIのものであるということである以上、無闇にオープンソースを名乗ることでコミュニティを敵に廻すのは得策では無いです。
部分的(dev-jの場合掲載されているソースコード)にオープンソースというのは多分オープンソースでは有りません。
他の部分についてもオープンソース「的な」ものになるように行動している積りではありますが。
誤解の無いように書いておきますが、完全に悪いのは僕であって「オープンソース」では有りません。
語感だけで勝手に憧れ、勝手に名乗っていたのは僕であって、別に名乗るように強制させられたワケではないのですから。
ただ、dev-jの名乗っていたオープンソースは裁判に出たら負ける代物です。
Re:メリットを考えろというコトか。 (スコア:1)
例えdev-jにとって問題となるようなアクセスでも、サイトへのアクセス自体を制限することは、即ち、5. 個人やグループに対する差別の禁止に反していることになります。差別を行いたいのは特定のアクセスなのですから。
恐らく、他から貰えばいいという事にはならないでしょう。
Re:メリットを考えろというコトか。 (スコア:1)
アクセス制制限すべきでない、というのはそうですね。
プロジェクトの情報資源に対する攻撃やいたずらを
警戒されるのであれば、書き込み権限をコントロール
されてはいかがでしょう。
#違う話かな・・・
Re:メリットを考えろというコトか。 (スコア:1)
別にOSD準拠のライセンスを選ぶことは難しいことでもなんでもないと思うのですが。それになんの負担が。
独自の変なことをライセンスで主張しようとしつつオープンソースブランドを利用しようとするから苦労するわけで、それを「厳しい」と呼ぶのはどうかなあ。
変なことのほうをあきらめて正しくブランドを利用した方がお得だと思いますよ。
まつもと ゆきひろ /;|)
Re:メリットを考えろというコトか。 (スコア:1)
プログラミングは小学生でも出来る。
ライセンスの解釈は? 微妙なところです。
単に、ソースコードが公開されているということを「オープンソース」という言葉で主張するのは攻撃の対象になる。
だったら僕はHyperTalkを人に教えるのと一緒に、(スクリプトが容易に閲覧できるとはいっても、)「このスタックはオープンソースです」とは間違っても描かないように教えます。
こんな風に晒されたらかわいそうですから。
そういうレベルで話をするなと言われればそれまでですが、オープンソースという言葉を軽くみているとコミュニティから痛い目に遭うのは事実でしょう。
オープンソースという単語を見ればソースが公開されていると一目でわかる。でも、本来の意義からするオープンソースではないから「もどき」を付ける。そういう思考です。
もっとも、それすら攻撃の対象となるならソースが公開されていることを端的に表わす別の表現を考えることにします。
Re:メリットを考えろというコトか。 (スコア:1, すばらしい洞察)
だから一般には GPL や BSDライセンスなどの
「よく知られた」ライセンスを使用して「負担」を減らそうとするわけです。
逆に自分で考えたライセンスは 法的に有効/無効 とかの確認も
自分でやらにゃいかんので「負担」が増えるはずなんです。
また、未知のライセンスはそれらの確認をユーザにも要求するので
さらに「負担」が増えるはずなんです。
> プログラミングは小学生でも出来る。
> ライセンスの解釈は? 微妙なところです。
プログラムが組める小学生ならライセンスぐらい理解できますよ。
Re:メリットを考えろというコトか。 (スコア:0)
OSI認定ライセンスで出すのは別に構わないけど、オープンソース活動しようとしてるわけじゃないのに、自分の出しているものがたまたまOSI認定ライセンス採用してるというだけでオープンソース活動家と間違えられたらすごく嫌かも。別に何も主張する気は無いのに。
Re:メリットを考えろというコトか。 (スコア:1)
オープンソースソフトウェアを公開してなくてもオープンソース活動家になれますし、オープンソースソフトウェアを開発してても活動家でもなんでもない人はいくらでもいます。
まつもと ゆきひろ /;|)
「オープンソース活動家」って何? (スコア:1)
この辺りのコメント [srad.jp]を見ると、何か「オープンソース活動家」や「オープンソースソフトウェアの開発者」に分類されることを忌避する人がいるようなのですが、何故なのでしょうか?
私の持っている「オープンソース活動家」のイメージは、「オープンソースにするとこんないいことがあるんだよ~」という宣伝をする人、という感じでマイナスイメージは無いんですが、そうは思わない人も世の中にはいるということなのだと思います。つまり、「オープンソース活動家」を(極端な単語で言えば)排除すべき、と考える人がいる(だから「オープンソース」の関係者には分類されたくない)ということです。
では、その人たちにとって「オープンソース活動家」とはどういうものなのでしょう?そして、何故排除されるべきと考えるのでしょう?
ESRの手による文章 [oreilly.co.jp]によれば、「オープンソース」という単語は、FSFのいう「フリーソフトウェア」という単語が当時既に持っていた(持たされてしまっていた、という方が正しいかもしれません)負のイメージを断ち切るために、新たに生み出された単語だったはずです。にも関わらず、現状の日本においては、このストーリーのいくつかのコメントに散見されるように、結果として負のイメージを持っている人が少なくないようです。
一人の「オープンソース」ファンとしては、「オープンソース」という言葉の正しい理解が広まるのはもちろん歓迎しますが、逆に何故こうした負のイメージを抱かれるようになってしまったのかについても考察すべきではないかと考えます。
負のイメージの形成過程を追うことにより、正しい理解をより広く広める方法が見えてくるような気がします。
Re:メリットを考えろというコトか。 (スコア:0)
>ース活動家になれますし、オープンソ ースソフトウェアを
>開発してても活動家でもなんでもない人はいくらでもいます。
これがその通りだとして(という
Re:メリットを考えろというコトか。 (スコア:0)
> (もっとも「いくらでもいます」には全く同意できないが)
Linuxカーネル、*BSD、GNOMEやKDE等々の開発者の多くが
活動家だとでもお思いですか?
Re:メリットを考えろというコトか。 (スコア:0)
オープンソースと結びつけられることはないでしょう。その単語を持ち出さない限り。
ましてやソフトウェアだけをみて積極的に活動している人かどうかなんて、
わ
Re:メリットを考えろというコトか。 (スコア:0)
オープンソースと分類されることで、実際に積極的に活動してるかどうか/活動に肯定的か否定的かどうかは関係なくその類の人だとみなされることを憂慮しています。
Re:メリットを考えろというコトか。 (スコア:0)
Re:メリットを考えろというコトか。 (スコア:1)
単なるWikiページで「違ってるよ」と書かれることをなんでそんなに恐れるんだか。
あ、違ってましたか、で終わりでしょう?
自分のプログラムにOSD準拠のライセンスを付ければオープンソース、そうでなければオープンソースでない。自分独自のライセンスを作ってOSD準拠にしようとでも言うのでない限りぜんぜん難しいことではないですよね。
もちろん、たとえばGPLの解釈に微妙な部分があるのは承知していますが、ここではそこまでの話はしていないですよね。
まつもと ゆきひろ /;|)
Re:メリットを考えろというコトか。 (スコア:0)
自分のプログラムにOSD準拠のライセンスを付ければ【OSD準拠】オープンソース、そうでなければ【OSD準拠】オープンソースでない。なら、分かります。
オープンソース=OSD準拠を決め打ちされているところが、どうしても引っかかります。
オープンソース=OSD準拠ということを世間に納得させる一番確実は方法は、裁判を起こして勝つ事でしょう。(言葉の定義を押さえた上で和解するのも良いかも)
あと、関連法規でも作ってもらって、定義
Re:メリットを考えろというコトか。 (スコア:0)
大きなのから小さいのまでたくさんあります。
これらを吟味せよといわれれば大変なのは判ります。
でも、オープンソース自体の条件は複雑でも大きくもありませんよ。
まずは定義を読んでみてくださいよ。
ライセンスについて何も考えたくないなら BSD ライセンスをおすすめしておきます。
Re:メリットを考えろというコトか。 (スコア:0)
彼らは苦労していない、ということに気付くべきです。
Re:メリットを考えろというコトか。 (スコア:0)
とか書いたけどオープンソース関係のアンテナ弱そうだから
気づいていない可能性のが高いのかも。
Re:メリットを考えろというコトか。 (スコア:0)
Re:メリットを考えろというコトか。 (スコア:0)
とか聞かれたら五文字じゃ済まなかったり。
Re:メリットを考えろというコトか。 (スコア:0)
Re:メリットを考えろというコトか。 (スコア:1, すばらしい洞察)
すばらしいです。
> →ソースを公開していることを示すために「オープンソースとします」と書いておく
ここは前向きで善意においてなされたことだと思うのですが、残念ですが、ここが間違っていたわけです。
> →そもそもライセンスをどうのこうのというほどのコードでもないから曖昧に
もったいない…
> というか、件のページの目的は、「これからはなるべくオープンソースって言葉を使わないようにしよう」と思わせることに有るようにしか思えない。
そう思われてしまうことはとても残念です。
> それぞれにそれぞれのポリシーが有って、OSIの定義から外れたオープンソースもどきを作っているワケで、それをオープンソースの定義に合わせて変更しようと思うほうがおかしい。
はい、それはおかしいですね。誰もそんなことは思っていません。
> 期待されているのは、オープンソースもどきが「オープンソース」を名乗らないということだ。
そのとおりです。
> 「オープンソース」ブランドは魅力的だ。
> 少しは流行ったから、自分好みに改造してやろうとか、なにかサンプルはないか といった人間を比較的簡単に誘導できる。
オープンソースは「かっこいいから」とかいうものではないとおもいますが…
むしろ、どちらかといえば「ダサい」ことじゃないかと思います :-)
> でも、ブランドへの加入条件は厳しい。
> ソースを利用する人間にもライセンス条項を理解し吟味することを要求させる。
そうですね。
でも、一回オープンソースを理解してしまえば、あとは他の n 個のオープンソースを、今度はいちいち吟味することなく利用し、改造し、配布できるわけです(★1)。
そうでなくて、n 個のソフトウェアにそれぞれのライセンスが定義されていたら、いちいち、つまり n 回ライセンスを吟味しないと利用すらできないわけです。
これは大変面倒くさいことに思えます。
で、もし流通しているオープンソースのなかに、実はオープンソースでないものが混じっていたらどうでしょう?
そうしたら、上記 ★1 のメリットさえ、消えてしまいます。
これは利用者、開発者、配布者、全員にとって大変困ることです。
なので、「オープンソースでないものはオープンソースといわないようにしよう」という主張をしているわけです。
Re:メリットを考えろというコトか。 (スコア:1)
でも、だからこそ、他のコメントに書かれているように、それだけ大事ではっきりと定義されているモノを「オープンソース」という言葉で表わしてしまうのはどうか。
コードが読めるという状況のためにGPLかLGPLかBSDLかどうかは重要では無いワケで、ライセンスが実際に重要になってくるのはコードを再使用しようとする時でしょう。
オープンソースというのは、ライセンスをのめない人間にはオープンじゃないオープンソース。
まぁ、考えてみれば当り前なんですけど。
では、みんなにオープンなソースコードはどう表現すればいいのか。と。
Re:メリットを考えろというコトか。 (スコア:1)
Public Domainじゃないですか?
厳密にライセンスとして表現したいのなら、
CreativeCommonsのを使えばよいでしょう
http://creativecommons.org/licenses/publicdomain
Re:メリットを考えろというコトか。 (スコア:0)
外部からはわかることではありません。
ソースやバイナリの再配布(友人などへのコピーも含みますよ)、
改変部分の再配布など
この問題には根深いものがあるとみた (スコア:0)
開発者は困らない。
なぜならば、実際に開発者として既存の成果に関与する際にはそれが「オープンソース」と表記されているか否かに関わらず、いずれにせよライセンスに当たるからです。
Re:この問題には根深いものが(余計なもの) (スコア:0)
Re:この問題には根深いものがあるとみた (スコア:0)
それもそうですが、オープンソースと(正しく)名乗っていれば、
ぱっと見て「ここまでのことができる」というのが判るわけですよ。
最終的にライセンスにあたるべきというんは同意しますが。
「ここまでのこと」は大きいです。
Re:メリットを考えろというコトか。 (スコア:1)
まあ、自分の権利を全く主張しないつもりなら
ライセンスはあまり重要ではなくなります。
野晒しでの開発というのも気軽なものですよ。
#実は私も言語を一つ作っていたり。
Re:メリットを考えろというコトか。 (スコア:1)
これだけのコメントが付いてみて、それがとんでもない誤解だったと解りました。
Re:メリットを考えろというコトか。 (スコア:1)
大丈夫、仲間はたくさんいます [ukai.org](?)
いや、あんまり集めて「OSI 定義」の方が少数派だってことになったらどーすんのかな、と思っただけ
Re:メリットを考えろというコトか。 (スコア:0)
Re:メリットを考えろというコトか。 (スコア:0)
彼らオープンソースの闘士たちは「自分たちの定義が正しい、正統、絶対」
だと信じていますから、多数派か少数派かは問題ではないのでしょう。
むしろ少数派なほうが修正主義者どもとの闘争にも火がつくというものです。
Re:メリットを考えろというコトか。 (スコア:1)
なりません。
匿名でも著作権は残りますので、オープンソース準拠にはなりません。
実際問題としては、その配布したものが自分のものだと証明するのが困難なので、
オープンソースと呼べる状態になったと解釈できるとは思いますが、
後から「それは自分のものだ」と言い出した人がいた場合、
その人が勝てるかは分かりませんが、ややこしい状態にはなってしまいます。
「全部自由」といった場合、OSI認定のライセンスではありませんが、
OSI定義に沿ったライセンスの下に配布されている、とは言えます。
Re:メリットを考えろというコトか。 (スコア:0)
元コメントのひとの条件も「それ以外は全て自由」ってちゃんと書いてあればそうです。
(名前を絶対に出すな、となると違うだろうが、
誰かが名前を出さずに配布したものはオープンソースになるでしょう)
Re:メリットを考えろというコトか。 (スコア:1)
ソースコードは、プログラマがプログラム を変更しやすい形態でなければなりません。意図的にソースコードを分かりにくくすることは許されませんし、
というように、容易に読めないコードは「オープンソース」ソフトウェアとなりえません。
何もかも自由と書くだけでは不足です。
「オープンソース」の定義には「私たち」という表現が幾つもあるわけで。
この件で「オープンソース」を名乗ることの重さを幾らかのCoderは知ったことでしょう。
「オープン」ソースとは自由なソースコードを示す言葉でもなんでもない。
OSDという「オープンソース」の憲法に従ったコードを表わす言葉だ。
「オープン」という響きにダマされてはいけない。
スクランブルされたコードや曖昧な使用基準を誰が許さないのか。OSDだ。
OSDに従わない「オープンソース」はみな消滅すべきだ。
Re:メリットを考えろというコトか。 (スコア:1)
しかしながら、容易に読めない派生物を許可する、容易に読めるコード自体は「オープンソース」ソフトウェアとなりえます。
少なくともOSD1.4 [archive.org]までは、明示的にPublic Domainに置かれたソースはOSD準拠でした。
Changelogによれば、1.2-1.3では、(暗黙に)Public DomainでもOKだったかもしれない。
現行の1.9では認定リストは別ページになっていますが、対応する記述はどれかわかりませんでした.
Re:メリットを考えろというコトか。 (スコア:1)
Re:メリットを考えろというコトか。 (スコア:1)
「わざとインデントや改行をなくして読みにくくする」とか「変数名をランダムなものにする」とかそういう操作をできなくするためにその規定があるわけで、そう書かなければ目的が達成できないのであれば「意図的にソースコードを分かりにくく」しているわけじゃないと思います。
Re:メリットを考えろというコトか。 (スコア:1)
cのソースとは限らないわけで。
> ところで、スパゲッティーソースは容認されるの?
「意図的」でなければ。
ま、「意図的」でなければけっこう恥ずかしいんじゃないかとは思いますが。
# 「意図的」かどうかをどうやって判断するのかは... 見る人が見ればわかるんじゃないかと。見たいかどうかはともかくとして。
Re:メリットを考えろというコトか。 (スコア:0)
こーゆー事言う人の作ったソフトのライセンスって
「ライセンス条項を理解し吟味することを要求」しないんだろうか?
Re:メリットを考えろというコトか。 (スコア:0)
件のページはそもそも比較的クローズなものとして運営されていた
にも関わらず、slashdot.jpで晒されたことについてはどのようにお考えですか?
Re:メリットを考えろというコトか。 (スコア:0)
>にも関わらず、slashdot.jpで晒されたことについてはどのようにお考えですか?
彼ら自身は「晒す」ことにネガティブなイメージはないらしいから、晒されてもかまわないのでは?
Re:メリットを考えろというコトか。 (スコア:0)
そうじゃなくて、そのままにしていれば、指摘された例は
ここまで大々的に晒されることはなかったことに対してなんですが。