發表時間：2003-01-09 20:33:46

IP:61.221.xxx.xxx 未訂閱

石頭閒語 (http://home.educities.edu.tw/shirock/ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=big5"> <META content="MSHTML 6.00.2800.1126" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff>

《Linux紅帽旋風》摘要

出版商與系列名：天下文化 - 資訊時代 13
原名：Under The Radar
作者：Robert Young (Chairman of Red Hat, Inc.) and Wendy Goldman Rohm
譯者：鄭鴻坦
ISBN：957-621-665-6
First edition: 2001.12.5
Second edition: 2002.10.30

原始碼授權

所有這些已經公開發布，供開放原始碼軟體所使用的標準授權協議，都有一些共通的特點。最明顯的就是，所謂開放軟體「自由使用」，除了表明軟體不收費之外，更意謂著將有關使用與再散播的限制減至最低程度。
亥克認為，最好是選一種現有的開放原始碼授權合約來使用，或是根據我們特定的業務需求，選擇一種來加以修改。
選擇中還包括了根本不必授權，也就是將軟體宣布為公共版權。雖然「公共版權軟體」這個名詞，經常被隨意用來泛指開放原始碼軟體或自由軟體，但是如果嚴格定義，公共版權軟體指的是沒有版權的軟體。就是說版權已經過了時效，或是版權持有人明確宣告放棄版權。沒有版權，就沒有所謂軟體「所有人」能加以授權；因而在任何情況下，任何人都可以使用該軟體，沒有任何限制。
「把軟體放進公共領域，能給使用者及開發人員最大限度的自由。然而，它同時會開啟另一個可能性，讓有些開發者利用這個軟體做基礎，創作出所有權專屬的程式。」亥克說道。如果這些程式在市場上取得優勢，從實際角度來看，縱使它仍有某些部分屬於公共版權，這軟體已經不再算是開放原始碼了。事實上，使用者甚至可能不知道，這個所有權專屬的產品，利用了公共版權的程式碼。
由於這個潛在的問題，大部分開放原始碼的支持者提倡，不要將軟體放進公共領域；即使是不相信「智慧財產」這個觀念的開發人員，也鼓勵大家使用著作權的機制，只要透過正式的開放原始碼授權，就能確保軟體的原始程式碼可供眾人運用。 GNU GPL 就是最好的例證（這一點稍後會說明）。

BSD授權

另外一方面，諸如 BSD 這類授權方式，相對較少對開發人員的行為加以限制，包括限制其發展開放原始碼產品的所有權專屬版本。
如亥克所說明的， BSD 授權原先被用在加州大學柏克萊分校發表的各個 Unix 版本上。從此以後， BSD 授權或是其改版授權（像是原始的麻省理工學院及X協會授權），就被其他幾個開放原始碼專案所沿用。
BSD 授權正式授與人們對原始程式碼或二進位碼無限制的使用權，並要求保留開發者的版權說明，以及相關資料。亥克指出，它還要求開發者得在廣告資料上列名，並在法律文字上明訂開發者的有限責任。
有些源自 BSD 授權的授權書，像是原始 X 協會授權，由於省略了廣告要求，因此遭受到批評。其他則是添加條款，要求軟體必須「收費」供應。
由於最初研擬 BSD 授權，是為了發表大學因研究而開發出的非商業性軟體副產品，所以它的法律條文反映了這種傳承。它們恪守給予研究者（也就是開發者）適當肯定的學術傳統，保障大學或者開發者受雇的機構擁有基本的法律權益。除此之外，它的條款對軟體的使用，沒有實質上的限制。
從商業軟體公司的觀點來看，在必須讓開放原始碼的授權發揮效用的情況下， BSD 型態的授權是條款與條件最少的一種。從開放原始碼開發者的觀點來看， BSD 型態的授權賦予使用者運用原始程式碼創作衍生作品的最高自由。這些自由涵蓋了依據 BSD 型態授權取得開放原始碼軟體，以及用它創作原始程式碼不開放的所有權專屬產品。
結果，許多開放原始碼的支持者，因為希望開放原始碼軟體所衍生的作品，也應該延續開放原始碼授權，因此建議後來者不要使用 BSD 型態授權。

「反版權(Copyleft)」條款

在另一方面，亥克就曾經詳細解釋過，GNU GPL 及其修正版本，企圖規範開發者的行為，禁止他們「私藏」程式碼，或者在更改開放原始碼的產品後，不將所做的變動回饋給開發者社群。
根據亥克形容，就許多方面來說， GPL 位在光譜的一端，BSD型態的授權在中間，而二進位碼的限制性授權則是在另一極端。基本上， BSD 型態的授權允許開放原始碼軟體無限制的商業用途，對衍生所有權專屬作品的創作毫無限制； GPL 則明確設計用來防止開放原始碼軟體被用以創作所有權專屬的衍生作品。
GPL 之所以能如此，是透過其中的「反版權」（copyleft）條款，要求經 GPL 而散播的程式，不得收取權利金，並須提供原始程式碼。它還要求以這類程式為基礎的衍生作品，也必須實施 GPL。
GPL 對所謂 GPL 程式的衍生作品，有著相當廣泛的定義。它這麼說：「傳播或發表的任何作品，其全部或一部分，包含或是衍生自 GPL 程式，或是這類程式的任何部分」，就是衍生作品。除了 GPL 程式的修正版本之外，還明確包括使用到 GPL 程式的片段程式碼，或是執行碼固定連結 GPL 程式庫的程式。無論新程式的原始程式碼原先經由何種授權， GPL 明確註明，當傳播根據 GPL 程式所製作的產品時，即使內含部分不是 GPL 的程式碼片段，這個整體作品的傳播，仍然必須遵循 GPL 規定—— 「不論作者是誰，其他授權人的許可及於整體，亦及於其任何部分。」
因此，如果在包含自有程式碼的所有權專屬程式中，使用到 GPL 程式碼，就必須依原先 GPL 程式碼的相同條件，將你的原始程式碼納入 GPL 。根據亥克所說， GPL 程式碼的這種性質，使得許多人比喻它是「病毒」，能夠顛覆所有權專屬的「主」程式，進而製造出更多的GPL程式。
換言之， GPL 程式碼能夠「感染」原本非GPL的程式，這個事實會導致一個現象：如果你採用 GPL 程式碼，就只能創作出 GPL 程式。任何團體，像是自由軟體基金會，如果想要鼓勵 GNU 哲學的散布，這個特性是必要的。亥克解釋說：「如果你想從頭創作開放原始碼產品，或想在產品內引用其他的 GPL 程式，這種特色也是必要的，或至少是可以容忍的，因為 GPL 廣為自由軟體開發族群使用與接受，而且現有的 GPL 程式碼數量很多。」不過，這個特性對那些想以其他方式，授權自有技術的商業軟體商來說，會構成問題。
各公司也可以稍微修改 GPL 較具爭議性的部分，而採取「創作者授權」（artistic license）的方式。網景後來就研擬出魔斯拉公共授權（MozPL）及後續版本「網景公共授權」（或稱為NPL），做法比 BSD 更進一步，同樣透過壓制「軟體藏私」的方式授權，但允許開發人員隨意創作所有權專屬的附加程式。
「既然開放原始碼軟體不能沿用傳統軟體的授權及收費方式，就必須根據提供給客戶的價值，找出產生營收與利潤的其他途徑。」亥克建議：「而這麼做如果想要成功，就必須選擇適當的企業模式，並且好好執行。」

可行的企業模式

為了替公司開創新的開放原始碼業務，亥克已經找出幾種企業模式，有一些也經過 OpenSource.org 確認。
「販售支援」模式是經由配銷媒體、商標、訓練、諮詢、訂製開發以及售後服務賺取收益，而不是透過傳統軟體權利金。
「介面糖霜」模式則是以銷售硬體為主，但在驅動程式及介面程式碼這類以往必須取得授權的搭配軟體，則是採行開放原始碼模式。
「相關配件」模式則是專門經銷圖書、電腦硬體，以及其他支援開放原始碼軟體的相關物件。
「促成服務」模式下，創作及配銷開放原始碼軟體的目標，主要是支援營利性質的線上服務公司。
「品牌授權」模式則是利用自身品牌及商標的使用權，向其他依此製造衍生產品的公司收取費用。
「先賣後送」模式則是讓一家公司的軟體產品，以傳統商業產品的方式開始產品生命週期，再於適當時機轉型為開放原始碼產品。
「軟體連鎖經營」結合了上述幾種模式（特別是「品牌授權」及「販售支援」），指的是一家公司授權其他公司，利用其品脾及商標，於特定地理區域或縱向市場中，成立相關機構進行訂製軟體的開發。公司向連鎖機構提供訓練及相關服務，以換取某種連鎖經營權利金。
亥克認為混合模式也行得通，如此可以各種不同的方式，緩和有關開放原始碼的限制。舉例來說，針對相同產品，一家公司或許會「兼容並用」傳統授權方式以及開放原始碼授權方式，依不同使用者予以區隔，譬如營利機構相對於非營利機構，或是機構相對於個人，以及／或是按不同的使用型態加以區分，像是內部網路相對於外部網路，某種平台相對於另一種平台，等等。
除此之外，一家公司可以將原始碼廣泛授權給所有使用者，甚至允許免費的「測試用」授權，但是仍然收取「修改權」的權利金，以某種方式限制修正版本的傳播。
雖然這些企業模式，就嚴格定義而言，並不是真正的開放原始碼模式，但亥克相信它們在某些狀況下，對某些公司來說，或許是可行的模式。第三方技術
亥克更進一步，為任何想實施開放原始碼策略的公司，提供一份入門指南。從所有權專屬轉換到開放原始碼，公司會面臨一些議題。
程式碼共用是其中之一。就是公司的開放原始碼產品，可能會與另外以所有權專屬程式碼為基礎的產品，共用一段通用程式碼。（這在網景案例中確有其事。）
在這種情況下，公司必須確定開放原始碼的開發能夠進行，而不至於使其他內部開發的工作複雜化。這點可能需要在授權方面做特殊考量，還有以模組化方式落實開放原始碼與所有權專屬程式碼之間的明確區隔。
亥克說道，在切換到開放原始碼模式之際，第三方技術可能也會成為一項議題。任何公司的產品，在現有原始程式碼的基礎中，可能包含經第三方授權的技術。這部分程式碼必須特別處理，才能製作可以發表的開放原始碼產品。典型的選擇是將程式碼徹底移除，或是透過特殊安排尋求把第三方程式碼包括在內的許可，或是使用相同或類似功能的開放原始碼來取代這種程式碼。第三方技術的存在，也可能影響公司對開放原始授權的選擇。
為確保原始程式碼可以公開傳播，程式碼也必須加以消毒。也就是刪除或更正任何深藏於程式碼中的不妥文字，以及程式人員在工作時所添加的，只為內部閱讀之用的精采評論。

雷蒙的建議

就在網景宣布後不久，雷蒙收到朋友寄來的電子郵件，提到網景之所以決定要開放瀏覽器技術的原始程式碼，是受到了他文章的影響。
雷蒙感到驚訝，因為他不曾與網景談過。一九九八年元月二十七日，他寫了一封內容如下的電子郵件給巴克斯代爾，作為回應。
上星期聽說我的論文＜教堂觀與市集觀＞，促使了網景決定散布領航員的原始程式碼，並嘗試採用市集開發模式，我覺得非常欣慰。我認為我可以有信心地代表整個自由軟體界發言說，我們全都為這項大膽的行動感到高興，願意支持網景，並祝你們落實新策略一切順利。
然而，行百里者半九十。立意良好、具前贍性的理論，必須有適切的執行予以落實。網景的宣告無可避免地，會引發後續能否有效執行的質疑。讓我得以寫出那篇論文的相同體驗，又促使我提出一些建議，希望你能慎重考慮。針對網景的執行面，我覺得有三點迫切的主要議題：
首先，網景原始碼授權的確切條款，將會是策略成功與否的關鍵。其次，自由軟體界的健全與善意，從現在起對網景已經有了正面的利害關係，必須考慮如何加以保護。第三，有心採用市集模式進行開發專案，並不等於知道如何實行。
原始碼授權的條文是第一項主要議題。它們是潛在雷區，因為在海外已經有傳聞，懷疑網景有意重演昇陽在爪哇授權上使過的欺騙手法——在極小字體印得密麻麻、乍看之下似乎相當寬鬆的條款中，暗藏了許多方便公司控管的文字。
我向你保證，即使只是若有其事，網景也會自食惡果。自由軟體及Unix 社群對昇陽授權案有種「上一次當，是你不要臉；上兩次當，是我自己蠢」的強烈感受。對於任何看似再度暗使控管把戲的圖謀，不會心軟。
我建議你們研究在http://www.debian.org/social_contract.html上的「德比安自由軟體準則」。它們是根據多年來對GNU授權及相對競爭的內容，以非常嚴謹的態度研擬而成。它們代表著人們對所謂「自由軟體」授權，最低限度的文化共識。網景的領航員原始碼授權必須與它們相符，才能夠取信於人—— 你們不應該只是順應，還必須把這種作法公開。在各種常用自由軟體授權的條款及意涵方面，正好我是個專家（在最大的 Linux 檔案網站上，用了我的詳細探討作為參考：你們可以連上 http://sunsite.unc.edu/pub/Linux/LICENSES/theory.html參閱）。我很樂意協助網景研擬授權。
你們選擇的策略，實際上使網景的未來，仰賴於自由軟體界的健全與善意。這兩者的維繫現在將是網景的重要考量。除非一般的自由軟體文化茁壯，你們將無法爭取到成千上萬具有開創性的共同開發者，如果他們對網景沒有好感，自然不會有興趣花時間在網景上。
幸好網景有極佳的形象做基礎。只要能妥善處理領航員原始碼授權，要做到這兩點既不至於太昂貴，也並不困難。你們必須和自由軟體界的領導機構，發展策略聯盟關係。這至少代表著，成為Linux 國際以及自由軟體基金會的贊助公司。
再說一次，這是你們該做、而且要公開做的事。你們要這麼做是因為，加強自由軟體文化的制度與團結，會增加你們得自市集策略的優勢。而你們要公開做是因為，它是給自由軟體社群的清晰訊息——你們會認真珍惜他們的貢獻。
最後，網景是否能夠順利落實市集開發模式，還有一項重大議題。姑且先不論你們要這麼做的動機，或是你們人員的才智與動力，過程中仍然有著實質上的障礙。我見到的就有兩大障礙。
首先，實踐（或是作為主要接觸）市集模式，較諸執行傳統大教堂式的開發，需要不同而且更寬廣的才能組合。你們必須謹慎選擇人員。理想人選應具備精湛的技術才能、極佳的溝通能力，以及在自由軟體界的良好風評。這個人還需要有足夠的政治判斷力，以便在主導專案的執行時，能讓網景與自由軟體社群的合作，是創造雙贏的局面。最後，這個人需要得到網景高層主管的信任，他才能做出那些雙贏決策，並接受監督是否落實。
對信任需求，我不能置喙，但是依其他條件篩選，我想我認得一位極佳人選，以及一位目前任職於網景的優秀人選。其次，你們可能會有文化上的惰性問題。比起任何我所知的、自外於自由軟體文化的其他商業單位，網景與該文化有著較好的聯繫。雖然如此，我能輕易地想見，實踐市集模式的誠實嘗試，可以如何被內部傾軋，以及對封閉式大教堂模式不自覺的依戀所蒙蔽。
我非常不希望這些不良後果發生，因為如果網景的嘗試受到挫敗，對於我所由衷信仰的自由軟體文化，會有極端負面的影響。自由軟體模式會落得極其不受信賴，使得未來類似的嘗試將難如登天。試想蓋茲會如何開懷大笑! 其他你可以自己想像……
所以我非常願意與你及網景合作，以確保你們的策略成功。最低限度，我能夠協助某些意識的激發。我認為網景同仁應該要有機會見識教堂觀與市集觀實地搬演，感受到公司內部明確訊息說，這就是你們選擇的方向。
在無損於我的超然立場的情況下，我還有其他方式，能致力於加強網景與自由軟體文化間的聯繫，使雙方互蒙其利。我願意和你探討這個可能性。
有鑑於此，一旦有適合雙方的時機，我願意與你及網景其他相關人員會面討論。

簡潔為上

紅帽開始接到來自分析師以及業界其他人的探詢，質疑扎文斯基的辭職，以及魔斯拉初期的種種困難，是否會對整體開放原始碼運動造成傷害。
一時之間，這種情形難免被解讀為對這個運動的一記重擊。但是我有不同的看法。相對於一開始就使用開放原始碼模式來建構程式碼，或許這個要「解放」龐大所有權專屬程式碼的挑戰，對扎文斯基而言太困難了。
封閉式軟體開發團隊在編寫程式碼的過程中猛抄捷徑，可能造成非常複雜難懂的所謂「義大利麵程式碼」（spaghetti code）。旁人不易瞭解箇中的奧妙，也就使不上什麼力氣來加以改進。
一個公開而且由一群同志以合作為基礎所建構的專案，可以確保程式碼即使不可能完美，至少夠清楚，能讓他人瞭解其邏輯，並且為之做出貢獻。
魔斯拉專案的問題在於，先是擷取大量閉門造車寫成的複雜C 程式碼，然後直接就「解放」了這些程式碼。
在另一方面，大多數成功的開放原始碼專案，從一開始就是開放原始碼專案。這種做法的好處在於，開放原始碼的工程師，由於無法為程式注解分神，會特意寫出極其簡潔的程式碼。實際上，他們會設法讓其他開發者只需「閱讀程式碼」，而不必閱讀程式碼的說明文件。
再者，基於必要，開放原始碼專案必須像是大型拼圖的個別片段一般，非常模組化。開發人員要能夠花上一、兩個星期，切割拼湊大段程式碼，而無需擔心會「毀掉」別人進行中的工作。網景通訊家不是以這種方式寫成的，所以魔 *************************************************************************** 哈哈&兵燹最會的2大絕招這個不會與那個也不會哈哈哈粉好

------
**********************************************************
哈哈&兵燹
最會的2大絕招這個不會與那個也不會哈哈哈粉好

Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind