基本觀念
OpenFoundry provides essential tools and services through its service platform for users to develop Open Source Software Projects, the operating funds comes from the National Science Council and the Research Center for Information Technology Innovation of Academia Sinica Taiwan.
https://www.openfoundry.org/basic-concepts
2019-11-21T15:45:34Z
自由軟體、開放源碼軟體與相近的名詞
2008-03-03T15:10:10Z
2008-03-03T15:10:10Z
https://www.openfoundry.org/tw/basic-concepts/1450-2010-07-13-09-53-46
葛冬梅
tmk2005@citi.sinica.edu.tw
<h3>一、自由軟體</h3>
<p>英文字源 ”free software” 指的是符合「四大自由」的軟體(註一)。四大自由是由 Richard M. Stallman 所訂定出來,包括:執行程式、研究與修改程式、散布程式以及改良程式四項自由,是以程式使用者為中心的四大主張,旨在實現程式使用者對於程式的各項自由。而判斷一個程式是否具有四大自由,必須視其授權條款內容而定,不過無論如何,自由軟體的著作權並未被拋棄,因此仍是受到著作權制度所保 護。有關四大自由與自由軟體進一步介紹,請見「四大自由與自由軟體」一文的介紹。</p>
<p> </p>
<h3>二、開放源碼軟體、開放原始碼軟體</h3>
<p>這兩個中文名詞的英文字源相同,均是 ”open source software”,只是因為翻譯上有不同的見解,所以產生兩個不同的中文譯詞。自由軟體鑄造場慣常使用「開放源碼軟體」一詞。<br /><br />開放源碼軟體指的是採用開放源碼授權條款的軟體,一份條款若是經過開放源碼促進會核可通過,認定其符合「開放源碼定義 (Open Source Definition, OSD)」,就可以稱為開放源碼授權條款。與自由軟體相同一樣,開放源碼軟體,也是受到著作權制度所保護。開放源碼定義與開放源碼促進會的進一步介紹,請見 「開放源碼定義與開放源碼促進會」一文的介紹。<br /><br />四大自由是以程式使用者能夠自由使用程式為出發點而訂定,自由開放源碼定義的源起則是希望此類軟體可以順利商業化,為此,開放源碼促進會註冊有服務標章,一個產品若包含有開放源碼軟體,就可以在包裝上標明這個服務標章,消費者看到標章就知道產品內包含有開放源碼軟體,進而因為開放源碼軟體的優點而購買這項產品。</p>
<p> </p>
<h3>三、其他相近名詞</h3>
<ul>
<li>免費軟體</li>
</ul>
<blockquote>
<p>免費軟體的英文字源是 ”freeware”,如中文翻譯名詞所示,就是一種免費的軟體,在使用上也沒有時間的限制,不過使用者不見得可以拿到原始碼,而在使用目的上也常有限制,例如:僅限非商業用途、僅限個人用途等等。雖然大部分的自由/開放源碼軟體都是免費使用,但也有不少是收費的,所以自由/開放源碼軟體並非免費軟體。</p>
</blockquote>
<ul>
<li>共享軟體</li>
</ul>
<blockquote>
<p>共享軟體的英文字源是 ”shareware”,這是商業公司發展出來吸引消費者購買軟體的的一種試用軟體。使用者可以使用共享軟體一段時間,例如三十天或二個月,之後就必須付費才可以繼續使用軟體,或者是購買功能完的軟體。不但因為使用期限有所限制,使用者也無法拿到程式原始碼,所以自由/開放源碼軟體並非共享軟體。</p>
</blockquote>
<p> </p>
<p>註一:這裡的「軟體」一詞包含程式碼與相關文件,或者也可以單指單純地程式碼而言。但若是使用「程式」一詞,則僅指單純地程式碼而言,不包含相關文件。</p>
<h3>一、自由軟體</h3>
<p>英文字源 ”free software” 指的是符合「四大自由」的軟體(註一)。四大自由是由 Richard M. Stallman 所訂定出來,包括:執行程式、研究與修改程式、散布程式以及改良程式四項自由,是以程式使用者為中心的四大主張,旨在實現程式使用者對於程式的各項自由。而判斷一個程式是否具有四大自由,必須視其授權條款內容而定,不過無論如何,自由軟體的著作權並未被拋棄,因此仍是受到著作權制度所保 護。有關四大自由與自由軟體進一步介紹,請見「四大自由與自由軟體」一文的介紹。</p>
<p> </p>
<h3>二、開放源碼軟體、開放原始碼軟體</h3>
<p>這兩個中文名詞的英文字源相同,均是 ”open source software”,只是因為翻譯上有不同的見解,所以產生兩個不同的中文譯詞。自由軟體鑄造場慣常使用「開放源碼軟體」一詞。<br /><br />開放源碼軟體指的是採用開放源碼授權條款的軟體,一份條款若是經過開放源碼促進會核可通過,認定其符合「開放源碼定義 (Open Source Definition, OSD)」,就可以稱為開放源碼授權條款。與自由軟體相同一樣,開放源碼軟體,也是受到著作權制度所保護。開放源碼定義與開放源碼促進會的進一步介紹,請見 「開放源碼定義與開放源碼促進會」一文的介紹。<br /><br />四大自由是以程式使用者能夠自由使用程式為出發點而訂定,自由開放源碼定義的源起則是希望此類軟體可以順利商業化,為此,開放源碼促進會註冊有服務標章,一個產品若包含有開放源碼軟體,就可以在包裝上標明這個服務標章,消費者看到標章就知道產品內包含有開放源碼軟體,進而因為開放源碼軟體的優點而購買這項產品。</p>
<p> </p>
<h3>三、其他相近名詞</h3>
<ul>
<li>免費軟體</li>
</ul>
<blockquote>
<p>免費軟體的英文字源是 ”freeware”,如中文翻譯名詞所示,就是一種免費的軟體,在使用上也沒有時間的限制,不過使用者不見得可以拿到原始碼,而在使用目的上也常有限制,例如:僅限非商業用途、僅限個人用途等等。雖然大部分的自由/開放源碼軟體都是免費使用,但也有不少是收費的,所以自由/開放源碼軟體並非免費軟體。</p>
</blockquote>
<ul>
<li>共享軟體</li>
</ul>
<blockquote>
<p>共享軟體的英文字源是 ”shareware”,這是商業公司發展出來吸引消費者購買軟體的的一種試用軟體。使用者可以使用共享軟體一段時間,例如三十天或二個月,之後就必須付費才可以繼續使用軟體,或者是購買功能完的軟體。不但因為使用期限有所限制,使用者也無法拿到程式原始碼,所以自由/開放源碼軟體並非共享軟體。</p>
</blockquote>
<p> </p>
<p>註一:這裡的「軟體」一詞包含程式碼與相關文件,或者也可以單指單純地程式碼而言。但若是使用「程式」一詞,則僅指單純地程式碼而言,不包含相關文件。</p>
商業應用模式
2008-03-03T15:08:41Z
2008-03-03T15:08:41Z
https://www.openfoundry.org/tw/basic-concepts/1449-2010-07-13-09-54-37
林誠夏
lucien@citi.sinica.edu.tw
<p>自由軟體的英文字源 "Free" 常給一般人「免費」的誤解,但其實自由軟體並不反商,其雖多設有「不收取授權金」的規約,是在開放分享精神的影響下,希冀軟體程式能得到多數人最大程度的利用,不致使被授權人窘於高額軟體授權金而無法自由的使用及研究,但除此之外,自由軟體開放共享的理念與營利收費機制並無本質上的衝突。<br /><br />惠普科技 (Hewlett-Packard Development Company, HP) Linux 部門的副總裁 Martin Fink 所著《The business and economics of Linux and open source》一書,將其多年觀察所得的自由軟體商業模式分為七類,筆者將其簡化分為三大類:第一類是將授權金營收完全轉換為服務性收費模式,第二類是以軟體加值的概念促進硬體的銷售,而第三類則是兼採自由及傳統方法的雙重授權模式。</p>
<p> </p>
<h3>一、服務性收費模式</h3>
<p>此類模式的商業基礎,在於將出售物品轉為出售服務,如同律師並非出賣法律,而是出賣其法律服務,而美語教學亦非出賣美語,乃是出賣其教學服務。舉實例來說,Red Hat、Novell SuSE、Mandriva 都是有名的自由軟體商業服務公司,其早期提供特定版本的 Linux 作業系統封包販售,近年已轉將收費項目深化於軟體應用諮商及支援服務如人才訓練課程等,亦由此獲得豐厚的固定營收。</p>
<p> </p>
<h3>二、嵌入式硬體販售模式</h3>
<p>自由軟體的商業化模式亦可表現於節省產品製作成本,或是增進產品效能以擴大銷售競爭力方面,以手機大廠 Nokia、Motorola 為例,其近年著手佈局於自由軟體相關的嵌入式 (Embedded) 運用態式十分積極,因自由軟體必然具有開放原始碼的特性,故能客製化 (Customized) 大幅提升軟硬體之間的契合度及穩定性,並因自由軟體多具有免徵軟體授權金的特性,進一步還能夠降低產品製作成本。</p>
<p> </p>
<h3>三、雙重授權模式</h3>
<p>所謂的雙重授權模式 (Dual Licensing Mode) 意指,軟體程式在散布時兼採自由軟體授權條款及傳統的商業授權條款併行釋出,使用者可視需求選擇無償釋出的自由軟體授權版本,或是付費使用其商業授權版本,雙重授權模式的優勢,在於其可將不同立場的各方利益調配得宜,其運作上的成功案例、一般可舉瑞典的 MySQL AB 及挪威的 Trolltech 公司做為代表:對商業模式的企業消費者而言,其樂於支付授權費用取得軟體的商業授權,故其後程式修改即毋須回應一般自由軟體授權條款會帶來的拘束,如開放原始碼的要求等;而對於無償取得的網路社群而言,其得以透過自由軟體授權條款取得「完整版本」的軟體;而對於程式的原始著作權利人而言,其透過商業授權取得固定的授權金營收,而無償取得軟體的網路社群亦會持續透過網路論壇,幫助其進行軟體的除錯 (Debug) 及改版的工作,可說是三方不同立場卻互蒙其利。<br /><br />目前、以我國的產業環境論,雙重授權模式較無可預期,因企業欲運用雙重授權模式有其前提要件,其一、軟體著作權人須獨占此軟體的著作權利,其二、軟體品質、口碑及市佔率皆須達於一定規模方有施行條件,此可列為我國自由軟體產業發展的長期計畫;但以現階段論、自由軟體產業的推動發展應著力於服務性收費及嵌入式硬體加值模式。因我國傳統產業結構中小企業林立,許多公司並無力耗費過高成本在管理系統建制上,如可透過自由軟體為中小企業建立量身訂作、簡單合用的管理系統,則此方面的服務費用收取可期;而在資訊產業方面,我國亦以硬體製作、代工佔最大比率,如能善用自由軟體於嵌入式硬體方面的加值空間,依其低取得成本、高客製化的特性,亦可有效增進國內產業的整體競爭力。</p>
<p> </p>
<p>【參考資料】</p>
<ol>
<li>Martin Fink, The Business and Economics of Linux and Open source, Prentice Hall PTR (2003).</li>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=991&Itemid=331">林誠夏,自由軟體的商業應用模式(上)-概念篇,自由軟體鑄造場電子報第81期。</a></li>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=1056&Itemid=331">林誠夏,自由軟體的商業應用模式(下)-雙重授權篇,開放鑄造場電子報第83期。</a></li>
</ol>
<p>自由軟體的英文字源 "Free" 常給一般人「免費」的誤解,但其實自由軟體並不反商,其雖多設有「不收取授權金」的規約,是在開放分享精神的影響下,希冀軟體程式能得到多數人最大程度的利用,不致使被授權人窘於高額軟體授權金而無法自由的使用及研究,但除此之外,自由軟體開放共享的理念與營利收費機制並無本質上的衝突。<br /><br />惠普科技 (Hewlett-Packard Development Company, HP) Linux 部門的副總裁 Martin Fink 所著《The business and economics of Linux and open source》一書,將其多年觀察所得的自由軟體商業模式分為七類,筆者將其簡化分為三大類:第一類是將授權金營收完全轉換為服務性收費模式,第二類是以軟體加值的概念促進硬體的銷售,而第三類則是兼採自由及傳統方法的雙重授權模式。</p>
<p> </p>
<h3>一、服務性收費模式</h3>
<p>此類模式的商業基礎,在於將出售物品轉為出售服務,如同律師並非出賣法律,而是出賣其法律服務,而美語教學亦非出賣美語,乃是出賣其教學服務。舉實例來說,Red Hat、Novell SuSE、Mandriva 都是有名的自由軟體商業服務公司,其早期提供特定版本的 Linux 作業系統封包販售,近年已轉將收費項目深化於軟體應用諮商及支援服務如人才訓練課程等,亦由此獲得豐厚的固定營收。</p>
<p> </p>
<h3>二、嵌入式硬體販售模式</h3>
<p>自由軟體的商業化模式亦可表現於節省產品製作成本,或是增進產品效能以擴大銷售競爭力方面,以手機大廠 Nokia、Motorola 為例,其近年著手佈局於自由軟體相關的嵌入式 (Embedded) 運用態式十分積極,因自由軟體必然具有開放原始碼的特性,故能客製化 (Customized) 大幅提升軟硬體之間的契合度及穩定性,並因自由軟體多具有免徵軟體授權金的特性,進一步還能夠降低產品製作成本。</p>
<p> </p>
<h3>三、雙重授權模式</h3>
<p>所謂的雙重授權模式 (Dual Licensing Mode) 意指,軟體程式在散布時兼採自由軟體授權條款及傳統的商業授權條款併行釋出,使用者可視需求選擇無償釋出的自由軟體授權版本,或是付費使用其商業授權版本,雙重授權模式的優勢,在於其可將不同立場的各方利益調配得宜,其運作上的成功案例、一般可舉瑞典的 MySQL AB 及挪威的 Trolltech 公司做為代表:對商業模式的企業消費者而言,其樂於支付授權費用取得軟體的商業授權,故其後程式修改即毋須回應一般自由軟體授權條款會帶來的拘束,如開放原始碼的要求等;而對於無償取得的網路社群而言,其得以透過自由軟體授權條款取得「完整版本」的軟體;而對於程式的原始著作權利人而言,其透過商業授權取得固定的授權金營收,而無償取得軟體的網路社群亦會持續透過網路論壇,幫助其進行軟體的除錯 (Debug) 及改版的工作,可說是三方不同立場卻互蒙其利。<br /><br />目前、以我國的產業環境論,雙重授權模式較無可預期,因企業欲運用雙重授權模式有其前提要件,其一、軟體著作權人須獨占此軟體的著作權利,其二、軟體品質、口碑及市佔率皆須達於一定規模方有施行條件,此可列為我國自由軟體產業發展的長期計畫;但以現階段論、自由軟體產業的推動發展應著力於服務性收費及嵌入式硬體加值模式。因我國傳統產業結構中小企業林立,許多公司並無力耗費過高成本在管理系統建制上,如可透過自由軟體為中小企業建立量身訂作、簡單合用的管理系統,則此方面的服務費用收取可期;而在資訊產業方面,我國亦以硬體製作、代工佔最大比率,如能善用自由軟體於嵌入式硬體方面的加值空間,依其低取得成本、高客製化的特性,亦可有效增進國內產業的整體競爭力。</p>
<p> </p>
<p>【參考資料】</p>
<ol>
<li>Martin Fink, The Business and Economics of Linux and Open source, Prentice Hall PTR (2003).</li>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=991&Itemid=331">林誠夏,自由軟體的商業應用模式(上)-概念篇,自由軟體鑄造場電子報第81期。</a></li>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=1056&Itemid=331">林誠夏,自由軟體的商業應用模式(下)-雙重授權篇,開放鑄造場電子報第83期。</a></li>
</ol>
四大自由與自由軟體
2008-03-03T15:07:13Z
2008-03-03T15:07:13Z
https://www.openfoundry.org/tw/basic-concepts/1448-2010-07-13-09-56-17
葛冬梅
tmk2005@citi.sinica.edu.tw
<p>四大自由是由 Richard. M. Stallman (Stallman) 所訂定,指的是:</p>
<ol>
<li><strong>自由之零</strong>:為了任何目的執行程式的自由。</li>
<li><strong>自由之一</strong>:研究程式如何運作的自由,並且將程式修改符合本身需求。程式碼的近用是實現這個自由的先決條件。</li>
<li><strong>自由之二</strong>:再次散布程式的自由,以幫助你的鄰居。</li>
<li><strong>自由之三</strong>:改進程式的自由,並將這些改進回饋給社群,讓整個社群均可以因此而受益。程式碼的近用是實現這個自由的先決條件。</li>
</ol>
<p> </p>
<p>依照這四大自由,一個程式存在的目的就是要可以被執行使用,所以使用者有執行程式的自由。執行過程中可能發現程式有缺陷或者不符自己的需求,必須修改才行,所以使用者應該有研究與修改程式的自由。而執行、研究與修改程式的自由不應該侷限在一個人身上,任何人均應該享有這樣的自由,所以使用者有散布程式的自由,讓他人也可以取得這個程式來執行、研究與修改。最後,為了讓所有的程式可以被修改地更臻完美,使用者必須要有將程式修改的內容讓開發社群知道的自由,讓其他正在開發的程式也有機會受到修改內容的啟發,而被修改地更完善。<br /><br />修改程式的形式是原始碼,因此為了要實現自由之一與自由之三,使用者必須可以自由取得程式原始碼,所以自由軟體最大的外在表徵是任何人都可以取得程式原始碼。<br /><br />必須注意的是,四大自由的重點並非在於收費與否。而是在於使用者的「自由」,若針對軟體收費不影響四大自由的實現,那麼這樣的收費當然被允許,所以自由軟體當時可以是收費軟體,反之則否。現行一般商業軟體為收取高額授權金作為散布的對價,影響到自由之一與自由之四的實現,因為受到這樣背景事實的影響,所以現行自由軟體大多不收取授權金,而僅針對散布收取符合基本成本的費用。此外,並非針對軟體本身所收的費用,當然是被允許的,例如:提供客戶自由軟體解決方案的服務費用、提供他人自由軟體擔保與保證的費用等,只要這些的收費機制不妨礙四大自由的實現。,所以自由軟體當然可以是收費軟體,只要這樣整套的收費機制並不妨礙四大自由的實現。因此四大自由精神並不阻礙軟體的商業販售。因此,四大自由的精神並不阻礙軟的商業販售。<br /><br />符合以上四大自由內容的軟體就是自由軟體 (free software),而判斷一個軟體是否屬於自由軟體,則是透過研判軟體授權條款的內容來進行。自由軟體基金會 (Free Software Foundation) 在其網站上有公布有自由軟體的清單(註一)。<br /><br />根據四大自由,Stallman 進一步思考出 copyleft 授權機制,並據此機制撰寫出 GNU General Public License (GPL)。有關 copyleft 授權機制進一步介紹,請見「copyleft 授權機制」一文的介紹。有關 GPL 進一步介紹,請進入「GPL 與 LGPL 專區」參考相關文章。</p>
<p> </p>
<p><strong>【參考資料】</strong></p>
<ol>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=501&Itemid=144">葛冬梅,充滿烏托邦理想的四大自由,開放鑄造場電子報第37期</a>。</li>
<li><a href="https://www.gnu.org/philosophy/free-sw.html">Richard M. Stallman,The Free Software Definition。</a></li>
</ol>
<p> </p>
<p>註一:https://www.fsf.org/licensing/licenses/。</p>
<p>四大自由是由 Richard. M. Stallman (Stallman) 所訂定,指的是:</p>
<ol>
<li><strong>自由之零</strong>:為了任何目的執行程式的自由。</li>
<li><strong>自由之一</strong>:研究程式如何運作的自由,並且將程式修改符合本身需求。程式碼的近用是實現這個自由的先決條件。</li>
<li><strong>自由之二</strong>:再次散布程式的自由,以幫助你的鄰居。</li>
<li><strong>自由之三</strong>:改進程式的自由,並將這些改進回饋給社群,讓整個社群均可以因此而受益。程式碼的近用是實現這個自由的先決條件。</li>
</ol>
<p> </p>
<p>依照這四大自由,一個程式存在的目的就是要可以被執行使用,所以使用者有執行程式的自由。執行過程中可能發現程式有缺陷或者不符自己的需求,必須修改才行,所以使用者應該有研究與修改程式的自由。而執行、研究與修改程式的自由不應該侷限在一個人身上,任何人均應該享有這樣的自由,所以使用者有散布程式的自由,讓他人也可以取得這個程式來執行、研究與修改。最後,為了讓所有的程式可以被修改地更臻完美,使用者必須要有將程式修改的內容讓開發社群知道的自由,讓其他正在開發的程式也有機會受到修改內容的啟發,而被修改地更完善。<br /><br />修改程式的形式是原始碼,因此為了要實現自由之一與自由之三,使用者必須可以自由取得程式原始碼,所以自由軟體最大的外在表徵是任何人都可以取得程式原始碼。<br /><br />必須注意的是,四大自由的重點並非在於收費與否。而是在於使用者的「自由」,若針對軟體收費不影響四大自由的實現,那麼這樣的收費當然被允許,所以自由軟體當時可以是收費軟體,反之則否。現行一般商業軟體為收取高額授權金作為散布的對價,影響到自由之一與自由之四的實現,因為受到這樣背景事實的影響,所以現行自由軟體大多不收取授權金,而僅針對散布收取符合基本成本的費用。此外,並非針對軟體本身所收的費用,當然是被允許的,例如:提供客戶自由軟體解決方案的服務費用、提供他人自由軟體擔保與保證的費用等,只要這些的收費機制不妨礙四大自由的實現。,所以自由軟體當然可以是收費軟體,只要這樣整套的收費機制並不妨礙四大自由的實現。因此四大自由精神並不阻礙軟體的商業販售。因此,四大自由的精神並不阻礙軟的商業販售。<br /><br />符合以上四大自由內容的軟體就是自由軟體 (free software),而判斷一個軟體是否屬於自由軟體,則是透過研判軟體授權條款的內容來進行。自由軟體基金會 (Free Software Foundation) 在其網站上有公布有自由軟體的清單(註一)。<br /><br />根據四大自由,Stallman 進一步思考出 copyleft 授權機制,並據此機制撰寫出 GNU General Public License (GPL)。有關 copyleft 授權機制進一步介紹,請見「copyleft 授權機制」一文的介紹。有關 GPL 進一步介紹,請進入「GPL 與 LGPL 專區」參考相關文章。</p>
<p> </p>
<p><strong>【參考資料】</strong></p>
<ol>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=501&Itemid=144">葛冬梅,充滿烏托邦理想的四大自由,開放鑄造場電子報第37期</a>。</li>
<li><a href="https://www.gnu.org/philosophy/free-sw.html">Richard M. Stallman,The Free Software Definition。</a></li>
</ol>
<p> </p>
<p>註一:https://www.fsf.org/licensing/licenses/。</p>
開放源碼定義與開放源碼促進會
2008-03-03T15:02:49Z
2008-03-03T15:02:49Z
https://www.openfoundry.org/tw/basic-concepts/1447-2010-07-13-09-57-12
葛冬梅
tmk2005@citi.sinica.edu.tw
<p>從時間進程的角度來看,「開放源碼 (open source)」一詞的出現較自由軟體來得晚。九0年代末期,自由軟體逐漸商業化,但是不少人將「自由軟體 (free software)」中的 ”free” 誤以為是免費的意思,使得自由軟體商業化遭遇許多阻礙,因此有人提議另選一個詞來替代自由軟體,最後「開放源碼 (open source)」一詞雀屏中選,並且仿照自由軟體,由當時 Debian 計畫的核心領導人 Bruce Perens 主筆撰寫出開放源碼定義 (Open Source Definition)(註一)。此外,還成立開放源碼促進會 (Open Source Initiative, OSI) 來管理開放源碼定義以及審核條款,只要一份條款被審核通過是符合開放源碼定義,就可以稱之為開放源碼授權條款,採用開放源碼條款散布授權的軟體即是開放源碼軟體,若一份商業產品中包含有開放原碼軟體,其包裝上可以標上開放源碼促進會的證明標章,認識這個標章的消費者就可以知道產品中有使用到開放源碼軟體,進而因為開放源碼軟體特有的優點而購買產品。</p>
<p>目前開放源碼的定義共有十點,內容如下:</p>
<p> </p>
<h3>一、自由再散布 (Free Distribution)</h3>
<p>使用者可以自由重製程式,並且隨意地散布或販售這些程式。現行商業軟體大多收取高額授權金,程式的散布流通性因此降低,為了避免這樣的障礙,條款不得針對使用者重製與散布程式的行為要求支付授權金或類似的費用。</p>
<p>這樣的要求屏除賺取短期金錢利益的企圖,因為透過程式是可以賺取長期利潤的,這樣的利潤不在於程式授權金,而是在於程式相關服務所產生的利潤,例如:客製化利潤、升級服務利潤、書面資料出版利潤、嵌入式硬體銷售利潤等等。</p>
<p> </p>
<h3>二、原始碼 (Source Code)</h3>
<p>原始碼是下面第三點修改程式與產生衍生著作的基礎,所以原始碼的取得必須沒有障礙,取得的原始碼必須容易修改。</p>
<p>程式必須包含原始碼,而且條款必須允許程式以原始碼或編譯過的形式來散布。若程式的散布未包含原始碼,則必須提供一個大眾化的方式讓他人可以取得原始碼,若想要因此收費,所收費用也不得超過合理重製程式所需花費。若是透過網路讓他人下載原始碼,則不可以收取任何費用。</p>
<p>使用者所取得的原始碼必須是修改程式的最優先形式。若為了增加他人修改程式的困難,而處心積慮地混淆原始碼原貌,是不被允許的。像預先處理程式 (preprocessor) 所產生的中間碼等,這類在編譯完成之前各種中間形式的程式碼,都不符合此點的要求。</p>
<p> </p>
<h3>三、衍生著作 (Derived Works)</h3>
<p>一個沒有後續維修的程式所能發揮的功用相當少,而允許修改是後續維修的必要條件,所以條款必須允許使用者可以修改程式,並且因此產生衍生著作。若是條款要求這些修改及衍生著作必須採用與原程式相同的內容來散布,也是可以的,不過這並非開放源碼定義的強制性要求,只是程式著作權人可以選擇這樣的授權內容。像 BSD 條款允許他人將程式原始碼完全封閉起來,但 GPL 就完全不允許,而要求所有修改與衍生著作都必須採用 GPL 授權。</p>
<p> </p>
<h3>四、原創作者者原始碼的一致性 (Integrity of The Author's Source Code)</h3>
<p>修改過的程式有可能被誤認為是程式原創作者自行修改的結果,為了避免這樣的誤解造成程式原創作者聲譽上的影響,條款可以限制原始碼不得以修改過的形式來散布,不過這樣的限制只可能在下列的情況下被允許:</p>
<p>(一)為了讓程式在建置過程中 (at build time) 可以被修改,要允許修正檔 (patch files) 與原始碼一起散布,</p>
<p>(二)若修改部分已經結合到程式中,必須明示他人可以散布這樣建置完成的程式,</p>
<p>(三)條款可以要求修改過的衍生程式必須加上不同的名稱或版本號,用來跟原始程式做區別,不過這當然並非強制性。</p>
<p>這樣的規定將程式原始部分與後續修改部分分開,不致產生混淆,而就算是修改過的程式,只要加上不同於原始程式的版本號或名稱,即可區別,將可不致影響原創作者的聲譽。</p>
<p> </p>
<h3>五、不得對任何人或團體有差別待遇 (No Discrimination Against Persons or Groups)</h3>
<p>為了讓開放源碼這樣的運作模式發揮到極致,必須讓不同背景的個人與團體都可以對程式有所貢獻,因此一份開放源碼的條款不會有將任何個人或團體屏除在開放源碼運作過程之外的規定。</p>
<p>有些國家對於特定種類的軟體有出口管制規定,若在條款中提醒使用者遵守這些規定,並不構成這裡所謂的差別待遇。</p>
<p> </p>
<h3>六、對程式在任何領域內的利用不得有差別待遇 (No Discrimination Against Fields of Endeavor)</h3>
<p>這一點的內涵如字面所示,不過主要的用意是在於:避免條款中出現禁止開放源碼程式被商業利用內容。開放源碼社群歡迎商業使用者的加入,而不是將其屏除在外。</p>
<p> </p>
<h3>七、授權條款的完整散布 (Distribution of License)</h3>
<p>條款所授與的權利不可受到限制,取得程式者必須完整地取得條款所授與的權利。例如:在條款之後附加保密協議 (non-disclosure agreement),其中規定,拿到程式者不得將程式的任何資訊散布給他人,這樣的附加條款等於限制取得程式者再散布程式,違反授權條款的完整散布。</p>
<p> </p>
<h3>八、授權不得專屬於特定產品 (License Must Not Be Specific to a Product)</h3>
<p>程式使用者所享有的權利,不得因為該程式是否屬於某特定軟體的一部分而有差異。若該程式自特定軟體中抽離,並且繼續採用原來的條款單獨散布,使用者所享有的權利,跟程式與特定軟體一同散布時相同的話,就樣的授權內容就符合這點的規定,反之則否。</p>
<p>此點是預防性的內容,防止使用者所享有的權利僅限於程式被包含在特定產品中,進而影響到第一點規定的自由再散布特性。</p>
<p> </p>
<h3>九、授權不得限制其他軟體 (License Must Not Restrict Other Software)</h3>
<p>條款不得針對一同散布的其他軟體有所限制,例如不得規定在同一散布媒介上的其他軟體也必須是開放源碼軟體。</p>
<p>必須注意的是,本點與第四點規範的情況不同,第四點是針對修改程式產生衍生著作的情況而言,本點是針對程式尚未被修改,僅單獨與其他不同程式或軟體放在一起散布的情況而言。因此 GPL 符合這一點,因為若單純將 GPL 程式與其他程式或軟體放在一起散布的話,GPL 並不要求其他程式或軟體也必須要採用 GPL 授權。</p>
<p> </p>
<h3>十、授權必須技術中立 (License Must Be Technology-Neutral)</h3>
<p>授權不得以特定技術或介面模式為前提。這點主要是為了避免條款被限制在網際網路或圖形化使用環境下才可以成立,例如條款規定採用「點選即視為同意 (click -wrap)」的程序作為使用者接受條款的要件,這樣的規定阻礙程式透過紙本形式散布,因此不符合技術中立要件的要求。</p>
<p> </p>
<p>開放源碼定義的原文抽象模糊,因此在應用上當然也有模糊不清之處,在經過許多申請案例的討論後,目前各點的內容均已經有大致的判定方向或範圍,不過在實際案例中,還是有少數條款的內容與上述定義略有出入。</p>
<p> </p>
<p><strong>【參考資料】</strong></p>
<ol>
<li>開放源碼定義原文請見:<a href="https://www.opensource.org/docs/definition.php">OSI,The Open Source Definition (Annotated)</a>。</li>
<li>Bruce Perens 自己對於開放源碼定義的註解:<a href="https://perens.com/OSD.html">The Open Source Definition</a>。</li>
</ol>
<p> </p>
<p>註一:Perens 當時是根據 Debian Free Software Guidelines (DFSG) 為基礎,修改之後完成開放源碼定義的第一版。DFSG 內容請見:<a href="https://www.debian.org/social_contract#guidelines">https://www.debian.org/social_contract#guidelines</a>。</p>
<p>從時間進程的角度來看,「開放源碼 (open source)」一詞的出現較自由軟體來得晚。九0年代末期,自由軟體逐漸商業化,但是不少人將「自由軟體 (free software)」中的 ”free” 誤以為是免費的意思,使得自由軟體商業化遭遇許多阻礙,因此有人提議另選一個詞來替代自由軟體,最後「開放源碼 (open source)」一詞雀屏中選,並且仿照自由軟體,由當時 Debian 計畫的核心領導人 Bruce Perens 主筆撰寫出開放源碼定義 (Open Source Definition)(註一)。此外,還成立開放源碼促進會 (Open Source Initiative, OSI) 來管理開放源碼定義以及審核條款,只要一份條款被審核通過是符合開放源碼定義,就可以稱之為開放源碼授權條款,採用開放源碼條款散布授權的軟體即是開放源碼軟體,若一份商業產品中包含有開放原碼軟體,其包裝上可以標上開放源碼促進會的證明標章,認識這個標章的消費者就可以知道產品中有使用到開放源碼軟體,進而因為開放源碼軟體特有的優點而購買產品。</p>
<p>目前開放源碼的定義共有十點,內容如下:</p>
<p> </p>
<h3>一、自由再散布 (Free Distribution)</h3>
<p>使用者可以自由重製程式,並且隨意地散布或販售這些程式。現行商業軟體大多收取高額授權金,程式的散布流通性因此降低,為了避免這樣的障礙,條款不得針對使用者重製與散布程式的行為要求支付授權金或類似的費用。</p>
<p>這樣的要求屏除賺取短期金錢利益的企圖,因為透過程式是可以賺取長期利潤的,這樣的利潤不在於程式授權金,而是在於程式相關服務所產生的利潤,例如:客製化利潤、升級服務利潤、書面資料出版利潤、嵌入式硬體銷售利潤等等。</p>
<p> </p>
<h3>二、原始碼 (Source Code)</h3>
<p>原始碼是下面第三點修改程式與產生衍生著作的基礎,所以原始碼的取得必須沒有障礙,取得的原始碼必須容易修改。</p>
<p>程式必須包含原始碼,而且條款必須允許程式以原始碼或編譯過的形式來散布。若程式的散布未包含原始碼,則必須提供一個大眾化的方式讓他人可以取得原始碼,若想要因此收費,所收費用也不得超過合理重製程式所需花費。若是透過網路讓他人下載原始碼,則不可以收取任何費用。</p>
<p>使用者所取得的原始碼必須是修改程式的最優先形式。若為了增加他人修改程式的困難,而處心積慮地混淆原始碼原貌,是不被允許的。像預先處理程式 (preprocessor) 所產生的中間碼等,這類在編譯完成之前各種中間形式的程式碼,都不符合此點的要求。</p>
<p> </p>
<h3>三、衍生著作 (Derived Works)</h3>
<p>一個沒有後續維修的程式所能發揮的功用相當少,而允許修改是後續維修的必要條件,所以條款必須允許使用者可以修改程式,並且因此產生衍生著作。若是條款要求這些修改及衍生著作必須採用與原程式相同的內容來散布,也是可以的,不過這並非開放源碼定義的強制性要求,只是程式著作權人可以選擇這樣的授權內容。像 BSD 條款允許他人將程式原始碼完全封閉起來,但 GPL 就完全不允許,而要求所有修改與衍生著作都必須採用 GPL 授權。</p>
<p> </p>
<h3>四、原創作者者原始碼的一致性 (Integrity of The Author's Source Code)</h3>
<p>修改過的程式有可能被誤認為是程式原創作者自行修改的結果,為了避免這樣的誤解造成程式原創作者聲譽上的影響,條款可以限制原始碼不得以修改過的形式來散布,不過這樣的限制只可能在下列的情況下被允許:</p>
<p>(一)為了讓程式在建置過程中 (at build time) 可以被修改,要允許修正檔 (patch files) 與原始碼一起散布,</p>
<p>(二)若修改部分已經結合到程式中,必須明示他人可以散布這樣建置完成的程式,</p>
<p>(三)條款可以要求修改過的衍生程式必須加上不同的名稱或版本號,用來跟原始程式做區別,不過這當然並非強制性。</p>
<p>這樣的規定將程式原始部分與後續修改部分分開,不致產生混淆,而就算是修改過的程式,只要加上不同於原始程式的版本號或名稱,即可區別,將可不致影響原創作者的聲譽。</p>
<p> </p>
<h3>五、不得對任何人或團體有差別待遇 (No Discrimination Against Persons or Groups)</h3>
<p>為了讓開放源碼這樣的運作模式發揮到極致,必須讓不同背景的個人與團體都可以對程式有所貢獻,因此一份開放源碼的條款不會有將任何個人或團體屏除在開放源碼運作過程之外的規定。</p>
<p>有些國家對於特定種類的軟體有出口管制規定,若在條款中提醒使用者遵守這些規定,並不構成這裡所謂的差別待遇。</p>
<p> </p>
<h3>六、對程式在任何領域內的利用不得有差別待遇 (No Discrimination Against Fields of Endeavor)</h3>
<p>這一點的內涵如字面所示,不過主要的用意是在於:避免條款中出現禁止開放源碼程式被商業利用內容。開放源碼社群歡迎商業使用者的加入,而不是將其屏除在外。</p>
<p> </p>
<h3>七、授權條款的完整散布 (Distribution of License)</h3>
<p>條款所授與的權利不可受到限制,取得程式者必須完整地取得條款所授與的權利。例如:在條款之後附加保密協議 (non-disclosure agreement),其中規定,拿到程式者不得將程式的任何資訊散布給他人,這樣的附加條款等於限制取得程式者再散布程式,違反授權條款的完整散布。</p>
<p> </p>
<h3>八、授權不得專屬於特定產品 (License Must Not Be Specific to a Product)</h3>
<p>程式使用者所享有的權利,不得因為該程式是否屬於某特定軟體的一部分而有差異。若該程式自特定軟體中抽離,並且繼續採用原來的條款單獨散布,使用者所享有的權利,跟程式與特定軟體一同散布時相同的話,就樣的授權內容就符合這點的規定,反之則否。</p>
<p>此點是預防性的內容,防止使用者所享有的權利僅限於程式被包含在特定產品中,進而影響到第一點規定的自由再散布特性。</p>
<p> </p>
<h3>九、授權不得限制其他軟體 (License Must Not Restrict Other Software)</h3>
<p>條款不得針對一同散布的其他軟體有所限制,例如不得規定在同一散布媒介上的其他軟體也必須是開放源碼軟體。</p>
<p>必須注意的是,本點與第四點規範的情況不同,第四點是針對修改程式產生衍生著作的情況而言,本點是針對程式尚未被修改,僅單獨與其他不同程式或軟體放在一起散布的情況而言。因此 GPL 符合這一點,因為若單純將 GPL 程式與其他程式或軟體放在一起散布的話,GPL 並不要求其他程式或軟體也必須要採用 GPL 授權。</p>
<p> </p>
<h3>十、授權必須技術中立 (License Must Be Technology-Neutral)</h3>
<p>授權不得以特定技術或介面模式為前提。這點主要是為了避免條款被限制在網際網路或圖形化使用環境下才可以成立,例如條款規定採用「點選即視為同意 (click -wrap)」的程序作為使用者接受條款的要件,這樣的規定阻礙程式透過紙本形式散布,因此不符合技術中立要件的要求。</p>
<p> </p>
<p>開放源碼定義的原文抽象模糊,因此在應用上當然也有模糊不清之處,在經過許多申請案例的討論後,目前各點的內容均已經有大致的判定方向或範圍,不過在實際案例中,還是有少數條款的內容與上述定義略有出入。</p>
<p> </p>
<p><strong>【參考資料】</strong></p>
<ol>
<li>開放源碼定義原文請見:<a href="https://www.opensource.org/docs/definition.php">OSI,The Open Source Definition (Annotated)</a>。</li>
<li>Bruce Perens 自己對於開放源碼定義的註解:<a href="https://perens.com/OSD.html">The Open Source Definition</a>。</li>
</ol>
<p> </p>
<p>註一:Perens 當時是根據 Debian Free Software Guidelines (DFSG) 為基礎,修改之後完成開放源碼定義的第一版。DFSG 內容請見:<a href="https://www.debian.org/social_contract#guidelines">https://www.debian.org/social_contract#guidelines</a>。</p>
軟體專利議題
2008-03-01T14:44:37Z
2008-03-01T14:44:37Z
https://www.openfoundry.org/tw/basic-concepts/1446-2010-07-13-09-57-52
葛冬梅
tmk2005@citi.sinica.edu.tw
<p>自由/開放源碼軟體授權條款初期都只有著作權授權,但是近年來專利相關討論漸多,浮上台面的專利疑慮也越來越多,因此專利逐漸成為自由/開放源碼軟體領域中重要的一塊。</p>
<p>專利制度主要在於促進產業發產,因此與同樣具有濃厚商業色彩的商標權統稱為「工業財產權」。因為這樣的目的,所以在設計上偏重保護產業利益,例如採取登記保護主義,只有登記的專利才受到保護,即使是最先發明者應用自己發明的技術,但因為相同技術已經被他人登記專利核准,在沒有例外的情況下,若沒有取得專利權人的授權,最先發明者這樣應用自己發明技術的行為,反而是侵犯了他人的專利權。此外,專利制度保護的是思想、程序等抽象的技術思想,而不是依據技術思想所實際製作的物品或呈現出來的文字描述,舉例來說,一個經過核准的奈米專利 K,在未經 K 專利權人同意的情況下,一件毛衣與一項電子儀器都應用到奈米專利 K,這兩項物品所呈現的外型與用途雖然完全不同,但是侵權使用的事實卻都是肯定的。</p>
<p>專利制度上述的特色,容易造成一般人在無知的情況下侵權應用他人專利,而自由/開放源碼軟體所特有的自由修改與散布方式,則可能會增加專利侵權的風險,所以近年來,自由/開放源碼軟體支持者開始採取一些措施,希望可以將這樣的侵權風險降到最低,或者是當侵權事件發生時,可以減少產生的損害。這些措施主要有三大類:</p>
<p><strong><br /></strong></p>
<h3>一、專利授權與授權終止條款</h3>
<p>這樣的專利授權有兩個層面:第一個層面是原始程式著作權人將程式中的專利,隨著程式的釋出一起授權出去;第二個層面是強制程式的修改者/貢獻者,也必須將寫入程式中的專利一起授權出去,在不清楚專利狀態時,有些條款還會要求修改者/貢獻者必須附上所有已知的相關資訊,讓拿到程式的其他使用者可以有機會循著這些資訊來聯絡上真正的專利權人,以合法利用程式。</p>
<p>所謂授權終止條款,大意是指自由/開放源碼軟體使用者或修改者等被授權人,反過來控告程式授權人或任何一位其他被授權人侵害他人專利,此時授與這位控告者的權利全部終止。這類規定的差異性頗大,有些條款只有規定上述內容,有些則規定詳細的應對措施與實施這些措施的期間。</p>
<p>以上規定的常見授權條款有:</p>
<ul>
<li>MPL (Mozilla Public License)</li>
<li>Apache License 2.0</li>
<li>CPL (Common Public License)</li>
<li>OSL (Open Software License)</li>
<li>GPL3 (GNU General Public License 3.0)</li>
<li>LGPL3 (GNU Lesser General Public License 3.0)</li>
</ul>
<p><br /><strong> </strong></p>
<h3>二、專利收集與開放</h3>
<p>這樣的措施主要是由一些支持自由/開放源碼軟體的公司所發起。這些公司中部分是主動將所擁有的大量專利釋出給他人自由利用,公開承諾不會控告自由/開放源碼社群對這些專利的利用,這些承諾可以在 Patent Commons Project 網頁中查詢到。部分公司則是集結成一個組織,透過組織四處收購或接受他人捐出專利,期望最終可以為自由/開放源碼軟體開發社群,成立一個龐大專利池 (patent pool),例如 OIN(註二)。</p>
<p><br /><strong> </strong></p>
<h3>三、取得不提出專利侵權主張的承諾</h3>
<p>有些利用自由/開放源碼軟體來營利的商業公司則乾脆與專屬軟體公司簽訂契約,取得對方不會向自己客戶提出專利侵權主張的承諾,例如:Novell 在二00六底與微軟簽訂技術開發合作契約,其中一項內容就是雙方承諾針對契約相關的產品提供專利保護,所以微軟不會對契約相關產品使用者行使專利權,依循這樣的模式,也開始有其他的公司與微軟簽訂類似的契約內容(註三)。</p>
<p>除了上述措施以外,Linux Foundation 為了讓 Linux 作業系統可以繼續順利改版與散布,因此也致力於降低專利所帶來的風險,上述所提及的 Patent Commons Project 就是由 Linux Foundation 所支持的。此外,該組織下還有一個 Open Source As Prior Art (OSAPA) 計畫,專門與美國專利商標局 (USPTO) 合作,致力於減少品質不佳專利的數量,透過檢驗專利申請案件的相關先前技術是否已經存在於既有的自由/開放源碼軟體中,一方面可以駁回不適格的專利申請案件,另外一方面則是降低了可能威脅自由/開放源碼軟體的專利技術。</p>
<p> </p>
<p>註一:<a href="https://www.patent-commons.org/commons/pledgesearch.php?searchSubmit=Find">https://www.patent-commons.org/commons/pledgesearch.php?searchSubmit=Find</a>。Patent Commons Project 是 Linux Fundation 之下的一個計畫。</p>
<p>註二:Open Invention Network,<a href="https://www.openinventionnetwork.com/index.php">https://www.openinventionnetwork.com/index.php</a>。</p>
<p>註三:<a href="https://www.news.com/Microsoft-makes-Linux-pact-with-Novell/2100-1016_3-6132119.html">https://www.news.com/Microsoft-makes-Linux-pact-with-Novell/2100-1016_3-6132119.html</a>;<a href="https://www.zdnet.com.tw/news/software/0,2000085678,20119246,00.htm">https://www.zdnet.com.tw/news/software/0,2000085678,20119246,00.htm</a>。</p>
<p>自由/開放源碼軟體授權條款初期都只有著作權授權,但是近年來專利相關討論漸多,浮上台面的專利疑慮也越來越多,因此專利逐漸成為自由/開放源碼軟體領域中重要的一塊。</p>
<p>專利制度主要在於促進產業發產,因此與同樣具有濃厚商業色彩的商標權統稱為「工業財產權」。因為這樣的目的,所以在設計上偏重保護產業利益,例如採取登記保護主義,只有登記的專利才受到保護,即使是最先發明者應用自己發明的技術,但因為相同技術已經被他人登記專利核准,在沒有例外的情況下,若沒有取得專利權人的授權,最先發明者這樣應用自己發明技術的行為,反而是侵犯了他人的專利權。此外,專利制度保護的是思想、程序等抽象的技術思想,而不是依據技術思想所實際製作的物品或呈現出來的文字描述,舉例來說,一個經過核准的奈米專利 K,在未經 K 專利權人同意的情況下,一件毛衣與一項電子儀器都應用到奈米專利 K,這兩項物品所呈現的外型與用途雖然完全不同,但是侵權使用的事實卻都是肯定的。</p>
<p>專利制度上述的特色,容易造成一般人在無知的情況下侵權應用他人專利,而自由/開放源碼軟體所特有的自由修改與散布方式,則可能會增加專利侵權的風險,所以近年來,自由/開放源碼軟體支持者開始採取一些措施,希望可以將這樣的侵權風險降到最低,或者是當侵權事件發生時,可以減少產生的損害。這些措施主要有三大類:</p>
<p><strong><br /></strong></p>
<h3>一、專利授權與授權終止條款</h3>
<p>這樣的專利授權有兩個層面:第一個層面是原始程式著作權人將程式中的專利,隨著程式的釋出一起授權出去;第二個層面是強制程式的修改者/貢獻者,也必須將寫入程式中的專利一起授權出去,在不清楚專利狀態時,有些條款還會要求修改者/貢獻者必須附上所有已知的相關資訊,讓拿到程式的其他使用者可以有機會循著這些資訊來聯絡上真正的專利權人,以合法利用程式。</p>
<p>所謂授權終止條款,大意是指自由/開放源碼軟體使用者或修改者等被授權人,反過來控告程式授權人或任何一位其他被授權人侵害他人專利,此時授與這位控告者的權利全部終止。這類規定的差異性頗大,有些條款只有規定上述內容,有些則規定詳細的應對措施與實施這些措施的期間。</p>
<p>以上規定的常見授權條款有:</p>
<ul>
<li>MPL (Mozilla Public License)</li>
<li>Apache License 2.0</li>
<li>CPL (Common Public License)</li>
<li>OSL (Open Software License)</li>
<li>GPL3 (GNU General Public License 3.0)</li>
<li>LGPL3 (GNU Lesser General Public License 3.0)</li>
</ul>
<p><br /><strong> </strong></p>
<h3>二、專利收集與開放</h3>
<p>這樣的措施主要是由一些支持自由/開放源碼軟體的公司所發起。這些公司中部分是主動將所擁有的大量專利釋出給他人自由利用,公開承諾不會控告自由/開放源碼社群對這些專利的利用,這些承諾可以在 Patent Commons Project 網頁中查詢到。部分公司則是集結成一個組織,透過組織四處收購或接受他人捐出專利,期望最終可以為自由/開放源碼軟體開發社群,成立一個龐大專利池 (patent pool),例如 OIN(註二)。</p>
<p><br /><strong> </strong></p>
<h3>三、取得不提出專利侵權主張的承諾</h3>
<p>有些利用自由/開放源碼軟體來營利的商業公司則乾脆與專屬軟體公司簽訂契約,取得對方不會向自己客戶提出專利侵權主張的承諾,例如:Novell 在二00六底與微軟簽訂技術開發合作契約,其中一項內容就是雙方承諾針對契約相關的產品提供專利保護,所以微軟不會對契約相關產品使用者行使專利權,依循這樣的模式,也開始有其他的公司與微軟簽訂類似的契約內容(註三)。</p>
<p>除了上述措施以外,Linux Foundation 為了讓 Linux 作業系統可以繼續順利改版與散布,因此也致力於降低專利所帶來的風險,上述所提及的 Patent Commons Project 就是由 Linux Foundation 所支持的。此外,該組織下還有一個 Open Source As Prior Art (OSAPA) 計畫,專門與美國專利商標局 (USPTO) 合作,致力於減少品質不佳專利的數量,透過檢驗專利申請案件的相關先前技術是否已經存在於既有的自由/開放源碼軟體中,一方面可以駁回不適格的專利申請案件,另外一方面則是降低了可能威脅自由/開放源碼軟體的專利技術。</p>
<p> </p>
<p>註一:<a href="https://www.patent-commons.org/commons/pledgesearch.php?searchSubmit=Find">https://www.patent-commons.org/commons/pledgesearch.php?searchSubmit=Find</a>。Patent Commons Project 是 Linux Fundation 之下的一個計畫。</p>
<p>註二:Open Invention Network,<a href="https://www.openinventionnetwork.com/index.php">https://www.openinventionnetwork.com/index.php</a>。</p>
<p>註三:<a href="https://www.news.com/Microsoft-makes-Linux-pact-with-Novell/2100-1016_3-6132119.html">https://www.news.com/Microsoft-makes-Linux-pact-with-Novell/2100-1016_3-6132119.html</a>;<a href="https://www.zdnet.com.tw/news/software/0,2000085678,20119246,00.htm">https://www.zdnet.com.tw/news/software/0,2000085678,20119246,00.htm</a>。</p>
相關法律領域
2008-02-27T00:00:00Z
2008-02-27T00:00:00Z
https://www.openfoundry.org/tw/basic-concepts/1444-2010-07-13-09-59-50
葛冬梅
tmk2005@citi.sinica.edu.tw
<p>自由/開放源碼軟體有其特殊的授權內容,但這並不代表自由/開放源碼軟體自行創造或制定出新的法律,這些授權條款仍然必須受到既有法律規定的拘束,若是條款內容與法律規定不符合的話,這一部分的內容就很有可能因此不具有法律拘束力。</p>
<p>與自由/開放源碼軟體相關的法律領域主要是智慧財產權,除此之外還包括民法。相關的法律規定當然不會僅止於本文所列,因為運用自由/開放源碼軟體的行為多樣,可以能涉及的法律種類與層面也因此有著無限的可能,例如商業販售自由/開放源碼軟體,這些商業行為自然必須受到公平交易法約束。此外,這些相關的法律規定與領域也會隨著各國法律制度而有不同。</p>
<p>在我國,具體相關的重要法律如下:</p>
<p> </p>
<h3>一、著作權法</h3>
<p><strong></strong>現在一般常見自由/開放源碼軟體授權條款都著重在著作權的授權,因此與著作權法有著密切的關係。</p>
<p> </p>
<h3>二、專利法</h3>
<p>軟體程式除了可以用著作權制度保護外,還可以用專利制度來保護。早期撰寫出來的授權條款大多沒有考慮專利保護制度所帶來的影響,所以並沒有專利相關內容,不過近來專利侵權議題浮上檯面,因為許多人擔心自由/開放源碼軟體較非自由/開放源碼軟體容易發生專利侵權糾紛,不過也因為這樣的討論趨勢,所以新近草擬的條款大多將專利保護制度所產生的影響納入條款內容中,包括:專利授權、提出專利侵權主張而引發授權終止等。有關這方面的討論,請見:</p>
<ol>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=522&Itemid=331">當專利遇上自由/開放源碼軟體(上)</a></li>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=521&Itemid=331">當專利遇上自由/開放源碼軟體(下)</a></li>
</ol>
<p><br /><strong> </strong></p>
<h3>三、商標法</h3>
<p>隨著自由/開放源碼軟體商業化販售越來越普遍,所以也開始有自由/開放源碼軟體申請商標,例如 Linux 與 Firefox(註一),因此也開始有些與商標相關法律議題被討論。</p>
<p><br /><strong> </strong></p>
<h3>四、民法</h3>
<p>上述的著作權法、專利法與商標法,其實都屬於民法的特別法,在有需要適用到法律條文來檢視授權內容的時候,先在這些特別法規中找尋到適用的規定來適用,若找不到,才回歸到民法中尋找適當的條文適用。此外,因為自由/開放源碼軟體的授權機制與定型化契約的運作方式類似,因此民法中定型化契約的條款也有適用的可能。</p>
<p> </p>
<p>註一:目前管理 Linux 商標的是 Linux Mark Institute,網址:<a href="https://www.linuxmark.org/">https://www.linuxmark.org/</a>;管理 Mozilla 商標的是 Mozilla Foundation,商標管理政策網址:<a href="https://www.mozilla.org/foundation/trademarks/">https://www.mozilla.org/foundation/trademarks/</a>。</p>
<p>自由/開放源碼軟體有其特殊的授權內容,但這並不代表自由/開放源碼軟體自行創造或制定出新的法律,這些授權條款仍然必須受到既有法律規定的拘束,若是條款內容與法律規定不符合的話,這一部分的內容就很有可能因此不具有法律拘束力。</p>
<p>與自由/開放源碼軟體相關的法律領域主要是智慧財產權,除此之外還包括民法。相關的法律規定當然不會僅止於本文所列,因為運用自由/開放源碼軟體的行為多樣,可以能涉及的法律種類與層面也因此有著無限的可能,例如商業販售自由/開放源碼軟體,這些商業行為自然必須受到公平交易法約束。此外,這些相關的法律規定與領域也會隨著各國法律制度而有不同。</p>
<p>在我國,具體相關的重要法律如下:</p>
<p> </p>
<h3>一、著作權法</h3>
<p><strong></strong>現在一般常見自由/開放源碼軟體授權條款都著重在著作權的授權,因此與著作權法有著密切的關係。</p>
<p> </p>
<h3>二、專利法</h3>
<p>軟體程式除了可以用著作權制度保護外,還可以用專利制度來保護。早期撰寫出來的授權條款大多沒有考慮專利保護制度所帶來的影響,所以並沒有專利相關內容,不過近來專利侵權議題浮上檯面,因為許多人擔心自由/開放源碼軟體較非自由/開放源碼軟體容易發生專利侵權糾紛,不過也因為這樣的討論趨勢,所以新近草擬的條款大多將專利保護制度所產生的影響納入條款內容中,包括:專利授權、提出專利侵權主張而引發授權終止等。有關這方面的討論,請見:</p>
<ol>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=522&Itemid=331">當專利遇上自由/開放源碼軟體(上)</a></li>
<li><a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=521&Itemid=331">當專利遇上自由/開放源碼軟體(下)</a></li>
</ol>
<p><br /><strong> </strong></p>
<h3>三、商標法</h3>
<p>隨著自由/開放源碼軟體商業化販售越來越普遍,所以也開始有自由/開放源碼軟體申請商標,例如 Linux 與 Firefox(註一),因此也開始有些與商標相關法律議題被討論。</p>
<p><br /><strong> </strong></p>
<h3>四、民法</h3>
<p>上述的著作權法、專利法與商標法,其實都屬於民法的特別法,在有需要適用到法律條文來檢視授權內容的時候,先在這些特別法規中找尋到適用的規定來適用,若找不到,才回歸到民法中尋找適當的條文適用。此外,因為自由/開放源碼軟體的授權機制與定型化契約的運作方式類似,因此民法中定型化契約的條款也有適用的可能。</p>
<p> </p>
<p>註一:目前管理 Linux 商標的是 Linux Mark Institute,網址:<a href="https://www.linuxmark.org/">https://www.linuxmark.org/</a>;管理 Mozilla 商標的是 Mozilla Foundation,商標管理政策網址:<a href="https://www.mozilla.org/foundation/trademarks/">https://www.mozilla.org/foundation/trademarks/</a>。</p>
法律特性
2008-02-20T14:36:33Z
2008-02-20T14:36:33Z
https://www.openfoundry.org/tw/basic-concepts/1445-2012-04-30-01-48-51
葛冬梅
tmk2005@citi.sinica.edu.tw
<p>從法律的角度來看,目前一個被稱為自由/開放源碼軟體的程式或軟體,大多具有下面的法律特性:</p>
<p>一、不收取授權金;<br />二、特定著作權權利被授與出去;<br />三、授權對象不特定;<br />四、授權地域不特定;<br />五、非專屬授權;<br />六、不附隨擔保或保證。</p>
<p> </p>
<h3>一、不收取授權金</h3>
<p>不收取授權金是自由/開放源碼軟體與專屬軟體 (proprietary software) 最大的分野所在,而這裡的授權金不單指著作權的授權金,還包括了專利授權金,只要名目是「授權金」的費用,都不會被收取。相對於許多收取高額授權金的程式,許多人自然會因為費用的因素而樂於利用自由/開放源碼軟體。<strong></strong></p>
<p> </p>
<h3>二、特定著作權權利被授與出去</h3>
<p>在不收取授權金的基礎上,軟體著作權人免費地將使用、重製、散布以及修改程式的權利授與出去。商業利用或販售屬於授權範圍內,因此任何人也可以將自由/開放源碼軟體進行商業化利用與販售,只要這些行為不違反程式的授權內容就可以。</p>
<p>為了要使用、重製與散布程式,被授權人只需要有程式的目的碼就可以了,但若為了要修改程式,被授權人就必須要有程式原始碼,因此大部分自由/開放源碼軟體的原始碼都有管道可以取得。因此,一般人所認識的自由/開放源碼軟體第二大特點:開放原始碼,從法律的層面來看,其實只是為了實現修改權所必須採取的行為,否則被授權人無法修改程式。</p>
<p>在此必須附帶說明:一般常聽到「開放原始碼」的文字描述,並不完全正確。如前面所述,提供/拿到原始碼的目的是為了實現修改權,而擁有修改權者是指拿到程式之人,所以有權利索取原始碼的人是拿到程式之人,而提供原始碼的對象也是這個人,被授權人再次散布自由/開放源碼軟體的時候,並沒有義務將原始碼公開給所有人,比較正確的用詞應該是「提供原始碼」。但是目前網際網路發達,將原始碼置於網路供人下載是個相當便利的管道,因此感覺起來,好像自由/開放源碼軟體的原始碼都是可以公開取得的,再加上英文常見 ”open source” 這樣的用詞,許多人就使用「開放原始碼」這樣的描述文字。</p>
<p> </p>
<h3>三、授權對象不特定</h3>
<p>這樣的特性是指:任何一個人、公司行號或機關團體都可以依照授權內容來利用程式,並沒有限制必須具備什麼樣的身分條件才可以利用程式。</p>
<p> </p>
<h3>四、授權地域不特定</h3>
<p>與前一個特性類似:在任何地域均可以依照授權內容來利用程式,並沒有限制在特定地域內才可以利用程式。這項特性在現行網路傳輸發達的時代具有特別的意義,因為目前自由/開放源碼軟體的主要散布方式,就是透過網路下載,唯有不限制授權地域,自由/開放源碼軟體才可以輕易地透過網路來散布。</p>
<p> </p>
<h3>五、非專屬授權</h3>
<p>這項特性對於自由/開放源碼軟體的商業化有相當程度的正面影響,因為非專屬授權讓程式可以雙重授權,而雙重授權則是一些重要自由/開放源碼軟體公司的商業運作模式。</p>
<p>「非專屬授權」這個概念與「專屬授權」相對立。簡單來說,專屬授權是指,一項權利一旦授與給一位被授權人之後,相同內容不得再授權給第二位,這位被授權人專屬擁有利用這項授權權利。相反地,非專屬授權就是指,權利人並未將權利專屬授權給任何對象,相同的權利內容他還可以再授權給他人。非專屬授權在業界運用相當頻繁,例如一部電影的戲院上映權利,可以將臺灣地區的戲院上映權非專屬授權給 A 公司,香港地區的則非專屬授權給 B 公司,若一開始就將規定將全球的戲院上映權專屬授權給 A 公司,這部電影香港地區的戲院上映權自然就無法再授權給 B 公司。</p>
<p>一些公司運用自由/開放源碼軟體這樣的授權特性,將自行開發、著作權完全掌握在自己手中的軟體以雙重授權來運用:一方面透過自由/開放源碼軟體的條款將程式授權出去,吸取社群的開發與修改意見,改良程式;另一方面透過商業授權條款,以收取授權金的方式將程式授權給商業公司或學校等組織利用。這樣的運作模式,可以透過廣大的社群成員來改良程式,同時也可以賺取授權金。目前採用這種方式運作知名的商業公司有 Trolltech 與 MySQL(註一)。</p>
<p> </p>
<h3>六、不附隨擔保或保證</h3>
<p>自由/開放源碼軟體不附隨有任何的擔保或是保證,也就是說因為使用自由/開放源碼軟體而產生的所有損失或法律責任,必須由被授權人自行承擔。例如因為程式品質不佳導致資料遺失,或者有人指控被授權人所使用的自由/開放源碼軟體侵害他人智慧財產權,這些損失與法律責任風險都由被授權人自己承擔,並無法像程式的著作權人或者前一手來請求賠償。不過,若是有人願意提供擔保或保證,並提出承諾的話,當然可以依據承諾的內容向擔保人或保證人求償。</p>
<p>這種不附隨擔保或保證的特色背後代表的是一種利益平衡的觀念:因為著作權人未收取權利金、未蒙利益,所以就不需要負責任。不過這裡所謂的不付責任,當然是在法律規範的限度之內,若是法律有特別的規定,這時候著作權人或是再次散布程式的被授權人當然必須依照法律負擔一定的法律責任(註二)。</p>
<p>以上所敘述的特性乃是原則,並不代表所有自由/開放源碼軟體授權條款均具備上面六項特性。此外,有些條款允許被授權人再次散布程式的時候可以自由採用授權內容,並不一定要與原授權條款一樣或相容,例如採用 BSD、MIT 散佈的程式,被授權人可以依照自己的意思自由運用程式,例如可以收取授權金的方式來散布程式,或者不提供原始碼給拿到程式之人,所以一個屬於自由/開放源碼軟體的程式,在散布過程中有可能喪失自由/開放源碼軟體的特性。不過無論如何,當然還是要看程式所適用授權條款的實際內容如何。</p>
<p> </p>
<p>註一:有關這方面進一步的介紹請見:林誠夏,<a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=1056&Itemid=144">自由/開放源碼軟體的商業運用模式(下)-雙重授權篇</a>,自由/開放源碼軟體鑄造場電子報,<a href="https://www.openfoundry.org/index.php?option=com_letterman&task=view&Itemid=92&id=280">第 83 期</a>。</p>
<p>註二:關於此點進一步討論請參見:林誠夏,<a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=518&Itemid=252">授權條款中免責聲明的法律意義</a>,自由/開放源碼軟體鑄造場電子報,<a href="https://www.openfoundry.org/index.php?option=com_letterman&task=view&Itemid=92&id=204">第 38 期</a>。</p>
<p>從法律的角度來看,目前一個被稱為自由/開放源碼軟體的程式或軟體,大多具有下面的法律特性:</p>
<p>一、不收取授權金;<br />二、特定著作權權利被授與出去;<br />三、授權對象不特定;<br />四、授權地域不特定;<br />五、非專屬授權;<br />六、不附隨擔保或保證。</p>
<p> </p>
<h3>一、不收取授權金</h3>
<p>不收取授權金是自由/開放源碼軟體與專屬軟體 (proprietary software) 最大的分野所在,而這裡的授權金不單指著作權的授權金,還包括了專利授權金,只要名目是「授權金」的費用,都不會被收取。相對於許多收取高額授權金的程式,許多人自然會因為費用的因素而樂於利用自由/開放源碼軟體。<strong></strong></p>
<p> </p>
<h3>二、特定著作權權利被授與出去</h3>
<p>在不收取授權金的基礎上,軟體著作權人免費地將使用、重製、散布以及修改程式的權利授與出去。商業利用或販售屬於授權範圍內,因此任何人也可以將自由/開放源碼軟體進行商業化利用與販售,只要這些行為不違反程式的授權內容就可以。</p>
<p>為了要使用、重製與散布程式,被授權人只需要有程式的目的碼就可以了,但若為了要修改程式,被授權人就必須要有程式原始碼,因此大部分自由/開放源碼軟體的原始碼都有管道可以取得。因此,一般人所認識的自由/開放源碼軟體第二大特點:開放原始碼,從法律的層面來看,其實只是為了實現修改權所必須採取的行為,否則被授權人無法修改程式。</p>
<p>在此必須附帶說明:一般常聽到「開放原始碼」的文字描述,並不完全正確。如前面所述,提供/拿到原始碼的目的是為了實現修改權,而擁有修改權者是指拿到程式之人,所以有權利索取原始碼的人是拿到程式之人,而提供原始碼的對象也是這個人,被授權人再次散布自由/開放源碼軟體的時候,並沒有義務將原始碼公開給所有人,比較正確的用詞應該是「提供原始碼」。但是目前網際網路發達,將原始碼置於網路供人下載是個相當便利的管道,因此感覺起來,好像自由/開放源碼軟體的原始碼都是可以公開取得的,再加上英文常見 ”open source” 這樣的用詞,許多人就使用「開放原始碼」這樣的描述文字。</p>
<p> </p>
<h3>三、授權對象不特定</h3>
<p>這樣的特性是指:任何一個人、公司行號或機關團體都可以依照授權內容來利用程式,並沒有限制必須具備什麼樣的身分條件才可以利用程式。</p>
<p> </p>
<h3>四、授權地域不特定</h3>
<p>與前一個特性類似:在任何地域均可以依照授權內容來利用程式,並沒有限制在特定地域內才可以利用程式。這項特性在現行網路傳輸發達的時代具有特別的意義,因為目前自由/開放源碼軟體的主要散布方式,就是透過網路下載,唯有不限制授權地域,自由/開放源碼軟體才可以輕易地透過網路來散布。</p>
<p> </p>
<h3>五、非專屬授權</h3>
<p>這項特性對於自由/開放源碼軟體的商業化有相當程度的正面影響,因為非專屬授權讓程式可以雙重授權,而雙重授權則是一些重要自由/開放源碼軟體公司的商業運作模式。</p>
<p>「非專屬授權」這個概念與「專屬授權」相對立。簡單來說,專屬授權是指,一項權利一旦授與給一位被授權人之後,相同內容不得再授權給第二位,這位被授權人專屬擁有利用這項授權權利。相反地,非專屬授權就是指,權利人並未將權利專屬授權給任何對象,相同的權利內容他還可以再授權給他人。非專屬授權在業界運用相當頻繁,例如一部電影的戲院上映權利,可以將臺灣地區的戲院上映權非專屬授權給 A 公司,香港地區的則非專屬授權給 B 公司,若一開始就將規定將全球的戲院上映權專屬授權給 A 公司,這部電影香港地區的戲院上映權自然就無法再授權給 B 公司。</p>
<p>一些公司運用自由/開放源碼軟體這樣的授權特性,將自行開發、著作權完全掌握在自己手中的軟體以雙重授權來運用:一方面透過自由/開放源碼軟體的條款將程式授權出去,吸取社群的開發與修改意見,改良程式;另一方面透過商業授權條款,以收取授權金的方式將程式授權給商業公司或學校等組織利用。這樣的運作模式,可以透過廣大的社群成員來改良程式,同時也可以賺取授權金。目前採用這種方式運作知名的商業公司有 Trolltech 與 MySQL(註一)。</p>
<p> </p>
<h3>六、不附隨擔保或保證</h3>
<p>自由/開放源碼軟體不附隨有任何的擔保或是保證,也就是說因為使用自由/開放源碼軟體而產生的所有損失或法律責任,必須由被授權人自行承擔。例如因為程式品質不佳導致資料遺失,或者有人指控被授權人所使用的自由/開放源碼軟體侵害他人智慧財產權,這些損失與法律責任風險都由被授權人自己承擔,並無法像程式的著作權人或者前一手來請求賠償。不過,若是有人願意提供擔保或保證,並提出承諾的話,當然可以依據承諾的內容向擔保人或保證人求償。</p>
<p>這種不附隨擔保或保證的特色背後代表的是一種利益平衡的觀念:因為著作權人未收取權利金、未蒙利益,所以就不需要負責任。不過這裡所謂的不付責任,當然是在法律規範的限度之內,若是法律有特別的規定,這時候著作權人或是再次散布程式的被授權人當然必須依照法律負擔一定的法律責任(註二)。</p>
<p>以上所敘述的特性乃是原則,並不代表所有自由/開放源碼軟體授權條款均具備上面六項特性。此外,有些條款允許被授權人再次散布程式的時候可以自由採用授權內容,並不一定要與原授權條款一樣或相容,例如採用 BSD、MIT 散佈的程式,被授權人可以依照自己的意思自由運用程式,例如可以收取授權金的方式來散布程式,或者不提供原始碼給拿到程式之人,所以一個屬於自由/開放源碼軟體的程式,在散布過程中有可能喪失自由/開放源碼軟體的特性。不過無論如何,當然還是要看程式所適用授權條款的實際內容如何。</p>
<p> </p>
<p>註一:有關這方面進一步的介紹請見:林誠夏,<a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=1056&Itemid=144">自由/開放源碼軟體的商業運用模式(下)-雙重授權篇</a>,自由/開放源碼軟體鑄造場電子報,<a href="https://www.openfoundry.org/index.php?option=com_letterman&task=view&Itemid=92&id=280">第 83 期</a>。</p>
<p>註二:關於此點進一步討論請參見:林誠夏,<a href="https://www.openfoundry.org/index.php?option=com_content&task=view&id=518&Itemid=252">授權條款中免責聲明的法律意義</a>,自由/開放源碼軟體鑄造場電子報,<a href="https://www.openfoundry.org/index.php?option=com_letterman&task=view&Itemid=92&id=204">第 38 期</a>。</p>