昨年、#笑ってはいけないSIerというハッシュタグがTwitter上で流行したことがあった。その際、数々の優秀な（ブラック）ジョークに紛れてGPLに対する誤った批判がなされてしまった。その内容はTogetterにおいて「そもそもOSSがサポート無いと使えない。GPLは禁止。OSSを使うのに研修を受ける必要がある。OSSのソースを読むのは禁止。#笑ってはいけないSIer」から派生したGPLについての談義としてまとめられている。その後さらに、書籍「ソフトウェアライセンスの基礎知識」の著者である可知豊氏が「GPL適用のソースコードを他言語に移植してBSDライセンスに変更できるか」というエントリで著作権法と照らし合わせながら見解を語ってくれ、そしてコメント欄でいくつかのやり取りが発生するということがあった。可知氏の考察はさすがというべきか、著作権法の適用範囲について詳しく解説されているので一見の価
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
Sony Electronics Inc. ("SEL") California "Do Not Sell My Personal Information" Request Under the California Consumer Privacy Act of 2018 (“CCPA”), California residents have the right to opt-out of the “sale”1 of their Personal Information to a third party, also referred to as the right to opt-out. To opt-out of the “sale”1 of your Personal Information to third parties, you may: • Complete the fo
GPLを利用するにあたって度々議論されるのが「プログラムの境界」という問題である。GPLソフトウェアを改良または組み込んで別のソフトウェアを作成すると、頒布する際に新しく作成したソフトウェアのライセンスもGPLにしなければならない。ここで注意しなければいけないのは、どこまでがそのソフトウェアの「境界」なのかということである。言い換えると、どこまでが「GPLソフトウェアを組み込んだ」状態なのかということである。自分のソフトウェアをGPLで頒布しようと考えている人にとっては、境界線はあまり意識しなくてもいいテーマである。優れたGPLソフトウェア資産は利用し放題のワンダーランドである。しかしGPL以外のライセンスを利用したいと考えている人にとっては、どこまでならGPLのソフトウェアを利用しても構わないのか？ということを明確に把握していないと、後で著作権法違反で訴えられることになってしまうので注意
Webの世界にもGPLと同様の自由や相互運用性をもたらす小粋なAGPLであるが、運用に際しては注意点がある。それは、ライセンスの互換性である。結論から言うと、AGPLはGPLv2と互換性がない。GPLv2を利用したソフトウェアを改変またはリンクして、AGPLとしてリリースすることは出来ない。それが最大の問題である。GPLv3では一部互換で、GPLv3のソフトウェアを改変してAGPLとしてリリースすることは出来ないが、GPLv3のコードをリンクしたソフトウェアをAGPLv3としてリリースすることが可能である。 なーんだ、じゃあGPLv3のソフトウェアを使えばいいのね？と思うかも知れないが、そうは問屋が卸さない。そもそもの問題点として、GPLv2とGPLv3の互換性がないという問題がある。GPLv3には、ソフトウェア特許に対する保護の強化（つまり、GPLv3ソフトウェア開発元の人が、その利用者
Webサイトのようにプログラムの頒布を伴わない用途においては、GPLソフトウェアを利用してもそのWebサイトのために開発したプログラムをGPLライセンスで公開する義務はない。そのため、多くのWebサイトはGPLソフトウェアを利用していてもソースコードレベルの互換性は殆ど無く、ソースコードの相互利用もなく、Webプログラマは車輪の再発明をしなければならず、多大な負荷を強いられているのではないだろうか。他人の目に触れていないソースコードは、恐らく欠点（バグやセキュリティホールなど）も多いことだろう。これではGPLライセンスの意味、つまりより多くのプログラムをGPLライセンスで流通させて、プログラマが自由に他人のソースコードを参照・利用できる（それによって車輪の再発明を防ぎ、ソフトウェアの発展を促す）という目的が台無しになってしまう。これは、フリーソフトウェアを支持する人達にとって好ましくない事
なぜ自分がMySQL関係の仕事をしているのか？もちろんMySQLが技術的に面白いということや、MySQLの優れた性能に惹かれているという部分はあるが、それよりも何よりもライセンスがGPLだということが一番の理由である。なぜGPLがいいのか？それは最も自由なライセンスだからである。 GPLよりBSDライセンスのほうが自由ではないのか？GPLソフトウェアを改変した場合、そのソフトウェアもGPLでリリースいなければいけない。BSDライセンスなら別のオープンソースでないライセンスにするという自由があるではないか。という反論があるかも知れない。 しかし考えて見て欲しい。BSDライセンスのソフトウェアを元に、オープンソースでないライセンスをつけた非常に優れたソフトウェアを開発したとしよう。そのことによって一体どれだけのメリットがプログラマ（またはエンジニア）に還元されるのだろうか。優れたソフトウェアで
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
ストーリー by hylom 2008年09月24日 18時15分 GPLなコードを使ってそうなソフトは他にもありますが… 部門より AppleのApp Storeで提供されているiPhone/iPod touch用ソフト「Mocha Remote Desktop」がGPL違反をしているとの報告があったそうだ（gpl-violations.orgのMLに投稿されたメール）。 Mocha Remote DesktopはiPhone/iPod touch向けのRDPクライアントで、無料のlite versionと、5.99ドルの有料版がApp Storeで公開されていた。 投稿されたメールによると、Mocha Remote Desktopが含まれるiPhoneのバックアップ（iPhoneをPCやMacに同期する際に、自動的にiPhoneのバックアップがPCやMac内に保存される）をgrepして
■ なぜGPLを選ぶのか Twitterで「OSDって不自由だよね」みたいな会話をちょっとしたので、(それとは関係なく)自分がリリースするソフトウェアにGPLを採用している主観的な理由を書いておこうと思った。 自作のソフトウェアをオープンソースソフトウェア(ないしはフリーソフトウェア)として配布しようとして、OSDを参照すると、けっこうさまざまな制約が課せられていることに気づいて、「なんだ、けっこう不自由だな」と感じてしまうのはよくあることだ。これは、そもそもOSDが謳う「自由」の主体が作者ではないことに思い至らないことに起因している。 作者にとって最大限の自由をもたらず配布形態は(いろいろと別の問題を抱えはするものの)public domainなわけで、そこにさまざまな条件を加えたOSD準拠のライセンスを選択することはなんらかの不自由を呑むことに他ならない。じゃあ、OSDが謳う「自由」は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く