タグ

2011年3月10日のブックマーク (6件)

  • 法務・知財

    情報サービス取引 同業者間取引 知的財産権法 経営資源管理 サイバーセキュリティ 法務・知的財産関連政策 法務研修テキスト 報告書 JISAブックレッツ14「デジタル時代のIT法務と契約実務」2022年11月1日新発売! 今日必要とされる法務・契約上の知識を多角的視点から編纂しています。 ◆内閣官房・公正取引委員会 「労務費の適切な転嫁のための価格交渉に関する指針」の公表について ~労務費の転嫁に係る価格交渉について、発注者及び受注者がそれぞれ採るべき行動/求められる行動を「12の行動指針」としてまとめたものです。 ◆公正取引委員会 「労務費の適切な転嫁のための価格交渉に関する指針」と「取引適正化・価格転嫁促進に向けた取組」についての説明動画 ~YouTubeで配信中です。 情報サービス取引 システム開発・運用取引 JISA報告書「JISAソフトウェア開発委託基モデル契約書2020」 報

    ryuzee
    ryuzee 2011/03/10
    システム開発の契約書のサンプル
  • スライド 1

    ソフトウェア開発過程における 文書の法的意義 Stage E シンポジューム ;ユーザとベンダ間の紛争を解決するために ソフトウェアタグはどのように機能するか? 2009/11/27 Copyright Ⓒ 2009 Akira Uchinuno 1 東京経済大学 内布 光 目 次 はじめに 1.ソフトウェア開発取引の意義 2.法的紛争の背景 3.開発過程における文書の意義 4.ソフトウェアタグと法的効果 まとめ (「おわりに」に代えて) 2009/11/27 Copyright Ⓒ 2009 Akira Uchinuno 2 はじめに  従来から、ソフトウェア開発取引(*)を巡ってユーザ・ベンダ間 でトラブル・法的紛争が絶えない (*) 主としてユーザの業務処理用ソフトウェア(アプリケーション)の開発 契約形態は「請負型」が主流・・・・ユーザ・ベンダの利害が対立 「派遣型」「準委任型

    ryuzee
    ryuzee 2011/03/10
    ソフトウェア開発過程における文書の法的意義に関する資料。最近のソフトウェア開発、特にアジャイルやスパイラルモデルでの紛争については友達の弁護士に聞いてみよう。
  • 情報システム・ソフトウェア取引トラブル事例集

    0 2010 3 BP 1 IT 18 6 18 9 18 < > 19 SaaS/ASP < > 21 2 3 ..........................................................................................................................................................................1 1. ............................................................................................................................5 1-1. .....................................

    ryuzee
    ryuzee 2011/03/10
    システム開発の契約に関するトラブル事例集。
  • 瑕疵 - Wikipedia

    売買などの有償契約において、契約の当事者の一方(買主)が給付義務者(売主)から目的物の引渡しを受けた場合に、その給付された目的物について権利関係または目的物そのものに瑕疵があるときには損害賠償などの責任を負う(561条以下。売買以外の有償契約への準用につき559条)。これを担保責任というが、このうち目的物そのものに隠れた瑕疵があった場合の責任を瑕疵担保責任という(570条、566条)。 瑕疵担保責任でいう隠れた瑕疵とは、買主が取引上において一般的に要求される程度の通常の注意を払っても知り得ない瑕疵を指し、買主は善意・無過失であることが必要である(通説・判例)[1][2][3]。瑕疵は取引通念からみて通常であれば同種の物が有するべき品質・性能を欠いており欠陥が存在することをいう[4][5][3]。契約に先立って売主が見や広告を用いて一定の品質や性能を保証した場合には、その基準に至らなければ

    ryuzee
    ryuzee 2011/03/10
    瑕疵と瑕疵担保責任。法的性質については契約責任説(債務不履行責任説)と解するのが有力説。商法526条も参照
  • 2011-03-10

    後ほど正式にデブサミサイトに掲載されますが、速報としてこちらにアップします ●ベストスピーカー賞 18-B-5 及川卓也「クラウド時代のソフトウェア開発」 17-B-4 鈴木雄介、小川明彦、吉羽龍太郎、大澤俊介 「チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか」 17-B-3 小川明彦、阪井誠「チケット駆動開発〜タスクマネジメントからAgile開発へ〜」 ●ベストバリュー賞:同点のため通常1組のところ2組 17-E-7 デブサミオフィシャルコミュニティから選出のLT大会2011 18-B-7 野村恭彦 市谷聡啓 橋大也 川口恭伸 平田守幸 岩切晃子「未来のために私たちの帆を立てよう」powered by DevLOVE ●特別賞:セッション部門 18-A-3 伊藤直也「スマートフォン向けソーシャルアプリケーション

    2011-03-10
    ryuzee
    ryuzee 2011/03/10
    すごい。聴きに来てくださった方ありがとうございます
  • 2011年版「あえて今、『システム内製』の勧め」

    50歳を過ぎたせいかどうか、元々しっかりしているとは言えなかった記憶力が怪しくなってきた。 つい先日も「はじめまして」と言いながら名刺を差し出すと、「以前お目にかかっていますよ」と笑われてしまった。仕事柄、一度会った人のことは忘れないように心掛けているのだが、これはまずい。 原稿を書いていても、途中で「同じことを前に書いたのではないか」「この逸話はすでに使ったはず」と気になってくる。しかも、いつ、どこに書いたのかをなかなか思い出せない。奥田英朗氏の小説集『空中ブランコ』に、同じことを書いてしまうのではないかと悩む女流作家が登場する。あれほどひどくはないが、似た心配をしてしまう。 題名でお分かりかと思うが、この原稿で書きたいのは、自社で利用する情報システムはできれば内製したほうがよい、ということだ。同じ主張を何度か書いた記憶がある。気になっているのは、次のような言い回しに関してである。 「ク

    2011年版「あえて今、『システム内製』の勧め」
    ryuzee
    ryuzee 2011/03/10
    競争力の源泉となるシステム=内製すべし、誰が作っても同じようなシステム=SaaSや外注で可。じゃダメなの?