自由なソフトウェアと自由なWeb
先日、ソフトウェアライセンスの勉強会に参加したり、オープンソースライセンスの議論が炎上白熱したりしているので、俺自身ソフトウェアライセンスについて考える機会が増えたように思う。プロフィールにも書いてある通り、俺はフリーソフトウェアが大好きである。フリーソフトウェアライセンスは（乱立したので）星のかずほど存在するのだが、その中でもやはりフリーソフトウェアという概念を提唱したリチャード・ストールマン等によるGPLを支持せずには居られない。GPLにもいくつかバリエーションが存在するのだが、その中でももっともとんがっている（最も強いコピーレフト条項が盛り込まれた）AGPLの採用事例が少ないように思う。なぜ採用があまり進まないのだろうかと考えた結果、ある重大な事実、特にWeb業界にまつわる事実に気がついたので、今日はそのことについて紹介しようと思う。結論は最後の方にあるが、あきらめずに頑張って読んで
ITmedia エンタープライズ：GPLにまつわる10個の誤解 (1/3)
GPLは最も広範囲に用いられているソフトウェアライセンスの1つだが、同時に最も誤解されている規約であることも間違いがないだろう。ここでは世間にはびこるGPLについての10個の誤解を取り上げよう。あなたの認識に間違いはない？ GNU General Public License（GPL）は最も広範囲に用いられているソフトウェアライセンスの1つだが、同時に最も誤解されている規約であることも間違いがないだろう。こうした誤解の中には、反対派によるプロパガンダ活動に起因している部分もあるが、法律の専門家および素人の双方においてライセンス関連の条項に触れる機会が少ないこともそうした原因の一部であり、またエンドユーザー用のライセンス条項として通常用いられている文言とGPLの条文とが混同されているという側面も存在しているようだ。いずれにせよ、こうした混乱を生み出している主要な原因は、条文の誤読、世間に流布
受託開発とGPL
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
GPLメモ - こせきの技術日記
配布とソースコード GPLの派生物を渡した相手が希望するなら、ソースコードを渡さなければならない。 不特定多数にソースを公開する義務はない。 AさんがBさんにGPLのソースから作ったバイナリを渡すとき、Bさんに要求されたらソースも渡さなければならない。 BさんがAさんから受け取ったバイナリを100人に売ったとき、その100人に要求されたらソースも渡さなければならない。 顧客の100人がバイナリを購入せず、BさんやAさんにソースを要求しても渡す必要はない。 オープンソースで行こう！: 第2回 オープンソースライセンス事情を俯瞰する 「特にGPLのソフトウェアをビジネス用途などで第三者に販売・提供する場合、その第三者からソースコードの開示要求があればそれに応じなければなりません」 ソースを渡した相手に、再配布を許可しなければならない。 渡された相手が「再配布しなければならない」わけではない。
「Windows 7」移行支援ツールにGPLコードが含まれていた--MS、認める
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Microsoftが米国時間11月13日に述べたところによると、同社の調査によって、「Windows 7」のネットブックへのインストールを簡便化するツールに確かにオープンソースコードが含まれていることが分かったという。 「問題となっているコードを調べた結果、われわれはこれが事実であることを確認できた。ただし、これはわれわれが故意にしたことではない」とMicrosoftのPeter Galli氏はブログで述べた。「弊社はツールの作成に関してサードパーティーと契約したが、コードレビュープロセスでオープンソースコードの存在を見逃したことから、われわれにも責任の一端はある。われわれはMicrosoft Storeを通して提供されているほかのコー
GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。
Googleがリリースしている有名なMySQL 5.0用パッチは、なんとBSDライセンスで提供されている。MySQLは周知の通りGPLでリリースされているが、GPLソフトウェアはその性質上、改変するとそのソフトウェアもGPLでリリースしなければいけない。だったら何故そのパッチをBSDライセンスで提供することが出来るのか？！ホントにそんなこと出来るのか？！Googleは何か間違ってるんじゃないか？！などと疑問に思われることだろう。 結論から言うと、Googleは何らライセンスの間違いを犯しているわけではなく、GPLソフトウェアにGPL互換のライセンスでパッチを書くことが出来るのは、GPLの条文そのものにしっかりと書いてあるのである。 以上の必要条件は全体としての改変された著作物に適用される。著作物の一部が『プログラム』から派生したものではないと確認でき、それら自身別の独立 した著作物であると
AGPLのライセンス互換性の問題について - 解決策はRoR
Webの世界にもGPLと同様の自由や相互運用性をもたらす小粋なAGPLであるが、運用に際しては注意点がある。それは、ライセンスの互換性である。結論から言うと、AGPLはGPLv2と互換性がない。GPLv2を利用したソフトウェアを改変またはリンクして、AGPLとしてリリースすることは出来ない。それが最大の問題である。GPLv3では一部互換で、GPLv3のソフトウェアを改変してAGPLとしてリリースすることは出来ないが、GPLv3のコードをリンクしたソフトウェアをAGPLv3としてリリースすることが可能である。 なーんだ、じゃあGPLv3のソフトウェアを使えばいいのね？と思うかも知れないが、そうは問屋が卸さない。そもそもの問題点として、GPLv2とGPLv3の互換性がないという問題がある。GPLv3には、ソフトウェア特許に対する保護の強化（つまり、GPLv3ソフトウェア開発元の人が、その利用者
GPLに対するオトコの個人的見解
なぜ自分がMySQL関係の仕事をしているのか？もちろんMySQLが技術的に面白いということや、MySQLの優れた性能に惹かれているという部分はあるが、それよりも何よりもライセンスがGPLだということが一番の理由である。なぜGPLがいいのか？それは最も自由なライセンスだからである。 GPLよりBSDライセンスのほうが自由ではないのか？GPLソフトウェアを改変した場合、そのソフトウェアもGPLでリリースいなければいけない。BSDライセンスなら別のオープンソースでないライセンスにするという自由があるではないか。という反論があるかも知れない。 しかし考えて見て欲しい。BSDライセンスのソフトウェアを元に、オープンソースでないライセンスをつけた非常に優れたソフトウェアを開発したとしよう。そのことによって一体どれだけのメリットがプログラマ（またはエンジニア）に還元されるのだろうか。優れたソフトウェアで
オープンソースをライセンス的に正しくつかうための11のチェックポイント - builder by ZDNet Japan
「オープンソースカンファレンス2009 Sendai」が1月24日、宮城県仙台市の東北電子専門学校で開催された。公式サイトのタイトルには「来ないとお仕置きだっちゃ☆」との追記が見えるが、アットホームな雰囲気の中で進行するカンファレンスであった。 本稿では、NEC OSSプラットフォーム開発本部 エキスパートの姉崎章博氏による講演「OSSをライセンス的に正しく使う／プロプラだけの製品とするための11のチェックポイント」を紹介する。なお、特に断りがない限り、全て日本の著作権法について説明している。 オープンソースソフトウェアをライセンス的に正しく使うために 姉崎氏が挙げたチェックポイントは次の11点。 その社製プログラム、すべて自社の著作物ですか？ 商用プログラムを同梱している場合、必要な手続きはお済みですか？ 他人の著作物を使用していないことを確認するためコード検査をしていますか？ OSSの
ピーコの追い込み - 山崎はるかのメモ
旧・山崎はるかの「ひみちゅ」(6) ピーコの追い込み ソフト著作権法違反の対策方針 ※このコンテンツは「山崎はるかの ひみちゅ No.6」から移転したものです ★ このエピソードは 三才ブックス・ゲームラボ にてマンガ化されました ★ △メモエリアにもどる ソフトウェアの著作権に対し、プログラマや経営者の価値観はさまざまである。 したがって、それぞれのプログラマや経営者が 著作権に対し、独自の解釈を行い・独自の許諾範囲を設定する。 著作権法はそれが許された法律であり、著作権者が かなり自由に独自の解釈を行ってよい。 それがあまりに非常識だと、裁判で争われることになるが、おおむね著作権者が強い。 （たとえば ○に耳をふたつ書けば、それだけでミッキーマ○スと解釈する人もいる） （まあ これは意匠権も含まれるが。） これが著作権法の特殊性である。 著作権法には、事実上 判例も法論も あまり通用し
ライセンス資料室
主に、フリーソフトウェアに関連するライセンスをまとめてあります。 基本的に、正式なライセンスは原文(ほとんど英語)だけで、だいたい日本語訳は参考程度にしか使用してはいけない。 現在のところ、ほぼ単なるリンク集。 Apache Software License The Apache Software License, Version 1.1 The Apache Software License, Version 1.1(非公式な日本語訳) Apple Public Source License Apple - Public Source - License Artistic License The Artistic License The Artistic License 日本語訳 1.0 芸術的ライセンス BSD License The BSD License The BSD Licen
オープンソースライセンスのGPLにおけるリンクの扱いについて、JavaScriptではどういう解釈をすればよいのでしょうか。…
オープンソースライセンスのGPLにおけるリンクの扱いについて、JavaScriptではどういう解釈をすればよいのでしょうか。 たとえば多くのJavaScriptライブラリがGPL(v3)で提供されていますが、それをライブラリとして利用して作成されたJavaScriptは「リンク」していると考えるべきでしょうか。 現時点の私の考えとしては、このJavaScriptを（製品パッケージに含めるなどして）頒布するにはGPLとしなければならないが、Webサイトなどでサービスとして実行形態で提供する場合はその部分は非GPLでも構わない、という理解でいますが、これは正しいでしょうか。 （ちなみにこの解釈は、なんとなく現状を見てみるとそのように理解されていそうだ、というものであり、あまり裏付けはありません。） 正しければこのような考えを裏付けしてくれる解釈、事例など、間違いであればその理由、根拠を示す資料
さまざまなライセンスとそれらについての解説 - GNUプロジェクト - フリーソフトウェアファウンデーション
このページはフリーソフトウェアファウンデーションのライセンシング&コンプライアンス・ラボによって保守されています。FSFへの寄付を行って、わたしたちの仕事を支援してください。ここに答えられていない質問がありますか? わたしたちのほかのライセンシングの資料を確認してください。または、こちらのコンプライアンス・ラボのメールlicensing@fsf.orgに連絡ください。 わたしたちは、ライセンスをいくつかの重要なポイントによって分類します。 それが自由ソフトウェアライセンスと言えるか。 それがコピーレフトのライセンスであるか。 GNU GPLと両立するかどうか。とくに記述がない限り、両立ライセンスはGPLv2とGPLv3の両方に両立性があります。 そのライセンスによって、現実的に何か特定の問題が生じるか。 よく出くわす自由ソフトウェアライセンスをほとんどこのページに挙げられるよう努力しますが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
