なぜWordPressテーマはGPLライセンスでも商売足り得るか – Capital P – WordPressメディア
さて、先日のインタビューを公開したところ、筆者のFacebook投稿に次のようなコメントが寄せられた。 以前からぼんやり疑問なのですが、GPLな有料テーマはGPL守る限りは無償でも再配布できますよね。 アクティベーション機能があるGPLなテーマもあるようですが、これのアクティベーション機能を削除するのは、法的にも思想的にもGPLに違反しませんし、アクティベーション削除版をGPLで配布することもできますよね にもかかわらずGPLな有料テーマがビジネスになるのは、WordPress界の文化的な背景があるのでしょうか。 質問者の方は経験豊富なエンジニアで、WordPressのことは知ってはいる。が、たしかに聞かれてみれば、GPLというライセンスの構造上、なぜそれでビジネスになりえるのかというのは、しごく真っ当な質問でもあるので、ここで一つ、問題の整理を兼ねて「なぜGPLライセンスの有料テーマ販売
Relicensing React, Jest, Flow, and Immutable.js
Next week, we are going to relicense our open source projects React, Jest, Flow, and Immutable.js under the MIT license. We’re relicensing these projects because React is the foundation of a broad ecosystem of open source software for the web, and we don’t want to hold back forward progress for nontechnical reasons. This decision comes after several weeks of disappointment and uncertainty for our
The MIT License, Line by Line
>> law, technology, and the space between All content by Kyle E. Mitchell, who is not your lawyer. You can subscribe via RSS/Atom or e-mail and browse other blogs. September 21, 2016 The MIT License, Line by Line171 words every programmer should understand This post is part of a series, Line by Line. The MIT License is the most popular open-source software license. Here’s one read of it, line by l
「JJUGナイトセミナー Java API訴訟問題を考える 」に行った - Qiita
概要 「JJUGナイトセミナー Java API訴訟問題を考える 」に参加してきました。今回はマイクロソフト品川本社での開催でした。 内容に不正確な点がございましたら訂正致します。 もしよろしければコメントか編集リクエストをくださいますと幸いです。 項目 値 日時 2016/07/11(Mon) 19:00-21:00 場所 マイクロソフト株式会社 品川本社 イベント詳細 https://jjug.doorkeeper.jp/events/46995 Twitterのハッシュタグ #jjug togetter http://togetter.com/li/998688 タイムテーブル Time Title Speaker 19:00-19:30 「Oracleが訴えるまでの経緯について～SunとOSSとIBMとAndroid～」 鈴木雄介さん（JJUG会長） 19:30-20:10 「Or
チャットサービス「Idobata」のオンプレ版 提供をはじめました - 株式会社永和システムマネジメント アジャイル事業部
永和システムマネジメント アジャイル事業部では、2016年3月1日より「Idobata」のオンプレ版 提供を開始しました。 サービスの提供ではなく、ソースコード使用許諾権の販売という形態になります。具体的には、GitHub の Idobata リポジトリのコラボレータになる権利を販売します。 利用者 (使う側) と開発者 (作る側) という関係ではなく、ともに Idobata を育てていくパートナーになっていただける企業や組織、あるいは個人の方にご利用いただくことを想定しています。 価格、許諾事項、導入の流れ等に関しては、以下のページをご覧ください。 https://github.com/idobata/idobata-info/blob/master/onpremise.md
JSをbrowserifyでビルドし、ライセンスコメントを適切に残す - $shibayu36->blog;
最近JSを利用するときは、依存モジュールはnpmを利用し、ES6やTypeScriptの仕様を開発には使った上で、ブラウザ用にコンパイルして配信するようになってきている。また同時にネットワークの負荷を下げるためにminifyを行う場合もある。 minifyはライセンスが絡むと少し難しい。例えばコメントを全て削除してしまうとライセンスコメントまで消えてしまう。この問題にはみんながそれぞれの手法で対処しているみたい。1年ほど前の記事でクライアントサイドJavaScriptのライセンス管理 | エンジニアブログ | GREE Engineering というものがあり、いろんなJSのコンパイルのためのライブラリが独自でライセンスの形式を決めていて、それにマッチしないものは消えてしまう、みたいな辛いことが起きてそうだった。 そこで今回は自分の勉強も兼ねて、npmのモジュールを含めてブラウザ用にコンパ
React + BrowserifyプロジェクトでJS/CSS/HTMLを圧縮(Minify)する - Umi Uyuraのブログ
ReactとMaterial UIを組み合わせると、それだけでBrowserifyで結合したJavaScriptファイルが1MB超えてしまうので、やっぱり圧縮とかした方が良いのかな―と思い、やり方を調べてみました。 ※2015/08/03更新 Licensifyを開発された @t_wada さんから改良の連絡をいただいたので、Licensifyの最新版1.4.0をもとに内容を更新しました。 Licensify - Nodeモジュールのライセンスコメントを生成する JSファイルを圧縮すると、ライセンスが記載されているコメントが消えてしまうという問題があるということで、本題の前に、Browserifyと組み合わせて、読み込んだNodeモジュールのライセンスコメントを生成してくれる Licensify を試しておくことにしました。 インストールはnpmから。 $ npm install lice
NDAについて、WWDCでAppleの中の人に聞いてみました - その後のその後
今年のWWDCでは例年に比べ Apple自身が公開してくれている情報 が多く、実質的にNDAが緩くなったといえます。 Appleが公開しているサンプルコードについてWWDCのラボで聞いてみた 際に、「今教えてくれたこと、ブログとかに書いていいんでしょうか？」と質問すると、次のような回答をくれました。 1. iOS Dev Center にログインする 2. Member Center に行く 3. [Your Account] > [Legal Agreements] > [iOS Developer Program License Agreement] を開く 4. "WWDC" で検索する (-> 10.1 Information Deemed Apple Confidential が引っかかる) 5. そこを読んでお前の弁護士と相談しろ なるほど、すごく明快な回答です。WWDCに限ら
mit-license.org
Open Source InitiativeのMITライセンスのページのURLを使ってMITライセンスと明示している人は結構多いと思います。ライセンス全文コピペするの面倒ですしね……。ただその場合は権利者の名前等を予め書き、ライセンス条項については以下のURLを参照……などと注意書きも含めた方が無難です。そういうのを「忘れるし！ 面倒だし！」と思ったRemy Sharpがmit-license.orgというウェブサービスを作ってくれました。 登録するとユーザー名をサブドメインとしたURLが確保されます。例えば僕の場合はhail2u.mit-license.orgです。このページを見るとわかるように権利者の名前と発行年、オプションとしてWebサイトのURLにリンクを張れたりもします。 curlでJSONを送りつけるという方法でも登録できるみたいですが、JSONファイルの登録とバッティングした
SourceMapを用いてOSSのライセンス明記を回避する方法 - オトノナルホウへ→
OSSライセンスの明記をSourceMapで回避しちゃおうという話。 例えば 複数のjsファイルを結合したプロダクトのコードをminifyしてCDNとかに置くパターンを想定。 こういう場合おそらく以下のようなケースがあると思うんですよ。 各jsファイルのminifyされたものを結合する 全てのjsファイルを結合した後の1ファイルをminifyする 前者のケースの場合は、各min.jsにライセンスが表記してある必要がありますし（まあ大体のOSSライブラリはこうなってるかもだけど）、後者のケースでも結局minifyする時にライセンス表記を消さないようにしないといけないんですね。 自分のチームじゃないんですが、前者の方法でライセンスを保持してるチームも実際にあります。 で自分のとこはどうしようかなあと思っていたところ、チームの先輩（まあ社歴は僕の方が長いのですがw）がタイトルにあるSourceM
Oracle wins copyright ruling against Google over Android
SAN FRANCISCO/WASHINGTON (Reuters) - Oracle Corp won a legal victory against Google Inc on Friday as a U.S. appeals court decided Oracle could copyright parts of the Java programming language, which Google used to design its Android smartphone operating system. An Oracle Corporation logo is seen on stage prior to the announcement of the company's latest SPARC servers at Oracle Conference Center in
AndroidをめぐるOracle対Google裁判を振り返る（後編）～ 残る課題はAPI著作権と9行のコード
AndroidをめぐるOracle対Googleの裁判で、Oracleは当初は7件の特許侵害を主な争点としていました。しかし7件中5件の特許が無効とされ（前編）、特許で闘うには不利な状況となりました。Oracleは法廷で、著作権侵害を主要な争点として取り上げることになります。 （本記事は「AndroidをめぐるOracle対Google裁判を振り返る（前編）～ Oracleが主張した特許侵害は認められず」の続きです） 特許侵害から著作権侵害へ争点が移る Oracleは、AndroidがJavaテクノロジと互換性があるAPIセットを持っていることから「37のAPIと、一部の実装コード」について著作権が侵害されたと主張しました。 この戦術はそれなりに有効でした。Oracle側は初めて「勝ち点」をあげることに成功します。 2012年5月7日、陪審員は、次の2件に関して著作権の侵害があったと認定し
Tech world stunned as court rules Oracle can own APIs, Google loses copyright appeal – Old GigaOm
In an unusual decision, an appeals court in Washington ruled on Friday that Oracle(s orcl) can copyright application programming interfaces (APIs) for the Java programming language. The ruling is a defeat for Google(s goog), which uses the APIs for its Android software, but also has implications for the technology industry as a whole, where APIs — which let computer programs speak to each other —
30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
「よくわかるFOSSライセンスまとめなんてないよねー」と煽られたので３分で書く。 オープンソースライセンスは、以下の３種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は「GPLv2以上」 準コピーレフト型にする場合は「LGPL兼MPL」 とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い（そしてどちらを選んでも問題ない）。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ： ライセンスの解釈については、
Githubによる、オープンソースライセンスの選び方 | オープンソース・ライセンスの談話室
「オープンソースライセンスは、分かりにくい。」 まだまだ、このように感じているソフトウェア開発者が多いようです。 たしかに、オープンソースライセンスをお手軽に解説した記事は、かなり人気があります。 ソースコード共有サービスとして人気のGithubの利用者にとっても、これは例外ではないようです。 Githubでは、オープンソースプロジェクトには、無償でレポジトリを提供していますが、「GitHub 上で公開されているソースコードの半分はライセンス的に問題あり」と指摘されていました。公開リポジトリの多くに、ライセンス文が設定されていなかったのです。ライセンスが設定されていないソースコードは、著作権者の明示的な許可が得られていないので、自由に複製・配布・改変できません。 そこで、ここでは、2013年7月にGithubが設置したライセンス選択サイト「Choosing an OSS license d
Study: Most projects on GitHub not open source licensed
Code-sharing website GitHub has grown so popular that it and open source are practically synonymous for many developers. But new research shows that most of the projects now on GitHub are released under license terms that are unclear, inconsistent, or nonexistent, leaving their legal status as open source software uncertain. That's according to Aaron Williamson, senior staff counsel at the Softwar
「若者のコピーレフト離れ」は本当か？ GitHub世代に注目してみる - YAMDAS現更新履歴
Open Source Is Old School, Says The GitHub Generation - ReadWrite 近年 GNU GPL に代表されるコピーレフトなライセンスから BSD、MIT、Apache ライセンスなどのより寛容な（permissive）ライセンスへの移行が起きているという話である。 ソフトウェアが書かれた言語別のコピーレフトなライセンス離れのグラフ（Perl を除くほぼすべての言語でそのトレンドが顕著）や、実は GitHub でホストされているプロジェクトの多くは、ちゃんとしたライセンス指定を行っていないとかなかなか興味深い。 この文章の結論は、この一文になるのだろうか。 License rebels, in other words, tend to become less rebellious as their projects mature. O
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - twada/licensify: Browserify plugin to prepend license header to your bundle
Go and License
Compare Licenses - TLDRLegal