4月26日是世界知識產權日，很多人或許會覺得這和軟件開發沒什麼關係，但事實上，開源軟件大多受到知識產權法中著作權法（Copyright，也稱版權）的保護。

開源軟件雖說開放了源代碼，但是用戶在使用、修改、再發布時，必須要遵守軟件中規定的開源協議（也稱開源許可證/開源License），否則可能構成侵權，惹上官司。

隨着計算機軟件的激增，其著作權保護愈發重要。同樣在26日，《中華人民共和國著作權法修正案（草案）》提交十三屆全國人大常委會第十七次會議審議。

修正案中有多處：如在第十條的出租權中明確包含計算機軟件的原件或者複製件權利；修正後的第五章“著作權和與著作權有關的權利的保護”中，第四十八條處加入對計算機及其系統或者網絡的完全性能進行測試條例。

雖然修正案還未最終確定，但這也顯現了加強軟件法律保護的趨勢。今天，我們就來談談計算機軟件開發、使用中涉及的一些權利問題，以及這些問題的源頭和當下的新爭議。

Copyright 和 Copyleft：開源著作權和開源協議

提到 “Copyright”，大家可能還會想到自由軟件之父 RMS 提出的“Copyleft”反版權思想。“Copyleft”最初是爲反對商業軟件而生，但它並不是放棄版權，“Copyleft”中的“Left”，不使用英語中“保留”的意思，而是指“Left（左）”，與“版權（Copyright）”中的“Right（右）”具有鏡像的關係。

二者的區別可總結爲：“Copyright”指軟件的版權和其它一切權利歸軟件作者所私有，用戶只有使用權，沒有其它如複製、重新修改發佈等權利。而“Copyleft”的特點是僅有版權歸原作者所有，其他一切權利可以與任何人共享。

首先，計算機軟件作者都可對自己的作品享有著作權“Copyright”。

著作權源於信息時代早期，最初指印刷出版之權，是印刷術發明催生起的複製（Copy）權（Right）。後來隨着科學技術發展，種類漸增，逐漸開始保護文學作品作者權利、作者的表演權利等等。1994年，計算機程序被明文提出應該作爲文學作品受到保護，1996年這一規定被世界知識產權組織在全球範圍內推行。

註釋：1994年4月15日，關貿總協定烏拉圭回合各締約方在馬拉簽署了《與貿易有關的知識產權協議》（TRIPS），其第十條規定：“計算機程序，無論是原始資料還是實物代碼，應根據《伯爾尼公約》（1971）作爲文學作品來保護。”

1996年12月20日，世界知識產權組織通過的《世界知識產權組織版權條約》（WTC）其第四條明確規定不論計算機程序表達方式或表達形式如何，均作爲《伯爾尼公約》第二條意義上的文學作品受到保護。

這爲國際件計算機軟件版權保護提供了統一的標準和依據。

其次，開源軟件作者在擁有著作權的同時，還可以自由決定如何與別人分享自己的作品，這便是“Copyleft”所提倡的理念，也是受開源許協議所保障的權利。

“Copyleft”通常被譯作“著佐權”，即通過許可證的形式，補足、輔佐著作權（Copyright）不足的版權授權，相當於一種權利與義務的契約。RMS 1983年9月創建 GNU 項目，1984年發表《GNU 宣言》，抨擊封閉源碼行爲，也創造了“Copyleft”一詞。

“Copyleft”思想脫胎於 RMS 的知識產權觀——他認爲知識產權是一種社會賦權，權利人應該被允許通過契約的方式，自由轉讓軟件權利，如複製、修改、再發布的權利。所以 RMS 提出，自由軟件在承認著作權的基礎上，可以通過許可協議，與公衆共享作品的其它權利。

1989年，RMS 與一羣律師起草了世界上第一個開源軟件協議——GNU 通用公共協議證書（GNU General Public License, GNU GPL ）。證書的序言體現了“Copyleft”的思想。

一是承認軟件的著作權；二是提供許可協議，來獲得複製、發佈、修改的法律許可。用戶可以獲得權利人通過許可證放棄的權利，但也必須遵守許可證的規定才能行使，如果不遵守開源軟件規定，便是侵犯了開源軟件著作權，其著作權人就有權要求對方停止相關行爲及其他。

至此，“Copyleft”一詞有了實際載體。而這也是現在開源許可協議既可以保護開源軟件作者著作權，又可以爲開發者提供修改、再發布權利的法律思想源頭和基礎。

開源軟件及協議的發展

基於“Copyleft”思想的 GPL 現在是使用最爲廣泛的許可證之一。

這個許可證在開放源代碼的前提下，幾乎可以說是“最大程度”地限制了使用者——它不僅要求用戶再修改的軟件要開源，而且如果用戶將 GPL 許可證下的軟件添加入專有軟件，那麼新組合的軟件也應當全部適用於 GPL 許可證，也就是說，組合裏所有的軟件都必須開源。

因此，GPL 被稱作是帶有“傳染性”的許可證。越來越多的開源軟件支持者認爲，我們應該向更加寬鬆的許可協議靠近，不應該在許可協議上做過多限制。

但 RMS 認爲，GPL 纔是真正保護了所有使用者的自由。因爲 GPL 協議可以規範使用開源軟件的用戶繼續開源，從而維護源碼開放使用的自由。

RMS 是自由軟件運動的領導者之一，被稱爲“自由軟件之父”。在組織人力起草 GPL 協議之外，他最爲人們津津樂道的成就還有創建 GNU 項目以及成立 FSF 自由軟件基金會。

現在我們常說的 Linux 其實是指 Linux 內核加上 GNU 套件，即 GNU/Linux，這是全世界尤其是超級計算機中使用率最高的底層操作系統。RMS 曾向媒體要求，在採訪他的時候，要用“GNU/Linux”稱呼操作系統，而非 Linux。

RMS 執着於解放軟件，一直致力推動軟件和世界自由，這讓外人覺得他脾氣執拗古怪。也有人問他，參與自由軟件運動多年，到底收穫了什麼。他說，“我比較感興趣的是，世界得到了什麼。我對我的人生很驕傲，因爲我人生的一半，都在爲自由奮鬥，抵制人們做不自由的事，雖然我們還沒達到勝利的目標。”

這個“勝利的目標”，在很多開發者看來，是不切實際的。1998年，Eric Raymond 發表《大教堂與集市》一書，爲開源奠定文化理論基礎。Raymond 以及他的追隨者認爲，RMS 和 FSF 在推動自由軟件的時候，受意識形態影響太深，與現實脫節。而爲了自由軟件儘可能大範圍地取得成功，應該側重提供源代碼的實用價值，而不是過多的講究共享和道德哲學。

很快，Raymond 邀請了十幾個自由軟件社區著名成員開會（當然，不包括 RMS），討論決定用“開源軟件”來代替“自由軟件”。1998年，Raymond 和 Bruce Perens 成立了開源促進會——OSIA，這個組織後來主導了開源運動，並定義了開源軟件，其中也對許可協議做了一定規範：

OSD：自由再發布；以源代碼的形式再發布；派生作品，即使用同款開源軟件協議，不同協議之間也可以兼容；作者源代碼的完整性，自己修改的程序用不同的版本號與原始的做區分，軟件用戶有權知道作者是誰；個人或團體不受歧視；開源軟件程序可以被使用在任何領域再發布許可協議，新增軟件不得添加新的條款；許可證不得只用於特定產品；許可證不得限制其他軟件；許可協議必須是技術中立的。

隨着開源運動的擴大，以及開源軟件定義的明晰，許可協議對開源軟件的促進、保護作用愈發凸顯，其種類也在不斷增加。《大教堂與集市》的譯者衛劍釩在近日發佈的一篇文章中，形象道出：

我允許你們XXX，我許可你們XXXX，你們可以XXXX，但是，你們必須XXXX，如果你們XXXX了，你們就必須XXXX，對了，對於XXXX這些情況，我可不負責。

你要同意，就用，不同意就別用。如果你用了，但違反了許可證的要求，我可能會告你啊！

國內近期有一起計算機軟件著作權訴訟案，涉及開源軟件和許可協議。2019年12月，北京高級人民法院對被告柚子（北京）科技有限公司、柚子（北京）移動技術有限公司、與原告數字天堂（北京）網絡技術有限公司侵犯計算機軟件著作權糾紛做出終審判決。

起因是兩被告公司的 APICloud 軟件複製及修改了原告數字天堂公司 HBuilder 軟件中的三個插件，這些插件採用了 GPL 協議。如前文所述，按照 GPL 的規定，只要使用了 GPL 下的軟件，就必須全部開源，但 APICloud 並沒有全部開源，於是引發訴訟。

最終，法院認定，柚子科技公司、柚子移動公司的 APICloud 軟件複製及修改了數字天堂公司 HBuilder 軟件中的三個插件，侵犯了著作權人數字天堂公司對軟件作品享有的複製權和修改權等權利，判令被告停止侵權並賠償71萬元。

此案是中國 GPL 訴訟第一案，其判決被認爲對開源軟件訴訟實踐有重要意義，這對之後類似案件的審判有較高參考價值，對國內開發者使用開源軟件也有指導意義。

國際上在實際判例中承認開源許可協議的法律效力來得更早。2008年，美國聯邦巡迴上訴法院首次在判決中主張了開源許可證的著作權協議。原告 Bob Jacobsen 採用 Artistic 許可證，發佈了自己的開源軟件。被告 Matthew Katzer 使用了該軟件，但是卻未履行許可證中規定的著作權聲明義務。最終，被告被認定違反 Artistic 許可證的行爲是侵犯了原告的著作權。

聲明作者的著作權，基本可以稱作是開源許可證的“入門級”協議，在此基礎上，許可證還規定了使用者是否可以將其拿去商用、是否可以打着原作者的名義營銷等等。此前，有人將較爲流行的幾種許可證做了一個劃分：

上圖中的幾個許可證僅是目前較爲流行的，在這之外，通過 OSI 認證的許可證還有。一項調查顯示，許可證逐漸被認爲是開發人員在決定使用某個開源項目時，因爲沒有開發人員願意在不知道接下來將如何發展的情況下，開始使用新的軟件包。

許可證種類和規定的多樣性導致軟件合規變得複雜，不過目前已經有一些工具可以初步降低這一門檻，比如 Linux 基金會推出的許可證使用規範工具 ACT、Gitee 的許可證引導功能。

一些爭議

在軟件開發過程中，圍繞軟件法律保護產生了多種爭議。

一方面，許可證應該規定哪些權利義務、應該走向寬鬆還是限制被廣爲討論。另一方面，人們是否應該爲軟件的設計思想申請專利也引發了開發者之間的對立。

許可證種類漸增的當下，人們愈發渴望更加寬鬆的開發環境、和更簡潔的協議。大量軟件從限制性許可證轉到寬鬆許可證。

Blackduck 數據顯示，從 2009 年到 2015 年的六年間，寬鬆型 MIT 許可證的份額上升了15.7%，Apache 的份額上升了12.4%；而 GPL v2 和 v3 的份額則下降了21.4%。GitHub 2015年發佈的許可證使用情況報告顯示，MIT 協議使用率最高，兩年前的一項研究也得出了同樣的結論。

然而，追求寬鬆又帶來新的問題。

MIT 是現在使用最廣泛，又最爲寬鬆的許可證。開發者只要保留原作者的版權和許可，便可以隨意使用，包括出售源碼。這時，原開發者就可能會面臨“別人都能拿着我的軟件出去售賣，我徒留版權有何用”的窘境，此刻大概只有用“自由與分享”的理想做註解了。而如果想避免這種狀況，開發者可以更換更爲嚴格的許可協議，或者不開源。

此外，近年還出現的情況，雲廠商直接將開源廠商的開源能力作爲雲環境下的商業服務，而不回饋開源社區，擠壓開源廠商業務，致使其陷入生存困境。這迫使許多開源軟件又從寬鬆型許可證轉向更嚴格的協議，甚至直接閉源。

更有甚者，認爲開源軟件應該脫離現有的著作權法，擁有一部屬於自己的《開源法》：以著作權法爲主的知識產權法是後工業時代和前信息時代的產物，它賦予人們對其創造出來的信息—電影、軟件等作品、發明等技術方案、產品設計—進行壟斷的財產權。但軟件存在的意義應該是作爲解決實際問題的工具，真正核心的特點是工具性、功能性，而非表面上的作品性。這時就不再適用著作權法，而是應該新建《》。

實際上，除了著作權和許可證，還有一部分軟件，尤其商用軟件可以同時受到專利法的保護。我國法律規定，計算機軟件專利保護期限爲從申請日起算20年。著作權保護期爲作者有生之年加死亡後50年；法人及其它組織的作品，其法律規定的相關著作權的保護期爲50年。

區別於著作權對軟件本身的保護，專利權保護計算機軟件體現在保護軟件的設計思想。比如，一個軟件構思，可以通過不同的編程語言來實現。著作權保護的是已經寫出來的整套編程，而專利權則保護編程語言背後的構思。

所以，一個軟件可以同時享有著作權和專利權，開源軟件也可以在開源之前，先爲軟件設計思路申請專利。

一些開源協議允許開源軟件享有專利權，如 Mulan PSL v2第2條規定：每個“貢獻者”根據“本許可證”授予您永久性的、全球性的、免費的、非獨佔的、不可撤銷的（根據本條規定撤銷除外）專利許可，供您製造、委託製造、使用、許諾銷售、銷售、進口其“貢獻”或以其他方式轉移其“貢獻”……Apache 2.0等開源協議也有類似的規定，而諸如 MIT 的一些協議，並未涉及專利問題，其是否存在默示的專利限制，還有待解答。

爲軟件申請專利的流程更爲複雜，但是其法律約更多，對軟件開發和共享造成更大阻力，因此催生了反軟件專利的運動。

反軟件專利的支持者認爲，軟件創新也不需要外界強力來推動，即不需要專利法去刺激創新。

這也引出了以上爭議背後的焦點問題——究竟什麼樣的知識產權保護，才能最大程度推動整個計算機軟件世界的創新與發展，而不是僅僅關注當下，或者某個體的既得利益？

相關文章