我最近遇到的針對開源軟件和社區的批評是開源永遠不會勝出;專有和封閉源碼(closed-source)軟件永遠都會存在。事實盡管如此，但這並不是開源的失敗使然。
那些認為相互競爭的模型、方法或項目的存在就是一種 “失敗” 的論調與開源的整個理念恰好背道而馳。自由重點之一就是人們可以選擇做自己喜歡的事情。
雖然很多軟件都會得益於共享和合作式的開發模型，但可能並非所有軟件都會如此。我的一位朋友是自由軟件項目的積極貢獻者，但他對每年付費使用 稅務軟件毫無怨言，因為根據稅法更新軟件的研究成本足以使想要投身此類軟件的志願者敬而遠之。在某種程度上即便是這些公司已經開始為個人提供免費 軟件，但他們大都對真正意義的自由 軟件望而卻步。
防病毒軟件供應商常常不願分享其代碼，他們有自己的理由;病毒制作者具有破譯代碼庫的能力，當然不能讓這些病毒制作者輕易得逞。
開發開放源碼的派生物
開源倡導者之間也存在一個重要分歧，即該如何劃分 GPL 方式的許可和 BSD 方式的許可。如果您基於此代碼構建了一個新的項目，那麼您也要在相同的許可條款下發布該項目麼?
人們通常都會將此視為是一場宗教式的戰爭。我想這也是公說公有理婆說婆有理的一個典型例子，完全取決於個人的偏好。雙方的支持者常常還會有些偏激並會做出一些不合理的爭辯，但本質上，二者都是可行的策略。
您請便，我的工作到此為止了
BSD 方式的許可的理念(也為其他的幾個許可所用)是生成軟件的目標是制作它並讓它可用，而其他人對此軟件的使用都是額外的獎勵。 如果某個開發者想要把這些代碼嵌入到一個閉源的應用程序內並從中獲利，且不回饋給社區，這種做法也是合理的，因為開發者也是在使用代碼，而且這也是代碼的 一個用途所在。
這種策略的支持者趨向於強調這種策略 “更為自由”，因為它對軟件的使用者的限制更少。而批評者則大多會稱這種策略有可能會讓軟件的變體最終演變成高度受限的軟件。對 BSD 許可下的軟件最常見的偽評判是認為有人會 “奪取” 這種許可所賦予的自由。但是，他們不能。BSD 許可下的原始軟件總是存在的，可自由使用，而不管從其派生的項目是何狀況。
共享即是關愛、分享
GPL 方式的許可的理念是著名的 “傳染性” 許可;其目標不只是此軟件應該是免費的，而且所有派生物也必須是同等程度免費的，所以不允許任何人使用此類軟件作為非免費軟件的一個組件。
此策略的支持者也趨向於強調該種許可 “更為自由”，因為它更能保證對這類軟件及其派生軟件的持續的自由和開放性。而反對者則多糾纏於這類軟件無法用於為數不多(但卻實際存在)的禁止為給定代 碼段使用開源模型的情況。對 GPL 許可下的軟件最常見的一種偽評判是這種許可的傳染性如何如何厲害。有些人曾告訴過我，當然是很真誠的，如果允許人們利用我在更為寬松的許可下發布的代碼並 將其鏈接到 GPL 許可下的代碼，那麼我就必須要將我的代碼也變成是 GPL 許可的並且必須將類似的限制施加給所有其他的用戶。這，很顯然是無稽之談。
GPL 的變體很多;而其中有些就是為了解答這類疑問的。
如何選擇
我遇到過有關哪種方式的許可更為恰當的問題。上述兩種方式對不同的場景有各自的優勢。我總結了一些原則，可幫助我為某個項目決定適合的許可方案。
Linux 內核是從 GPL 許可獲益良多的典型例子。依我看來，是共享進展中的開發工作的重要性使然。尤其是，如果沒有 GPL，供應商就可以借助硬件驅動程序將使用者鎖定到它們提供的內核，因為只有這個內核可以支持某個特定的硬件。有了 GPL，內核驅動程序必須能作為源向他人開放，允許他人將這些驅動程序用於其他內核，並在需要的時候做適當的調整。
X Windowing System 則在更少限制的 MIT 許可下發展得不錯。盡管人們可以開發商業系統，但由於人們使用的是標准的服務器，所以事實是若硬件驅動程序不能用於標准的 X 服務器，那麼肯定會影響硬件的銷售。
在某些情況下，很難分辨哪種策略更為適合。BSD 內核的偏好者看起來能夠坦然接受商業產品使用其內核而又不向其發回任何驅動程序的可能性(盡管 這種情況似乎非常少)。現在有一些協議或文件格式庫是在 GPL 條款下發布的，且得到了一些使用。
如下的這些原則可幫助您做決定：
假設您已經發布了代碼，您發現有人正在使用它。但您尚不知道他們是否會發送回更改，您只是聽說他們之所以使用您的代碼是因為您的代碼可以正確解決他們的某個技術問題。
如果上述情形讓您很高興，那麼您就可以使用兩種許可中的任何一種來允許他們這麼做。如果這種情形讓您擔心他們有可能不會共享，那麼就使用一種許可來要求他們共享。如果這種情況讓您很惱火，因為他們沒有付費給您，那麼就不要使用任何開源許可。放松些!
上一頁12下一頁查看全文 內容導航
