• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            戰魂小筑

            討論群:309800774 知乎關注:http://zhihu.com/people/sunicdavy 開源項目:https://github.com/davyxu

               :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              257 隨筆 :: 0 文章 :: 506 評論 :: 0 Trackbacks

            本文部分摘自評論:從射手QQ之爭看開源許可證的選擇

            首先,開源并不代表放棄自身的權力,相反,開源軟件之所以存在,正是它非常注重這種權力,并且把這種權力賦予了軟件的所有使用者。小心的選擇許可證是開發開 源軟件的第一步,也是每一個開源軟件作者所必須要了解的,這代表了你對你的軟件的最基本態度。很多的時候,這背后也隱藏著某種商業策略,特別是有商業公司 支持的項目。
            比如Android為什么是Apache 2.0而不是LGPL/GPL發布?為什么Linux是以GPL發布?其中絕對不是簡簡單單的看哪個許可證用得多就選擇哪個,而是深思熟慮的結果。千萬不 要小看這個選擇,一個許可證之于軟件就相當于價值觀之于普通人,代表了這個軟件的基本品性。一個錯誤的許可證選擇可能會直接導致整個項目的失 敗,XFree86就是一個好例子,所以,選擇許可證是一件小心、謹慎的事情。
            各種開源的許可證主要的限制還是在redistribution(發布),所以個人/商業公司開發的軟件包含了GPL的代碼,只要你不發布,是可以任意使用的。
            GPL
            這里不想再解釋長篇的GPL譯文和更長的FAQ。 簡單說,GPL軟件的使用者有權力得到軟件的代碼,只要使用了GPL,在發布(redistribution)的時候,整個項目也必須是GPL的,即主程 序和靜態鏈接的庫(Linux的.a和Windows的.lib)必須是GPL的,動態鏈接庫(Linux的.so,Windows的.dll)必須是比 GPL兼容的。所謂GPL兼容,也就是GPL軟件中可以使用的庫,這些許可證必須比GPL弱(如LGPL,BSD),而不能是某個商業許可證。這里有一個 兼容列表 List of FSF approved software licenses。正因如此,GPL是帶有很強的傳染性,只要你的軟件使用了GPL的代碼,那么就請以GPL開放源代碼吧,并且你的項目中也不能有任何和GPL不兼容的庫。
            LGPL
            GPL 帶有很強的傳染性,那么如果一個庫使用GPL發布,那么使用這個庫的所有軟件也必須使用GPL發布,這對不想開放源代碼的商業軟件來講是致命的打擊——你 可以不使用其他的庫,但最基本的libc是無論如何繞不開的,如果libc是以GPL發布,就相當于所有軟件必須以GPL發布了。所 以,LGPL(Lesser GPL)誕生了。LGPL定義為,在以LGPL發布的庫的基礎上開發新的庫的時候,新的庫必須以LGPL發布,但是如果僅僅是動態鏈接,那么則不受任何限 制。這樣商業軟件就可以隨意的使用LGPL的庫了。因此,LGPL也具有傳染性,但限制在在其基礎上開發的庫上,而并不限制使用它的程序本身——它的傳染 性遠小于GPL。

            BSD、Apache 2.0

            相對GPL/LGPL的開放源代碼,BSD,Apache 2.0就寬松許多——商業軟件可以任意的使用BSD,Apache 2.0發布的軟件代碼,而不需要開放源代碼,只需要提及代碼的原出處就可以了。BSD和Apache 2.0提及的方式稍有不同,具體可以參考協議的詳細內容。它們是GPL兼容的。
            了解了幾種常用許可證的異同,再來看許可證的選擇。


            Android 使用寬松的Apache 2.0發布,因為Google作為一個商業公司,并不想失去商業軟件的支持,它希望團結一切可以團結的力量加入的Android的開發中來,壯大自己的陣 營,使用Apache 2.0就無可厚非了。而Google本身,并沒有喪失對Android的控制權,不會擔心另外一個公司拿走了Android的代碼開發出一個閉源 Android的對手。因為,只要Android不斷的出新版,社區不停的跟進,并且不停的修改API,其他基于Android開發的公司不得不把自己的 Patch提回到主干上,否則,必然將耗費大量人力物力在維護自己的Patch上(錢這方面你斗得過Google?),得不償失。而且,閉源之后,與整個 社區為敵,作為一個定位軟件平臺的項目,會流失大量應用軟件開發者,以小博大,任何一個商業公司都不會干這種勝算不高的蠢事。


            在看以 GPL發布的Linux為什么比以BSD發布的FreeBSD成功。其實正是因為GPL的傳染性。當一個開發人員在Linux基礎上開發一個新功能之后, 不得不以GPL開放源代碼,貢獻回Linux,這樣Linux本身才能越來也越壯大而且留住了相當的開發人員,形成了一個 優秀軟件->很多使用者和貢獻者->貢獻->更優秀的軟件->更多的使用者和貢獻者... 的良性循環。
            正如每一個成功的男人背后都有一個女人,每一個成功的開源軟件背后都有一個符合它策略的開源許可證。許可證明確的版權劃分,明確的版權劃分為軟件發展提供 了一個良好的環境。正是因為老外重視版權,天天為版權爭吵,才會有一個良好的商業軟件和自由軟件大環境。相對的,漠視版權的中國無論商業還是開源軟件,才 會淪落到毫無創新能力,只能給外國打打下手,作點邊角外包的境地。

            posted on 2009-12-20 19:29 戰魂小筑 閱讀(2067) 評論(2)  編輯 收藏 引用 所屬分類: C++/ 編程語言

            評論

            # re: [轉]GPL 與 LGPL 掃盲 2009-12-20 20:58 Sunshine Alike
            學習了,這個協議以后還不能亂選  回復  更多評論
              

            久久96国产精品久久久| 亚洲国产成人精品女人久久久 | 久久夜色精品国产网站| 久久人妻无码中文字幕| 少妇高潮惨叫久久久久久| 国内精品久久久久影院日本| 99久久免费国产特黄| 国产精品免费久久| 无码八A片人妻少妇久久| 久久久久成人精品无码中文字幕 | 久久免费视频一区| 亚洲va久久久噜噜噜久久天堂| 丰满少妇高潮惨叫久久久| 国产一区二区三精品久久久无广告| 欧洲国产伦久久久久久久| 国产美女久久精品香蕉69| 久久久久久A亚洲欧洲AV冫| 亚洲精品tv久久久久久久久| 国产精品日韩深夜福利久久| 久久人人爽人人爽人人片AV高清| 久久中文娱乐网| 久久棈精品久久久久久噜噜| 亚洲欧美另类日本久久国产真实乱对白| 国内精品久久久久影院一蜜桃| 久久精品中文字幕大胸| 亚洲成色999久久网站| 久久香蕉国产线看观看精品yw| 亚洲日韩欧美一区久久久久我| 亚洲国产精品一区二区久久| 日日躁夜夜躁狠狠久久AV| 一本大道久久香蕉成人网| 91性高湖久久久久| 久久精品国产亚洲一区二区| 久久婷婷五月综合色高清 | 亚洲va国产va天堂va久久| 欧美一级久久久久久久大片| 久久久久香蕉视频| 久久99精品久久久久久秒播 | 久久九九久精品国产免费直播| 久久综合久久久| 国产精品免费久久久久电影网|