ノートPCに入れたLinuxデスクトップで、元々入ってたOEM版のWindows10のライセンスを使って仮想マシンを作成する | 俺的備忘録 〜なんかいろいろ〜
Blog 201905 ノートPCに入れたLinuxデスクトップで、元々入ってたOEM版のWindows10のライセンスを使って仮想マシンを作成する 元々はWindowsが入ってたノートパソコンにLinuxを入れて使っている場合、元々入ってたWindowsを仮想マシンなどで使いたいといった場合がある。 Windows 7とかだとPCに貼ってあるシールのライセンスを使えばとりあえず利用できたのだけど、Windows 10の場合はOEMライセンスとしてインストールされているので、ライセンスシールが貼ってなかったりする。 で、なんか方法無いのかなと調べてみたところ、どうやら仮想マシンのハードウェア情報を一部いじれば実現できそうだということがわかった。 I just bought a new laptop. The first thing I did was take out the unboot
OEM 版 Windows 10 の仮想化に必要なライセンス | blog.yottun8.com
Windows 10 を仮想化環境上で利用したいと思い、技術的には何の問題もないと分かっているのですが、ライセンス的にどうなのかが分からなかったので調べてみました。 OEM 版 Windows 10 Pro がプレインストールされた PC を持っている PC の OS は Linux に入れ替える Linux 上に仮想化環境 (例. VirtualBox) を構築し、その環境上で Windows 10 Pro を稼働する 仮想マシンの Windows 10 Pro は、ホストの Linux からリモート アクセスして利用する ホストの Linux と仮想マシンの Windows 10 Pro の利用者は同じ この内容は Microsoft に問い合わせた結果として得られたものではありますが、あくまでライセンスの処理については自己責任ということでお願いします。同様の状況であってもサポート窓口
OSSのライセンスを理解する（「使用」と「利用」の違い、知っていますか？） - Qiita
最近、私的にDockerで遊んでいるのですが、Dockerを使っていると様々なライセンスを有したオープンソースソフトウェア（OSS）と遭遇します。自分が知らない間に著作権に抵触してしまうことが怖かったので、OSSのライセンスについて以下の流れでまとめてみました。 「ライセンス関連用語」を理解する 「オープンソースの定義」を理解する 「コピーレフト」を理解する 「主要ライセンス」を理解する 1.「ライセンス関連用語」を理解する OSSを理解するにあたって、まずは主要なライセンス関連用語の定義を理解することが重要です。私の場合は、「使用」と「利用」の違いや「オープンソースソフトウェア」と「フリーウェア」の違いについて、恥ずかしながら明確に理解できていませんでした。。。 【オープンソース・ソフトウェア（Open Source Software, OSS）】 ソースコードが無償で公開されており、誰
PHPのJSONライセンス問題が一応決着 - hnwの日記
2012年頃に、PHPのJSONエクステンションのソースコード中に次のようなライセンス文言が含まれていると話題になりました。 The Software shall be used for Good, not Evil. これはJSONライセンスと呼ばれるライセンスの一文です。「このソフトウェアを良いことに使うのはいいけど、悪いことには使っちゃダメ」といったところでしょうか。 これはフリーソフトウェアの定義に反しており*1、各種LinuxディストリビューションでJSONエクステンションを配布できないことになるため、ちょっとした騒動になったというわけです。 本稿ではこのJSONライセンスへの対応が現在どうなっているかを紹介します。 各種Linuxディストリビューションの対応 PHPのJSONエクステンションはjson_encode()やjson_decode()などの重要な関数を提供するエクス
図解：Apache License2.0の特許条項 | オープンソース・ライセンスの談話室
西尾泰和さんが「でかい企業のOSSがApache License 2.0だと嬉しい理由」として、Apache License2.0の特許条項を解説しています。 Apache License, Version 2.0の特許条項は、こんなふうになっています。 3. 特許ライセンスの付与 本ライセンスの条項に従って、各コントリビューターはあなたに対し、成果物を作成したり、使用したり、販売したり、販売用に提供したり、インポートしたり、その他の方法で移転したりする、無期限で世界規模で非独占的で使用料無料で取り消し不能な（この項で明記したものは除く）特許ライセンスを付与します。ただし、このようなライセンスは、コントリビューターによってライセンス可能な特許申請のうち、当該コントリビューターのコントリビューションを単独または該当する成果物と組み合わせて用いることで必然的に侵害されるものにのみ適用されます。
でかい企業のOSSがApache License 2.0だと嬉しい理由 - 西尾泰和のはてなダイアリー
「無期限で世界規模で非独占的で使用料無料で取り消し不能な特許ライセンスを付与します」という条項があるので使わせてもらう側が「わーい、便利なライブラリだー」と思って使っていたら後から「特許料払え！」と言われるという悲劇が起こらないことだって。 3. 特許ライセンスの付与 本ライセンスの条項に従って、各コントリビューターはあなたに対し、成果物を作成したり、使用したり、販売したり、販売用に提供したり、インポートしたり、その他の方法で移転したりする、無期限で世界規模で非独占的で使用料無料で取り消し不能な（この項で明記したものは除く）特許ライセンスを付与します。ただし、このようなライセンスは、コントリビューターによってライセンス可能な特許申請のうち、当該コントリビューターのコントリビューションを単独または該当する成果物と組み合わせて用いることで必然的に侵害されるものにのみ適用されます。あなたが誰かに
MIT license を読む 2013-12-22 - 未来のいつか/hyoshiokの日記
MIT licenseはシンプルだ。3段落しかない。 最初の段落で、何を認めるか(grant)を述べている。2番目の段落で、どのような条件の時、上記の許可(permission)を与えるか、そして3段落目は無保証ということを宣言している。 ソフトウェアは著作権で保護されているので、第三者が勝手にコピーしたり、変更したり、何かにそのまま含めたり、出版したり、再配布したり、サブライセンスしたり、販売したりはできない。 そこでMITライセンスは、著作権者が自分の著作物に対して、第三者が上記のことをすることを許可している。"Permission is hereby granted" このライセンスは契約なのか、著作権の権利の不行使の宣言なのかという法律上の論争があるがここではそれに踏み込まない。 The MIT License (MIT) Copyright (c) Permission is h
クライアントサイドJavaScriptのライセンス管理 | GREE Engineering
最近シリコンウエハーもらって嬉しかったago（@kyo_ago）です。 このエントリはGREE Advent Calendar 2013 11日目の記事です。 今回はクライアントサイドJavaScriptにおけるライセンス管理の問題を取り上げたいと思います。 ライセンス管理の問題点 「使用しているライブラリのライセンス管理をどうするか」はクライアントサイドJavaScriptにかぎらず発生する問題ですが、クライアントサイドJavaScriptには以下の様な特徴があるため問題が複雑になります。 コードが結合、圧縮される場合がある クライアントサイドJavaScriptでは読み込みの速度を上げるため、使用しているライブラリの結合、圧縮を行うことがあります。しかし、この時誤ってライセンス文が捨てられてしまうことがあります。 ソースが外部に公開される クライアントサイドJavaScriptではソー
自作ソースコードに、MITライセンスを適用する３つのやり方 | オープンソース・ライセンスの談話室
自分の作ったソフトウェアをオープンソースとして公開する。まだまだ敷居が高いようです。人気のソースコード共有サービスGithubも、無償で使う場合にはソースコードをオープンソースにする必要があるのですが、「GitHub 上で公開されているソースコードの半分はライセンス的に問題あり」という話もあるくらいです。 では、なぜオープンソースライセンスが、なかなか適用されないのでしょうか。 その理由としては、 オープンソースにしたくない オープンソースライセンスの適用方法が分からない といったことが考えられますが、前者は、Githubの利用条件に合わないので、そもそも無理があります。 さて、後者の「ライセンスの適用方法が分からない」ですが、前回、Githubのライセンス解説サイトを取り上げた時も、「ライセンスが分からない、めんどう」といったコメントが、いくつか見受けられました。ですから、ライセンス適用
ライセンスの選択を恐れる必要はありません - 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
GPLは数あるライセンスのうちもっとも使われているものなのになんで蔑ろになるのか
法律家と深く話をしたことがないので、ぜひ聞いてみたいことがある。というのも、 法務部や顧問弁護士がわからないからだめーってのも。RT @nippondanji: GPLは使えないという批判の多くは、GPLはよく分からないから今居る現場では使いたくないという内容を形を変えて言ってるものが圧倒的に多い。 — ARAKI Yasuhiroさん (@ar1) 10月 31, 2012 @ar1 プロプライエタリソフトウェアのEULAのほうが遥かに種類が多いのに、おかしな話ですよね。 — Mikiya Okunoさん (@nippondanji) 10月 31, 2012 GPLはあらゆるライセンスのうちでも最も言及され、衆人の目にさらされ、生き延びてきたライセンスなので「わからない」というのはプロたる法律家がわからないというのはありえないと思う。 そこで、聞きたいことは以下二点。。 法律家は「GP
オープンソースのコードを取り込んだ時のライセンス表記について - 30歳からのブラウザづくり
GPLのコードを１行でも取り込んだ場合は、ソフトウェア全体をGPLで配布しなければいけませんが、BSDやMITライセンスのコードを一部取り込んだ場合のライセンス表記ってどうなってるんだろう？と思っていろいろ調べてみた。 BSDライセンスに関しては、Wikipediaによると以下のような記載がある。 「無保証」であることの明記と著作権およびライセンス条文自身の表示を再頒布の条件とするライセンス規定である。この条件さえ満たせば、BSDライセンスのソースコードを複製・改変して作成したオブジェクトコードをソースコードを公開せずに頒布できる。 ようするに、「無保証の明記」と「著作権表示」をどこかに書いておけばOKということのよう。 ちょっとひっかかるのが「ライセンス条文自身の表示」の部分。ライセンス条文を書いてしまったらBSDライセンスのコードを再利用しているソフトウェア全体がBSDライセンスで配布
GPLソフトウェアのパッチをBSDライセンスで提供することの意義
先日の投稿「GPLが適用されているソフトウェア＝MySQLのパッチをBSDライセンスでリリースする。」では、GPLが適用されているソフトウェアにBSDライセンスのパッチを提供することが出来るということを書いた。ただし、それが出来ることによってどのような意義があるのかということについては触れていなかった。その結果、 という疑問が生じたらしい（ブコメ参照）ので、パッチをBSDライセンスで提供するということはどういうことなのかを説明しようと思う。 まず第一に、パッチ自身はBSDライセンスなので、BSDライセンスに従う限り他のプログラムへ流用することが出来る。パッチといえども、それが何かの機能を追加する類のものであれば巨大なプログラムになり得るだろう。事実、Googleが提供するMySQLのパッチもかなりデカイ。パッチの規模がでかくなれば、独立して機能する有益なロジックが多々含まれることになるだろ
サーバ仮想化導入の前に検討すべきこと ～複雑化するライセンスを理解する
サーバ仮想化環境におけるライセンスの考え方は、非仮想化環境と比べ、考慮すべき層が増えたことで複雑になる。本連載では、期待する恩恵を享受するためのライセンス選択のポイントとケーススタディによるコスト試算を、導入の際の検討指針として提示する。 お薦め記事 デスクトップ仮想化で必要になるWindowsライセンスは？ Hyper-V環境でのMicrosoft Windows Serverライセンスの仕組みとは？ 近年、仮想化技術は広く浸透する道をたどり、“導入検討が当たり前”の風潮すら出てきた。その背景には「コスト削減効果」や「運用管理負荷の軽減」への期待が大きい。しかし、何も考えず同技術を採用するだけでは逆にコスト増、運用管理負荷増になってしまう場合もある。 本稿では、サーバ仮想化導入の前に明確化しておくべき観点を整理するとともに、仮想化ソフトウェアの概要を紹介する。 サーバ仮想化導入の前に明確
GPLメモ - こせきの技術日記
配布とソースコード GPLの派生物を渡した相手が希望するなら、ソースコードを渡さなければならない。 不特定多数にソースを公開する義務はない。 AさんがBさんにGPLのソースから作ったバイナリを渡すとき、Bさんに要求されたらソースも渡さなければならない。 BさんがAさんから受け取ったバイナリを100人に売ったとき、その100人に要求されたらソースも渡さなければならない。 顧客の100人がバイナリを購入せず、BさんやAさんにソースを要求しても渡す必要はない。 オープンソースで行こう！: 第2回 オープンソースライセンス事情を俯瞰する 「特にGPLのソフトウェアをビジネス用途などで第三者に販売・提供する場合、その第三者からソースコードの開示要求があればそれに応じなければなりません」 ソースを渡した相手に、再配布を許可しなければならない。 渡された相手が「再配布しなければならない」わけではない。
オープンソースライセンスの基礎と実務 :: handsOut.jp
スライド1: オープンソースライセンスの文部科学省基礎と実務先端 IT スペシャリスト育成プログラム2008-12-10(アップデート版)可知 豊 http://www.catch.jp/本テキストは、クリエイティブ・コモンズ・ライセンス(表示 2.1 日本 )の下でライセンスされています。Copyright 2008 Yutaka kachi スライド2: 本日の主題本日は、オープンソースライセンスの基本と実務について解説します。著作権の考え方:再利用の制限と促進の2本柱制限:作者の利益保護促進:文化の貢献と発展オープンソースライセンスは、ソフトウェア再利用の促進手段です。Copyright 2008 Yutaka kachi スライド3: 自己紹介可知 豊 Kachi Yutakahttp://www.catch.jp/(元)テクニカルライター株式会社クレオ ZeeM戦略統括部 マ
ＯＳＳからコードをアンコミットできるのか？：夜な夜な海外ネット：オルタナティブ・ブログ
レッドハット株式会社の山本 裕介氏が公の場でＤｒｏｏｌｓチームと議論しているので、ここで取り上げさせていただく。 山本氏がＤｒｏｏｌｓプロジェクトにコミットしたコードの削除を依頼している。コミットするときの手続きで著作権は作成者にあるが、ライセンスはコミュニティのものになることに同意していると思う。（レッドハット株式会社に勤めているので、手続きを省略している可能性もある。実際に同意したかは山本氏に確認はしていない。） https://jira.jboss.org/browse/JBRULES-2660 リンクのページの下のやり取りの結果として、残念ながらも山本氏はチャットから排除されてしまったそうだ。 もし山本氏の要求が通たら、オープンソースプロジェクトは成り立たなくなる。誰でも、何時でも貢献したコードを取り消すことができたら、安心してソフトが使えなくなってしまう。 Ｄｒｏｏｌｓプロジェク
[ruby-dev:42166] Ruby'sライセンスの、BSDLとのデュアルライセンスへの変更
Subject: [ruby-dev:42166] Ruby'sライセンスの、BSDLとのデュアルライセンスへの変更 From: "NARUSE, Yui" <naruse@ r i j Date: Wed, 1 Sep 2010 01:48:16 +0900 Ruby's ライセンスは BSDL と Ruby's のデュアルライセンスになります。 == 拝啓 Ruby's ライセンスは、Ruby とその関連ソフトウェアで用いられており、 GPLv2 と狭義の Ruby's ライセンスとのデュアルライセンスになっています。 しかし、このライセンスには以下のような問題がありました。 * GPLv3 非互換 * 慎ましやかには、BSDL として Ruby's のコードを配布できない * 一方で、その気になれば引用条項や名前条項を使ってなんでもできる 結局、Ruby's ライセンスのコピーレフト
Ruby 1.9.2リリースとWEBrick脆弱性問題の顛末 - 西尾泰和のはてなダイアリー
はい、Ruby 1.9.2がリリースされましたね。このバージョンではWEBrick にゼロデイ攻撃可能な脆弱性 - スラッシュドット・ジャパンで紹介されている脆弱性が僕が書いたパッチで修正されているわけなのですけど、そもそもなんで僕が修正しているのか、って顛末がわりと面白いので紹介します。 Apple、upstreamに報告してくれないまま脆弱性をCVEに届け出る upstreamに連絡が来ないまま脆弱性が公開される ruby-devにAppleが書いたと思われるパッチが貼られる(Appleでない人間によって) パッチのライセンスが不明なので取り込めない ライセンスを問い合わせるAppleの窓口が不明なので問い合わせもできない ruby-devを読んだ人はライセンス上安全なパッチを書けない 脆弱性だから話は非公開に進めたい yuguiさんがruby-devを読んでない僕に書かせることにする
MITやGNU GPLなど、オープンソースのライセンスについて | チバのブログ
この前書いたYUI CompressorでjavascriptやCSSを連結・圧縮の中で圧縮後にライセンスの表記が消えてしまっていたことについて、いろいろな方から指摘を受けました。 あまりにライセンスに関して無頓着であったので、かなり恥ずかしいです。 今後恥ずかしい思いをしないために、オープンソースのライセンスについて調べてわかったことを書いて、自分の脳みそに叩き込もうと思います。 他の色々なライセンスについても調べて随時追加していく予定。 写真：adulau有名なライセンス GNU General Public License (GNU GPL) BSD ライセンス MITライセンス Artistic License (Perl のライセンス) パブリックドメイン GNU General Public License (GNU GPL) Free Software Foundatio
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
