抵制踐踏GPL的QQ影音

天下大事 23 Comments »1,141 views

2009年11月份,ffmpeg組織指責QQ影音使用了開源ffmpeg的源代碼,但是並沒有按照GPL許可證的規定開放源代碼,因而將QQ影音列入了「恥辱榜」( Hall of Shame http://ffmpeg.org/shame.html),這個恥辱榜上面還有著名的流氓軟件「暴風影音」。到底是怎麼一回事兒?這還得從GPL、LGPL說起。

GPL(GNU General Public License),是「GNU通用公共許可證」。LGPL(GNU Lesser General Public License),是「GNU較寬鬆公共許可證」。按照GPL及LGPL許可證文本的內容,其基本意思是開放軟件的版權限制。GPL許可證的授權模式是,如果某一軟件使用GPL許可證,那麼這個軟件可以使用其他GPL軟件的源代碼,就是「人人爲我,我爲人人」的源代碼使用模式。但GPL許可證由於過於自由,一些希望保留公司商業秘密但又希望採用優秀的開放源代碼的公司無所適從,爲此又有了LGPL許可證。LGPL許可證的基本模式與GPL一樣,但是將目標縮小到動態鏈接庫。也就是一個軟件如果使用了同樣使用LGPL許可證的動態鏈接庫的源代碼,那麼必須公開這些修改部分的源代碼,並且授權其他同樣使用LGPL許可證的他人使用或修改這些動態鏈接庫。

「QQ影音」的問題就出在GPL和LGPL上。因GPL許可證牽涉的是公開軟件全部的源代碼,而LGPL只涉及動態鏈接庫的部分源代碼公開。ffmpeg是一個同時以GPL和LGPL發佈的解碼器庫,基礎部分以LGPL發佈,而部分功能則以GPL發佈。可恥的是,QQ影音使用了ffmpeg的GPL部分,卻沒有按照要求開發源代碼,因此已經構成了嚴重的侵權。ffmpeg畢竟是一個民間非盈利組織,其實力難以與財大氣粗的騰訊大佬抗衡,所以ffmpeg只是將QQ影音名單列入了恥辱榜,而沒有能力提起訴訟。

然而半年多過去了,騰訊卻對此置若罔聞,對各界問責死不回應。在此我正是要譴責騰訊的這種無恥行爲,以一個年收入以億計的公司,實在做了一個極不良的表率。所謂「出乎爾者,反乎爾者」,不要創造一個可以肆意踐踏規則的環境,否則終將害人害己。身爲具有影響力的華人創辦的國際上市公司,騰訊應該承擔起大公司的社會責任,結束違反GPL協議的行爲,不要讓中國開發者蒙羞!雖然騰訊各種無恥的抄襲行爲已經讓人司空見慣了,但這次對GPL的踐踏還是不可饒恕的。我想要告誡騰訊的是,你永遠也吸引不來高端的用戶羣,別看你現在欺騙用戶撈到了不少好處,不要忘了「竭澤而漁,豈不得魚?而明年無魚」。

在QQ影音結束侵權之前,我會不遺餘力地號召抵制QQ影音,並散佈騰訊的侵權行爲。希望諸位熱愛開源事業、保護支持產權、反對騰訊流氓行爲的同仁更夠響應號召,將這篇文章轉載出去。

BYVoid原創

标签:, , , , , , , , ,

Open Chinese Convert 開源簡繁轉換

中文與漢字, 設計開發 17 Comments »406 views

Open Chinese Convert(OpenCC)是一個中文簡繁轉換開源項目,提供簡繁轉換詞庫和可供程序調用的程序庫(libopencc)。現託管於Google Code

關於簡繁轉換

由於種種歷史問題,漢字系統被割裂爲「簡化字」和「繁體字」,然而「簡化字」並不能完全取代原有的繁體字,一方面是由於古籍、書法、文字學的研究需要,另一方面則是港澳臺日韓越及其他海外地區「簡化字」並不通行。隨着信息技術的發展,這方面的需求不斷突出,因此簡繁轉換便成了一個信息技術界和中文研究界需要共同解決的問題。

精確的簡繁轉換一直以來是一個難題,其原因主要是簡體和繁體互有一對多的現象,而具體用字對應規則需要聯繫上下文分析語義纔能確定。而廣義的「簡繁轉換」,還包括了不同地域習慣用字和用詞差異的轉換(如「软件」「軟體」等),甚至詞和詞之間也有「一對多」的關係,因而使轉換更加複雜。目前現有的簡繁轉換軟件,即使是專業的(收費),也不能完全解決這些問題,在開源界能接近其水平的更是寥寥無幾。因此OpenCC的誕生,就是爲了儘可能地解決這個難題。

一些概念

漢字(據不完全統計)有十萬之眾,「簡化字」非但沒有減少漢字數量,反而使漢字數量更加龐大。雖然日常用到的字祇有數千,且有着複雜的關係。要做好簡繁轉換,必須理解這之中的許多關係與微妙的差別

「異體字」

由於漢字造字年代久遠,且非一人一時之所造,通行時間又爲世界之最,流變眾多,許多字並非祇有一種寫法,如「為爲」「朵朶」「畫畵」「污汚汙」等等。這些字祇是寫法不同,而沒有任何表意的區別,因此被稱爲「異體字」。狹義的異體字是沒有任何表意的區別的一組字,而廣義的異體字還包含了表意範圍有交叉或所屬關係的字以及「通假字」。下文中的異體字全部是狹義的異體字

需要注意的是「通假字」祇是同音假借,本字和被假借字可能意義完全不同,因而不是異體字。而「訛字」和「俗字」(絕大多數)則屬於異體字。例如「繫」字在傳抄的時候,左上角被寫成了「車」,然後以訛傳訛,就產生了訛字「繋」。「俗字」或稱「俗體字」是民間通行的一種變體,許多俗字就是筆畫較爲減省的異體字,也有很多來自訛字。

「繁體字」「簡體字」「簡化字」

嚴格地說,「繁體字」和「簡體字」是異體字關係,「繁體字」是相對「簡體字」而創造的概念。「簡體字」這一名稱,始見於1935年民國教育部總結的一批「古已有之」、「歷代通行」的「筆劃較少的」異體字。這批簡體字主要蒐集自民間話本「述而不作」地整理出,沒有類推造字。

「簡化字」,顧名思義則是人工簡化的字,這個概念的產生與近代「漢字改革」思潮有關,最早見於錢玄同的文中。1964年,中國文字改革委員會出版了《簡化字總表》(不是「簡體字總表」),簡化字開始在中國大陸流行開來。1977年,中央又發佈《第二次漢字簡化方案》,1986年被廢除,史稱「二簡字」。慢慢「簡化字」這一概念就被固定下來,專指中國大陸推行的簡化字

可見「簡體字」並不等於「簡化字」,前者強調異體關係,後者強調簡化關係。而現在這兩個概念趨於混淆,乃至用「簡體字」表達「簡化字」的意義更常見,其主要原因是由於另一個詞彙「簡體中文」的出現。比起中文的混淆,英文解釋更加清楚:「簡化字」的英文翻譯是「simplified Chinese characters」(簡化過的漢字),simplified源自動詞simplify簡化。「簡體字」由於概念不常見,沒有公認的正式翻譯,有一種譯 作「simpler variants of Chinese characters」(較簡單的漢字變體)。

由於「簡體字」和「繁體字」本身存在對立關係,繁體字也就慢慢變成專指港澳臺用字了。事實上港澳臺用字也不盡相同,如「裏」「裡」等,於是又有了「港澳繁體」「臺灣正體」等名字。

已有項目的缺陷

OpenCC的的誕生並不是輪子的重複發明,而是爲了實現一個更好的簡繁轉 換計劃,因爲目前已有的各種項目,或多或少地有着各種缺陷。

Wikipedia

毫無疑問最廣爲人知的簡繁轉換項目莫過於Wikipedia提供的簡繁轉換表。Wikipedia有效地利用了分散的人力,整理出了一個數量不小的表格,其優點在於*詳細地區分了簡繁轉換和地域轉換。但是也有許多不足:

  1. 異體字處理混亂,「一簡對多異」被當作「一簡對多繁」處理。如「为」對應「爲為」。
  2. 一簡對多繁有眾多爭議,處理不統一,時分時不分。如「卷烟」「烟卷」分別用了「煙」和「菸」。
  3. 有大量不成詞的「詞」,祇爲正向最大轉換優化,不兼容別的分詞算法。如「们斗了胆」「們斗了膽」。
  4. 專爲Wikipedia設計,依賴編輯的人工干預。
  5. 一般非地域轉換中「着」被併入「著」,不符合香港、海外等地用字習慣。

使Wikipedia做出改變較難,尤其是在這種民主的管理模式下,多數人(臺灣)可能會毫不顧及少數人(香港)。

cconv

cconv是另一個簡繁轉換的項目,較早開發,有一定的用戶。缺陷很明顯:

  1. 簡繁轉換和地域轉換混同一談。
  2. 完全沒有處理異體字。
  3. 功能雜糅了編碼轉換和簡繁轉換,不易剝離。
  4. 簡繁轉換數據被編譯到庫中,無法修改和擴展(除非重新編譯)。
  5. GPL協議發佈,對開發者限制較大。
  6. 目前長期無人維護。

OpenCC 的特點和方法

OpenCC特點

  • 嚴格區分「一簡對多繁」和「一簡對多異」。
  • 完全兼容異體字,可以實現動態替換。
  • 嚴格審校一簡對多繁詞條,原則爲「能分則不合」。
  • 使用歧義分割+最少分詞算法,儘可能從技術上優化轉換效果。
  • 詞庫和程序庫完全分離,可以自由修改、導入、擴展。
  • 以Apache開源協議發佈,使開發者真正可以自由使用。
  • 已經用於ibus-pinyin的繁體模式輸入,由ibus開發組長期協助維護。
  • 支持 C,C++,Python,PHP等多種語言調用,命令行直接調用,以及圖形界面(開發中)。

解釋

OpenCC有獨立的「一簡對多繁」表、「一繁對多簡」表和異體字表,保證沒有混雜着異體字。而且可以方便地自定義地區習慣使用的異體字,兼容臺灣、香港和海外地區不同的習慣。

簡繁轉換詞庫中數萬詞彙經過校對,最大可能地保證轉換準確性,用字原則爲「能分則不合」。舉例如「臺」「檯」「台」,在臺灣習慣中,有合流爲「台」的現象,但其意義界限明顯,故OpenCC從分,(具體見此列表)。根據不同的習慣,也可以設定爲合流。

簡繁轉換功能的核心算法爲歧義分割+最少分詞,簡單解釋爲首先掃描待轉換字符串,分割成若干個有歧義的區間(即每個區間內可以有多種分詞方案),然後對每個區間的字內構造圖論模型,使用最短路徑算法求出最優分割方案,然後對分詞的結果每部分進行轉換。這種算法不僅準確性高於直接正向掃描轉換,而且速度也很快,測試中每秒可以轉換8.4MB文本(UTF8編碼,內容爲小說,速度僅供參考)。

OpenCC把詞庫和程序庫完全分離,程序庫可以讀取兩種格式的詞庫,一種爲Tab分割的平面文本,一種爲OpenCC專門優化過的數據結構,ocd格式。平面文本數據庫格式方便閱讀和修改,ocd格式是OpenCC構造出的Double Array Trie數據結構,使用其可以大大提供轉換速度。OpenCC還提供了詞庫轉換程序,可以自由在兩種格式之間轉換。

OpenCC程序庫提供了C,C++,Python,PHP等語言的接口,便於在任何環境下使用,此外還提供了命令行直接調用的模式,圖形界面也在開發當中。

詞庫來源

OpenCC的繁體到簡體轉換的詞庫是由單字對應人工校對後生成的,單字對應數據來自Unicode數據庫以及人工的覈對和修改。簡體到繁體的詞庫由大量的繁體語料自動轉換到簡體然後校對而成。

參考資料

歡迎試用和加入

如果感興趣,可以先在綫試用一下, 然後安 裝到你的系統

開源非一人之力,有眾人的支持纔能做得更好。歡迎有意者加入開發,歡迎中文專業者和愛好者加入詞庫審校工作。

如有任何問題或建議,請到 http://code.google.com/p/open-chinese-convert/issues/entry 報告。或者可以直接與BYVoid取得聯繫

标签:, , , ,

分布式版本控制系统——Mercurial

Linux 7 Comments »294 views

最近惊喜的发现,Google Code的项目设置的“Version control system:”中多了一个名叫的“Mercurial”的选项,而不再仅仅是唯一的的一个选项:Subversion。心血来潮,于是决定试用一下。

Mercurial和Subversion简直是不能相提并论的,因为Mercurial是“分布式版本控制工具(DVSC)”,而Subversion是“集中式版本控制工具”。什么意思呢?用过Subversion的都知道,使用Subversion必须有一个中央服务器来存储代码,每个开发人员都要有一个客户端,从服务器上取得代码拷贝,本地修改后再提交到中央服务器。而Mercurial则不需要这么一个中央服务器的存在(也可以有),也就是说,每个开发者都在本地代码仓库中存取、修改,没有任何一个代码仓库更有权威性。这有什么好处?我觉得最大的一点是,使用分布式版本控制工具可以自由地修改代码,而不必担心会影响到别人,因为无论怎么改代码都是存储在本地的。同样原因的另一各好处就是可以自由地在不联网时控制版本库,而开发者之间的写作只需要在联网时进行即可。当然我只能简单说说了,更多的不同推荐阅读一下这篇为什么我们要放弃Subversion。当然Mercurial并不是唯一的一种分布式版本控制工具,还有强大的git。ibus和ibus-pinyin的开发,就是用的git作为版本控制工具。有过git使用经验的我感觉的Mercurial并不是很难,如果没有经验的话就不好说了,因为有很多概念和传统的SVN不同,需要一段时间适应。推荐一篇入门文章:分布式的,新一代版本控制系统Mercurial的介绍及简要入门。Mercurial命令行工具名字是hg,都是“汞”的意思。

很高兴能够看到Google Code开始支持分布式版本控制工具了,但至于Google为什么选择了Mercurial而不是Git,有一篇文章介绍Git 與 Mercurial 的分析。说了这么多,到底怎么在Google Code上用Mercurial呢?我的项目已经有SVN作为管理工具了,首先要解决的问题是把SVN上面原有的代码移植到Mercurial上,当然简单的方法是把最新的版本直接提交到Mercurial版本库,但我想要留下SVN上所有的版本提交记录,这里有一篇文章讲得很好 在Google Code上用 Mercurial 取代 Subversion 管理你的项目”

作为分布式版本控制工具,自然会有很多分支,而分支之间错综复杂的关系如果没有一个图形化的工具是很难阅览的。著名的git开源托管网站github.com提供了在线的分支网络阅览功能,因此可以一目了然(如下图),但Google Code就没有这么好的功能了,因此还依赖一个本地的图形化工具。

找来找去,找到了小乌龟TortoiseHg。TortoiseHg本身是一个面向Windows平台的工具,和TortoiseSVN,TortoiseGit一样。高兴地发现它是GTK+写的,因此也提供了Linux版本。我在Ubuntu下使用apt-get install tortoisehg就安装了,按照网上提供的方法,再安装一个python-nautilus,然后将集成tortoisehg到nautilus

mkdir -p ~/.nautilus/tortoisehg/src/ 
cd ~/.nautilus/tortoisehg/src/
hg clone https://bitbucket.org/tortoisehg/stable tortoisehg
mkdir -p ~/.nautilus/python-extensions/
ln -s ~/.nautilus/tortoisehg/src/tortoisehg/contrib/nautilus-thg.py ~/.nautilus/python-extensions/

之后重新登录,或者使用nautilus -q重启nautilus引擎即可。但是我按照此方法安装后却发现不能正常使用,而且没有任何错误提示。于是又Google半天,终于找到了解决方法。在终端中使用tail -f ~/.xsession-errors,再次在文件浏览器中点击菜单中TortoiseHg的功能,这时终端中显示出了如下信息:

abort: This version of TortoiseHg requires Mercurial version 1.5.n to 1.6.n, but finds 1.4.3

原来是Ubuntu官方源中Mercurial版本太低了,因此我使用了ppa的源:

sudo add-apt-repository ppa:tortoisehg-ppa/releases
sudo add-apt-repository ppa:mercurial-ppa/releases
sudo apt-get update
sudo apt-get install mercurial python-nautilus tortoisehg

再次打开,已经安装成功。

标签:, , , , , , ,

有幸加入ibus-pinyin的开发

設計開發 16 Comments »373 views

最近结识了中文Linux下最常见的输入法iBus的作者Peng Huang,并有幸加入了ibus-pinyin输入法的开发工作。开发输入法本身就是一个不常见的工作,因此很难找到相关资料,而开发一个优秀的拼音输入法更是难上加难。在此深切地膜拜Peng Huang,能与这样的牛人合作并从中得到指点,真是莫大的荣幸。

不少传言说iBus是Python写的,效率不行,实际上这是一个谣传。ibus的确曾经是python写的,但是现在已经用C++重写,效率得到很大的提高,而且兼容性要远远强于Scim。iBus全名为intelligent input bus,顾名思义它是一个输入法平台,也可以理解为是一个已经写好的与系统交互的库,各种输入法运行在iBus上。输入法只是调用了iBus,调用iBus可以让其作者专心地编写输入法功能的代码,而不是把过多的精力浪费在与系统交互上,也增加输入法的可移植性。而ibus-pinyin正是iBus作者Peng Huang写的一个运行在iBus上的拼音输入法。

花了不短的时间才大致看明白了ibus-pinyin的源码,发现大致的逻辑是:捕获用户输入的字符串-将字符串解析为拼音-查询词库将拼音解析为词汇-用词汇智能组句-显示候选词-输出文本。其中第一步和最后一步都很简单,因为已经被iBus提供了良好的接口,因此重点在于拼音解析词汇解析智能组句上。由于开发力量过小(开发人员加上我才3个人),这些功能的实现还很简单。像拼音解析遇到了歧义(如xian,fangan)还都只是指定一种(出现概率较大)解析方式,没有实现高度的智能化。

我所关注的部分是为ibus-pinyin实现声调模式,注音模式,和精确简繁转换这些功能。声调模式需要一个字库,这个已经从Unicode获得,而词库目前是不带声调的,要实现带声调需要较大人力。注音模式主要是推广到繁体用户那里,因为据我了解到的注音输入法智能组句功能都很弱,如果有这样强的输入法一定会受欢迎的。精确的简繁转换主要是实现输出地道的繁体,这就要解决大量的简繁一对多词汇了,具体实现也很复杂,只能逐步做。

截至今日(2010.5.12)ibus-pinyin的最新版本是1.3.5,下一版本发布之前两位开发者精力主要集中在开发输入法Lua插件支持和用户词库同步上。Lua插件就是让输入法支持自己开发的外接程序,让用户更灵活定制。用户词库同步是目前较为成熟的输入法都具备的功能,就是实现用户可以将自己的词库上传到服务器上,便于用户保存输入习惯,另一方面也方便我们统计和更新词库。但是作为开源软件,服务器费用是个问题,目前可以考虑用免费的Google App,将来也许可以得到像Google这类大公司的赞助吧。我很看好ibus-pinyin的发展,因为首先它是开源的,而且容易实现跨平台。目前没有好用的能够跨平台的输入法,而这个市场正好可以由ibus-pinyin来填补吧。

标签:, , , , , , , ,
25 queries. 0.621 seconds. Designed by NattyWP .
Images by desEXign.