1. codeweavers正巧在做这件事情,CEO把这件事当作高优先级的任务.
2. 目前已经和Canonical合作,预计几个星期后就会上线,不久后大家就可以在Ubuntu Software Center的 for
purchase中购买到CrossOver .
3. CrossOver 有一个SPECIAL DEAL CODE ,直译过来大概叫做特别交易代码, 如果任何人想购买CrossOver,
只要在下单的时候输入这个特别交易代码 "DEADDUCK" , 就可以打5折, 这个活动截止到本月底 .
CrossOver 的购买地址: http://www.codeweavers.com/store/
目前, CrossOver Linux Standard 是 39.5 美元, 打5折后是 20美元左右, 100多块, 对一些人来说有点贵,
对一些人来说应该还可以接受. 问题是, CrossOver 不支持支付宝支付, Ubuntu Software Center也还未支持,
等到它们支持的时候估计这次打折活动早已结束了吧~
如果支付方便的话,我个人挺愿意购买一套的,比起正版的Windows系统, CrossOver 还是挺便宜的.
购买CrossOver,除了能得到商业技术支持以外,还有一个很大的好处,就是可以向codeweavers公司提出要求,
希望Wine/CrossOver支持某某软件,尽管也可以直接到Wine的项目提出建议,但是付费用户的要求会优先被
考虑.
事实上,Wine/CrossOver的开发还有一种模式,就是用户向CrossOver提出,愿意付费换取CrossOver对某个自己
喜爱的win程序的支持,如果价钱合适的话,CrossOver就可以雇用开发者进行开发.不过我不知道这方面有没有
成功的例子,不知有没有朋友知道?
最后, look for CrossOver to be in the Ubuntu Software Center before too long ;-)
--
Regards,
Qian Hong
-
Sent from Ubuntu
http://www.ubuntu.com/
问题是, CrossOver 不支持支付宝支付, Ubuntu Software Center也还未支持,
等到它们支持的时候估计这次打折活动早已结束了吧~
我也没买过CrossOver,说说我的理解,希望不会误导~
1. CrossOver有一些针对特定软件对Wine做的dirty hack,这些补丁无法被Wine接受,
所以CrossOver支持的程序实际上比Wine多一些.当然,随着Wine的改进,CrossOver
支持的Wine也早晚会支持的.
2. CrossOver提供一键安装的bottle,方便用户,省去很多配置.
在 http://www.codeweavers.com/products/cxlinux/ 看到下面这段话,没有看懂 (或者是不敢相信自己的理解)
CrossOver Linux lets you use many Windows plugins directly from your
Linux browser. Plugins work on any x86 based Linux distribution and
will integrate with most browsers including Firefox, Netscape,
Konqueror, Mozilla, and Opera. CrossOver also integrates with Gnome
and KDE to let you transparently open any Word, Excel or PowerPoint
file. But even better, you can open these attachment types directly
from any mail client.
照这么说,crossover对网银插件的支持应该是不在话下的?不知大家是怎么理解的?
> --
> 您收到此邮件是因为您订阅了 Google 网上论坛的“广州 GNU/Linux 用户组”论坛。
> 要向此网上论坛发帖,请发送电子邮件至 gz...@googlegroups.com。
> 要取消订阅此网上论坛,请发送电子邮件至 gzlug+un...@googlegroups.com。
> 若有更多问题,请通过 http://groups.google.com/group/gzlug?hl=zh-CN 访问此网上论坛。
>
>
所以我觉得应该让 Wine 慢慢地离开我们,Linux 总不能活在需要用 Windows 程序丰富第三方软件的地步吧。在我看来,宁愿使用一个有功能缺陷的操作系统,不到万不得已也不会用 Wine
顺道在这里回复 Qian Hong 和 Hiphen 在支付宝控件的那一帖
这里我想说说我对 Wine 的看法。
首先我对 Wine 的开发者致意崇高的敬意,他们的努力是应该尊重的。但是我们真的只能奢望一个和微软毫无关系的社区能够创造出完美兼容的软件吗?我认为是不可能的。网银 ActiveX 控件是极度依赖 Windows 的东西。U 盾的驱动也只有 Windows 版本,即使进行逆向工程也不是容易的事情。但为何我们还要奢望 Wine 完成高难度的任务呢?跨平台本来就是巨大的难题。
记得很久以前在爱范儿看过例子,国外一个大公司,因应客户跨平台的需求,开发了一个基于 Adobe AIR 的应用,从而实现了 Windows、Linux 和 Mac 三大平台都能使用同样体验的软件。但众所周知的是 Adobe AIR 其实和 Flash 很大关系的。而 Flash 在非 Windows 上的体验十分不好。结果那个应用的反应十分不好。后来那个公司重新开发了功能精简过的原生 Windows 客户端,用户量反而增长得很快。后来又出了原生的 Mac 版。说到最后,他的那个客户端功能,其实用 Web 更容易实现得到,而且可以保证不会跨平台的兼容性问题。
如果说到 Wine 可以避免盗版问题,反而是 Wine 更容易引起版权问题。各大发行版默认发行的时候是不会预装 Wine 的,用户需要自行安装,因为要避免一切有可能存在的侵犯微软版权的问题。没有公司能够保证 Wine 自带 dll 库没有使用来自逆向工程的代码,没有侵犯微软版权的。如果真的微软找到马脚走上门打官司,即使打赢了也会弄得遍体鳞伤,这种版权官司很花律师费的,小公司肯定不够大公司耗资源。另外 Wine 本身也不是尽善尽美,很多时候需要从 Windows 里拿 dll 才能 Wine 到程序,这应该也算是侵权行为吧。微软应该不允许把自家的 dll 放到另外的平台上跑吧。
所以个人认为跨平台最好的办法是在每一个平台上开发原生的客户端或者替代品。但是在国内,我们不可能期望有这样愿意为顾客服务的伟大公司。摆上 Web 也是不错的选择,现在也越来越多的应用云端化了。比较靠谱的做法是跑虚拟机,其实跑虚拟机也不是特别耗资源吧。HuntXu 那台旧电脑跑 XP 也是蛮 OK 的。实在的额外成本并不是那么高的,微软最新的 EULA 貌似已经规定了,如果实体机获得 Windows 的正版授权,那么在这个实体机上的任意多台虚拟机也可以使用这个正版授权而无须额外付出费用,以前是需要额外加钱的。所以这不算是大问题吧。
所以我觉得应该让 Wine 慢慢地离开我们,Linux 总不能活在需要用 Windows 程序丰富第三方软件的地步吧。在我看来,宁愿使用一个有功能缺陷的操作系统,不到万不得已也不会用 Wine,宁愿跑虚拟机。我是不是有点原教旨主义呢?呵呵!
如果当初腾讯开发开心农场的时候不是用 Web 而是用客户端,或许会 N 多人吐槽了。哈哈!
--
2011/2/27 Qian Hong <frac...@gmail.com>:
> 4.万一Wine真的有法律问题,最终用户是否需要承担法律责任呢?我觉得不用,只要把有问题的
> Wine版本删除就可以了,如果将来Wine发布新版本,把有问题的代码都删除了,那么用户可以下载
> 新版本继续使用,不过这只是主观臆测,还没找到可靠的论证,我发了邮件请教openfoundry,如果有
> 回复我就贴出来. 如果有哪位朋友了解这个问题的请指教!
全文转贴如下:
===========================
Hi Qian,
以下簡單回覆您這個問題的相關資訊。
您問題的核心重點應該是在於:如果使用了免費授權的開源軟件,而後發生涉及侵權的狀況時,法律負擔上有什麼樣的風險?
其實、大部份的開源軟體都可以自由地在網際網路下載到,並且多是免費下載,也因為取得手段不涉及價金的給付,所以開源軟件的授權條款裡,多會明訂「不負擔保責任」,也就是說、即使某個開源軟件a,其開發團隊聲稱這些軟件裡並不包含任何商業軟件逆向工程的結果,但最後如果被此商業軟件公司實際舉發並證明為真的話,這些開源軟體a的使用者,還是要負擔一部份的侵權責任。
因為各國關於著作權法(Copyright
Law)的預設還是債權關係,也就是說、商業公司直接向開源軟件a的散布者和使用者來要求求償,因為這些散布者與使用者,他們實際上散布與使用了該商業公司被違法還原的軟件;而第二階段、再由開源軟體a的散布者和使用者向開源軟體a的開發團隊及上流散布者來求償,但第二階段的求償常常無法奏效,因為開源軟件a的開發團隊可能是以免費、無償的方式來散布他們所撰寫的開源軟件a,而且散布時有特別註記「免責聲明」,所以、即使這些上游的散布者特別聲明其並沒有利用還原私有軟體(Proprietary
Software) 的方式來開發專案,最後被證實為真時,使用者還是比較難以從這些開發團隊手上得到完整的求償。
簡單的法律實務與邏輯關係就是:商業公司向涉及還原侵權的開源軟件之下游使用者與散布者求償→該開源軟體之下游使用者與散布者向上游的開發者與散布者求償。
實務上有三種作法來解決您所碰到的這個疑慮:
1、取用「明示附有擔保的開源軟件」
例如RedHat在它部份的專案裡,有提供收費服務,雖然在這個狀況下,實際被散布的還是一般的開源軟件,但是RedHat在開源軟件的授權條款之外,再與使用者增訂收費式的擔保條款,在這種狀況下,如果嗣後這些開源軟件被控侵權,則RedHat就會照增訂契約的相關規定,來擔負這些軟體造成的侵權責任。
關於明示擔保提升開源軟件擔保責任的法源依據,可以參考GPL3(GNU General Public License, Version3)第7條a款的這段文字:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
a) 宣告與GPL3本文第十五條及第十六條有別的免責條款或所謂的責任限定條款;
2、利用保險契約來解決
在美國紐約有一間保險公司,名稱為Open Source Risk Management
(http://www.osriskmanagement.com/about.html),就是一家承擔開源軟件風險保單的保險公司,也就是說、對於將開源軟件放置進商業產品時,對於嗣後是否會涉及侵權有所疑慮時,也有這樣購買風險保單的選項,這亦不失為一種處理方式,也就是說、先購置保單,若日後發生侵權的風險且被證實為真時,實際在負擔賠償責任時,就可以得到保險金的給付來降低風險。
3、完善證據保全來減輕自身的侵權風險
利用Print Screen或是各種可能有效舉證的方法,將Wine這類專案聲稱自己並不涉及還原工程的聲明保存下來,日後如果真的被控涉及侵權,則可合理舉證來免除自己的「故意責任」,因為在著作權、專利權方面的範疇,如果被歸類為「故意侵權」,則賠償金額會以倍數成長,一般來說是就其所得利益乘以3倍來進行賠償金的估算,但若能舉證自己並非故意侵權,則法院即不會主動提高賠償金方面的數額。
一點粗淺的意見希望對您有所幫助,
若後續再有問題,歡迎隨時來信接續討論。
敬祝 順心健康、事事如意
20110301 1159 自由軟體鑄造場 林誠夏
============================
==摘录如下==
On Thu, Apr 28, 2011 at 2:49 PM, Nikolay Sivov <bungl...@gmail.com> wrote:
> On 4/28/2011 10:45, Alexey Fisher wrote:
>>
>> MultiByteToWideChar are called directly only from one function. All other
>> colls in comctl32 go thrue this function.
>
>> It was recovered with from dissassambled code.
>
> This is not allowed in Wine development. All you can use is tests, but after
> this patch you're most likely banned (from comctl32 changes at least).
===========
--
您收到此邮件是因为您订阅了 Google 网上论坛的“广州 GNU/Linux 用户组”论坛。
要向此网上论坛发帖,请发送电子邮件至 gz...@googlegroups.com。
要取消订阅此网上论坛,请发送电子邮件至 gzlug+un...@googlegroups.com。
若有更多问题,请通过 http://groups.google.com/group/gzlug?hl=zh-CN 访问此网上论坛。
上次跟gzlug的朋友们在这里讨论了关于wine的一些问题,颇有收获.感谢openfoundry的法律支持,解答了关于wine的版权问题,列表里的讨论也告了一段落.
虽然openfoundry的解说在很大程度上可以打消我个人对于wine的版权问题的疑虑(不知其他朋友是否跟我一样?),但我对于开源和法律相关的问题思考没有停止,最近又有了新的发现和想法,所以挖出旧贴跟大家交流.
首先,我想小结一下我们之前在gzlug讨论的(法律相关的)内容,我认为基本上可以归结为两类:一是版权问题,而是EULA问题.
微软曾经发布过一个Windows Research Kernel(简称WRK),
讲windows操作系统内核的部分代码公开,但是不允许重新发布.如果wine在开发过程中,有开发者参考了WRK的代码,那么就侵犯了微软的版权;
微软的产品EULA相信无一例外都会禁止反汇编/反编译等逆向工程的手段,所以加入wine的开发者使用了反汇编的代码,那就违反了EULA,也就是说违反了合同法,将被追究法律责任.
对于上面两个方面的问题,wine项目通过对开发者进行严格的限制来避免.然而,最近我发现一个新的问题无法用这种方式避免,请看下文.
新发现的起源: wine上的一个bug : http://bugs.winehq.org/show_bug.cgi?id=19816
这个bug中,用户要求wine开发一个msvbvm60.dll的开源替代版,( msvbvm60.dll 是微软visual basic
run time的一部分, ) wine项目的老大认为开发这个msvbvm60.dll是可行的,(见3楼评论,)
而10楼的相反意见引起我的注意:
You talking about implementing something that's not a part of an OS. What's
worse, you talking about something that MS holds lots of patents and copyrights
on. Ask any lawyer how feasible it is to re-implement MSVB.
注意这里一个关键词: patent,专利.
看到这里,我第一次意识到,专利问题也是wine所面临的潜在法律风险中的重要环节(甚至怀疑会不会是最难解决的困难)
我用google patent简单搜索了一下微软注册的与visual basic有关的专利:
http://www.google.com/search?tbo=p&tbm=pts&hl=en&q=%22visual+basic%22+inassignee:Microsoft&num=10
google显示有2300多个搜索结果!
很多人都知道,正是因为winrar的专利,导致至今为止没有一个开源软件重新实现winrar的压缩算法.所有支持rar格式的开源软件,实际上都调用了winrar提供的闭源库.
当商业软件公司通过专利来限制开源社区开发兼容产品的时候,恐怕地球人已经没办法阻止他们了.
目前为止,我唯一能想到的对wine这类兼容产品有利的事情就是反垄断法了,但是很没底.
希望这个问题会引起大家的兴趣,和大家一起交流学习 ;-)
P.S. wine项目在2005年起已经得到Software Freedom Law Center
的支持,SFLC为开源软件提供的法律支持同时包括版权/EULA/专利等多方面,
参见: http://www.softwarefreedom.org/news/2005/may/11/wine/
然而,从2005年到现在, SFLC似乎没有公开发表过关于wine项目存在的潜在法律风险的评估.
--
Regards,
Qian Hong
-
请帮助我的同学 *姚勋元* 一家: http://goo.gl/HFhP5
Please help my classmate *Yao Xunyuan* and his family by a small
donation: http://goo.gl/91Q7X