亦敵亦友：智財法如何協助自由與開放源碼社群

過去我曾撰文評估自由與開放源碼社群面對的智財風險，以及如何駕馭這些風險的可能性。我並非第一個，也不會是最後一個作出如此評估的人。畢竟，由於自由與開放源碼社群運動某部分是源自於，對企業使用智財權來阻礙開放性與技術分享的一種反動，因此該社群很自然地會以不信任態度看待智財法。

雖然某種程度的不信任也許是應該的，但這也讓自由與開放源碼社群忽視了智財法某些對他們有所幫助的面向。儘管並非完美，專利、著作權、商標、商業機密法各自都能有益於自由與開放源碼社群。

1. 著作權

因為軟體會自動受到著作權保護，自由與開放源碼社群運動的創始者，得以使用著作權作為基礎，在寬鬆的著作權授權下，將自由與開放源碼公開給大眾使用。當然，沒有著作權的話，或許什麼問題都沒有。不過事實證明著作權相當具有彈性，可以允許自由與開放源碼擁護者和私有軟體廠商，各自追求他們對於軟體世界的夢想。

這種彈性的好處彰顯在幾個方面。例如，因為自由與開放源碼社群使用的主要著作權授權如今已眾所周知，後續的使用者更有機會熟悉這些條款與授權下的權益，有助於減少交易成本。雖然我曾指出，在企業環境下授權也許會產生相反的效果，也就是增加交易成本，但對於許多開發者而言，授權的熟悉度很可能帶來信任並促進重用。的確，自由與開放源碼著作權授權的運作，在某些方面更像是商標，將原始碼受到信任的訊息，傳遞給後續開發者。

著作權法也包含了一些能夠幫助自由與開放源碼社群的限制。舉例而言，著作權只能延伸到想法的特定表達之上，而非底層的構想本身。當一個想法僅能以有限形式加以表達時，也就是說這個想法和表達合而為一時，著作權一般來說並不適用。著作權也不適用於功能性系統、流程、操作方法。

自由與開放源碼社群去年就曾受益於這些限制，其重要性未來更可能再提升。例如，Oracle 最近以 Google 在 Android 體系中使用 37 個 Java API 套件為理由，宣稱 Google 侵犯其專利與著作權。地方法院最後認定，問題核心的 Java API 因為在系統或操作方法中扮演功能性角色，所以不受到著作權保護。這些 API 是達成互相操作性這個目的的必要條件。Oracle 的專利索賠也失敗了。該公司雖然正在對此裁決提起上訴，但在此期間，該裁決與其背後的著作權限制，至少可以為追求開放、協作軟體開發的自由與開放源碼社群，提供某些慰藉。這項裁決一旦確定，將有助為自由與開放源碼開發者，鋪好一條通往更加開放未來的路。

2. DMCA

對於自由與開放源碼社群來說，1998 年的美國數位千禧年著作權法 (DMCA) 是另一個好壞參半的東西。DMCA 嚴格來說並非著作權法，但卻與著作權有關。一般認為數位化內容成長可能導致更多著作權侵害案例，成為了國會之所以制定此法的部分原因。因此此法的許多規定，都是為了保障著作權持有者免於可能更多的著作權侵害。而這些都是會引來著作權極簡主義者不滿的典型條文，包括許多自由與開放源碼圈子裡的人。事實上，GPL 3.0 版 (General Public License Version 3.0) 的第三節，正是為了抵制 DMCA 的 DRM 條文。

但是 DMCA 也包含了一些條文，能幫助自由與開放源碼發展與一般著作權保障內容的使用。譬如，DMCA 包含了避風港 (safe harbors) 條款，只要線上服務供應商遵守 DMCA 的基本要求，即可保障服務供應商免於負擔其用戶行為所引發之責任，像是上傳侵權內容。如果沒有這個重要的責任保護，YouTube 與其他線上服務的續存將面臨相當大的困難。

對於自由與開放源碼代管網站，如自由與開放源碼基金會、Github、Sourceforge 等，DMCA 所提供的保護也為協助促進自由與開放源碼發展，扮演了重要角色。複製私有廠商的軟體程式碼，並上傳到線上自由與開放源碼存儲庫，在自由與開放源碼圈子裡是很少見的案例。但是在其所可能發生的範圍內，DMCA 可以保護遵守 DMCA 的服務供應商，免於潛在責任的疑慮。因此大幅降低了為自由與開放源碼社群提供軟體開發平台的風險。

3. 商標

傳統上商標法的主要目標是保障消費者。為了保護消費者免於對商品或服務來源產生混淆，而賦予使用特定標誌的商標權。這仍是今日商標法的首要重點。

商標法對自由與開放源碼社群而言多半是雙贏。有效的品牌打造是自由與開放源碼專案賴以脫穎而出的關鍵方式之一，而商標法有助確保此一做法。這對於具開放且寬鬆特質的自由與開放源碼特別重要。沒有商標法，分支自由與開放源碼專案的人，可以為了借用原專案的名氣，使用和原始出處相同的標誌，以吸引使用者。在這樣的情況下，可能有相當多使用者會產生混淆。或許因為上述與相關原因，許多的主要自由與開放源碼授權，都明確地拒絕賦予任何的商標權。

標誌一般只有在市場上作為來源識別使用時，商標法才會對其提供保護。因此，當開發者使用第三方 API，且第三方標誌作為實作該 API 的一部分而必須使用時，在這樣的情況下，技術上該第三方標誌並非在市場上作為來源識別。至少就商標法而言，開發者使用商標作為該 API 實作所需部分，應該不構成問題。

4. 專利

正如我在其他文章中所述，專利法可能是自由與開放源碼軟體最大的敵人。從修改專利法以配合自由與開放源碼發展的方面來說，儘管還有許多有待改進之處，事實上專利法已經為自由與開放源碼社群，提供了某些協助，或至少提供了某些自救方案。

專利法的既有技術 (prior art) 或許是最直接的一種方式。對於專利申請者在發明或提出同樣發明前，已經開發或公開釋出的發明概念，技術上不予以發放專利。當然，這個說法把事情過度簡化了，要決定是否構成即有技術，自有一套複雜的規則存在，而本文不會深入這些細節。只不過，這些規則意味著，開發高品質軟體並儘快公開釋出，對於自由與開放源碼社群有很大的幫助。

美國專利局在發放專利前，並未盡力詳熟即有技術這一點，雖然已經飽受許多批評，但那些早已行之有年，或是現有技術下顯而易見的發明，依舊不斷地獲得專利。不過，與其只是抱怨這種情況，自由與開放源碼社群可以且應當利用，近來頒佈的美國發明法 (America Invents Act，AIA) 下所新引入的程序。在 AIA 之下，有了多方複審 (inter partes review) 可以廢止任何專利，不論該專利的發放是在 AIA 實施之前或之後。想要廢止 AIA 生效之後發放的專利，只要在專利發放算起 9 個月之內，也可以選擇走領證後複審 (post-grant review) 程序。對於想扳倒已發放的專利，領證後複審的程序比起多方複審更為有利。

這些程序短時間內變得頗為複雜，但其重點很簡單，那就是儘管 AIA 未能達到許多人的期待，但在讓自由與開放源碼社群能更容易廢止不應該發放的專利上，AIA 的確取得了一些進展。在這方面，像是 Post Issue Peer to Patent 專案等等嘗試，是不錯的開始。擴展這些努力可望有助自由與開放源碼社群。

5. 商業機密

由於不被知悉或無法藉由適當工具輕易查明，而可從獲得經濟價值的資訊，基本上是商業機密法的保護對象，必須加以合理的努力以確保其秘密。通常公司會在專利提供的相對短期保障，以及商業機密法提供的潛在性無限期保障之間做出選擇。

商業機密法與專利法之間的關鍵差別在於，商業機密法不會針對他人的獨立開發，而保障商業機密的持有者。而專利，反過來說，一般而言可以控告專利涵蓋之技術的侵權者，即使該侵權者是獨立發展出該項技術（也就是說，不是從專利持者者複製而得）。

因此在商業機密法之下，如果自由與開放源碼社群發展出碰巧與第三方商業機密極為相似的技術，但過程中並未盜用第三方的商業機密，商業機密法一般對他們並無追索權。此外，假如第三方公開釋出其產品，而產品中使用的商業機密可透過逆向工程加以取得時，一般而言這樣的逆向工程在州商業機密法 (state trade secret law) 下，被視為取得該資訊的合理工具（另一方面，一旦複製了程式碼，可能觸犯著作權侵害，而對於逆向工程的合約限制也可能生效）。

這種對逆向工程的寬限，很顯然不適用於聯邦法令美國經濟間諜法 (Economic Espionage Act of 1996)，因為它會把逆向工程列為刑事犯罪。不過，這項聯邦法令受到許多爭議，許多人認為，美國律師不太可能針對州法 (state law) 所允許的行為，而對當事方提起訴訟。到目前為止，現有的證據似乎證實了這一點。

結論

儘管自由與開放源碼社群與傳統智財法並非處處切合，智財法的確對該社群提供了某些幫助。在前文裡我檢視了各種智財法能協助自由與開放源碼社群的方法。但這並非意指智財法不需要重大改革，就能更好地配合自由與開放源碼。我曾經撰文指出若干我認為有助於調和自由與開放源碼發展和傳統智財法的改革。不過在此期間，利用智財法的有利面向，自由與開放源碼社群能獲得更好的保障。

◎本文翻譯自 Outer Curve Foundation，原作者為 Clark Asay：https://www.outercurve.org/Blogs/EntryId/103/Frenemies-How-IP-Law-Helps-FOSS-Communities-guest-blog-by-Clark-Asay