開源與標準：為什麼對待專利如此不同？

制定標準規範和開源軟體的開發有許多共同之處：兩者都是競爭者可以合作的機制；兩者都可以促進互操作性；兩者都可用於促進新技術的採用；兩者都可用於聚合或協調成熟技術。

一項技術可以同時使用標準和開源：有時一個先於另一個；在其他情況下，它們可以並行進行。它們越來越多地使用類似的工具和流程實踐（例如，細粒度版本控制；利用問題跟蹤器一起推動某些開發討論）。

相似程度可能導致過度概括，錯誤地暗示一切都是可互換的（混合與搭配），在這兒選擇一種做法；在那兒將它與一個過程相結合。實際上，獲取在一個領域中獲得的經驗並查看它提供的好處是否可以在其他環境中獲得，可能是有價值的。但是，對於某些實踐而言，背景更為重要。

雖然有相似之處，但也存在顯著差異。在前面的文章《沒有規則的治理：復刻潛力如何幫助項目》中，我討論了在利用 復刻 （ forking ） 潛力作為一種可以促進輕量級治理的力量方面，開源軟體開發和標準開發治理能力的不同。另一個不同之處在於專利規則的選擇。

如何對待專利

參與者專利權的處理通常在開源軟體開發和標準開發中以不同方式排列。這種差異有一個理由。而且，這種差異會對構建開發過程產生影響。

• 開源：在為開源項目做出貢獻時授予的專利許可通常由每個貢獻者的貢獻確定。
• 標準：參與者在標準制定方面做出的專利承諾通常由整個最終規範確定。

開源項目：基於貢獻的專利規則

基於貢獻的專利規則是什麼意思？如果專利所有者提供軟體，由於軟體添加到項目中，項目軟體侵犯了該貢獻者擁有的專利，那麼貢獻者不應該返回來期望獲得使用它所貢獻的軟體的專利許可費。當然，有許多不同的許可文本可以讓我們忙於分析每個許可的解釋，並討論情況中的不確定性和細微差別。在另一篇文章中，我在 MIT 許可協議的背景下談到了這個問題（《為什麼 MIT 的專利許可不討人喜歡？》）。我認為，基本上來說，開源開發中的共同期望就像我上面所描述的那樣：當你為開源做出貢獻時，你將為你提供的軟體提供所有必需的許可權，之後你將無法返回來再要求獲得使用你所貢獻軟體的許可費。

標準制定：基於標準規範的專利規則

相比之下，在制定標準時，通常會有更高的期望：參與者應對專利做出承諾，這些專利對整個最終規範至關重要，而不僅僅是對其貢獻。這些專利承諾並不取決於確定誰對規範提出了什麼想法；對於那些參與開發規範的人來說，他們的承諾是整個標準規範。

包括在其中的專利

確定相關專利的分析在軟體和規範之間也有所不同。軟體通常包括與相應的標準規範相比不需要的實現細節；在提供軟體時，將包括對這些細節使用任何專利的許可。相反，規範開發的專利承諾僅限於對規範「必要」或「必需」的專利。當然，這取決於規範的內容。對於互操作性標準，規範應僅包括實現互操作性所需的詳細級別，從而允許實現細節在標準的競爭性實現之間有所不同。對必要專利的承諾不包括實施細節方面的專利，這些專利可用作競爭優勢。

專利規則差異的基礎

為什麼在專利處理方面存在這種差異？鑒於標準和開源軟體的開發方式存在差異，這種不同的處理方式很有意義。

更有限的與貢獻範圍相關的專利符合大多數協作軟體開發的漸進式、開放式特性。開源項目經常持續發展，其方向可能會隨著時間的推移而演化。雖然可以設置路線圖和里程碑並發布快照版本，但這些不太常見，並且比標準項目中常見的範圍限制和版本目標具有更少的限制性影響。

可以看出，考慮到標準規範開發結構的差異，標準開發的更高期望值（整個最終規範，不僅僅是貢獻）是有意義的。標準規範通常採用具有明確範圍的強版本導向演進。規範開發通常適用於特定的快照版本。標準開發活動通常具有一組目標功能（通常在諸如章程之類的文檔中表示）。與許多軟體開發活動的情況相比，這為可能應用到標準開發活動的技術範圍提供了更清晰的公共的進展預期。這種範圍的明確性有助於潛在參與者在開始參與時評估參與標準制定項目的專利影響。相比之下，開源軟體開發項目更為開放，通常不會排除採用任何特定技術的可能性。

對開源項目和標準管理的影響

這些對待專利的不同措施需要不同的項目管理方法。

開源項目通常準備接受來自新貢獻者的補丁。貢獻者可能會隨著時間的推移而來去。一些貢獻者留下來。其他人可能會為該項目來解決一個有限的問題。通過軟體貢獻，可以更容易地了解誰貢獻了什麼軟體，而不是準確理解誰以一種更抽象的方式「參與」。

另一方面，參與標準制定活動通常具有大量的正式手續。而且，在涉及專利承諾時，這種參與的正式性非常重要。當一個人參與該規範的大部分開發時，對最終規範的專利承諾是有意義的。標準制定過程是否可以從提供單一、有限貢獻的人那裡獲得完整的最終規範承諾？重要的是要有一個過程，以便清楚地了解誰參與誰，誰不參與。需要明確參與者以支持來自實際專利所有者的專利承諾，實際專利所有者通常是由坐在桌旁（比喻，儘管這可能涉及實際的談判桌）的個人所代表的公司。

如何獲得基於規範的承諾？軟體標準中典型的免許可費專利承諾最常被作為獲得標準組織成員資格或負責規範開發的特定委員會成員資格的條件。為了使這一機制發揮作用，成員資格必須是一個定義明確的概念，以便有一個明確的成員資格決策點（即，用於觸發專利承諾的明確行動）和承諾的受益人可以依賴的明確的記錄文件。除了參與清晰度之外，為了促進持懷疑態度的專利參與者的參與，項目需要具有明確的範圍和明確的開始和結束（明確指出專利承諾將適用的「最終規範」）。這種參與模式與典型的開源項目有很大不同，典型的開源項目可能有一個連續的參與，其範圍包括維護幾個主要的驅動程序到只提交一個補丁。

專利政策

雖然我所描述的差異通常是這種情況，但某些特定活動遵循不同模式可能有一些原因。例如，考慮作為標準開發活動附帶的參考實現的軟體。可能有一個強有力的理由期望參與者對完整的最終參考實施提供承諾，而不僅僅是限定於他們對它的貢獻。當然，可能存在其他邊緣情況；可能存在嚴格安排的開源開發；可能會有連續的、隨心所欲的規範開發。

標準制定的專利政策可分為合理和非歧視（RAND）或免許可費（RF）：基本上來說，實施標準的專利許可費包括需要交（RAND）或不需要交（RF）。制定與軟體相關的標準（本文的重點）更多地使用免許可費政策。關於專利許可費預期問題是許可或承諾範圍政策之外的另一個維度。

結論

標準的制定和開源軟體的開發通常具有不同的參與者專利期望範圍（僅限於貢獻或整個最終可交付成果）。這些不同的選擇基於通常如何進行開發的顯著差異，而不是任意差異。

作者簡介：Scott Peterson 是紅帽公司法律團隊成員。很久以前，一位工程師就一個叫做 GPL 的奇怪文件向 Scott 徵詢法律建議，這個致命的問題讓 Scott 走上了探索包括技術標準和開源軟體在內的協同開發法律問題的糾結之路。

譯者簡介：薛亮，集慧智佳知識產權諮詢公司總監，擅長專利檢索、專利分析、競爭對手跟蹤、FTO 分析、開源軟體知識產權風險分析，致力於為互聯網企業、高科技公司提供知識產權諮詢服務。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive