關於本報

自由軟體鑄造場電子報
報主:中央研究院資創中心
創刊日期:2004-06-03
發報頻率:雙週刊
訂閱人數:3,349
官網:

近期電子報


訂閱便利貼


將貼紙語法置入您的網站或部落格當中, 訪客可以輸入mail取得認證信,並按下確認連結後, 快速訂閱您的報紙。
預覽圖
訂閱自由軟體鑄造場電子報報
自由軟體鑄造場電子報
-----------------------------------------------------------------------------------------------------
Plurk FaceBook Twitter 收進你的MyShare個人書籤 MyShare
  顯示內嵌語法

自由軟體鑄造場電子報
發報時間: 2009-12-29 05:00:00 / 報主:OSSF
[公益聯播]捐款芳名錄
本期目錄
[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
[法律源地] 以契約限制 GPL 程式碼散布的法律爭議
[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
翁卓立/文 2009/12/20

NetworX 是一套以 PHP 撰寫的互動型社交網路平台,符合各種規模的公司或組織在網站架設上的需求。除了可以應用在公司或組織等團體的使用環境之外,也能作為社群的交流平台。此外,更允許使用者自行調整設定,讓 NetworX 更加切合自身的需求。

如果要投票表決目前在網際網路上最為流行的網站應用為何,許多人多半會將票投給微網誌與社交網站平台。的確,這兩種網路服務雖然不能說是一夕爆紅,但從台灣過去幾個月的媒體報導來看,似乎給人一種如果不知道這兩種網站服務為何,便已經跟不上流行的感覺。經由新聞媒體的大肆渲染之後,相信大多數人就算沒玩過 Facebook,也都知道上面有一個「開心農場」的小遊戲。

NetworX 軟體小檔案

軟體版本:1.0.2
軟體性質:GNU General Public License (GPL)
使用限制:無
官方網址:http://www.socialabc.com
下載網址:http://sourceforge.net/projects/networx/files/NetworX-src-1.0.2.zip/download(11.6MB)

[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
▲NetworX官方網站

事實上,像 Facebook 這樣的社交網站只是利用小遊戲增進會員中的彼此互動,並吸引使用者停留在網站中,但這些小遊戲並不是社交網站的主要訴求。所謂的社交網站,注重的畢竟還是人與人之間的交流,而不是讓人沈迷其中的小遊戲。

本文所要介紹的 NetworX,本身也是一套社交網站的架設平台。或許一提到這是社交網站的架設工具,便會先讓人產生負面印象。但事實上 NetworX 只是一套相當單純的社交網站平台,本身並沒有提供小遊戲的功能,所以可以讓使用者更加注重在社交網站的基本核心,也就是利用網站介面作為彼此溝通聯絡的管道。

從 NetworX 所提供的主要功能來看,更可以驗證這個說法。例如個人資料的編寫可以讓所有人了解某個使用者的專長與興趣,留言系統可以讓對社群有想法或意見的人直接留下訊息。部落格功能可以作為資訊、新聞或最新消息的分享平台,而論壇功能則可以讓使用者進行討論,以便針對特定議題發表個人的看法。

至於互動式的事件行事曆、檔案共享以及邀請其他人加入特定群組的功能,也是 NetworX 的重點所在。如果架設網站時考慮的主要項目是在管理工具上, NetworX 的管理介面也不會讓人失望。NetworX 的管理介面相當直覺且易於操作,更擁有強大的報表與統計功能,可以讓系統管理者直接得知社群成員的統計資料和相關的活動列表。

NetworX 是一套以 PHP 撰寫的互動型社交網路平台,可以提供全方位的特點,以符合各種規模的公司或組織在此方面網站架設的需求。除了可以應用在公司或組織等團體的使用環境之外,也能作為社群的交流平台。使用者可以自行進行各種調整,讓 NetworX 更加切合自己的需求。

[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
▲NetworX 的主畫面。

使用 NetworX 來建立自己的社交平台相當簡單,只需要花費幾分鐘進行安裝與設定,即可完成整個架站作業。無論是學校、班級或宗教團體等小型群組,或是較為專業的醫師、律師等團體,都能利用 NetworX 作為彼此溝通交流與互動的線上平台。有了這樣的社交平台,所有人便能以較為快速的方式將資訊傳遞給社群中的所有人;而網路上的其他使用者,如果需要尋找相關的資料時,也可以從此網站中取得自己所需要的重要資訊。

至於網路上實際採用 NetworX 的案例,則包含了以社交功能為主要訴求的入口網站、公司行號的內部網站、線上媒體(包含雜誌、報紙以及各種出版品的業者)、電子商務,以及其他非營利性的組織等等。

[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
▲NetworX 的安裝相當容易,只需幾個簡單的步驟即可完成。


◎ NetworX的特色

要成為社交網路平台的最佳選擇,NetworX 自然提供了許多獨樹一格的特色,其中比較主要的有三十餘項之多,而且每一項功能都能獨自加入或移除,讓使用者在建立社群網站時有更多的自主性,可以成立一個獨一無二的網站。


※ 社交媒體

像 NetworX 這樣的網站平台,本身便是以幫助人群彼此連接與進行互動為設計的主要目的。網站上的使用者可以建立自己的個人資料,並分享自己的專長、興趣。使用者也能在自己的群組中加入新朋友或是聯絡人,分享自己的相片與影片,也能讓朋友得知自己目前的動態與想法。


※ 媒體收集

NetworX 本身所提供的媒體收集功能,可以讓使用者上傳相片或影片,並使用網頁方式進行共享。在上傳檔案時,如果要上傳的檔案數量較多,可以利用大量媒體上傳程式進行。此程式允許一次上傳最多高達一百張相片至個人的網頁中。已經上傳至社交網路平台的相片,則可以另外建立相簿以進行分類與管理,讓所有使用者都能以最快速的方式找到相關的圖片或影片。

[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
▲NetworX 的檔案分享功能,可讓使用者將相片或影片分享給他人。


※ 線上事件

NetworX 內建的事件行事曆功能,讓使用者與其他人的互動更加密切,並且可以進行活動的推廣與宣傳。使用者除了可以透過 NetworX 將自身相關的事件分享給其他人以外,也能參與其他使用者的事件。

有需要的話,也可以持續追蹤特定事件,以便在第一時間得知相關的訊息。這些動作彼此都能夠互相進行,也就是說,使用者可以參與別人的事件或活動,其他使用者亦能參加自己的事件。

線上事件的功能可以讓使用者以非常簡潔便利的方式公開自己的既定行程,並分享相關資訊給網站上的所有使用者,例如新產品的上市展示、各種週年慶活動、特賣會等等。

藉由 NetworX 的行事曆元件,除了讓使用者安排自己未來的行程之外,也增加其他使用者參與自己所安排活動的機會,亦可提高雙方彼此的互動程度,可說是一舉數得。

[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
▲NetworX 的行事曆除了可以記載自己未來的行事計畫之外,也能公開給其他人作為參考。


※ 簡訊功能

NetworX 所建立的社群網站,與各種主要的論壇系統雷同,都提供簡訊功能以供使用者彼此互相聯絡使用。一些網站系統會將簡訊功能稱為私人訊息,因為這些訊息通常是以私下傳送的方式進行,只有傳送與接收端的帳號擁有者才能得知訊息的內容,不必擔心訊息內容被外人得知。

也因為簡訊功能具有相當程度的私密保護功能,所以在需要於社群中進行較為機密的資訊傳遞時,都能利用此功能進行資料交換。如此一來,個人的私人資料不會在公開的網路中被顯示出來,自然也就減少了許多個人資料外洩的困擾。而為了確保簡訊內容不會被外人取得,無論是訊息的發送者或接收者,在存取該則簡訊時都需要先行登入系統,驗證過身分後才能進入收件匣取得訊息的內容。

[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
▲簡訊功能提供了相對較為隱密的溝通方式。


※ 會員群組

網站中的所有會員都是來自於真實社會,所以社群網站也等於是一個小型社會的縮影。每個人在真實世界中都有自己喜好的事物,來到網路上的社群網站,自然也會有想要與擁有相同興趣的人進行討論與分享。這樣的需求在 NetworX 所架設的系統之中相當容易被滿足,因為 NetworX 所提供的會員群組功能,正是為了這樣的需求所設計的。

NetworX 的使用者可以自行建立各種群組,以便提供系統上的成員一個彼此進行討論的空間。擁有相同嗜好的使用者,可以加入自己感興趣的群組成為會員,即可與其他群組中的會員進行互動。群組會員亦可邀請自己的聯絡人加入該群組,而這也正是社交網站成立的最大目的,也就是無論進行互動的主因為何,讓所有人彼此都可以產生互動。

透過文件共享的特色,NetworX 的會員群組可以提供更進一步的功能,讓群組中的成員利用文件或資源的共享,並藉由分工合作的方式於虛擬的網路世界中完成真實世界的工作。善加利用這項優點,可以讓辦公室中的工作更快完成,並為公司帶來更多的利益。


※ 搜尋與過濾

任何網站系統在經過一段時間的運作之後,通常都會因為資料量逐漸擴增而變得越來越難以駕馭。因為要在無數的資料中尋找特定的幾筆資料,系統若沒有提供合適的工具加以輔助,一般很難在短時間內完成這樣的艱鉅任務。

NetworX 設計時也考慮到了資料在大量增加的情況下,尋找特定資料的困難度必定呈現指數型的上昇曲線。對於使用者而言,不但不會因為採用系統而獲得好處,反而會因為資料的建檔變得更加容易,而在資料庫中形成更多的資料量,相對地,搜尋資料時將會變得更加困難。為了避免這樣的問題產生,NetworX 採用了一套與系統完全整合的搜尋與過濾功能,讓資料檢索不再成為使用者的負擔。

[技術專欄] 管理介面直覺易操作 - 打造 NetworX 互動型社交網站
▲藉由搜尋功能,可以更加快速地找到所需要的資料。

舉例來說,如果系統上已經建立了許多使用者群組,並擁有數以千計的使用者帳號。如果沒有提供搜尋或過濾功能,無論是要尋找特定帳號或是特定的群組,都會是一件曠日費時的工作。但只要利用 NetworX 的搜尋介面,在輸入正確關鍵字的情況下,無論是尋找使用者帳號或群組,都會是相當容易的一件事。

當然在進行搜尋作業的時候,關鍵字的選擇將會影響搜尋的結果與速度。如何以最適當的關鍵字進行搜尋,則需要一點時間加以練習,才能在最短的時間內找到自己所需要的資料。


※ 簡易管理

許多人常說架站容易管站難,這句話的原意原本是指架設網站的技術並不難,難的在於網站成立後所需要面對的各種人際關係處理技巧。如果人與人之間的問題沒有以適當的方法加以處理,往往會形成許多更大的問題。

雖然架設網站的技術往往都不是非常複雜,但這是對於已經有一定程度的 IT 人員才成立的一句話。因為即使是簡單的網站系統,系統管理員都有可能因為需要進行一些細部調整,而必須直接修改網站系統的程式碼。對於有經驗的程式設計人員或是 IT 專業人員而言,這樣的修改或許不會是太大的問題。但對於患有程式恐懼症的人來說,光是要找到相對應的程式碼可能就不是很容易的一件工作,更不用說要加以修改。

其實,網站系統的管理並不一定真的需要進行程式修改,只要網站系統的設計有周詳的考慮,系統管理員大可直接使用現有的功能進行管理,而不必實際動手修改程式。對於 NetworX 而言,採用此系統的管理員相較之下幸福許多。因為 NetworX 在系統管理方面早已考慮到許多經常會被修改的部分,並提供相對應的操作介面與功能,所以系統管理員只需要使用這些操作介面,即可完成幾近全部的管理功能。除非想要修改的功能是系統本身沒有提供的,否則完全沒有修改程式原始碼的必要。

也因為 NetworX 在管理介面上的設計十分良好,就算使用者本身並不是專業的 IT 從業人員,也能直接進行整個系統的管理。或許,有人會質疑這樣的設計方式會讓網站架設變得太過容易,加上沒有豐富經驗的網站管理者,會導致系統的穩定性下降。但事實上大多數的網站管理並不需要動用太過深奧的網路管理理論,良好的操作介面設計,不但可以造福一般使用者在操作系統時不需要花費太多時間進行學習,也可以讓系統管理員將寶貴的時間花費在更需要人力處理的部分,而不是從事一些枯燥的管理工作。

NetworX 希望系統管理員只須使用滑鼠點擊畫面上的按鈕即可完成所有管理工作,而不是進入系統目錄中尋找特定的程式碼再加以修改。而這樣的設計理念也造就 了NetworX 的管理介面變得相當容易使用,系統管理員如果想要修改社群的相關設定,決定何種資料可以被公開,以及被公開的對象為何等等,都只需要進入管理介面點選幾個按鈕就能夠完成。

所以,NetworX 的系統管理員需要的只是正確的判斷力,可以決定各種資料的公開程度;最不需要的則是程式設計能力,因為這樣的能力在 NetworX 系統之中根本是英雄無用武之地。


※ 展示站台

如果上述的說明已經讓人對於 NetworX 產生興趣,但又無法確定這樣的一套系統是否可以滿足個人或團體的需求,或許可以考慮前往 NetworX 官方網站所提供的試用網站。在實際操作過後,多少可以更加了解 NetworX 的功能與特色所在,進而得知 NetworX 的設計是否符合自己的需要。

NetworX 的試用站台網址為「http://www.socialabc.com/index.php?page=demo」,利用此網站所提供的使用者與管理者帳號,便可以進一步了解系統前端的操作介面以及後端管理選單的所有功能。


※ 結語

一般人聽到社群網站,第一個想到的總是像 Facebook 這種目前已經被不少公司行號列為封鎖對象的網站,因為會對它產生一些負面的印象。事實上,Facebook 會遭到封鎖,並不是因為本身的社交功能,而是許多人沈迷在 Facebook 的小遊戲中,影響上班時的表現。以 NetworX 所提供的功能來看,除了目前並未支援小遊戲以吸引更多使用者之外,其餘的功能與特色都與 Facebook 相去不遠。如果不要將 Facebook 的負面印象過於放大,仔細思考社交網站能夠帶給公司或團體何種利益,或許可以較為正確地為社交網路平台作出合理的評斷。水能載舟亦能覆舟,這個道理在網站平台上也一樣適用。


作者簡介:

翁卓立

逢甲大學資訊工程系畢業,當年因為要嘗試不同於微軟的作業系統而安裝 Linux。目前主要利用 Linux/FreeBSD 進行各種私人網站架設工作,包括 WWW、FTP、Blog、網路相簿等等。

⊙本文經《網管人》同意,轉載自第 47 期文章內容。


[法律源地] 以契約限制 GPL 程式碼散布的法律爭議
林珈宏/文 2009/12/20

在眾多自由軟體授權條款中,歷史最久、也最知名的 GNU General Public License(以下簡稱 GPL)(註一)是開發自由軟體過程中經常會接觸到的授權條款。GPL 的重要性除了為逾六成的自由軟體專案採用之外,其被戲稱像病毒感染性一般的授權拘束性,更是廣被知悉的重要特性(註二);授權拘束性要求 GPL 程式碼之衍生作品皆仍須採 GPL 授權,以維持永久改作的自由,這是自由軟體社群喜愛它的原因,但同時也是商業經營者又愛又怕之處:商業經營者既愛自由軟體快速開發、成本低廉的優勢,卻又擔心競爭者將迅速地再複製其基於 GPL 開發的程式,因此商業實務上,廠商違反 GPL、不願依 GPL 開放原始碼的情況層出不窮。
 

本文要探討的爭議點在於:GPL 程式碼的開發者,得否以契約限制後手不得再散布其程式;以及該限制散布契約的法律效果為何,最後提出建議的解決途徑
也因為本文非屬初階的淺談介紹,而是傾向於稍微進階的法律面探討,所以以下分析所使用文字、法理、契約條文等,對於絕大多數的程式開發者而言可能較為艱澀難懂,筆者盡可能以較為淺顯的方式說明;力有未逮之處,敬請讀者包容海涵,亦可至自由軟體鑄造場的法政討論區再來一同研究、討論!

會發生這個爭議的情況是因為,GPL 授權拘束性,其發生義務的關鍵在於授權人做出「散布 (convey) 程式碼」的行為,也就是說,一旦開發者將 GPL 程式碼散布給任何人(不論僅散布目的碼 (object code) 或同時散布原始碼 (source code) ),即必須使取得程式目的碼的該後手能得到原始碼。因此,可以反面推論得出「就算程式碼是 GPL 授權的,只要不散布給任何後手,純屬單純內部使用,就不必提供他人取得原始碼的管道」這個結論(註三)。既然僅限取得目的碼之後手才有權利向前手索取原始碼,所以不願意提供原始碼的開發者就會設法使他人無法取得其目的碼,這樣的想法就會衍生出本文的爭議事實:開發者直接要求其特定的後手不得將程式碼再散布給任何第三人。

舉例來說:某甲依 GPL 釋出程式給某乙,但與乙約定,其取得該程式僅限供乙內部使用,而不得散布其原始碼或目的碼給任何第三人;乙必須同意此條件,甲才願意散布該程式給乙。同時,乙也同意,如果乙違反這個約定,向第三人提供該程式碼,則必須賠償甲若干金額之違約金。(註四)

以下解析本案例之法律關係:

  1. 依照自由軟體基金會 (Free Software Foundation, FSF) 的定義,自由軟體必須要含有「四大自由」:(一)執行程式、(二)研究、修改程式、(三)散布程式,及(四)改良程式並回饋眾人的自由。(註五)從這四個要件來檢視本案例,甲雖然沒有不讓後手乙取得該程式原始碼,也就是後手仍然享有執行程式、研究、修改程式等自由,但是卻限制乙散布的自由,這已經違反自由軟體授權條款的基本精神。雖然單單對於精神有所牴觸並不直接可以得出違反自由軟體授權條款之法律效果如何,但由於 FSF 是 GPL 制定者及管理者,它對於 GPL 的解釋將會很大程度地影響到包含法院在內的許多人的見解,因此 GPL 在解釋上必然、也必須要完全符合四大自由;所以這個約定乙不得再散布程式碼的契約,在結論上就會被認為是違反 GPL 的,因為這個契約已經違反四大自由了。
  2. 依 GPL 第二版 (GPL v2) 條文第 6 條規定,授權人甲不得對乙做任何的限制;依 GPL 第三版 (GPL v3) 條文第 7 條「附加條款」之規定,僅得就本條所明文規定的第 a 款至第 f 款這六種事由來例外地附加限制,除此之外,不得為任何其他限制。本案例中,約定「後手未經前手同意,就不得再散布給任何人」的契約,依 GPL v2 即不得為之,並且這個契約也不在 GPL v3 所例外明示容許的六款情況之內,同樣不得為之;所以若有禁止散布之限制約定,則視為喪失 GPL 之合法授權(註六)、(註七);未經授權利用該著作,即屬侵害原著作權人著作權之行為。
  3. 以法律的觀點檢視這個違反 GPL 的約定,本文見解認為,它是另一個獨立的契約,而非附條件或附負擔的 GPL 授權契約。因為 GPL 已明示不得在其條款以外施加額外的附加條件或負擔,為探求當事人的真意並尊重其締約自由的考量下,宜解釋為這是該 GPL 授權契約以外的另一個契約。從契約法的原則來看,這個附加限制的契約仍為有效,其違約金條款亦為有效。(註八)所以若後手乙違反該契約,就必須對甲負擔債務不履行之損害賠償責任。
  4. GPL v3 條文第 2 條規定,若甲乙之間僅屬於「內部關係」,則可例外地不視為對後手散布的行為。但甲乙在法律上是獨立的二個權利主體,彼此又無僱佣、承攬關係,無法被認為僅屬內部關係,所以這就必須認定為散布行為。同前所述,一旦散布該程式,就必須依照 GPL 來提供原始碼,同時也必須讓後手享有四大自由──其中當然包括了自由再散布給任何第三人之權利。
  5. 本例中,由於甲乙約定乙不得再散布給第三人,如此甲就等同喪失了 GPL 之合法授權。如果該程式是源自於他人的 GPL 程式碼,則原權利人就可以向甲請求侵權行為的損害賠償;但是,如果該程式完全是由甲所撰寫的,在沒有其他因素影響之下,甲是程式的唯一著作權人,也就是法律所定的最初權利人,所以甲想要如何釋出這個程式,有完全的選擇自由,即使甲同時宣稱以 GPL 釋出,又與乙訂定本文探討的限制契約,因為根本就沒有侵害任何人的權利,因此也無須討論到甲是否違反 GPL 以及是否需要賠償的問題。

所以本案例前提,也跟商業實務上最常見的情形一樣:甲並不是最初著作權人,而是繼受他人以 GPL 授權的程式碼,再加以改作成為自己的程式;依前述小結,甲與後手約定其不得再散布程式,即必然將喪失 GPL 之合法授權,而變成侵權行為。既然如此,為何甲還會這樣做呢?

理由一:甲原來不願以 GPL 釋出它的程式碼,但如果是用「GPL+限制後手散布權」的方式,甲就可以控制程式碼的流向不會被商業競爭者得到,甲就會更為願意釋出其程式碼。商業實務上,商業公司將原始碼交付給協力廠商,同時限制其再散布修改之後的程式碼,這是很常見的慣行;也因為這樣長久慣行的傳統授權方式,導致商業公司或許並不那麼清楚這麼做即會違反 GPL 並造成侵權,甚至不清楚侵權的後果,除了損害賠償之外,還有可能在訴訟過程中遭到假處分或禁制令等等,以致於產生這樣的結果。

理由二:甲乙間的約定很難被外人所知悉,因為這個限制的契約並不要求要公開或登記(不具公示性),並且 GPL 授權契約同樣也不具公示性,如果雙方皆守口如瓶,乙也完全遵守不再散布給任何第三人的約定,則現實上他人的確很難得知這件事。

不過,FSF 的態度當然是不樂見 GPL 程式的散布者與後手自訂契約;雖然,自訂契約又不對外聲張的情況下,FSF 的確查察不到或是難以發動司法行動,但是一旦這個 GPL 程式並非由該自訂契約雙方所自行寫作,或是有對外散布行為,那麼 FSF 的態度是接受舉報,並且如果原著作權人願意授權的話,他們會代理訴訟行為來禁止這樣的行為。(註九)

理由三:倘此事真的「不幸」被發現了,甲也不會在第一時間就面臨法律訴訟;起訴之前的過程中會有溝通、準備的緩衝期間:可以準備和解、釋出原始碼,拖延到該程式碼已無商業利用價值時再釋出;一旦在正式進入訴訟程序之前就釋出原始碼,原著作權人(通常是社群)的目的也達到了,訴訟程序通常就沒有開始的必要。如此一來,甲可能認為,在此階段的損失是只有信用及商譽,而沒有特別想到金錢損失。但是事實上,甲一旦侵權被發現,原權利人亦有可能在交涉的過程中,很迅速地起訴;一進入訴訟程序,就會使甲承擔極大的法律風險,這是甲不能夠輕忽的可能性。

另外,如果原著作權不是社群,而是商業公司(例如之前經營 MySQL 的 SUN),事實上並不容易產生上述的問題,結果反而可能是,甲會直接向原著作權人取得商業的專屬授權 (proprietary licensing),因為甲並不擔心支付授權金(這是商業傳統上一貫的做法),甲不願意的是公開原始碼。當然,甲也不是不能跟社群另外談商業授權,但自由軟體社群的本質及精神就是不支持專屬授權的行為,所以本文就不特別就此情形為假設條件了。

這種現況如何改變?以下提出幾點建議:

方法一:要求商業公司正視侵權所面臨的嚴重損失。社群的最終目的即是希望大家皆能遵守 GPL 的規定來開放原始碼,訴訟是最後的、最激烈的、也是最能收效的手段。事實上,如果商業公司對於侵權的的法律責任稍作研究即可了解到, 除了在敗訴後必須開放原始碼以及負擔損害賠償之外,還有可能在訴訟過程中遭受假處分或禁制令,它的殺傷力極大,可禁止公司繼續利用該程式碼,會讓公司的產品從市場上下架、在海關被扣留、生產線停工,金錢損失甚鉅,因此迅速提出訴訟,並向法院聲請假處分(註十),是自由軟體著作權人目前對商業公司所能採行最據嚇阻力的法律措施,才能迫使商業公司正視這個法律風險,同時也能在訴訟前階段能取得更優越的談判地位;進而商業公司未來才會更加尊重 GPL 的規定。

方法二:除民事侵權訴訟外,以我國為例,違反著作權法的行為往往尚有刑責(註十一)。甲公司違反 GPL,等同未經授權而改作、重製、再授權他人的著作物,在能證明行為人有故意的情況下,著作權人可經由檢察官起訴行為人之不法行為;刑事責任對於公司經營者而言,往往比民事賠償更具嚇阻力,也不失為一個強而有力的手段。

方法三:商業公司在抄寫程式碼的同時,務必清查其授權狀態,若涉及 GPL 授權,只有兩條路:接受並且遵守它的規定,否則只有避免抄寫 GPL 程式碼,轉而找尋義務性較少的 BSD 等條款或改寫程式原始碼。

方法四:由於 GPL 授權的對象僅止於程式碼,而不及於以外之其他著作;商業利用上,許多製程及設定上的調校及 know-how,不必然須以程式碼之方式傳遞於後手,而得以說明文件之方式交由合作、協力之廠商或產業聯盟會員,這麼做就可以不必限制後手的散布權,以合乎 GPL 的規定,使任何後手皆享有完整的四大自由,又可以達到避免競爭者迅速複製同類型產品的損失之效果。這點是筆者的個人見解,目的是希望能在開放原始碼的公益考量與商業競爭的私益考量之間,尋找可能的平衡點。

結語:在商業公司的共同開發及交互授權的競爭合作策略之下,近年來商業實務上已逐漸形成產業聯盟或上下游廠商整合生產的競爭模式。基於經營之考量,對於 GPL 程式碼的運作及授權情況可能發生本例這種遊走邊緣,甚至步入侵權的結果,或許在所難免;然而,也不能夠只因為「難免」違反而正當化不遵守 GPL 的行為。筆者認為,我們還是應該就法律及商業之間找出更多可能的選項,而不應該消極地認為既然無法不違反 GPL 就只好繼續偷偷侵權。也就是說,商業公司在面對 GPL 時,仍然必須找到真正合法的,或至少更佳、更尊重原著作權人及自由軟體社群的商業模式。筆者在前述方法四中,僅提供一個可能可運作的模式來拋磚引玉,期待本文能讓讀者一起思考相關的問題,一起找出更多雙贏的可能性!

(在此感謝自由軟體鑄造場法政組同仁林懿萱、葛冬梅、林誠夏在筆者撰文的過程中對於本文提出許多有洞見的想法及建議;惟本文文責仍由筆者自負,固不待言。)

參閱GPL v2 條文GPL v3 條文

授權拘束性亦有被稱為授權承繼性 (License Inheritance)、授權互惠性 (License Reciprocal)、授權感染性 (Viral Effect) 以及授權攫取性 (License Capture) 等名詞,係因文義及哲學意涵相異所致,但實指同樣一種性質。本文係採較中性、僅描述其性質,除去價值判斷的用詞。

參閱自由軟體基金會網站的問答集:If I know someone has a copy of a GPL-covered program, can I demand he give me a copy? "No. The GPL gives him permission to make and redistribute copies of the program if he chooses to do so. He also has the right not to redistribute the program, if that is what he chooses."

本例之假設為,甲乙為兩家商業公司(因為通常個人之間較不會出現這種約定),並且,甲乙雙方之締約地位對等,針對其約定之條件,乃屬於個別磋商任一方針對契約締結與否及其內容如何皆享有完全自由的商議空間

參閱:The Free Software Definition葛冬梅,充滿烏托邦理想的四大自由 ,自由軟體鑄造場電子報,第35期。

GPL v2 條文第 7 條及 GPL v3 條文第 12 條 (No Surrender of Others' Freedom) 規定:"If, as a consequence . . . for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License." 依上述條文,如果有前手有施加一些條款跟 GPL 有所牴觸的,那前手也不能免除後手遵守 GPL 條件的義務。亦可參閱自由軟體基金會網站的問答集:Does the GPL allow me to distribute copies under a nondisclosure agreement?,是指出 GPL 不准這樣的限制約定。既然 GPL 不准這樣的做法,這樣的做法自然違反 GPL,違反 GPL 就等於喪失合法授權。

雖然本文見解原則上認為一旦有此限制散布契約的存在,即等於增加 GPL 所無之限制,而使甲喪失合法被授權人的地位;惟就法律解釋的邏輯推演而言,亦非不可能存在甲未違反 GPL 之空間—因為乙事實上並非被前手「壓迫」。GPL v2 條文第 6 條:". . . You may not impose any further restrictions on the recipients' exercise of the rights granted herein. . . ." 係指前手針對 GPL 所賦予後手之各種權利,不得更為施加 (impose) 任何限制。從同條前段可見,後手擁有的各種權利,包括了重製、散布及修改等自由;四大自由本就包括作為及不作為的自由在內,亦即後手於修改該 GPL 程式之後,本可依照自己的意願選擇散布該程式,並開放原始碼,或是不對任何人散布程式,以規避他人對其索取原始碼。乙既得自願地選擇不再對外散布程式碼,依舉重以明輕之法理,為何乙不能自願地選擇與甲約定不再對外散布程式碼呢?畢竟二者皆為相同的自願,GPL 容許其自已決定不散布之自由,卻禁止其與前手約定不散布之自由,在邏輯上即有衡突之處。並且,甲乙契約得以成立之基礎即在於任何一方都出於完全的自願(當事人意思表示必須自由是契約成立生效的要件之一),如此則可推得「乙事實上並非被前手壓迫」之結論。自由地內心自我決定不散布程式與自由地與他人約定不散布程式皆為相同的自由,依此論點則可推出甲乙合意約定乙不得再散布程式之契約並不必然使甲違反 GPL 而喪失合法被授權人之地位。惟此與自由軟體基金會的見解(多數見解)相反。

私法自治原則之體現即在契約自由,契約自由即指並不輕易將一個契約解為無效,除非該契約違反法律的強行規定或有背於公共秩序善良風俗,其效力始受影響。本例中之另一個契約及其違約金,並未違反上述規定(GPL 並非法律,僅為一契約),當事人間為如此約定則不宜解為無效。

當然,如此的見解會引發一個疑慮:如果這個限制後手再散布的契約的違約金條款仍然有效,那麼不論原著作權人是否出面對前手主張侵權,後手一旦違約,則必然將面臨違約金的賠償。然而,必須再度提醒的是,導出此結論之假設前提乃是「甲乙兩公司之締約地位、談判能力對等」(參閱註四),亦即雙方商議是出於完全的自願,並且得對於契約條款內容為個別磋商,所以才如此認定。反之,若前手與後手的締約實力懸殊,後手就前手提出之契約內容毫無置喙之餘地,僅能就其預定的契約條款為同意與否的擇一性選擇,則此情況宜解為該違約金條款為無效。總而言之,本案例僅係基於一種假設而推導出之結論,並無一般性的適用;該違約金條款的有效性,仍須就個案判斷之。

參閱自由軟體基金會網站的問答集:Does the GPL allow me to distribute copies under a nondisclosure agreement?

這裡的假處分是指「定暫時狀態假處分」,即如果不立即停止被告的侵權行為,將會對於原告發生重大之損害的話,原告可以聲請法院為定暫時狀態之處分,法院的裁定可以禁止被告繼續使用該程式碼。參閱

轉寄『第 141 期 以契約限制 GPL 程式碼散布的法律爭議』這期電子報

寄信人暱稱  寄信人email
收信人暱稱  收信人email

  • 社群留言
  • 留言報主