一般公司在採購軟體、聘僱員工或者是與其他公司共同研發技術等事務的過程中，常會涉及軟體著作財產權的讓與。傳統上，著作財產權讓與多半由雙方經過協商讓與細節、達成合意、及簽訂讓與契約的程序來達成。但 copyleft 性質的開源軟體，其要求衍生著作的著作人／散布人也必須採取同樣的授權模式，才能夠進行該衍生著作的散布、流通與修改（註一）。這樣的開源軟體若套用傳統的著作財產權讓與模式，將會遇到窒礙難行的問題，甚至可能無法達到原本欲取得軟體著作財產權以達到的商業利用目的。因此，本文以下將就這些相關問題淺析之。

當一家公司試圖以傳統對著作財產權的想法來進行著作財產權讓與的交易，通常會經過以下過程：(1) 讓與人及受讓人雙方針對規範到軟體的條款進行協商，以及 (2) 要求權利的轉讓（註二）。然而，前述兩點套用在開源軟體上，會遇到困難，甚至不可行，原因在於：

一、開放源碼授權條款無法被個別協商

當兩家公司欲訂定著作財產權讓與契約，通常會由其中一方的法務人員先提出契約草案，另一方收到後若對合約內容有意見，則會回提其修改版本給對方。若兩方對合約內容一直無法達成合意，則會有好幾輪來回討論修改，直到協商出雙方都同意的條款內容為止。然而，這樣的模式卻無法套用在開源軟體上，一來因為開源軟體多由眾人參與開發的特性，所開發出的程式著作財產權分歸不同的人所有，要進行著作財產權讓與交易，很難有唯一對談的窗口（註三）；另一方面，即便找到可洽談著作財產權讓與的對象（暫且稱某甲），也因為由某甲撰寫的程式、或某甲擁有程式著作財產權的部分，可能只佔整個軟體開發專案的一小部分，某甲最多只可對其撰寫或擁有著作財產權的程式部分擁有決定權，由其他人撰寫的程式著作財產權既不歸屬某甲，則當然不可能全由某甲與買方協商整個軟體專案的權利讓與。再者，任何授權條款都必須經過開放源碼促進會 (Open Source Initiative, OSI) 的嚴格審核（註四），才被認可為「開放源碼授權條款 (Open Source License)」，也因此經 OSI 認證過的開放源碼授權條款內容，並不能被使用人自行修改，或者說，一經修改，就不得再自稱此份條款是 OSI 認證通過的「開放源碼授權條款」了（註五）。

二、copyleft 性質的開源軟體專案不適合成為聘僱契約的標的

當一家公司所購買的不是商品，而是勞務，譬如公司聘僱員工，在勞動契約書中要求，員工受雇期間職務上完成的著作，其著作財產權歸公司所有，這樣的約定內容，尚屬合理（註六）；而在出資聘人的情況，若出資人於合約中要求受聘人其完成著作，以出資人為著作人，亦算於法有據（註七）。然而如前所述，開源軟體專案具有多人參與開發及後續修改的特性，一家公司若想透過聘僱或出資的方式，要求受雇人或受聘人其撰寫的程式著作財產權歸屬該公司，然後進一步再取得整個軟體專案的著作財產權，並不可行，一來因為整個軟體專案可能有數十、數百、甚至更多的程式撰寫者參與開發，要和所有參與專案開發者皆成立委聘關係，實際上幾乎不可能；再者，copyleft 性質的開放源碼授權條款多要求其適用軟體或衍生著作，必須能夠自由再散布，且不得以直接收取軟體授權金 (royalty) 的方式進行營利。所以，既不得限制他人販賣或散布此一開放源碼軟體，亦不得收取授權金，這麼一來，對公司來說，透過聘僱或出資的方式試圖取得開源軟體著作財產權的實質意義將大幅降低。

三、取得開源軟體時多難以令其散布者直接提供擔保

由於我國現行著作權制度並不需要登記，自著作完成起即自動受到法律的保護（註八），因此，為確保讓與人確實為該著作的創作人或權利人，以電腦程式為例，在傳統電腦軟體的著作財產權讓與契約中，常見要求讓與人保證該電腦軟體的著作財產權確實為其所有，並有權為該軟體的移轉，且具文擔保該程式的撰寫未侵害任何第三人的權利（註九）。這樣的擔保責任在開源軟體上很難實現，因為開放源碼授權條款既要求授權人不得收取授權金，相對的也就免除授權人對被授權人提供擔保的責任，這些免責的範圍亦包含不侵權保證在內。而雖然近年重新修編的開源軟體授權條款，以 GPL-3.0 為例，有限度的加上額外添附條款 (additional term)，讓商業散布者可以自行提高所散布開源軟體的擔保責任，以利其承接商業營利的業務，但目前此種由上游廠商提供額外擔保的利用方式仍未普及，大部份的情況還是軟體元件的承包廠商以無償的方式取得開源專案，經過客製化修改加工之後再散布予下游廠商，這樣的程式取得過程，多難以令承包廠商能具文提供擔保予下游廠商來進行權利讓予。

四、開源軟體後續散布時並不禁止商業利用

公司透過著作財產權讓與契約的簽訂，目的在獨佔著作的利用權，以增強自身在同業間的競爭力。然而，以 copyleft 性質之開源軟體而論，其本身並不禁止商業利用、且要求在散布程式時必須提供原始碼的特性，將使得公司無法藉著傳統著作財產權讓與，以取得開源軟體完整著作財產權的方式，達到強化己身競爭力的目的。因為程式一旦經產品販售的手段散布出去，則相關的程式原始碼受到授權條款的拘束也必須一併提供，而後續其他商業公司，便可以將這些開源軟體專案的程式碼加值至自身的產品裡，這將導致第一家散布公司的產品競爭力相對地降低，而原則上，只要後續這些商業公司完全遵守該條款的各項義務性規定，就不會去侵犯到第一家散布公司的相關權利。

承上所述，開源軟體雖不允許收取授權金，但仍可收取其他相關服務費用，且開源軟體契約授予被授權人的是非專屬 (non-exclusive) 的權利，因此若一公司使用到開源軟體，付費買到的多是改進程式、除錯的服務，而不是買到該程式的著作財產權。此外，開源軟體由多人參與開發，即便透過簽訂委託開發程式契約的方式，取得一部分程式的著作財產權，也會因為這一部分程式可能佔整體軟體開發專案很小的比例，而沒有太大意義，並且若封閉這部分的程式，不再散佈出去提供大眾自由利用，將會因為違反許多 copyleft 性質的開放源碼授權條款，所取得的被授權人權利亦可能遭到終止，而後便不得再繼續利用此一開源軟體。

本文以為，在面對開源軟體時，應改變傳統終局地買斷軟體著作財產權的思維，以新的眼光認識開源軟體，現行有不少透過開源軟體社群來維護自家產品程式碼的商業公司，就是最佳的例證。這些公司聘用員工來積極參與產品相關的開源軟體社群開發工作，並且將員工所撰寫的程式碼，提交到這些開源軟體社群中，促使社群開發者共同維護這產品相關的程式碼，例如除錯、增進效能等等，而當產品升級時，商業公司可以在略加修改之後，就直接利用這些社群所維護的程式碼。因此，在面對具有 copyleft 性質開源軟體的時候，若能坦然接受其專有的特性，跳脫傳統著作財產權讓與的思維來加以利用，例如：改以支付程式開發者服務費用，或直接參與社群開發等等的方式，就可以安心地站在巨人的肩膀上享受前人所共同開發出的程式成果，讓公司的營利目標與開源軟體社群的整體發展產生良性的互動循環。

---

註一：關於 copyleft 的定義，請參見 https://www.openfoundry.org/tw/glossary/736-copyleft，與專文：葛冬梅，泛談 copyleft 機制與創用 CC 的「相同方式分享」授權要素，https://www.openfoundry.org/tw/legal-column-list/2051--copyleft--cc-（最後瀏覽日：06/16/2011）。

註二：https://blogs.computerworlduk.com/simon-says/2011/02/open-source-procurement-copyrights/index.htm（最後瀏覽日：06/15/2011）。

註三：同前註。

註四：OSI 為一非營利組織，開放源碼界著名的「開放源碼定義」(Open Source Definition, OSD) 即是由其維護。OSI 對授權條款的審查程序包含：審核申請 OSI 認證的授權條款是否符合開放源碼定義、是否已有內容相同或類似的授權條款、是否具存在實益，並給予該授權條款適當的分類等，詳參 OSI 網站 "About the Open Source Initiative" (https://opensource.org/about) 及 "The License Review Process" (https://opensource.org/approval) 之說明（最後瀏覽日：06/16/2011）。

註五：前揭註二。

註六：我國著作權法第 11 條規定，受雇人於職務上完成之著作，以該受雇人為著作人。但契約約定以雇用人為著作人者，從其約定。

註七：我國著作權法第 12 條規定，出資聘請他人完成之著作，以該受聘人為著作人。但契約約定以出資人為著作人者，從其約定。

註八：我國著作權法第 10 條規定，著作人於著作完成時享有著作權。

註九：劉承慶 (2006)。《涉外合約與智慧財產權系列之三－智慧財產權的讓與及授權（上）》，載於外貿協會專欄網站：https://www.is-law.com/old/OurDocuments/IP0012MA.pdf（最後瀏覽日：06/16/2011）。