GitHubで後からライセンスを指定する方法 - Qiita
tl,dr GitHub上でリポジトリトップに [LICENSE] ファイル作ればよろし やりたいこと GitHubでリポジトリを作る時にライセンスを指定できるのは有名ですが、ライセンスを指定しないで作っちゃったリポジトリに後からライセンスを適用したい、ってこともあると思います。 実は楽勝です。 やりかた GitHubの当該リポジトリを表示し、(やりたいのであればブランチ切るとか選択するとかなんとかしてから)リポジトリのトップディレクトリで [Create New File] ファイル名を指定できるので、そこに [LICENSE] と入力 すると右側にライセンス選択のプルダウンが現れる 選んでコミットしておしまい MITライセンスを選べばちゃんとライセンス文章の名前の所をGitHubに登録した名前に変えてくれてますし、そのまま使えるものになっています 参考 : Open source li
知らないと損をする６つのライセンスまとめ
オープンソースやフリーウェア、フリー素材などが巷に溢れ、それらを利用する機会が増えたわけですが、ライセンスに関わる問題がより身近になってきました。 創作活動をより公正に行う上で必要な情報をまとめてみました。 簡単にまとめると、使おうと思ったリソースが Apacheライセンスだとラッキー！ BSD、MITならまあ使える GPLはきびしー！ て感じです。 制約の種類 ライセンスで制約されるのは著作物を使用する上での禁止・許可・義務事項です。 各ライセンスでは何が禁止・許可・義務の対象となっているかを知ることが、理解の近道です。 まずはライセンスでよくあげられる禁止・許可・義務事項についてまとめます。 ※ここでは利用する創作物（作品やコード）のことを単にソースと呼びます 著作権表示義務 どっか見えるとこにこういうの↓を表示してね Copyright© mycode , 2014 All Righ
ライセンス・キーの生成 (GENLICKEY)
ライセンス・キー生成(GENLICKEY)コマンドは，ユーザーがプロダクトまたはプロダクトのフィーチャーにアクセスできるライセンス・キーを生成します。このキーはプロダクトおよびこのコマンドで入力したシステム情報に特有のものです。生成されるキーは18 桁の文字および数字(A-Fおよび0-9)の組み合わせになります。このコマンドを実行するためには，システム上にキーを生成しようとしているプロダクトのプロダクト定義が存在しなければなりません。 また，このコマンドはライセンス・リポジトリーにライセンス情報を追加します。キーは生成されたすべてのキーのヒストリーを保管するリポジトリーに保管されます。リポジトリーを表示して，特定のプロダクトまたはシステムにどのようなキーが生成されたかを調べることができます。ライセンス・リポジトリーを処理するために，DSPLICKEY, ADDLICKEY,およびRMVLI
比較的強固なライセンスキーの生成 - kaisehのブログ
プログラムのバイナリ自体が改ざんされる可能性を無視して、解析・偽装が困難なライセンスキーを生成/検証する手法というと、やっぱり以下のような公開鍵暗号方式になるんだろうか。 RSAのキーペアを作成しておく。 管理者側は「プログラム固有の情報＋ユーザ固有の情報」を秘密鍵で暗号化してライセンスキーとする。 1024ビットの鍵の場合、パディングの88ビットを引いて936ビット=117バイトを固有情報の記述に使用可能。ユーザ名とメールアドレス程度の情報は格納することができる。 この場合、ライセンスキーの長さも1024ビットになる。これをBase64でエンコードすれば172文字のキーになる。Base16なら256文字。 プログラム側には公開鍵を埋め込んでおく。 ユーザが入力したライセンスキーを公開鍵で復号化して検証する。 以下はライセンスキー生成部のサンプル。 import java.math.Big
やさしい「Apache」と厳しい「GPL」、IoT標準化に最適なライセンスとは
今年の技術トレンドの1つである「IoT」。その分野のもつポテンシャルは相当なものだが、その「規格」については依然としてバラバラとしており一体感のない状態だと言える。 最近になって世界が標準化への大きな一歩を踏み出したことからも見えるように、これまでさまざまなベンダーがクラウド上に「データ・サイロ」を建設してきたが、本当に必要なものは“異なるIoTプロジェクトに携わる開発者同士のコミュニケーションをより促す”オープンな場であることは明白だろう。 だがしかし、どのようなオープンソースライセンスが開発者同士のシェアリングのために適当であるかについては、まだ答えが出ていない。その点についてCessanta社のCTOであり共同設立者のセルゲイ・リュブカ氏は、「少なくとも現段階では、より厳密なGNU一般公衆ライセンス『GPLv2』がIoTに適切だ」と考えているという。 果たして本当にそうなのだろうか？
GPLやMITやCCなど主要ライセンスの内容と意味のまとめ
ＷＥＢ制作者にとっての強力な手助けとなる「無料素材」や、ＰＣの作業効率を格段に向上させる「フリーソフト」。ＷＥＢの世界では、もはやタダで手に入らないものは無いんじゃないかとさえ思えるほど、さまざまなものが無料で配布・提供されています。 しかしそれらは「使用料金が無料なだけ」であって、「完全に自由に使用する事が可能ではない」のです。 世の中に無料で出回っている画像やプログラムソースやアプリケーションなども、そのほぼ全てが、なんらかのライセンス（使用許諾条件）に添った形で配布・提供されているのです。 著作権を有する制作者本人が示す使用許諾条件を守る事は、制作者への敬意であると同時に、意図しない「著作権の侵害」を未然に防ぐ手段でもあります。 しかし、このライセンスというのが、なかなかに分かり難い。コムズカシイ文言の洪水だったり、そもそも英文だったり、GPLとかLGPLとかCCとか略語まみれだった
【保存版】GLPにApache Licence2.0,知らなかったでは済まされないライセンスのお話 | Share Tips
【保存版】GLPにApache Licence2.0,知らなかったでは済まされないライセンスのお話Android そもそもライセンスは用語に頼るのか ITのライセンスとなるとGLP,LGPL,Apache Licence2.0, GNU,Modified BSD Licence ・・・と 『略語』ばかり耳にします。 必ずAPIを使った地図のに指定のロゴを入れる(GoogleMap)とか じゃらんのロゴの指定のように『何をどうしろ』とはっきり書けばいいんじゃないか そう思うかたもいらっしゃるのではないでしょうか。 『略語』ばかりの方は、実はオープンソースライセンスの名前群です。 ソフトウェアには著作権があり、利用者は制作者（法人も含む）とライセンス契約を結ぶことで、 著作権に関する許諾を得ています。 そうすることで、契約の内容に沿った形で自由にソフトウェアが利用出来ことで さ
ライセンスの選択を恐れる必要はありません - Qiita
この記事はCC BY 3.0に基いて公開されてゐるWebサイトChoosing an OSS license doesn’t need to be scary - ChooseALicense.comのコンテンツ各ページを翻訳し、単一記事として再構成、訳者による補足を追加したものです。 2017年5月9日に開示されたコミュニティガイドラインに伴って、本記事の翻訳部分につきましては削除いたしました。 (この記事が削除または非公開化されない限り、編集履歴からお読みいただくことは可能です。) (訳註: この「はじめに」及び末尾の「訳者による補足」の章は原文にはなく、翻訳者(@tadsan)によるものです。記事の著作権表示及び元Webサイトの利用規約、免責事項、そしてこの記事についての訳者の見解について記します) (この記事の一部または全て ——ただしコメント欄は含まれない—— はCC BY-SA
GitHubでライセンスを設定する - Qiita
はじめに GitHubでソースコードを公開する場合、ライセンスを明記していないリポジトリがよくあります。 誰かに使ってもらうことを想定していないのであれば特に問題ないのですが、せっかく公開しているのであれば、誰かに使ってほしいですよね。 というわけで、GitHubでのライセンス設定の方法を紹介したいと思います。 ライセンスを明記するかどうか まず、ライセンスを明記しない場合は、どのような扱いになるのでしょうか。 ライセンスが明記されていないソースコードに対しては、このページにあるように、デフォルトの著作権法が適用されます。 つまり、ソフトウェアの複製、改変、（複製物または二次的著作物の）再頒布が認められません。 （ただし、forkした場合は上記を認める記述がGitHubの利用規約中にあり、GitHubの利用者はそれに同意したことになります） 改変せずにそのまま使用することだけを認めたいなら
Apache Licence 2.0ってどう書けばいいのさ | Androidアプリつくったった
Androidアプリ開発でApache Licence 2.0のソースを使った場合の書き方 ライセンスの記載しっかりやってますか。 ちょっとでもひっかかったらこの機会に勉強してしまいましょう。 今回は、Androidのオープンソースライセンスの中でも で頻繁に見かける『Apache 2.0ライセンス』に絞ってポイントを紹介します。 ▼ ソース内にコピペで使えるようにサンプルを置いてあります。ご活用ください。 やるべきことは以下の2つです。 1 ストアの掲載情報の”説明”に記載する 2 ソース内にライセンスの詳細を記載する ▼ ではもう少し詳しく解説します。 1 .ストアの掲載情報の”説明”に記載する 【日本語版】 このソフトウェアは、 Apache 2.0ライセンスで配布されている製作物が含まれています。 自動翻訳だと This software contains
GNU系OSSライセンスに関する一考察
GNU LGPLが産まれた経緯 LGPLは、v2.1では「Lesser GPL」と表記します。ところがv2.0では「Library GPL」という名称でした。 名称が変更になったのにはいくつか理由があります。「ライブラリ形式のフリーソフトウェアは無条件に、GPLではなくLGPLを採用するものだ」という誤解を与えないようにすることが1つです。もう1つは、ソフトウェアによっては、本来ならばライセンスをGPLにしたいけれど、戦略的に譲歩して一段劣等（Lesser）な「フリー」とすることがあります。そうした際に、あくまでも「仕方なく」LGPLにしているのだというニュアンスを明確に表すためです。 この辺りの詳しい説明は、「あなたの次のライブラリにはライブラリGPLを適用するべきでない理由」をご覧ください。 では、なぜ、わざわざ劣等なGPL（＝LGPL）というライセンスを作成したのでしょうか。Linu
GNU系OSSライセンスに関する一考察
表1 OSSライセンスの考え方（繰り返しになりますが、現実にはこの3つに分類できないOSSライセンスもあるでしょう。中には、表面的には同じような要件を備えていても「そんな考え方で作成したライセンスではない」とお怒りになる著作権者（開発者）がいらっしゃるかもしれません。ただ、ここはあくまで入門者向けの説明として、こういう分類を許していただければと思います） 今回は、上記のうち「GNU系ライセンス」の考え方について紹介します。これは表1では「互恵のLicense」とも分類されます。ソースコードの開示を条件に、著作物を受け取った受領者にもまた、第三者に著作物を頒布（譲渡）する権利を与えるというものです。つまり、ソースを受け取ったら、自らもソースを与えるという「互恵の関係」を求めるライセンスです。Copyleft（コピーレフト）とも表現されます。 2種類あるGNU系ライセンス GNU系のOSSライ
さまざまなライセンスとそれらについての解説 - GNUプロジェクト - フリーソフトウェアファウンデーション
このページはフリーソフトウェアファウンデーションのライセンシング&コンプライアンス・ラボによって保守されています。FSFへの寄付を行って、わたしたちの仕事を支援してください。ここに答えられていない質問がありますか? わたしたちのほかのライセンシングの資料を確認してください。または、こちらのコンプライアンス・ラボのメールlicensing@fsf.orgに連絡ください。 わたしたちは、ライセンスをいくつかの重要なポイントによって分類します。 それが自由ソフトウェアライセンスと言えるか。 それがコピーレフトのライセンスであるか。 GNU GPLと両立するかどうか。とくに記述がない限り、両立ライセンスはGPLv2とGPLv3の両方に両立性があります。 そのライセンスによって、現実的に何か特定の問題が生じるか。 よく出くわす自由ソフトウェアライセンスをほとんどこのページに挙げられるよう努力しますが
Qt のライセンスについての考察 – philo式
Qtを使うと決めたものの、ライセンスのことをすっかり忘れていました。そういえば、以前も Qt にしようか迷って、ライセンスの余りの酷さに心が折れたことを思い出しましたよw SRA のサイトにFAQがあったのでざっと目を通してみました そして、そこで驚愕の記述が。 Q8 : オープンソースでないアプリケーションを Qt のオープンソース版で開発し、販売を開始する時に商用ライセンスを購入するのは可能ですか？ A8 : いいえ。商用ライセンスの取り決めは、商用ライセンスの取り決めの下に Qt を用いて開発されたソフトウェアだけに適用されます。この取り決めに先だって Qt オープンソース版で開発されたコードには適用されません。商用版ライセンスなしに Qt で開発されたソフトウェアは全て、オープンソースソフトウェアとしてリリースしなければなりません。 えぇぇぇぇ!!!まーじーでーすーかー!!!!??
MSボリュームライセンスをまとめてみる | POPOLOG
「中小企業にはメリットがなさそう」「複雑すぎて選び方がわからない」と言い訳を考えては避けてきたのですが、「こんなことでは社内SE失格だ」と一念発起して調べてみました。そこで今回は、理解できた部分を簡単にまとめてみます。 ※「中小企業」向けの内容になっています。 ボリュームライセンスの基本のキ ボリュームライセンスのメリットは？ パッケージ版に比べ「メディアやマニュアル、製品のパッケージを省くことによるコスト削減」、「複数ラインセンスをまとめて購入することによる割引」などがあり安く購入することができます。さらに製品のダウングレード権も付加されます。またソフトウェアアシュアランスの購入も可能になります。 ソフトウェアアシュアランスって何？ ボリュームライセンスを語るには、切っても切れないのがソフトウェアアシュアランスです。これは何なのか？簡単に言ってしまうと「ソフトウェアの保守サービス」に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
