タグ

関連タグで絞り込む (16)

タグの絞り込みを解除

licenseに関するgfxのブックマーク (19)

  • クライアントサイドJavaScriptのライセンス管理 | GREE Engineering


    最近シリコンウエハーもらって嬉しかったago︵@kyo_ago︶です。 このエントリはGREE Advent Calendar 2013 11日目の記事です。 今回はクライアントサイドJavaScriptにおけるライセンス管理の問題を取り上げたいと思います。 ライセンス管理の問題点 ﹁使用しているライブラリのライセンス管理をどうするか﹂はクライアントサイドJavaScriptにかぎらず発生する問題ですが、クライアントサイドJavaScriptには以下の様な特徴があるため問題が複雑になります。 コードが結合、圧縮される場合がある クライアントサイドJavaScriptでは読み込みの速度を上げるため、使用しているライブラリの結合、圧縮を行うことがあります。しかし、この時誤ってライセンス文が捨てられてしまうことがあります。 ソースが外部に公開される クライアントサイドJavaScriptではソー
    クライアントサイドJavaScriptのライセンス管理 | GREE Engineering
    gfx
    gfx 2013/12/11
    リンク

  • 30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場


    ﹁よくわかるFOSSライセンスまとめなんてないよねー﹂と煽られたので3分で書く。 オープンソースライセンスは、以下の3種類に大別される。 代表的なライセンス 改変部分のソースコードの開示が必要 リンクして使う、他のソフトウェアのソースコード開示が必要 GPL (コピーレフト型) ○ ○ LGPL /MPL (準コピーレフト型) ○ × BSDL / MITL (非コピーレフト型) × × 自作のソフトウェアをオープンソースで公開する場合、 コピーレフト型にする場合は﹁GPLv2以上﹂ 準コピーレフト型にする場合は﹁LGPL兼MPL﹂ とするのが無難。非コピーレフト型はMITLのほうがBSDLよりも明確だと言われることが多い︵そしてどちらを選んでも問題ない︶。 ※表の出典は OSS ライセンスの比較および利用動向ならびに係争に関する調査 より詳しく知りたい方へ‥ ライセンスの解釈については、
    30秒でわかるオープンソースライセンスまとめ - kazuhoのメモ置き場
    gfx
    gfx 2013/10/04
    エンジニア必読！
    リンク

  • OSSライセンスの比較および利用動向ならびに係争に関する調査 - 調査報告書

  • TiVo化 - Wikipedia

    TiVo化（英: Tivoization）とは、GNU General Public License (GNU GPL, GPL) のような、ソフトウェアをコピーレフトなソフトウェアライセンスの条件下に組み込むが、ハードウェアの制限により、利用者がソフトウェアの改変版をそのハードウェア上で動作させることを妨害するようなハードウェアDRM、製品を作成することを示す用語である。リチャード・ストールマンがこの用語を作り出した。彼はこの方法によって、GNU GPLが保護するように意図していたソフトウェアの自由の一部が、利用者に認められなくなると主張している[1]。この用語はTiVo社がTiVoブランドのハードディスクレコーダー (DVR) にGNU GPLライセンスのソフトウェアを利用していたにもかかわらず、そのハードウェア設計によりユーザーが改変版ソフトウェアを実行することを積極的に妨害していた

  • OSSライセンス関連情報：IPA 独立行政法人 情報処理推進機構

    オープンソースソフトウエアのラインセンシングと IPR:Intellectual Property Right (知的財産権)についての情報です。 オープンソースライセンスの説明

  • あなたのサイトのJavascriptが自由なソフトウェアのであることを表示しよう！ Javascript License Web Labels登場。


    フリーソフトウェア財団から、JavaScript License Web Labelsという取り組みについての発表があった。これはひと言でいうと、ウェブページ上で使われているプログラミング言語であるJavascriptのライセンスをきちんと表示しようという取り組みだ。なぜそのような仕組みが必要なのか？どうやって使うのか？ということについて今日は説明しようと思う。 ユーザーの了承なしに実行される無数のJavascriptコードたち Javascriptはかつて、ウェブページのちょっとした装飾というような目的で主に利用されていた。それはページの内容に大きな影響を及ぼすものではなく、とてもささやかなものであった。しかし、今は事情がまったく違う。ウェブページに付随するJavascriptは年々大きくなり、Google Docsのようにワープロや表計算までをも実行されるようになった。それはもはやささ
    あなたのサイトのJavascriptが自由なソフトウェアのであることを表示しよう！ Javascript License Web Labels登場。

  • AndroidアプリとLGPLライセンスについて問題ないという解釈のツイート


    m2ym @m2ym これらの記事はライセンスのバージョンをちゃんと示しているし、"GNUの見解"とか謎なこといってないから誠意が感じられる。あのスライドは単にLGPLをdisりたいだけとしか感じなかった 2012-01-27 07:31:03 m2ym @m2ym FSFの活動はソフトウェアエンジニアにとって非常に重要であるから、ビジネスに使えないからいかんとか言って切り捨てるのは自分の首を締めるだけだと思うよ 2012-01-27 07:32:46 m2ym @m2ym AndroidとLGPLに関する私見ですが、アプリケーションが使用しているライブラリを自由に差し替えられる旨を要求するのがLGPLの主旨であることを鑑みると、単純にアプリケーションのJarファイルとライブラリのソースコード︵オプショナル︶を頒布して、︵続く︶ 2012-01-27 08:13:19
    AndroidアプリとLGPLライセンスについて問題ないという解釈のツイート
    gfx
    gfx 2012/01/27
    アプリケーションの.jarがあればソースコードは簡単に復元できるので、「ソースコードを配布しなければならない」とほぼ同じ条件だと思うのですけど。
    リンク

  • Android アプリに LGPL ライブラリを組み込むとソースコード開示義務が発生するらしい: ある SE のつぶやき


    オープンソースライセンスの中でも、GPL ライセンスはソースコード開示義務があるため扱いにくいライセンスです。業務であればまず GPL ライセンスのライブラリは利用できません。 一方、LGPL(Lesser General Public License) ライセンスのライブラリは、一定の条件の元でソースコードの開示義務を負わないため、業務利用も可能となります。 ︵参考︶GNU Lesser General Public License – Wikipedia ですが、Android アプリで LGPL ライセンスのライブラリを組み込むと、必ずソースコードの開示義務を負うとのこと。これを知らないとかなり危険ですね(追記あり・後述)。 詳しくは以下のスライドをご参照ください。 --- 2012.1.27追記 この件について詳細に調べていた方がいたようです。結論としては Android アプリで
    gfx
    gfx 2012/01/26
    ふーむ…。
    リンク

  • 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﹁二次創作同人”小説”﹂に関する記述を追加 著作権の適用範囲 著作権の保
    gfx
    gfx 2011/11/19
    リンク

  • 脱GPLを目指すFreeBSD、FreeBSD 10ではC++標準ライブラリも脱GPL | スラド オープンソース


    原則的には、ソフトウェアからの出力結果は、たとえ使用したソフトウェアがGPLライセンスでも、ライセンスには縛られない(http://www.gnu.org/licenses/gpl-faq.ja.html#CanIUseGPLToolsForNF 参照)から、 GCCでコンパイルしたソフトウェアがGPLの縛りを受けるなんて、ないはずなんだけど。 だったらなんで脱GPL化する必要があるのかと思ってググってみたら http://www.wdic.org/w/TECH/GPLv3 [wdic.org] によると 特許 GPLのコードを使用し、特許が含まれるコードを作成したとする。そのコードはGPL条項に基づいてGPLで公開されなければならない。 GPLv2では、そこに含まれる特許については、特許を持っている人間の裁量に任されており、つまりソースは公開はされるが、特許があるため厳密な意味で自由には

  • 「ソフトを購入する」ということ


    ソフトウェアにお金を払うという行為は、いったい何を意味するのだろうか。ITの詳しい人にとっては“常識”と思えることでも、別の人には“違う”ということがある。 今回は﹁ソフトを購入する﹂という日本語についての筆者の雑感である。ある企業でのコンプライアンス教育と大学教授とやり取りの2つの出来事を紹介しよう。 中堅の部品メーカーにて2年ほど前にある会社の工場内でコンプライアンスの啓蒙教育を行った。その会社はコンプライアンスに積極的に取り組んでいたようだ。2回目の講習の時である。ちょうど筆者がソフト著作権について説明した際、若い女性が質問をした。 ﹁……ということは、例えば自分が秋葉原でソフトを購入したとしても、そのソフトは自分が好き勝手にコピーして友人に渡したりしてはいけないということですか？　でも、そのソフトは私がお金を払ったものですからどう使おうと構わないのではないですか？　おかしくないで
    「ソフトを購入する」ということ

  • オープンソースライセンスの基礎と実務 :: 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戦略統括部 マ

  • 自由なソフトウェアと自由なWeb

    先日、ソフトウェアライセンスの勉強会に参加したり、オープンソースライセンスの議論が炎上白熱したりしているので、俺自身ソフトウェアライセンスについて考える機会が増えたように思う。プロフィールにも書いてある通り、俺はフリーソフトウェアが大好きである。フリーソフトウェアライセンスは（乱立したので）星のかずほど存在するのだが、その中でもやはりフリーソフトウェアという概念を提唱したリチャード・ストールマン等によるGPLを支持せずには居られない。GPLにもいくつかバリエーションが存在するのだが、その中でももっともとんがっている（最も強いコピーレフト条項が盛り込まれた）AGPLの採用事例が少ないように思う。なぜ採用があまり進まないのだろうかと考えた結果、ある重大な事実、特にWeb業界にまつわる事実に気がついたので、今日はそのことについて紹介しようと思う。結論は最後の方にあるが、あきらめずに頑張って読んで

    自由なソフトウェアと自由なWeb

  • 「java-ja 第1.9.2回 チキチキ ライセンスって何ですか？」に参加した。


    先日、﹁java-ja 第1.9.2回 チキチキ ライセンスって何ですか？﹂という勉強会に参加してきたのでレポートしたい。宣伝文がやたらとお茶目︵タイトルも？！︶だが、その日の雰囲気も負けず劣らず楽しいものであったと思う。ライセンスというお固い議題なのに！！である。ちなみに、本ブログでは常々ライセンスについて色々と綴っているが、今回は基本的に聞く側として参加した。︵最後にちょっとだけマイクを握らされて︵？︶しまったけれども。︶ 講師を努めて頂いたのは﹁ソフトウェアライセンスの基礎知識﹂の著者である可知 豊氏。 可知氏のブログ: Placebo Effect 今回の発表資料はこちらにあり、CC-BYで利用可能になっている。︵CC-BYはクリエイティブコモンズライセンス- CCL -のひとつである。CCLについては本ブログでも何度か紹介したので、忘れた人はぜひ復習して欲しい。 *1 *2 *3
    「java-ja 第1.9.2回 チキチキ ライセンスって何ですか？」に参加した。

  • [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を読んでない僕に書かせることにする

    Ruby 1.9.2リリースとWEBrick脆弱性問題の顛末 - 西尾泰和のはてなダイアリー

  • 受託開発とGPL

    GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発（SI）におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない！！というわけで、今日はGPLを受託開発（SI）において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL（とその仲間たち＝LGPL、AGPL）が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対

    受託開発とGPL
    gfx
    gfx 2010/06/03
    リンク

  • OSSライセンスが求める条件とは？


    OSSライセンスを4つに分類してみる70以上の種類が存在するOSSライセンスは、OSIのOSDありきで作成されたわけではありません。中には、各著作権者が自由気ままに記述したライセンス条文もあり、その全貌︵ぼう︶を理解しようとすると絶望的な気分になることもあります。 しかし、いろいろな人がこれらを何とか分類しようと試みています。 前回の冒頭で紹介した﹁Black Duck Protex﹂のコード検査で使用するナレッジベースでは、大きく以下の2種類の属性に分けて登録されています。 この﹁互恵の﹂ライセンス、﹁寛容な﹂ライセンスという見方は、商用のプロプライエタリなプログラムでOSSのプログラムが検出された際に、﹁寛容なライセンスでソースコードの配布を強要されないか﹂、それとも﹁互恵のライセンスだから返礼としてソースコードを配布しなければならないか﹂という点に注目して分類しているようです。 一
    OSSライセンスが求める条件とは？

  • 筑波大学におけるプログラム等と成果有体物の取扱い

    大学が社会からの多様な要請に応えて研究成果の技術移転を図っていくためには、基本的に知的財産の大学への帰属と管理の一元化が必要です。このような考え方に基づき、筑波大学は、平成16年1月には、「筑波大学知的財産ポリシー」を作成し、また、同年4月の国立大学法人化を契機に、知的財産規則、職務発明規程等の整備・改訂を進めてきました。 これまで、本学が制定した知的財産ポリシー及び知的財産規則等では、一部の知的財産については別に定めることとしておりました。そのため、ワーキング･グループを設置し、特に、プログラム、データベース、デジタル・コンテンツ及びノウハウ並びに成果有体物について、検討を重ねるとともに、その結果をもとに、規則等の整備を進めてきました。 これらの知的財産の取扱いについての理解のために、本ホームページを活用していただければ幸いです。

    gfx
    gfx 2009/09/02
    リンク
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.