1. <tt id="5hhch"><source id="5hhch"></source></tt>
    1. <xmp id="5hhch"></xmp>

  2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

    <rp id="5hhch"></rp>
        <dfn id="5hhch"></dfn>

      1. 淺議拆封許可合同的認定

        時間:2024-08-01 02:57:37 法學畢業論文 我要投稿
        • 相關推薦

        淺議拆封許可合同的認定

        摘要:作為早期采用契約形式保護軟件利益的延續,拆封許可合同今天廣泛存在并成為軟件著作權人權利行使的主要途徑之一。拆分許可合同本質上是軟件著作權人與用戶之間訂立的格式化的著作權許可使用合同,其效力同時受到合同法和著作權法的雙重規范。   關鍵詞:拆封許可合同;軟件;著作權   Abstract: Following the way adopted in the early days to software protection by contract law, shrink-wrap license, one of the main ways that used by the copyright owner in exercising its copyright, is still used extensively. It is a copyright license contract established between copyright owner and software user in essence. Its enforceability would be influenced not only by the rules for standard contract that established in contract law, but the copyright itself once have been licensed.   Key words: Shrink-wrap License; Software; Copyright; Nature; Enforceability
          
          拆封許可合同(即英文中的“Shrink-wrap License”)的稱謂,在英美國家,源自于它們最初被置于軟件包裝盒外的熱縮塑料包(shrink-wrap)之下[1],用戶一旦打開軟件封裝,即可獲得對相應軟件的有條件使用權;而在我國,學者們基于該類合同的訂立與購買者的拆封行為的緊密關聯,即合同訂立的承諾以“打開軟件封裝”這一特定行為完成,便形象地稱其為拆封許可合同。
          拆封許可合同雖已成為軟件交易中不可缺少的組成部分,但到底什么時候被首先采用,并不清楚[2]。已經明確的是,它是采用合同形式實現軟件收益這種古老的形式的特殊表現,由于,甚至在軟件獲得版權保護之前,軟件著作權人就已經運用合同保護他們的成果。到20世紀80年代,拆封許可合同就已經成為了軟件市場的明顯特征。
          
          一、拆封許可合同的概念和作用
          
          作甚拆封許可合同,學者們的定義并不一致[3],且這些定義局限于現象描述,故不免煩瑣或片面,無法反應這類合同的本質屬性。 筆者以為,采用常用的“屬加種差”方法,考慮到拆封許可合同的屬概念為合同,它與其他合同的不同在于當事人一方為軟件著作權人、合同的內容圍繞著作權許可使用而確定以及其條款為格式條款等方面,因此,拆封許可合同是軟件著作權人許可他人使用其軟件的格式合同。
          拆封許可合同的作用主要在于:一方面通過控制終極用戶對軟件的使用方式,保障軟件著作權人對軟件的專有權利;另一方面,延伸了軟件知識產權人對軟件信息的控制,滿足了其要求尋求充分甚至不當保護軟件的愿看。由于,只要用戶啟封包裝,即宣告合同成立,雙方當事人特定軟件所享有的權利義務得以確定,加之合同系格式合同,故軟件著作權人可以輕易的控制用戶對軟件的使用,從而保障其專有權利。同時,由于合同的訂立過程中用戶處于完全被動的地位,存在著嚴重的信息不對等,因此,對方(并非總是軟件著作權人)可以輕易地獲得他以為充分和必要的保護。同時,現行的與軟件權利保護相關的知識產權立法,如著作權法、貿易秘密法、專利法等難以對軟件著作權人的利益提供充分的保護,①也是軟件著作權人廣泛采用拆封許可合同的主要動力。通過授予軟件購買者使用軟件的許可而不是將軟件“徹底”賣出往,軟件著作權人能夠保存和控制他們的產品。這種控制包括了所有權保存、用戶使用限制、反向工程禁止、拒盡擔保義務的聲明、責任免除和法律適用選擇。而且大多數拆封許可協議都是非排他性的,這就意味著軟件商可以將軟件以同樣的方式再次許可他人使用。
          
          二、拆封許可合同的性質
          
          界定拆封許可合同的法律性質對拆封許可合同的效力認定以及雙方當事人具有重要意義。我國學者多以格式合同作為其效力認定的基礎,個別學者就交易本身的性質進行了研究[4]。筆者以為,拆封許可合同在本質上是著作權許可使用合同,在形式上符合格式合同的條件。易言之,拆封許可合同是格式化的著作權許可使用合同。
          首先,從訂立過程看,拆封許可合同是軟件著作權人為節約交易用度,在生產和包裝軟件過程中預先確定合同條款,購買者僅有同意或不同意的權利,不能就合同的條款與賣方進行磋商,當用戶拆啟包裝軟件時,即視其接受該授權之全部條款。因此,拆封許可合同是一種格式合同。
          其次,從軟件銷售過程看,用戶取得軟件的所有權僅依靠于買賣合同,通常與拆封許可合同無關。在計算機及軟件發展的早期,拆封許可合同往往與軟件買賣合同糅合在一起而成為一份合同,它們在訂立時間和方式上是完全相同的,買賣軟件的之時也是軟件使用范圍確定之際。但隨著軟件通用化時代的到來,軟件銷售與使用許可開始分離。從用戶在商店中買到一套軟件到其終極決定使用軟件,事實上存在兩份合同——即軟件買賣合同和著作權許可使用合同,它們在成立時間上通常有著明顯的先后之分(買賣合同通常在用戶完成價款支付和取得軟件時成立,而拆封許可合同則在用戶打開軟件包裝時成立);在成立方式上也有明顯的不同(前者通過協商一致的昭示方式達成,后者則以做出特定行為表明合同成立);在權利義務關系及合同主體上也不一致(前者通常在軟件生產商或其代理人與終極用戶之間達成、合同法律關系的客體是軟件,而后者只能在軟件著作權人(它與軟件生產商并不總是一致)與用戶之間達成、合同法律關系的客體是軟件使用行為)。對此,美國同一州法全國委員會制定的《同一計算機信息交易法》(Uniform Computer Information Transaction Act, UCITA,該法于1999年7月獲得通過,2000年,2002年修訂,作為示范法建議各州采納)持同樣的觀點。該法對計算機程序、計算機信息及計算機信息交易進行了分別定義,第102條第(11)項規定,計算機信息交易是指創設、變更、轉讓或許可計算機信息或計算機信息中的信息權利的協議或行為。第(12)項規定,計算機程序是指直接或間接用于計算機上以產生某種特定結果的一套語句或指令,該術語不包括分別識別的信息內容[5]。據此在合同法上區分了傳遞于計算機的操縱指令和傳達于人的信息內容;在著作權法上,此區分事關財產權和侵權題目,而在該法中,該區分事關合同法上的風險負擔和義務履行題目。該法第209條立法理由更是明白無誤地指出很多規;袌鼋灰咨婕叭疆斒氯恕煞莺贤,并在第613條對生產商、銷售商和終極用戶的權利義務關系進行了具體的規定。其結果是,立法者以為,若終極用戶(被許可人)同意許可條款,則可能會對銷售商和出版商(the publisher)這兩個不同的主體產生依靠[6]。
          根據合同權利相對性以及我國合同法第137條之規定,①用戶通過買賣合同取得了軟件載體的所有權,并未取得軟件的著作權。同時依據前述買賣合同與拆封許可合同三個方面的不同,不能以為拆封許可合同就是買賣合同的組成部分,也不能以為拆封許可合同是一個獨立的買賣合同,它只能被認定為軟件著作權許可使用合同,該合同權利的享有依靠于三方主體(當軟件著作權人與軟件銷售商為一人時為兩方主體)之間的兩份合同。
          
          三、拆封許可合同的效力認定
          
          鑒于拆封許可合同的前述法律性質,其效力應分別從合同法和著作權法上加以分析。
         。ㄒ唬┎鸱庠S可合同的效力受制于合同法的一般原理
          1.對拆封許可合同訂立過程的不同認定影響其效力
          對拆封許可合同訂立過程的不同認定,決定著拆封許可合同是否成立。對此,美國判例法曾持不同的態度。在第七巡回法院審理ProCD案之前,Step-Saver案、Arizona Retail案以及地區法院審理ProCD案時,均將買主看做要約人(由于正是買主通過向軟件賣主打電話開出了訂單),軟件賣主看做要約的承諾人。由于買主是要約人,要約當然不會包括拆封許可協議的條款。相反,與Step-Saver 和Arizona案的審理法院不同,第七巡回法院以為賣主是要約人,買主是承諾人。而且,第七巡回法院視軟件賣主的要約是一個附條件的要約,受到拆封許可合同條款的約束,在合同被視為成立之前,其條款應當被買主單獨承諾。根據ProCD案的事實,價款、數目和貨物在被告Zeidenberg選定它?促徺I的套裝軟件(標的物)、從貨架上取下所需要的個數(數目)、走向商店柜臺支付價款(價格)時合同的價格、數目和標的物都已特定。ProCD案也成為了美國法院首個承認拆封許可合同效力的判例[7]。顯然,該認定符合了現如今盡大多數軟件買賣的客觀實際,也就是說,從軟件買賣的實際過程看,要約人應是軟件商,而終極用戶則為承諾人。   2.軟件生產商應當為終極用戶提供適當、可行的選擇機會
          拆封許可合同以特定行為完成承諾。固然在各國法上,承諾可以行為方式做出,但并非所有行為均可成立有效的承諾,從而訂立合同。在拆封許可合同的訂立上,只有在特定的行為系要約所認可或要求、要約本身符合要約的一般要件且在受要約人承諾之前已經充分知悉要約內容的情形下,合同才能成立,否則,就自始不能認定合同的存在。這要求軟件生產商應當在終極用戶為特定行為之前為其提供充分的、必要的知悉拆封許可條款的機會和可行的選擇機會,包括向用戶明確提示許可條款的存在、提供可行的閱讀方式、拒盡訂立合同且取得已支付價款方式等[8],否則,均會因其對契約自由精神的妨害而影響合同的成立,從而導致拆封許可合同無效。Tony Brower v. Gateway 2000, Inc. (1st Dept. N.Y., August 13,1998)案中的情形即為適例。在該案中,引起爭議的原因是其爭議解決條款規定“就本項軟件交易所產生的任何爭議應提交國際商會的仲裁機構仲裁”,而國際商會的仲裁規則規定爭議金額小于5萬美元的案件,原告應預先繳納4 000美元的仲裁費,其中2 000美元即使最后的裁決對消費者有利也是不可返還的。法院認定這一條款是顯失公平的,依據《同一商法典》第2-302條是無效的。由于,“將上述仲裁規則適用于爭議數額不大的軟件交易實際上剝奪了消費者尋求法律救濟的可能性!盵4]
          3.拆封許可合同不應不當妨害軟件買賣合同目的的實現
          在軟件及其使用權的取得過程中,同時存在買賣合同和拆封許可合同。依前者,用戶取得了軟件載體的所有權,據后者,用戶取得了軟件著作權的部分或全部使用權。終極用戶對軟件載體的占有、使用、收益、處分權利,軟件商不應不當限制。如多數終極用戶購買軟件的目的首先是使用該軟件以實現預期結果,若拆封許可合同限制了用戶的該目的,就即是用戶訂立買賣合同的目的不可能實現,這勢必引起買賣合同主體之間法律關系的緊張,不利于維護交易的穩定。此外,拆封許可合同中的不當免責事由,也可能會不利于買賣合同目的的實現;拆封許可合同不應對買賣合同的內容做出實質性變更,除非終極用戶明確表示同意。
          4.拆封許可合同不應排除軟件買賣合同中擔保義務的承擔
          拆封許可合同的應用,增加了軟件用戶的留意義務,也給軟件商否認合同法規定的一些合同默示擔保義務提供了可能。此外,拆封許可合同還給買賣合同強加了很多限制性內容,如軟件使用方式的限制、責任免除、法律適用選擇等。依據契約自由和公平原則的要求,拆封許可合同中免除己方責任、加重對方負擔或不當限制對方權利的條款,如未以適當方式提醒對方留意,則該類條款無效,同時,當此類條款的存在妨礙軟件買賣合同訂立的根本目的時,應當認定拆封許可合同無效。
         。ǘ┎鸱庠S可合同的效力受制于著作權的限制制度
          1.拆封許可合同的期限不得長于軟件的保護期限且軟件著作權尚未屆滿
          軟件是適格的著作權客體,這已得到國際社會的普遍認可。著作權保護的期限性保障了著作權法促進文化傳播及繁榮目的的實現,符合憲法目標和著作權保護的宗旨。保護期限屆滿后,作品進進公共領域,公眾可以自由使用。因而,作為著作權許可使用方式的拆封許可合同,其有效條件之一便是所許可使用的著作權仍然有效,倘若拆封許可合同的期限長于作品的保護期限,而仍然使之有效,則即是合同權利優先于著作權,軟件著作權的保護期限制度的價值名存實亡,從而破壞著作權法業已建立的利益平衡機制。因此,拆封許可合同的期限長于所許可軟件的著作權保護期限或者被許可軟件著作權業已屆滿者,應為無效。
          2.拆封許可合同不得妨礙公道使用制度
          發端于英國、成就于美國判例法的著作權公道使用制度歷數百年而魅力不減,已得到各國著作權法的廣泛認同,它對于平衡著作權人和公眾之間的利益至關重要。從各國規定的公道使用情形看,大多保障了公眾在文化、教育、信息傳播和人性主義方面的非營利性自由使用。由于對拆封許可合同性質的不當理解,利用拆封許可合同限制公道使用的情形時有發生,如不分青紅皂白,要求已經取得的軟件的使用均需付費的情況以及與此相類似的其他技術保護措施的采用,便在很大程度上妨礙了公眾對已發表作品公道使用權,甚至是徹底封閉了公道使用的大門;诠朗褂玫膹娦蟹ㄐ再|,在個案審查中,對于妨礙公道使用的條款,應認定為無效。究竟,著作權保護從未給予著作權人對作品的所有可能的使用方式的完全控制[9] 。
          3.拆封許可合同不得避開首次銷售原則
          自1908年美國聯邦最高法院在Bobbs Merrill Co.v.Straus案之后,著作權的首次銷售原則被確立下來,并體現在了1909年《著作權法》第41條中。美國學者Patterson講出了公道首次銷售原則的內涵,他以為,著作權是控制作品首次銷售的權利,而未包括作品的二次銷售的權利;蛘f是,法律答應著作權人控制對著作權的使用,但這種控制并未延及對作品本身的使用。其目的在于消除著作權的專有性對著作權有形物質載體商品化流通的消極影響、化解著作權和物權在表達與載體合一情形下的沖突以及防止著作權人就同一表達重復獲利;谲浖髌泛鸵暵犠髌肥褂梅绞降奶厥庑,首次銷售原則已經進行了相應的修正,但應當明確,在不妨害軟件出租權、出借權的條件下,軟件商采用拆封許可合同限制終極用戶再次轉讓軟件行為應當被認定為無效。
          此外,作為著作權許可使用,所許可軟件應當是享有著作權的作品,倘若被許可軟件本身不享有著作權,則拆封許可合同當然無效;若許可人并非軟件著作權人,則應按無權處分處理。
          
          參考文獻:
          [1] David G. Post. SHRINKWRAP LICENSES AND LICENSING ON THE INTERNET. http://docs.law. gwu. edu /facweb/dnun
          ziato/shrinkwrap.htm.
          [2] Aunya Singsangob, A Validity of Shrinkwrap and Clickwrap License Agreements in the USA : Should we follow UCITA? http://legalaid.bu.ac.th/files/articles/A_VALID_OF_SWL.pdf.
          [3] 于宏偉.試析拆封授權合同[J].法學論壇,2003,(1);楚靜.從ProCD公司訴博登澤格一案探討拆封授權合同的效力及規制[J].中國水運,2007,(7).
          [4] 林在志,鐘奇.網絡時代的格式合同——論拆封合同與點擊合同[J].民商法學,2001,(5):63.
          [5] UNIFORM COMPUTER INFORMATION TRANSACTIONS ACT. (Amended 2000, 2002). http://www. law. uh.edu/ucc2b/UCITA_final_02.pdf.
          [6] UNIFORM COMPUTER INFORMATION TRANSACTIONS ACT. (Amended 2000, 2002). http://www. law.uh.edu/ucc2b/UCITA_final_02.pdf.
          
          [7] David L. Hayes. The Enforceability of Shrinkwrap License Agreements On-Line and Off-Line . http://www.fenwick.com/docstore/Publications/IP/IP_Articles/Shrinkwrap.pdf.
          [8] Thomas J. Smedinghoff. Online Transactions: The Rules for Ensuring Enforceability in a Global Environment. http://www.bakernet.com/ecommerce/7-etran-req.pdf.
          [9] 464 U.S. 417, 432 (1984).

        【淺議拆封許可合同的認定】相關文章:

        淺議融資租賃合同的特征03-23

        建筑論文-淺議工程合同的談判技巧03-03

        淺議無權處分03-24

        淺議存貨審計03-21

        淺議審計假設03-24

        淺議備課的要素結構03-19

        淺議民法中的乘人之危03-07

        淺議英語論文03-30

        淺議民事再審程序01-11

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码

        1. <tt id="5hhch"><source id="5hhch"></source></tt>
          1. <xmp id="5hhch"></xmp>

        2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

          <rp id="5hhch"></rp>
              <dfn id="5hhch"></dfn>