まえがき開発中のソフトウェアのライセンスを策定するため、現時点でのベストプラクティスについて探っていたところ、ここ数年の OSS ライセンスの動向が面白かったので復習も兼ねてまとめました。 特に、Umbrel が採用したという PolyForm という新しいライセンス形態が面白かったので、これについて詳しく述べます。 なぜ今ライセンスについてまとめるのか私はソフトウェアやサービスをマネタイズする方法について興味があり、特にビットコインの応用について調べたりしています。 ビットコイン (Lightning Network) を HTTP で利用することで、Web API の課金方法の可能性は大きく広がることは間違いないのですが、これはあくまで単なる支払いの手法であって、広く使われる事を前提としたソフトウェアの開発を支える手法にすることは(それだけでは)難しいという問題があります。 ソフトウェ
最近シリコンウエハーもらって嬉しかったago（@kyo_ago）です。 このエントリはGREE Advent Calendar 2013 11日目の記事です。 今回はクライアントサイドJavaScriptにおけるライセンス管理の問題を取り上げたいと思います。 ライセンス管理の問題点 「使用しているライブラリのライセンス管理をどうするか」はクライアントサイドJavaScriptにかぎらず発生する問題ですが、クライアントサイドJavaScriptには以下の様な特徴があるため問題が複雑になります。 コードが結合、圧縮される場合がある クライアントサイドJavaScriptでは読み込みの速度を上げるため、使用しているライブラリの結合、圧縮を行うことがあります。しかし、この時誤ってライセンス文が捨てられてしまうことがあります。 ソースが外部に公開される クライアントサイドJavaScriptではソー
The MIT License (MIT) Copyright © 2024 <copyright holders> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to perm
Latest topics > 「元のソフトウェアがGPLだから公開できない」という誤解について 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « Nexus 7とハードウェアキーボードの組み合わせを実用する Main 「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 » 「元のソフトウェアがGPLだから公開できない」という誤解について - Jan 30, 2013 会社のブログに掲載するつもりで書きましたが、タイミング的に発表が遅れてしまいそうということだったので、勢い重視でこちらで公開してみます。 1月31日16時台追記。hide氏の意向についてのこのエントリでの推測が全く
前回は受託開発をする際にGPLライブラリを用いた場合のライセンスの扱い、主にソースコードの開示義務について説明した。今日はさらにもっと掘り下げて、受託開発でGPLが使える場合、使えない場合、使いたい場合などについて考察してみたい。なお、今回のエントリは前回の続きであるため、まだ前回のエントリを読まれていない方は先にそちらを読んで頂きたい。 おさらい: ライセンシーへソースコードを開示する前回のエントリにおいて解説したことまとめると次の2点となる。 受託開発でGPLを使うときは、発注者＝ライセンシーに対してGPLに基づいてソースコードを開示する必要がある。 ライセンシーがソフトウェアを再配布するかはあくまでもライセンシーの自由。 後者について補足すると、GPLではライセンシーに対してNDAなどでソフトウェアの再配布を禁止することを認めていない。発注者側が「GPLソフトウェアとして一般公開しよ
GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対
ＷＥＢ制作者にとっての強力な手助けとなる「無料素材」や、ＰＣの作業効率を格段に向上させる「フリーソフト」。ＷＥＢの世界では、もはやタダで手に入らないものは無いんじゃないかとさえ思えるほど、さまざまなものが無料で配布・提供されています。 しかしそれらは「使用料金が無料なだけ」であって、「完全に自由に使用する事が可能ではない」のです。 世の中に無料で出回っている画像やプログラムソースやアプリケーションなども、そのほぼ全てが、なんらかのライセンス（使用許諾条件）に添った形で配布・提供されているのです。 著作権を有する制作者本人が示す使用許諾条件を守る事は、制作者への敬意であると同時に、意図しない「著作権の侵害」を未然に防ぐ手段でもあります。 しかし、このライセンスというのが、なかなかに分かり難い。コムズカシイ文言の洪水だったり、そもそも英文だったり、GPLとかLGPLとかCCとか略語まみれだった
The Magical Jelly Bean KeyfinderはWindows用のオープンソース・ソフトウェア。WindowsやOfficeを再インストールしようと思った時に必要になるのがライセンスキーだ。購入時のケースにシールで書かれているが、常に手元にある訳ではないので探しても見つからないことがある。とても不便な思いをしたことがある人も多いだろう。 Windowsのライセンスキーを忘れた時に 企業であれば一つのライセンスキーで運用することもできるが個人では難しい。そこで使いたいのがThe Magical Jelly Bean Keyfinderだ。このソフトウェアはインストールされているWindowsやOfficeのライセンスキーを表示してくれるソフトウェアなのだ。 対応しているのはWindows 95、98、ME、2000、XP、Vista、Server 2003、Server 2
なんか、AndroidアプリをApacheライセンスで公開したらそのままGoogleマーケットに載せられて、その載せた人には誠意がない、みたいに怒ってるんだか悔しがってるんだかしてる人がいた。 http://blog.ngsdev.org/archives/android/oyadonavi/ けど、ライセンス的に問題がないんなら、怒るのも悔しがるのも筋違いだと思う。 というか、Apacheライセンスみたいな自由なライセンスで公開するってのはそういうもんでしょ、と。 「この行為自体、良心があるとは思えません。」とか「そのまま自分の名前でマーケットに突っ込むなんて！」と書いてるけど、それを許したのはあなたでしょとしか言いようがない。 「ご自由にお使いください」と書いてて、いざ自由に使ったら文句いうというのはどうかと思う。 「パクリ」とか「盗作」とかいうタグがついているようだけど、ライセンスに
ITMediaのニュースで報じられているように、WikipediaのライセンスがGFDL - GNU Free Document Licenseからクリエイティブコモンズライセンスに変更された。クリエイティブコモンズライセンスって何？と思う人も多いだろう。実は、以前からオトコのコンピュータ道にはクリエイティブコモンズライセンスを適用している。（ページ右上のCC-BY-NC-SAというのがそれである。）クリエイティブコモンズに関しては、以前の投稿で紹介したので詳しくはそちらを見て欲しい。 ここで概要を簡単に説明すると、クリエイティブコモンズはAll rights reservedではなくSome rights reservedのライセンス、つまり著作権を全て主張するのではなく、著作権の一部を主張するために考案されたライセンスである。著作権で守られたドキュメントや画像、写真、楽曲やその他著作物
いまや、企業が何らかのソフトウェアを開発するときに、オープンソースソフトウェア（OSS）との付き合いを考えずには済まない時代になりつつあります。私は、企業の製品開発者向けにOSSライセンスコンプライアンスに関するコンサルティング・サービスを行っていますが、その中から得られた経験を踏まえながら、OSSとうまく付き合い、コミュニティに還元していくために重要と考えられるポイントを紹介していきたいと思います。 そもそも順守しなければならない事柄は何か？ 前回「訴訟が増えている!? OSSライセンス違反」では、「許諾にかかわる利用方法および条件がライセンス条文、つまり許諾要件」であることを説明しました。 そもそもOSSライセンスでの許諾条件には、どのようなものがあるのでしょうか？ ピンとこない方のために、1つ例を挙げて解説してみましょう。 許諾条件とはライセンス条文そのものですから、正確を期するには
On January 1st, Sencha plans to switch its primary support forum from a hosted solution to Stack Overflow. Obviously, we’re flattered, but we think we’re the right place to support any developer community. Other framework and library creators have answered questions about their products here before—check out this answer from curl creator Daniel Stenberg. But we don’t often have companies use us as
Latest topics > オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « 無責任中間法入 Moezilla Japan 設立のお知らせ Main FUELが酷すぎる » オープンソースなライセンスやコピーレフトなライセンス、クリエイティブコモンズについて、他のライセンスとどう組み合わせられるのかを図にしてみた - Apr 02, 2008 オープンソースなライセンスとかコピーレフトなライセンスとかたくさんありすぎて違いがよく分かってなかった（自分で使ってるのに……）。特に、それぞれどう組み合わせること
去る6月末に正式リリースされた、GNU General Public Licenseバージョン3 (GPLv3)の日本語全訳を公開する。読みやすさ、理解のしやすさを旨に訳出した。訳に関する意見や誤訳の指摘は、本記事へのコメントとして寄せて頂けるとありがたい。 GNU 一般公衆利用許諾書 (GNU General Public License) バージョン3、2007年6月29日 日本語訳、2007年9月5日 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. (訳: 本ライ
去る6月末、GNU GPLv3と共に正式リリースされた、GNU Lesser General Public Licenseバージョン3 (LGPLv3)の日本語全訳を公開する。読みやすさ、理解のしやすさを旨に訳出した。訳に関する意見や誤訳の指摘は、本記事へのコメントとして寄せて頂けるとありがたい。 GNU 劣等一般公衆利用許諾書 (GNU Lesser General Public License) バージョン3、2007年6月29日 日本語訳、2007年9月5日 Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changi
GNU GPLv3が近く完成し、フリーソフトウェアパッケージはGPLv2からGPLv3へアップグレードすることができるようになる。この記事では、GPLv3へライセンスをアップグレードすることが重要である理由を説明する。 GNU GPLv3（GNU一般公衆利用許諾契約書バージョン3）が近く完成し、フリーソフトウェアパッケージはGPLv2からGPLv3へアップグレードすることができるようになる。この記事では、GPLv3へライセンスをアップグレードすることが重要である理由を説明する。 まず始めに、アップグレードは必須ではないという点をおさえておくことは大切だ。GPLv2は今後も有効なライセンスであり続ける。一部のプログラムが GPLv2に留まったまま、そのほかのプログラムがGPLv3へアップグレードしたとしても、何か非常に困る大変なことが起こるわけではない。GPLv2と GPLv3との間に互換性
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く