很多法務在草擬修改合約時，如果手邊沒有「現貨」，那就直接把合約名稱打在網路上或唸給 AI 聽，範本就包山包海源源不絕地讓人可以百裡挑一，再改成公司需要的版本，下班！簡直是天助我也！不過，這下班的前提，也就是「怎麼改」的那一關，像是各合約與標的物性質如何及應該要寫清楚降低風險的地方在哪，這個基礎功還是需要平常對產業與法律知識的累積。

雖說平日裡經手不少科技公司合約，但筆者總是尋尋覓覓，希望能有機會找到一本可以對這些「有點像又不太像」的合約們（銷售？授權？訂閱？服務？）進行比較與分析，最好在中翻英上還可以給客戶一些適當的用字建議。最近閱讀了美國科技業律師 David Tollen 寫的《The Tech Contracts Handbook》，開頭前幾頁立馬見真功夫，把將科技合約分成四大類，分別是：軟體授權 Software Licenses、雲端服務訂閱 Cloud Services Subscription、專業服務 Professional Services、移轉 IP 所有權 Transfer of IP Ownership。

這麼清楚的分類，實在解了我心頭之惑。

雖說必須非常汗顏的承認，目前我整本尚未讀完，但越讀越覺得，年度工作好書「就是這本了」！所以便迫不及待地想先就理解完的部分，寫篇文章跟大家分享。

第一種科技合約類型：軟體授權 Software Licenses

這種型態的合約，是屬於一種著作權的授權行為，因為供應商讓軟體下載至客戶端 On-premise 而涉及了著作權裡的重製權，或是供應商讓經銷商 Distributor 進行分銷，而涉及了著作權裡的散布權。

作者建議，草擬時首當其衝便是要精準定義授權產品 Licensed Product，並在情況限制條款 Condition and Restriction 中清楚表示：客戶僅購買了使用該軟體的權利，而非軟體本身，因此軟體所有權依然屬於開發者或擁有者；建議明示：

「Customer receives no title to or ownership of any copy or of the Product 客戶不取得任何產品或複製產品的所有權」這樣的句子，並且按客戶類型不同，再加上他們在使用上的限制。

同樣，授權範圍條款 Scope Term 的撰寫也是根據客戶類型而定，典型的授權文字像是：「 本廠商向客戶在期限內授予下述權利：Provider hereby grants Customer a license during the Term: 」。例如針對終端使用者 End User ，可能授權內容除了下載 Download、使用 Use 以外，可能會包括重製 Reproduce （可能須限定數量）或是修改 Modify 等；如果客戶是經銷商 Distributor，除了授權期間 Term 外，可能還要談限定區域 geographic territory、專屬與否（exclusive/nonexclusive），當然，授權內容僅是經銷？還是包括重製（如果有，應加上限定目的）甚至轉授權 Sub-license 等等「特定授予權利 the rights specifically granted」。

第二種科技合約類型：雲端服務訂閱 Cloud Services Subscription

大名鼎鼎的 SaaS （軟體即服務）就是其中一種類型啦！作者非常強調在條文裡千萬不要用「License」這種著作權授權的字眼，僅單單使用「Subscription」一詞來表示客戶僅「訂閱」了「遠端存取權限 remote access」，並建議條文清楚載明：

「This Agreement does not grant Customer any right to reproduce, modify, distribute, or publicly display or perform the Software 本協議並不授權客戶任何重製、修改、散布、公開展示或演示本軟體的權利。」

同時，作者也很排斥業界常用的「雲端服務 Cloud Service」一詞，認為這種合約型態應該起名叫「雲端存取 Cloud Access」才避免引人誤解。為什麼呢？因為一般使用到「Service」這個字，想到的是像維護、維修、諮詢等等的 IT 人力服務，可是單純的雲端服務不會提供這樣的人力資源，那是誰來服務呢？問錯了，不是誰！是「啥」！是供應商的電腦軟硬體在提供這樣的服務，那不是用「存取 Access 」一詞更精準嗎？

第三種科技合約類型：專業服務 Professional Services

這類型合約與上述兩種的根本不同在於：這裡廠商提供的是專業「人力」，當然啦，專業人力服務合約經常伴隨著上述兩種型態的軟體合約一起簽訂，可能是一起研發或是提供維修等，不管如何，這裡重點擺在：如何清楚描述這個合約裡的標的：「專業服務」。

關於如何設計這裡的條款，作者指出：「Professional services descriptions can be task-driven or outcome-driven. 專業服務的描述可分為任務導向或結果導向。」任務導向著重於描述清楚供應商提供的活動，而非目標的達成；而結果導向則描述供應商應達成的目標為何，而不著墨於達成的方式。

任務導向的典型寫法像是：

「During business hours, Providers shall staff the help desk with no fewer than 2 technicians. 供應商應於營業時間內提供不少於兩名技術人員進行服務支援。」

而結果導向的典型寫法像是：

「 Providers shall write a software application that conforms to the Technical Specifications. 供應商應寫出符合本技術規格的軟體應用程式。」

那該怎麼決定呢？一般而言，任務導向對供應商有利（我人給你，那到底做不做得成，你家的事），但對客戶而言，自然比較傾向結果導向（你人來，就給我把事情做到好為止）。但當客戶對所需的服務並不能夠在簽約當下確定，或許需要的就是任務導向的描述寫法；那如果考量到比較複雜專案的所需技術的變化性，以及供應商可能對目標的達成有「省錢之道」的情況下，或許結果導向的定義方式可以為供應商帶來較多的利潤。

第四種科技合約類型：移轉 IP 所有權 Transfer of IP Ownership

此種合約型態是讓客戶獲得標的物「所有權」（這可以是軟體，或資產 Assest、發明 Invention 或交付成品 Deliverables — 老規矩，第一步就是要定義清楚）。作者指出，簽訂這種合約的客戶應該要先思考：真的有必要取得所有權嗎？還是使用授權型態的合約就夠用？同時，無論是否取得所有權，客戶都不能忘記要與提供對象簽訂好關於標的物的保密合約 NDA 或保密條款 Confidentiality Clause。

而在設計所有權條款 Ownership Term 前，作者提醒，法務們必須要清楚兩種主要取得所有權的法律架構：轉讓 Assign 與職務上著作 Work for hire（PS 這就是台灣著作權法第 11、12 條透過事前約定，讓客戶基於雇傭或出資聘人之法律關係而原始取得著作人地位）——對客戶而言，後者的原始取得，當然比較保險。

• 推薦閱讀：章忠信教授《著作人格權不能讓與，還能約定由雇用人當著作人嗎？》談著作權法第十一條及第十二條的適用情形。

可要注意的是，職務上著作僅限於著作權，不適用於專利或其他 IP 產品，因此在約定職務上著作的條款同時，欲取得所有權的出資人，經常準備了「備胎條款」—— 轉讓條款，亦即在根據適用法律下無法被認定為是職務上著作時，出資人有權要求權利人將所有權移轉給自己。因這本書是按美國法寫的，所以閱讀本章的同時，可以認識到美國法認定為職務上著作的情況，並相應地設計出條款。

作者將所有權條款分為三大類：第一類是僅限定於移轉著作權的狹義移轉 Limited Transfer ，這很常與提供專業服務合約型態一起並存，也就是客戶要求供應商提供人力去研發，然後研發成功後再將產品的著作權轉讓給自己。第二類是包山包海移轉所有權利（包括專利）的廣義移轉 Broad Transfer ，這種類型很常出現在合作研發協議裡，或是被當作上一段講的「備胎條款」：也就是公司跟自己「請」的人之間簽署。而第三類，便是針對這些「請」的人—受雇人 Employees 或承包商 Contractors （著作權法上用語是：受聘人）— 來設計的條款，當然啦，這前提是雙方的聘雇合約有效囉！

在目前越來越複雜的合約型態裡，更常見的其實是混合以上這四大類型的綜合性合約 Combination Agreement，例如，第二種雲端服務加上第三種專業服務來提供技術支援。本文只是根據筆者就本書第一部分（後面還有第二及第三部分）最印象深刻的地方做一點粗淺的討論，日後還會就其他部分繼續發文分享。