tstalk Vol.1というテクニカルサポートのトークイベントに行ってきていろいろお話したり聞いたり考える機会になったので書き出しておくよ。いろいろなテクニカルサポートな人が集まっておもしろかった。ソフトウェア製品サポート、ハードウェア製品やそのファームのサポート、非サポート(興味がある、昔やっていた、サポートを利用するお客様の立場だけど、というような方々)、その他、みたいなごちゃまぜ編成。 ランダム箇条書きな感じで。 テクニカルサポートは楽しい テクニカルサポートはケーキバイキングみたいなお仕事 基本的に扱う内容はエンジニアであるお客様がつまずいた「技術的に難しいところだけ」おいしいとこどり食べ放題 「サポート」を「エンジニアリング」する、多くの改善余地のある創造的な作業が多め 例えばプログラマ関連だと、WebとDBとの橋渡しをするだけのコード書きや(デザインなどの創造的な作業ではない

GPLv3にはソフトウェア特許についての言及（GPLv3 第11条）がなされているが、どうもこの点については誤解が多く人々がGPLv3の利用を躊躇する理由になっているように思う。GPLv3の特許条項はGPLv3に対するFUDの元凶になっているように思う。実は筆者は最近「GPLv3を適用したソフトウェアを公開するとあなたの持っている特許は全て無効になる」という（如何にもGPLv3を適用すると不利益を被るような）誤った説明がなされているのを目の当たりにしたところであり、筆をとる必要があると感じた次第である。そこで、今日はGPLv3における特許の取り扱いについて説明しようと思う。 GPLv3の要求事項GPLv3が定めるのは、簡単にいうと「あなたがGPLv3が適用をしたソフトウェアに特許が含まれる場合、GPLv3でライセンスされたそのソフトウェアを利用／使用するユーザーを特許侵害で訴えませんよ！」

先日、友人の紹介でRed Hat社に勤めるエンジニアの方たちと食事をした。Red Hat社のエンジニアの方々とはあんまり交流が無かったのだが、やはりLinuxに、そしてフリーソフトウェアに魂を燃やす漢たちの発想は一味違う！！興味深い話を聴き、とても良い刺激を受けることができたので皆さんにも紹介したいと思う。 再会参加者の面子を事前に聞いていなかったので驚いたのだが、なんとそこには古い知り合いの顔があった。KVM徹底入門の共著者である森若和雄氏である。彼とは大学院時代、同じ研究室の先輩後輩の間柄（自分の方が一年先輩）なのだが、当時自分は落ちこぼれであり、森若氏は自分より遥かに高いスキルを持ち合わせていたのをよく覚えている。卒業後お互い別々の道を歩いた末に、同じフリーソフトウェア支持者として再会出来たのは大変喜ばしい。 学生時代の森若氏の口ぐせは「Perl最高！Perlがあれば何でもできる！ヒ

米Jaspersoftは米国時間2010年7月14日、MySQLおよびJavaの展望に関する調査結果を発表した。多くのオープンソースコミュニティが、米Oracleの米Sun Microsystems買収によってOracleに移管されるJavaとMySQLの将来を悲観したが、買収が完了した今ではOracleをJavaとMySQLの管理者として好意的にとらえる企業が多いという。 OracleがSunを買収したことにより、MySQLから他のデータベースへ切り替えるという企業はわずか5％だった。47％はMySQLの使用を継続すると答え、まだ判断する時期ではないとする回答者は19％だった。なお、切り替えを考えている企業は、代替品としてPostgreSQLを一番に挙げた。 OracleのもとでMySQLの開発と革新が進むと期待する回答者は43％、従来通りと見る回答者は35％。悪化を懸念する回答者は22

IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

最近、企業とオープンソースの関わり方について、企業にお勤めの方から質問されることが増えてきた。 自社ソフトウェア製品の某を、これこれこういった条件の下でオープンソース・ソフトウェアにしたいのだが、ライセンスはどれを選べば良いか、というような明確でテクニカルな質問であれば、答えるのは簡単だ。しかし、オープンソース・コミュニティと「うまくやっていく」にはどうしたら良いか、というような極めて曖昧な質問をされることも多い。私は企業に勤めたことがないので企業の内情には大して通じていないし、そもそも曖昧な質問には答えようがないのだが、それでも今回はあえて後者を取り上げてみよう。 のっけから申し訳ないが、私が思うに、問題は「オープンソース・コミュニティとどう付き合うか」ではない。より本質的には、社外の不特定多数の人々と日常的に意思疎通せざるを得ず、しかも情報のコントロールが事実上効かないような環境に、今

例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働

オープンソースという言葉がソフトウエア以外の分野に広まることで、良いことと悪いことがひとつづつある。 非組織的で自発的なコラボレーションの有効性が一般に広く認識され市民権を得る オープンソースでないソフトウエアがオープンソースと呼ばれてしまう危険性が高まる 私は、1.を重視して、他分野に転用してこの言葉を広い意味で使ってきた。だから「お前が言うな」と言われそうだが、オープンソースという言葉を使う時には、2.についても考慮すべきだと思う。 オープンソースとは、本来は、開発の方式ではなくてソフトウエアのライセンスを分類する為の言葉だ。オープンソースの定義 という広く認められた文書があって、これに合致するライセンスによって配布されているソフトウエアがオープンソースである。 つまり、ソフトウエアは、それがオープンソースであるかそうでないか、何の紛れもなく客観的に判定できるのだ。だから「オープンソー