Facebookの特許条項付きBSDライセンスが炎上している件について｜こんぴゅ
先月あたりから、オープンソースソフトウェア（以下、OSS）のライセンスのあり方について、Facebookを火種にして侃々諤々の議論が起こっているので解説してみる。 ASFがFacebookにNOをつきつけることの始まりは、Apache Software Foundation（以下、ASF）という著名OSSプロジェクトを多数保有する非営利団体が、Facebookが自社OSSに付加している独自ライセンス Facebook BSD+Patents license を「Category-X」リスト（禁忌リスト）に追加したことだ。 ASFプロジェクトは、Category-Xに含まれるOSSに依存してはいけない決まりがあるため、Facebook製のOSSに依存しているプロジェクトは、8月31日以降はそれらの依存を取り除いてからではないと新しいリリースが出来ない。影響を受けたプロジェクトは少なくとも C
オープンソースライセンス比較用早見表
このファイルを使用中のユーザーが多すぎるため、一部のツールを利用できない場合があります。再試行詳細閉じる オープンソースライセンス比較用早見表 : Sheet1ABCDEFGHIJKLMN1ライセンスと著作権の表示変更した旨を示すことソースコードの開示ライブラリとして使用すること商用利用改変配布派生物に別のライセンスを課す特許の利用個人利用作者に責任を求めること商標の利用注記2No License必須可能禁止禁止禁止可能GitHubで公開したソフトウェアにライセンスを付記しなかった場合の条件3GPL v2.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし4GPL v3.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし5Affero GPL v3.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし6Artistic GPL 2.0必須必須必須必須でない可能可
403 Forbidden
＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう
クライアントサイドJavaScriptのライセンス管理 | GREE Engineering
最近シリコンウエハーもらって嬉しかったago（@kyo_ago）です。 このエントリはGREE Advent Calendar 2013 11日目の記事です。 今回はクライアントサイドJavaScriptにおけるライセンス管理の問題を取り上げたいと思います。 ライセンス管理の問題点 「使用しているライブラリのライセンス管理をどうするか」はクライアントサイドJavaScriptにかぎらず発生する問題ですが、クライアントサイドJavaScriptには以下の様な特徴があるため問題が複雑になります。 コードが結合、圧縮される場合がある クライアントサイドJavaScriptでは読み込みの速度を上げるため、使用しているライブラリの結合、圧縮を行うことがあります。しかし、この時誤ってライセンス文が捨てられてしまうことがあります。 ソースが外部に公開される クライアントサイドJavaScriptではソー
30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので３分で書く。 オープンソースライセンスは、以下の３種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い（そしてどちらを選んでも問題ない）。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ： ライセンスの解釈については、
Latest topics > 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解 - outsider reflex
Latest topics > 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « 「元のソフトウェアがGPLだから公開できない」という誤解について Main アドオンの自動ビルドとかリリース手順の自動化とか » 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 - Feb 03, 2013 元のプロダクトがGPLでも、自分で開発した部分のソースは別のライセンスを指定できるよ、というエントリを書いた後で、言及した事例が自分の想像を超えた残念事例だったという事を
Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤解について - outsider reflex
Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤解について 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « Nexus 7とハードウェアキーボードの組み合わせを実用する Main 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 » 「元のソフトウェアがGPLだから公開できない」という誤解について - Jan 30, 2013 会社のブログに掲載するつもりで書きましたが、タイミング的に発表が遅れてしまいそうということだったので、勢い重視でこちらで公開してみます。 1月31日16時台追記。hide氏の意向についてのこのエントリでの推測が全く
GPLメモ - こせきの技術日記
配布とソースコード GPLの派生物を渡した相手が希望するなら、ソースコードを渡さなければならない。 不特定多数にソースを公開する義務はない。 AさんがBさんにGPLのソースから作ったバイナリを渡すとき、Bさんに要求されたらソースも渡さなければならない。 BさんがAさんから受け取ったバイナリを100人に売ったとき、その100人に要求されたらソースも渡さなければならない。 顧客の100人がバイナリを購入せず、BさんやAさんにソースを要求しても渡す必要はない。 オープンソースで行こう！: 第2回 オープンソースライセンス事情を俯瞰する 「特にGPLのソフトウェアをビジネス用途などで第三者に販売・提供する場合、その第三者からソースコードの開示要求があればそれに応じなければなりません」 ソースを渡した相手に、再配布を許可しなければならない。 渡された相手が「再配布しなければならない」わけではない。
邪悪なクリエイティブ・コモンズで起こるべくしておきた事件
Internet Brands Sues People For Forking Under CC BY-SA - Slashdot CC-BY-SAでライセンスされているWikitravelのコミュニティが、forkしてWikimediaに移行することを決定した。すると、Wikitravelは訴訟を持ちだした。 CC-BY-SAはforkできるライセンスである。唯一の条件は、同じライセンスのもとで公開することだけだ。WikitravelはCC-BY-SAが何なのかわかっていないようだ。 これは、起こるべくしておきた事件である。というのも、クリエイティブ・コモンズは邪悪だからだ。クリエイティブ・コモンズというライセンスはなく、CC-BYとかCC-BY-SAとか、ひどいのになると、CC-BY-NCとかCC-BY-NDなどがある。これらのライセンスは、お互いに非互換であるにも関わらず、同じクリエ
JavaScriptの著作権侵害で弁護士さんに相談した時のはなし : ねこの足跡 Revenge:
もう何年も前になりますが、 以前開発してたプログラムを同業他社がコピペして使っていたのをたまたま発見し、頭に来て弁護士さんに相談したときのお話しです。 あたしってほんとバカ ある日、いつものようにお昼ごはんを食べながらニュースサイトを眺めていると、新しく競合他社がサービスを開始したというので早速チェック。 ふむふむ。中々よく出来てるなぁと感心しながら触っていたのですが、不思議なことに使えば使うほどデジャブに襲われたんですよ。どっかで見たことあるな、これ…と。 「……まさかな」と思いながらおもむろにブラウザの「ソースを表示」した瞬間我が目を疑いました。フレームワークも、もちろんそれを使ったコードもほぼそのまま。ご丁寧に変数名までバッチシ同じ。十中八九コピペされてると核心しました。思わずセブンのおでん吹くかと思いましたよ。危ない危ない。 悔しいじゃないですか。 表に見えるコードはJavaScr
LGPLに関する追記 « Code Archives
以前投稿したLGPLとAndroidの関係に関するスライドが、某所で叩かれていたようなので反応してみます。 個人的にはLGPLが嫌いなわけではないので、勘違いされているのが非常に残念です。 LGPLの恩恵に与っている身としては、間違えた使い方はやめましょう という話なのですが、誠意がないスライドだとか言われてしまっているので、悲しいです。 もちろん当人はライセンス条項は熟読しているとは思いますが、説明時にライセンス条項一つ示さずに私見で大丈夫って書いてしまったり。抜け穴的な利用方法を説明する人のほうが、よほどLGPLに対して誠意がない気がします。ってこういう反応しちゃうところが僕も大人じゃないなぁ。 スライドのタイトルは結果的に釣り餌になってしまったみたいですが、内容はjarで頒布されているLGPLのライブラリをそのまま使ったらLGPLの影響を受けてしまうというものです。 もちろん僕自身
MPL 2.0 FAQ
In addition to Cookies necessary for this site to function, we’d like your permission to set some additional Cookies to better understand your browsing needs and improve your experience. Rest assured — we value your privacy. MPL 2.0 FAQ About This FAQ This is the Mozilla Public License (MPL) version 2.0 FAQ. It aims to answer the most common questions people have about using and distributing code
LGPLと動的リンク | vyamaの日記 | スラド
LGPLといってもver2.1の話。ver.3はまだ読んでない。まあ、ver.3でも多分通用する話だとは思うが。一応念のため。 LGPLの解釈に「LGPLed ライブラリと動的リンクすれば、自分の書いたアプリケーションはLGPLに従わなくてもよい」(※1)というものがある。googleとかで探すと結構でくわす、らしい。 以前読んだGPL FAQには、典型的な動的リンク例である、プラグインをバイナリで配布する場合についての解説があって、その場合は全体がGPLで保護される著作物だと書いてある。またLGPL2.1の前文にも静的リンクか共有ライブラリとして利用するのか(だから当然プライベートな動的ライブラリであっても)に関らず、実行形式は派生物になると書いてある。だから、当然LGPLの条件に従って、バイナリ配布は6節の条件に従わなくてはならないと思っていた。つまり、オブジェクトファイルを公開するな
オープンソース・ライセンスの談話室 | ギークもスーツも、お気楽に。
これはオープンソースとビジネスを両立させたい企業にとって良い作戦かも。 ニュース HashiCorpがTerraformなど自社製品のライセンスをオープンソースから変更、決断の理由と影響は？：BSLを採用 – @IT HashiCorp、製品ライセンスを「Business Source License」に – ZDNET Japan HashiCorp、全製品のライセンスを商用利用に制限があるBSLライセンスに変更すると発表 － Publickey 解説 Terraformのライセンスの変更とその影響 Business Source License 1.1. 零細企業経営者視点 | by V | Aug, 2023 | Medium ちなみに、一定期間後に移行するライセンスは製品によって異なる。 HashiCorpのTerraformはMPL (＠ITの記事は間違っていると思う)。 Mar
GPL適用のソースコードを他言語に移植してBSDライセンスに変更できるか | オープンソース・ライセンスの談話室
Twitterに「#笑ってはいけないSIer」というのが流れていまして、そこから枝分かれてして「「そもそもOSSがサポート無いと使えない。GPLは禁止。OSSを使うのに研修を受ける必要がある。OSSのソースを読むのは禁止。#笑ってはいけないSIer」から派生したGPLについての談義 – Togetter」というのが出てきました。 そのなかのGPLなソースコードについて説明されていることが、すこーし違うんじゃないかなぁ、と思うところがあり、私なりに調べてみました。 #2011-11-19 AM8:30 「短いコード」と「結論」を追記 #2011-11-20 AM5:30 「運用」を追記。「結論」を修正 #2012-01-20 AM0:30 短いコードにいくつかの具体例を追記してみた #2013-07-20 PM10:20「二次創作同人”小説”」に関する記述を追加 著作権の適用範囲 著作権の保
I-2-7. BSDLとApacheライセンスのメリット・デメリット | 日本OSS推進フォーラム
BSD Licenseと、Apache Software Licenseの特徴と、最も制約が少ないゆえのメリット・デメリットを解説する。BSDライセンスの有名な「宣伝条項」について触れ、修正BSDライセンスを紹介する。 【学習の要点】 * BSD Licenseは「無保証」であることの明記と著作権表示だけを利用、再配布等の条件とするOSSライセンスである。 * 初期のBSD Licenseには、改変して作成したソースコードの広告に開発者を表示することが条件として盛り込まれていたが、この条項を削除し、GPLとの互換性を持たせた。 * BSD License の制約の少なさから、Apache Software LicenseやPHP License (PHP)など、多くのOSSライセンスが、BSD Licenseの内容を取り込んでいる。 図I-2-7. BSDライセンス概念図 【解説】 1)
I-2-6. MPLの特徴、MPLとソフトウェア特許 | 日本OSS推進フォーラム
MPL (Mozilla Public License)の特徴を解説する。OSSの特長であるバザール方式を促進しつつ、商用ソフトとの共存に配慮したこと、特にMPLでは特許との関係性が強調されていることを示す。 【学習の要点】 * MPLライセンスによるOSSを改変した場合は、同じライセンスの適用を求めるが、一体となって動作するが独立する自己開発したソフトウェアについては、別のライセンスを適用することが可能である。 * MPLの特徴のひとつに、トリプルライセンスがあり、MPL/GPL/LGPLの三つのライセンスを併用することも可能である。 * MPLは、GPLと異なり、特許に対し明確な規定をし、特許侵害によるリスクに対応している。 図I-2-6. MPL概念図 【解説】 1) MPL(Mozilla Public License) * 概要 - MPLとは、Mozilla Public Li
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MPL 1.1 FAQ- HISTORICAL USE ONLY
修正BSDライセンスの条文を読む (目次) - とあるソフトウェア開発者のブログ
Mozilla — 利益ではなく、ユーザーのためのインターネット