Updates from 二月, 2009 Toggle Comment Threads | Keyboard Shortcuts

  • kiang 22:28:45 on 2009 年 02 月 09 日 Permalink | Reply
    Tags: AGPL, FrontAccounting, GPL   

    AGPLv3 相容於 GPLv3 ? 

    最近參與了 FrontAccounting 社群關於授權方式的討論:
    http://frontaccounting.net/punbb/viewtopic.php?id=398

    FrontAccounting(FA) 的前身是 OpenAccounting(OA) 與 webERP ,其中 OA 已經很久沒有更新了,而 OA 與 webERP 都是使用 GPLv2 授權,因此 FA 在 2.0 與早期版本都是使用 GPLv2,只是在上面討論發起後,開發者似乎有意將授權轉換為 AGPLv3 。

    雖然 OA 是改寫自 webERP ,據說已經完全沒有使用到 webERP 的程式碼,而 FA 的開發者取得 OA 作者的同意,將程式的授權更新到 GPLv3 。接著, FA 的開發者發現 GPL 授權內容有提到, AGPLv3 相容於 GPLv3 ,因此認為可以直接將 GPLv3 授權轉換為 AGPLv3 ,所以就決定在 FA 2.1 版開始使用 AGPLv3 授權。

    我在 gnu 網站找到了一則關於相容的說明:
    http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible

    這才了解到,GPL 所謂的相容是指兩個不同授權的程式可以放在一起,像是核心程式使用 AGPLv3 時,模組可以選擇使用 AGPLv3 或 GPLv3 任一授權方式,並非如同 FA 開發者所指能夠直接轉換。接著針對這點發現提出回應,也將內容發到 gpl-violations 的通訊論壇確認。

    接著 FA 開發者暫時將以 AGPLv3 授權的程式撤下,透過各種方式進行意見的交流,不過他們提到已經取得 OA 作者的完整授權,選擇 GPLv3 或是 AGPLv3 都可以,只是希望聽聽大家的意見。

    我提到,對網頁介面為基礎的程式來說,AGPLv3 就好像是共產主義一樣,任何人只要能夠存取程式就可以要求完整的原始碼,而 GPLv3 就好像是資本主義下的稅負一般,即使總是有人抱怨其他人的逃漏稅,但這不應該是改選擇共產主義的理由。

    我並不喜歡那種抱著投機心態使用 ASP/SAAS 授權模式的商業模式,但是我更不喜歡一堆不相干的人無時無刻吵著要程式碼的態度,這是我排斥使用 AGPL 授權的原因。在討論中還有提到,那些使用 ASP/SAAS 方式迴避 GPL 授權的供應商,他們所修改的程式碼還是有回到社群的機會,因為工作中接觸到那些程式碼的工程師或是合作廠商,只要他們在放棄合作與工作前提出要求,GPL 有著不得加諸限制的條款,他們原則上可以合法取得完整的程式碼以及散佈那些程式碼的權力。如果社群中真需要那樣的功能,而那些公司也沒能夠妥善照顧所有可接觸程式碼的工程師,相信這些程式碼還是有機會回到社群。

    最後, FA 選擇了 GPLv3 ,不過也語帶保留的提到或許未來還是有可能改採 AGPLv3:
    http://frontaccounting.net/punbb/viewtopic.php?id=480

    簡單的說, GPLv3 跟 AGPLv3 兩個授權可以放在一起,但是不能換來換去。 ;)

     
    • micmic 16:26:00 on 2009 年 05 月 15 日 Permalink

      太多 lincense 了,GPL ,LGPL ,MPL ,MIT ,BSD ,APACHE 的叫什麼我忘了….
      ,其實我認為 opensource 的 erp 應該有機會做的起來.

    • kiang 17:45:45 on 2009 年 05 月 15 日 Permalink

      APACHE 的就叫 APACHE 啦 ;)

      ERP 不是件簡單的事情,能夠凝聚眾人的智慧是最好不過了。

  • kiang 12:18:56 on 2009 年 02 月 07 日 Permalink | Reply
    Tags:   

    給 OpenFoundry 的建議 

    昨晚跟 Freddi 與 KC 碰面,聊的是 OpenFoundry 的推廣活動,在討論過程中有提到過去跟 OpenFoundry 的一些互動,不過時間太久所以印象模糊了些,於是剛剛就找了一下。

    是從這篇文章的評論開始的:
    http://kiang.blogspot.com/2004/07/20040711.html

    OpenFoundry 是由 RT, Kwiki, Sympa, SVK 等工具組成,早期透過 Perl 設計一個整合式的 UI ,現在是使用 Ruby 。在當時看到 autrijus 的評論後,我就試著去翻譯 gforge ,翻譯的成果在 OpenFoundry 網站上都還找的到,只是很久沒有更新:
    http://of.openfoundry.org/projects/161/download

    不過 OpenFoundry 並沒有採用,只是一直用自己的方式試著把一些工具組合在一起,因此穩定度、畫面整合等問題似乎到了今天還是沒有根本的解決,所以我還是強烈建議他們改採用 gforge ,或是可以選擇類似 sourceforge.net 最近的作法,提供一些常見的應用給專案開發者,像是 Trac ,他們也有將修改的部份公開來:
    http://sourceforge.net/project/showfiles.php?group_id=238161&package_id=289462

    OpenFoundry 所選擇的應用程式不是不好,而是需要花許多的功夫進行整合,而 GForge 已經整合好了,為什麼不用? GForge 是基於 Sourceforge 早期釋出的版本進行延伸,因此熟悉 Sourceforge 操作的人對於 GForge 並不會感到陌生,它的安裝相信不會比起開發一個整合介面要難。

    就算喜歡使用 Ruby 開發,那為何不選擇使用 Redmine ( http://www.redmine.org/ ),它實作了 Trac 上看的到的功能,還進一步支援多專案等功能,連 Git 都支援了…

    上面是針對平台的建議,再來是針對推廣工作。

    OpenFoundry 在開放原始碼軟體的推廣工作往往受限於年度計劃方向、執行者的目的(論文?)或是排斥商業行為的習慣,引來了不少的抱怨。

    在昨晚的討論中有提到,為什麼不先將焦點放在一些能夠產生良性循環的專案上面?以 CRM 為例,想要使用這方面軟體的公司不少,如果針對這個軟體進行一系列的說明、教學等活動,擴大使用者社群後,自然願意在社群投注資源的企業就會變多,資源多了自然就可以吸引開發者,開發者如果能夠專注於開放原始碼的創作而不需要顧慮經濟問題,相信這個社群會進入所謂的良性循環。

    但是目前看到的一些推廣工作,都是將大部分的焦點放在開發者,試著要培養更多的開發者,但是結果似乎永遠不如預期,為什麼?因為參與活動的人大多將獲得的知識放在自己的工作上面,也大多只對於跟現在或未來工作相關的主題感興趣,最後大概只有那種滿腔熱血的青年會跳出來做些事情,不過這樣的熱情大多燃燒不了多久,因為沒有適當的環境來延續這些熱情。

    但過度商業化也不是一件好事,如果活動裏面介紹的都是些商業軟體,或是被調整過而且無法直接取得的軟體,相信效果也會大打折扣。

    簡單的說,請將焦點集中在使用者社群,這樣的社群才有機會形成產業,產業出現了,就不用擔心開發者不夠的問題;把餅做大,而不是一直在消耗資源讓圈子越來越小。

    好吧,如果真的那麼排斥商業,那不妨就先將焦點放在學校用的到的部份,像是 Moodle 或者國人自行開發的學務系統也好( http://x.tnc.edu.tw/ )。

    已經有人在做?那為何不要一起做?團結不是應該力量大些嘛?

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel