設定要替換的判決書內文
臺灣臺中地方法院民事判決 94年度訴字第1079號
原 告 永大數位動力股份有限公司
法定代理人 丙○○
訴訟代理人 林士傑律師
複代理人 陳世川律師
被 告 戲谷資訊網路科技股份有限公司
法定代理人 乙○○
訴訟代理人 武燕琳律師
複代理人 甲○○
上列當事人間請求損害賠償事件,本院於95年9月12日言詞辯論終結,判決如下:
主 文
原告之訴及假執行之聲請均駁回。
訴訟費用由原告負擔。
事實及理由
壹、程序方面:按當事人得以合意定第一審管轄法院,但以關於由一定法律關係而生之訴訟為限。
前項合意,應以文書證之,民事訴訟法第24條定有明文。
本件依卷附軟體開發合約書第10條之約定,兩造已合意就本合約訟爭事件,由本院為第一審管轄法院,則本院就系爭訴訟事件有管轄權,合先敘明。
貳、實體部分:
一、原告主張:㈠兩造於民國93年7月20日簽訂軟體開發合約書及軟體使用授權合約書,約定由被告承攬原告之「www.avgame.com.tw」網站資料庫及網頁開發等工作,其中開發合約書標的金額為新台幣 (下同)92 萬元整、授權合約書為28萬元 (以上均未稅),並於軟體開發合約書第2條約定:「㈠系爭規格書訂於簽約日起15日內經甲方 (即原告)確認後完成。
㈡系統交付訂於系統規格書完成60天內完成。
㈢系統驗收及教育訓練訂於交貨後30日前完成」。
雙方簽訂合約後,原告已依約支付第一期款189,000元之定金 (含稅),不料被告事後提供之系統需求規格書並不符合原告之需求,幾經溝通後雙方同意改採UML格式製作,原告於93年8月26日寄送UML範本予被告,雙方乃於93年9月7日簽訂補充合約,除同意並確認主要功能需求及規格書改採UML格式製作外,並同意合約開發進度時間由93年9月7日重行起算,原告始同意另預付部分第二期款項96, 600元 (含稅)予被告,然而,被告事後遲至同年10月28日方寄送錯誤之規格書予原告,經原告反映後,原告直至93年11月8日方再收到被告寄送之規格書,但規格書之內容應包含「使用者案例」 (Use Case Diagram)、「循序圖」(Sequence Diagram)、「類別圖」 (ClassDiagram)、「元件圖」 (Component Diagram)及「ER-Model」五部分,然被告於93年11月8日所提供之規格書,內容多處缺失,除全部欠缺ER-Model與元件圖外,其餘主要缺失如下:其一,前台部分 (即外部使用者使用之功能):⒈使用案例不完整,細部功能部分皆無使用案例,與後台功能部分對照後,更可知前台主要功能底下之細項功能之使用者案例部分係被告漏未製作,而非無須製作。
⒉缺少類別圖,前台之各項功能,被告均完全未製作類別圖。
⒊循序圖與流程名稱有錯誤,無法配合;
其二,後台部分 (即原告內部人員管理該平台所使用之功能):⒈使用案例存有缺失。
⒉「類別圖」之內容依原告所提供之範例所示,所應記載者應為程序處理之步驟,而非欄位之名稱,惟被告之規格書中,後台之類別圖內容所載者僅為欄位之名稱,全部錯誤。
⒊除「會員管理」有製作循序圖外,其餘「產品管理等」7個功能皆無循序圖。
原告遂於同年11月18日以電子郵件通知被告應補正該規格書供原告確認,惟迄今被告均未再提出任何一份規格書,是被告就雙方合約約定之第1項工作,至今仍無法完成,原告已通知被告補正,惟被告均置之不理。
㈡被告雖一再辯稱,其於93年11月8日提出之規格書內容已符合債之本旨,然本件規格書經雙方合意送交東海大學鑑定,鑑定報告書第2點載明:「依原告意見狀之鑑定第1條UML 缺失總表所示,所交付的系統規格書並不完整,93年7月20 日與93年9月7日所定的規格並未完全列於系統規格書當中,故系統規格書不符合上開契約約定意旨」,由此可知,被告並未依債之本旨提出給付,乃係可歸責於被告而致本件發生遲延。
因被告一直無法提供雙方確認的「系統規格書」就逕行開發系統,原告基於順利完成工作、以配合原告上市,俾減少因被告工作遲延造成之損失之考量,安排人力積極協助被告測試系統功能,並匯總報告通知被告,但此協助的本意卻遭被告曲解為一直新增功能、變動需求,導致系統開發延遲的主因,然系統規格書既尚未確認,又何來變更需求?且查被告早已遲誤雙方約定之完工日期,被告仍主動於94年1 月7日寄發電子郵件通知原告,向原告確認同年1月25日將完成全部工作,並應於同年1月26日實施系統安裝及教育訓練、於同年1月31日雙方檢討問題等,原告為免投入之時間及金錢完全白費,而勉為接受,詎被告又無法完成,甚至於94年2月23日以電子郵件告知原告其所完成之工作情形,沒想到完成度僅有百分之30。
而查被告既已主動表明其可於94年1月25日完成工作,則其未能如期完工即應負給付遲延之責,原告除多次催告被告外,並於94年4月1日以第268號存證信函催告被告若能於94年4月15日前完成工作經原告測試無誤,則原告可不向其請求損害賠償,然被告仍未能如期完成工作,而查本件雙方乃以工作於特定期限完成或交付為契約之要素,被告非於一定時期為給付不能達契約之目的,依民法第255條規定,原告得不經催告即解除雙方契約,原告亦已於94年4月19日以台中逢甲郵局第332號存證信函通知被告解除契約,並送達於被告,依法即生解除契約之效力,原告並得依民法第502條及第231條規定請求損害賠償。
而原告與被告簽立軟體開發合約書及軟體使用授權合約書,其中「軟體使用授權合約書」之性質,乃與軟體開發合約書屬契約之聯立,若軟體開發合約之內容無從履行,該授權軟體合約亦無從期待可能單獨履行,原告依法解除軟體開發合約,亦得同步解除與之聯立之軟體使用授權合約書。
㈢本件係因可歸責於被告之事由而有遲延給付之情形,即屬可歸責於被告之債務不履行,原告並得請求損害賠償,玆將賠償之金額計算如下:其一,原告解除契約後,已給付之定金及預付之費用共285,600元及利息應返還原告;
其二,原告因本合約而著手製作相關產品機器及支付人事工資,卻因被告之債務不履行,除相關產品皆已無法使用外,相關機器設備工人皆閒置而無法使用,而已導致原告之損害,且與被告之債務不履行有因果關係,其中包括:⒈免費卡80,000張共285,600元。
⒉付費卡10,000張共78,225元。
⒊伺服器機器設備折舊:710,000(元)÷72(月)×5(月)=49,305元。
⒋人事薪資費用:20,000(元)×2(人)×9(月)=360,000元;
其三,原告本預定網站應於93年12月起開始營運,且已著手相關設備之購置,卻因被告之債務不履行,而無法獲得預期之利益,暫以每月6萬元計算,至94年4月30日止為30萬元。
是綜上原告所得向被告請求回復原狀及損害賠償之總金額為1,358,730元整,屢向被告交涉均不得要領,為此依承攬契約之法律關係提起本訴等語。
㈣原告訴之聲明:⒈被告應給付原告1,358,730元整及自起訴狀繕本送達翌日即94年5月26日起至清償日止按年息百分之5計算之利息;
⒉訴訟費用由被告負擔;
⒊原告願供擔保請准宣告假執行。
二、被告則抗辯以:㈠原告向被告定作之軟體系統,係以原告於93年7月20日前所提供之系統需求為範圍,報價單亦係依雙方上開確認範圍,而於簽約當時,原告並未主張附件一所示需求內容不完整,亦未表示需以UML製作系統規格書、細項功能圖,嗣因原告要求改以UML格式製作系統規格書,雙方始於93年9月7日重新合意確認需求,被告雖同意以UML格式製作系統規格書,然並未同意開發時程要按原約定重行自93年9月7日起算,亦未提到UML一定要具備「使用者案例」、「循序圖」、「類別圖」「元件圖」、「ER-Model」五種內容,且依93年9 月7日契約,亦無法解釋成被告同意按照原93年7月20日契約所定時間提出系統規格書,因為依原告要求改以UML格式製作規格書,已經不可能於93年9月7日以後15日內提出,苟如原告所言須於15日內提出系統規格書,則自93年9月7日起算,被告應於93年9月22日提出系統規格書,然被告於93年11 月8日提出,原告亦未異議;
苟系統規格書如原告所言有重大缺失,何以原告拒絕簽認系統規格書後,仍繼續提出新的需求要求被告製作?進者,本件系統開發直至94年4月間,原告猶指示要增加經銷商功能,顯然原告主觀認為系統規格書不符伊期待,卻不影響原告開發之目的,雖學理上UML有9種圖形:使用個案圖、循序圖、合作圖、狀態圖、活動圖、類別圖、物件圖、元件圖、部署圖,但提供給系統使用者觀看的只有使用個案圖、循序圖、合作圖、狀態圖、活動圖五種,元件圖乃專給「系統開發者」、「系統整合者」使用,原告不屬於系統開發者或系統整合者,故依被告認知,既未同意製作元作圖,自無必要製作元件圖給原告。
關於「影音館」、「購物館」部分,確實為雙方93年7月20日訂約時所無,而係原告於93年8月10日由原告函告被告要求網站區分為「遊戲館」、「影音館」、「購物館」,被告始將之加入93年8月第一次提交之規格書內;
於93年8月24日原告又要求增列「影音館」限台中線上會員,故雙方於93年9月7日訂約確認時,才會有「影音館」、「購物館」,惟其內容一直修改,原告在系統開發過程中需求增增改改、反覆無常,如此善變之定作指示,實不可歸責被告未製作詳細正確符合原告期待之系統規格書。
本件被告曾架設網站提供原告上網測試,亦同意於94年4月15日前南下台中作安裝測試,但原告卻要求被告將原告在94年4月2日以後提出來的需求全部做成UML,以及所有測試、教育訓練、細項需求規格書全部文件均需於安裝時完全提出,被告表示不可能於4月8日受通知,而於4月15日將上開文件製作完成,原告便拒絕安裝測試。
此後,被告又於94年4月26日發函表示請原告於5月1日前提供相關主機,被告願南下進行測試,然原告仍置若罔聞,本案確實已經進行到可安裝測試階段,原告卻仍以規格書未提出細項功能規格等文件不足之理由拒絕,本件債務不履行實可歸責於原告。
㈡關於東海大學軟體工程與技術中心製作之鑑定意見,未衡量本件被告係以雛型法開發軟體,且部分鑑定意見未針對問題回答,部分鑑定意見回答了沒問的問題,甚至有前後矛盾之處,詳如下述:⒈查雙方雖於93年9月7日重新合意確認需求書,被告並未同意開發時程要按原約定重行自93年9月7日起算,反而強調因此導致開發時間延宕,不可歸咎於被告,況雙方於93年9月7日最後確認後,原告又不斷以e-mail更刪系統需求內容,被告如何提出增加工時與書面資料?更進者,依合約第13條第2項規定「系統規格書確認後」原告又有修改時,被告始得提出增列工時費用或時限權利,惟本件尚未達系統規格書確認階段,被告自無法動用此項權利,鑑定意見卻謂被告如同意應於60日內完成云云,與本件契約及事實經過不符。
⒉鑑定意見一方面肯定被告所述UML格式及內容、用途,他方面又認為依原告所提文件,原告認為不符被告所提系統規格書就不符合契約所定,此等邏輯,被告難以接受。
又鑑定意見既承認UML格式沒有ER-Model,僅有使用者案例圖、順序圖、合作圖、狀態圖、活動圖5種適合非技術人員討論溝通用,其餘類別圖、物件圖、元件圖、部署圖鮮少與委託人溝通,則被告交付之系統規格書本不需具備ER-Model、類別圖、物件圖、元件圖、部署圖,加上原告並未要求被告交付之系統規格書需具備合作圖、狀態圖、活動圖,是被告所交付系統規格書未如原告所述之瑕疵。
至於鑑定報告認為粗糙部分,係因原告程式需求不明確,定作人無法明確指示情形下,被告也無法據此開發出詳細具體之程式需求,故本件被告以雛型法繪製案例圖,應無不可,鑑定單位顯然刻意忽略或未就原告定作指示之模糊列入思考範圍。
至於鑑定報告所謂欠缺「細項資料」,原告應舉證證明細項資料為坊間軟體開發業者必備之文件,且就兩造93年7月20日契約及93年9月7日確認事項中,從未涵括所謂「細項需求」,另關於鑑定意見表示「使用者案例圖」欠缺「權限管理」部分,於93年9月7日雙方確認開發事項內容中,原告未曾提及要求模組的「權限管理」圖,被告焉有必要額外於系統規格書製作「權限管理」。
⒊鑑定單位於附件三逐一就原告所提電子郵件要求列表說明時,既列明有兩封電子郵件屬於增加需求,卻於本文說明刻意簡化為僅有部分補充部分修改,不僅前後矛盾,其公正性更啟人疑竇,且就鈞院及兩造未詢問之問題回答,被告自難甘服。
㈢本件瑕疵乃定作人指示不明確所生,原告不得主張民法第493條、第494條、第495條之權利,縱依第497條第1項規定,原告可定相當期限請求被告改善其工作或依約履行,惟原告與被告多次郵件往來,均未定相當期限命被告改善,依原告於94年4月1日提出之存證信函,原告並未定期催告修補瑕疵,反是拒絕收受,從而原告在危險尚未移轉前,本無瑕疵修補請求權,自不得要求減少報酬。
縱 鈞院仍認為本件並無定作人指示瑕疵、亦無未定期限要求改善,則依民法第494條但書,系統規格書瑕疵並非重要,原告仍不得解除契約。
倘 鈞院仍認可歸咎於被告時,被告亦得主張民法第259條第1項第3款及民法第511條,主張原告已受領部分給付,就此部分原告縱欲解除契約,仍應照受領時之價額以金錢償還之,如 鈞院認為原告並未受領,則依民法第511條主張定作人應賠償承攬人因契約終止所生之損害。
本件契約並非以工作於特定期限完成或交付為契約之要素,亦非屬於一定時期為給付不能達其契約之目的之定期性給付,且本件債務不履行係可歸責於原告,原告不得解除契約等語。
㈣被告答辯聲明:⒈原告之訴駁回;
⒉訴訟費用由原告負擔;
⒊如受不利之判決,被告願供擔保免為假執行。
三、下列事實為兩造所不爭執,本院採為判決之基礎:㈠兩造在93年7月20日訂立「軟體開發合約書」及「軟體使用授權合約書」,如原告起訴狀所附原證一、二 (其中軟體開發合約書即如送請鑑定機關參酌之附件一)均為真正。
㈡軟體開發合約書第一條 (一)約定「『www.avgame.com.tw』網站之內容依據甲方系統需求 (詳附件一、二)開發」,其中附件一、二為被告答辯狀所附被證一之報價單及功能說明表。
㈢兩造事後另於93年9月7日重新合意確認需求,如被告答辯狀所附被證四之確認需求約定書 (如送請鑑定機關參酌之附件二)為真正。
㈣兩造於93年9月7日重新合意確認需求並簽訂確認需求書後,被告於93年11月8日交付重新確認需要之系統規格書予原告,送請鑑定機關參酌之附件三「被告交付系統規格書」為真正。
㈤原告於93年9月7日重新合意確認需求並與被告簽訂確認需求書後迄94年4月2日止,曾陸續多次寄發如送鑑定機關參酌之附件四「原告陸續交付被告之電子郵件」為真正。
四、法院之判斷:本件之爭執要點厥在於是否因可歸責於被告之事由致給付遲延、原告因此得以解除契約並請求損害賠償?亦即:系爭契約對於被告所負給付義務之期限約定如何?又被告於93年11月8日所交付之系統規格書如有瑕疵是否構成給付遲延?原告在93年9月7日迄94年4月2日所寄發予被告之電子郵件有無要求變更原本需求、是否影響被告工作完成期限?茲說明本院判斷結果如下:㈠兩造在93年7月20日訂立「軟體開發合約書」及「軟體使用授權合約書」後,因雙方對於系統需求未能達成合意,乃另於93年9月7日重新確認需求並簽訂確認需求約定書,除重新確認原告之需求功能外,另於確認需求約定書開宗明義載明「本公司 (指被告)已依雙方所簽訂之軟體開發合約書,第二條第一項所定,於簽約日起15日內製做出系統規格書,迄今尚未得到確認,並於93年8月26日AM11:10收到貴公司 (指原告)所寄發AV GAME功能修改資料000000-0檔,文內並要求我方 (指被告)修改規格書製做格式,我方針對貴公司所提出之需求予最後確認,因此而致開發時間遭延宕,不可歸責於本公司之責。
本公司將依本次需求確認,重新製做規格書〈使用UML格式〉,貴公司應於送交規格書次日起算三日內,支付款項 (指第二期款),若有修改,則於修改完成日之次日,支付合約所載第二期款項,並不得另行再修改需求確認之功能。」
等語,為兩造所不爭執,並有上開軟體開發合約書及確認需求約定書等件影本在卷足憑。
㈡兩造於93年9月7日重新確認需求並簽訂確認需求約定書後,被告於93年11月8日交付系統規格書,原告認為規格書有瑕疵要求被告修改,但被告迄未修改即逕行開發軟體,原告隨即配合安排人力積極協助被告測試系統功能,並匯總報告通知被告,詳如兩造所不爭執之「原告陸續交付被告電子郵件」所載 (即送請鑑定機關參酌之附件四),已據原告具狀陳稱在卷 (起訴狀參照)。
又被告抗辯原告所寄送之電子郵件內容多次要求修改原先確認之需求功能等情,雖為原告所否認,然而,本院依兩造合意送請東海大學軟體工程與技術中心鑑定結果,原告所寄送被告之電子郵件內容,其中於93年11月1日、93年11月2日、93年12月16日、93年12月24日(兩次)、94年1月12日 (兩次)、94年1月18日、94年2月23日、94年2月24日、94年3月24日、94年4月2日等,分別要求被告修改或增加需求,有東海大學軟體工程與技術中心95年6月15日鑑定文件附卷可稽,是原告於93年9月7日重新確認需求後,又要求被告修改、增加需求功能等情,應堪認定。
又本件規格書如經確認後不再做任何修改,則軟體開發工作所需時間可以正確決定下來,但若軟體開發期間需求再做變更,則因修改而影響到之軟體必須暫停開發,直至需求再次確認之後,方可繼續進行軟體開發,直至完成,而本件原告所作上述修改、增加需求功能之要求,確實會延後被告完成交付軟體時間等情,亦有上述東海大學軟體工程與技術中心鑑定文件在卷足憑。
又被告對於原告所作上述修改需求功能之要求,多已配合修改開發軟體程式等情,亦據兩造於本院95年8月29日言詞辯論時陳稱在卷。
㈢是兩造於93年9月7日重新確認需求後,依其各自對於系爭契約履行所作處置、反應可知:其一,被告於93年9月7日重新確認需求後逾15日,始於93年11月8日交付系統規格書予原告,甚且原告認為被告所交付之系統規格書並不完整 ( 上開東海大學軟體工程與技術中心鑑定文件參照),但原告事前既無要求被告應在一定期間內交付系統規格書,事後更未要求、等待被告提出完整、無瑕疵之系統規格書,即任由被告逕為進行軟體開發工作,並配合安排人力積極協助被告測試系統功能,以及匯總報告通知被告,由此顯見被告履行交付系統規格書義務之時間,對於原告而言,已無足輕重,甚且,原告更已同意被告在提出完整無瑕之系統規格書前即可逕為進行軟體開發工作。
其二,兩造於93年9月7日重新確認需求時在確認需求書內明文約定「本公司 (指被告)將依本次需求確認,重新製做規格書〈使用UML格式〉,…若有修改,則於修改完成日之次日,支付合約所載第二期款項,並不得另行再修改需求確認之功能。」
等語,此項不得再修改需求確認功能之約定,應為原先在93年7月20日所訂立之軟體開發合約書第13條第2項關於原告有權要求變更修改需要之特別約定,而排除原契約關於原告可要求修改需求之約定。
然而,被告對於原告在93年11月1日、93年11月2日、93年12月16日、93年12月24日 (兩次)、94年1月12日 (兩次)、94年1月18日、94年2月23日、94年2月24日、94年3月24日、94年4月2日分別要求修改增加需求等均予配合,根據被告長期以來多次配合原告要求修改需求之行為,亦已默示原告事後仍可要求修改需求之權利。
其三,原告在93年9月7日至94年4月2日為此,長達超過六個月期間內所發送予被告之電子郵件,或補充原約定需求之細節或修改、增加需求內容,並未就被告履行義務期間有所催告,況且原告所作上述修改、增加需求功能之要求,確實會延後被告完成交付軟體之時程,亦據東海大學軟體工程與技術中心鑑定在案,是客觀上,亦不容原告一方面要求被告配合修改需求內容以增長被告所需完成交付工作之時間,一方面又苛責被告仍應按93年7月20日所簽訂軟體開發合約書第2條所約定之開發時程履行其義務。
由兩造自93年9月7日重新確認需求後,迄94年4月2日原告寄發原證五號存證信函催告被告完成工作為止,長達超過六個月期間內,當事人一方多次要求修改、增加軟體之需求內容,另一方亦多已配合修改軟體程式以迎合需求,而該修改需求又勢必延長軟體開發完成交付之時間,兩造之客觀行為顯亦已默示同意本件軟體開發完成交付時間應為不定期。
㈣承上所述,本件被告所負軟體開發完成交付義務之時間應為不定期,則原告雖曾於94年4月2日送達被告如原證五號所示之存證信函,催告被告應於94年4月15日前完成相關工作,但本院審酌原告於94年3月24日以及同年4月2日仍以電子郵件要求被告修改需求內容等情,有上開東海大學軟體工程與技術中心鑑定文件附卷可按,再參酌兩造原先在93年7月20日簽訂之軟體開發合約書第二條關於標的物開發時程之約定內容「㈠系統規格書訂於簽約日起15日內經甲方確認後完成(但被告所負交付系統規格書義務之履行,對於本件原告而言已無足輕重,詳如前述),㈡系統交付訂於系統規格書完成60天內完成…」以觀,原告於94年4月2日始送達被告催告完成時間之存證信函,即要求被告應於94年4月15日完成全部工作,其催告被告完成工作之期間難謂相當,況且,被告事後亦於94年4月15日以被證七號所示之存證信函要求原告準備機器實機測試安裝,原告隨即於94年4月19日 (仍非完成工作之相當期間)以原證六號存證信函送達被告表示解除本件契約,於法尚有未洽,自不發生解除契約之效果。
且本件被告所負完成軟體開發義務之時間既為不定期,原告甫於94年3月24日及同年4月2日要求被告配合修改需要,隨即以存證信函要求被告應於不相當期間之94年4月15日完成交付工作,並進而於94年4月19日再次送達被告存證信函表示解除系爭契約,被告如擔心其將來完成工作無法收取報酬而不願繼續開發軟體程式,要屬通常之反應,是本件被告縱迄未能完成交付所開發之軟體程式,亦屬可歸責於原告之事由所致,尚不能責令被告負給付遲延之損害賠償責任。
㈤至於東海大學軟體工程與技術中心鑑定文件,認為「…不過若乙方 (指被告)同意合約所示之15日內完成系統規格書,60 天內完成整個系統並交付於甲方 (指原告),則應全力於合約時程內完成工作,若甲方需求修改的範圍太大,則乙方應提出增加工時與費用的書面資料,與甲方共同商討並完成工作」以及「…但是,依合約書第十三條第二項規定,甲方有權利要求乙方修改相關文件內容,乙方不得異議。
且乙方有權利提出增加費用與時程的權利,但法院提供給我們的資料並未看到乙方所提出的相關文件證明。
乙方在回應甲方修改之請求應快速處理,決定同意或不同意或需增加經費,不該因甲方提出修改,做為工作延誤之唯一理由」等語,逾越本院所囑託鑑定範圍而自行就契約權利義務內容表達個人意見,已有不妥,並無拘束法院之效力。
況且,兩造原先於93年7月20日訂立之軟體開發合約書第13條第2項,約定原告有權要求修改需求內容乙節,已在93年9月7日兩造重新確認需求時,重新明文約定原告不得再次要求修改需求內容等語,顯已排除原先軟體開發合約書第13條第2項之適用。
但考慮兩造重新確認需要後,原告未求被告提出完整之系統規格書之前,隨即同意被告逕為進行軟體開發工作,而被告自93年9月7日重新確認需求以後,亦長達超過半年多次配合原告修改需求之要求,又原告要求修改需求之結果,勢必增加被告完成軟體開發之時間,是自兩造重新確認需求後之客觀行為以觀,已另形成一新的默示合意:一方面原告有權修改需求內容、而另一方面被告完成交付軟體開發之時間則為不定期,如此解釋,兩造間之權利義務始能均衡並符合誠實信用原則。
而鑑定文件關於上述意見,則係援引早已在93年9月7日兩造重新確認需求時所排除適用之軟體開發合約書第13條第2項約定,而自行在受囑託鑑定事項範圍之外,詮釋契約之權利義務,因與本院上開事實認定不符,尚不足採,併予敘明。
㈥從而,原告主張解除系爭契約要求被告負回復原狀及給付遲延之損害賠償責任,並據以請求被告給付1,358,730元,及自本件起訴狀繕本送達翌日即94年5月26日起至清償日止,按年息百分之5計算之利息,洵屬無據,應予駁回。
又原告之訴既無理由而應予駁回,其假執行之聲請,即失所附麗,應併予駁回。
五、訴訟費用負擔之依據:民事訴訟法第78條。
中 華 民 國 95 年 9 月 29 日
民事第一庭 法 官 王永春
以上正本係照原本作成
如對本判決上訴,須於判決送達後20日內向本院提出上訴狀中 華 民 國 95 年 9 月 29 日
書記官
還沒人留言.. 成為第一個留言者