【立此存照】业内人士再次表明墙国统信UOS与深度deepin自带的Wine违反LGPL许可协议
先给不太清楚统信UOS与深度deepin的人做简单介绍：
「深度deepin」是「深度公司」发行的Linux系统，「统信UOS」是基于「深度deepin」修改而成的收费版。
两者都是中共在背后撑腰的「国产Linux系统」，并且加入了大量私货。
目前，「深度公司」已经成为了「统信」的附属。
关于Wine，这个是用来在第三方系统（诸如Linux, macOS, FreeBSD）运行Windows程序的软件。
由于Windows是闭源系统（尽管有泄露的代码，但由于版权问题无法直接用），因此Wine实现功能前基本都要靠“猜测”，所以进展一直都不快。
为了更方便地使用Windows软件，「深度deepin」魔改了Wine。然而按照Wine的许可协议(LGPL)，改完后需要公开代码，但他们没这样干，于是这个违规行为再次被业内人士抨击。
来源是v2ex的其中一个讨论贴：https://www.v2etwitter.com/t/880985
首先是有人给深度deepin辩护（57楼）：
接着是其他人的反驳（63楼）：
64楼：
随后是Wine开发者出现（67楼）：
————————————分割线————————————
看完这冰山一角，顺便评论一下。
“深度”公司说，自己向Wine提交的代码经常被拖延、冷处理，于是只好自己弄一份。
然而截图也提到了，他们自己弄一份却不继续公开。
向上游提交代码被拖延，以及自己弄一份却不公开，这两件事都很可疑。
先说后一件事情，自己弄一份但不公开。这让人怀疑到底是不是夹杂了见不得光的私货，比如监视并记录用户在使用软件过程中的一举一动。
对了，公开代码夹带私货且成功提交，事实上早就有人做过成功的实验。
明尼苏达大学就做过实验，故意往Linux项目提交漏洞代码，并且成功了，在成功之后就公开实验结果。
虽然这件事导致明尼苏达大学被Linux项目“拉黑”，但这个实验向大众证明，人总会有疏忽的时候。
往公开项目提交私货代码往往需要相当高的技巧，因为不能被项目组的人一眼看出，并且也不能被其他人轻易地看出。最好能拖上五年十年甚至更长时间才被发现。
就举个近期的漏洞事件，cURL这个工具存在长达24年的漏洞（还好单纯是作者的无心之失），直到本月初（2022年9月）才被发现。这个漏洞的具体情况可以自己查一查，说到底其实就是某些人对cURL的使用方法、配置方式超出了作者的想象，以至于作者本人都没想过会有人这样用。可以放心的是，cURL的这个漏洞是用来对服务器发动洪水攻击的，而不是被人悄悄地入侵自己的电脑，所以大家可以继续放心使用。但我还得提醒一句，看懂后别拿去用来攻击他人的机器。
可想而知，如果第三方的人想要故意插入漏洞而不被发现，就需要让私货代码显得符合「正常使用」的逻辑，并且触发漏洞的方式必须出乎意料。
而深度公司内负责Wine的开发者显然达不到这种水平，看看Wine社区的开发者所写的评论就可以得知——“有些贡献，但是不多”、“经常是为了刷 KPI ，质量不高”、“并不积极修改完善”。
也许就因为这样，深度公司索性就自己闭门造车，并且由于完全闭门，真就可以说随便怎么干都行。
这就顺理成章地回到第一件事情，“向上游提交代码被拖延”。
目前来看，Wine项目暂时还是安全的，Wine开发者对代码的检查仍算负责。
————————————分割线————————————
同样需要小心的是，「深度」和「统信」，还有「华为」、「腾讯」等公司都是Linux内核的代码贡献者，我不知道他们有没有向Linux内核提交过水平够高、能瞒天过海的漏洞代码。
但Linux内核有已经出现了污染组件了，这就是「SM」（商密）系列的「国密算法」，SM2、SM3、SM4都已经内置于Linux内核当中，用来给墙内厂商提供方便。
当初这条消息出现时，我是很担心的，因为除了算法设计者，没人知道SM算法有没有故意设计的漏洞，第三方专业人士都很难验证，更何况内核代码把关人未必都是算法专家。
后来发现情况还好，只要不用「国密算法」，那就没事。
而「深度deepin」和「统信UOS」，毫无疑问，都主动使用了「SM国密算法」。
「深度deepin」是「深度公司」发行的Linux系统，「统信UOS」是基于「深度deepin」修改而成的收费版。
两者都是中共在背后撑腰的「国产Linux系统」，并且加入了大量私货。
目前，「深度公司」已经成为了「统信」的附属。
关于Wine，这个是用来在第三方系统（诸如Linux, macOS, FreeBSD）运行Windows程序的软件。
由于Windows是闭源系统（尽管有泄露的代码，但由于版权问题无法直接用），因此Wine实现功能前基本都要靠“猜测”，所以进展一直都不快。
为了更方便地使用Windows软件，「深度deepin」魔改了Wine。然而按照Wine的许可协议(LGPL)，改完后需要公开代码，但他们没这样干，于是这个违规行为再次被业内人士抨击。
来源是v2ex的其中一个讨论贴：https://www.v2etwitter.com/t/880985
首先是有人给深度deepin辩护（57楼）：
最开始 deepin 选择自己 fork 一份 wine 维护就是不得已而为之的，因为 wine 上游经常不理 deepin 发的补丁，不知道是因为当时老外们并不关心国人用户的刚需，所以对待 deepin 针对国产毒瘤软件的修改并不积极，还是因为觉得这些补丁是“针对特定软件的魔改”所以质量不高不接受，又或者单纯是开源社区驱动效率太低，没能及时合并这些补丁，总之最后的结果就是 deepin 不得不自己维护一个分支。
而至于开源协议这个事情，那就很复杂了。首先，据我所知，deepin 官方从来没有对任何个人使用 deepin-wine 的二进制的行为有过禁止和处罚，很多把 deepin-wine 开源移植到其他发行版的作者也是 deepin 社区的活跃用户，大家基本上对这方面也都没什么争议。个人猜测，deepin-wine 没有正式开源，一方面可能是有些私有或专有代码可能是会有风险的，比如对毒瘤软件的逆向分析所做的补丁，这部分如果真的开源了或许会有麻烦，另一方面，可能是不少“友商”会更加方便地“拿来主义”，然后骄傲一把沸腾一波，然后收获喝彩获得经费……
所以开源协议这个事，从 archcn 的角度，我觉得没有问题，但是从 deepin 的角度，我猜测也是有自己的考量和苦衷。
早期的 wine 很多情况下对国产毒瘤软件的支持非常差，当时 deepin-wine 几乎是唯一解，现在有些软件直接用新版本的 wine 也能近乎开箱即用（但是和 deepin-wine 还是有差距），一方面是 wine 本身的进步，一方面也是 deepin-wine 的某些补丁慢慢得合并到了上游，所以不管怎么样都不应该否定 deepin 在这方面的努力和贡献。
接着是其他人的反驳（63楼）：
恕我直言,deepin/深度违反开源协议就是违反开源协议,违反 lgpl 就是违反 lgpl,这事真的没法洗.
deepin 牛逼可以自己重新开发一个闭源的 wine 替代,这样就没人管得着了
可惜他们没有,拿了别人 20 年的开源成果,然后修改一番闭源,还嘲讽其他人"拿来主义"?还隐情?这啥操作
你看看你引用的所谓 deepin 给上游贡献的补丁,一共多少个?wine 一年新增的补丁又是多少个?
64楼：
如果各位 Linux 桌面用户对微信有需求的,首先考虑微信原生那个版本,如果不能用就直接用上游 wine 直接装一个.wine 7.15 之后的版本,包括截图的大部分功能都可用.
基于如下原因 Linux 用户应该认真考虑抵制 deepin-wine 这种毒瘤,并将他们的恶名传播,直到他们做出改变:
1. deepin-wine 违反 lgpl 协议,违反开源的游戏规则,破坏开源 /自由软件生态
2. 基于安全考虑,完全有理由怀疑他们是不是给他们的 deepin-wine 加了什么
3. deepin 对于自己违反开源协议这个行为的不懈和狡辩,实在令人厌恶,使得 1 的负面影响扩大.
如果大家继续使用这样的软件,无疑是对你喜爱的 Linux 开源自由软件生态的沉重打击.因为真正把代码和大家共享的人和开源生态的维护者的名声得不到声张.
各个发行版更应该把这样的软件排除在软件源之外,因为它既不是开源软件,也不是商业软件,而是违权软件.
随后是Wine开发者出现（67楼）：
作为一名 Wine 的开发者，对于深度 /UOS 我觉得我可以说一下。
1. 深度 /UOS 违反 LGPL 协议，分发的 Wine 没有开放源代码。
2. 深度 /UOS 是对上游有些贡献，但是不多。最近一两年发的代码经常是为了刷 KPI ，质量不高，所以容易被维护者忽视。在获得上游开发者的反馈后也并不积极修改完善，导致难以合并到上游。这些未完善的代码我们称之为 hack ，能让某些软件运行起来，但是可能不正确，影响其他软件运行。
3. 不公开这些代码的另一个原因是想形成对其他国内厂商的竞争优势。但这种行为其实让社区会做更多的重复工作。毕竟就算是 hack 公开出来，也有助于其他开发者了解问题所在。
————————————分割线————————————
看完这冰山一角，顺便评论一下。
“深度”公司说，自己向Wine提交的代码经常被拖延、冷处理，于是只好自己弄一份。
然而截图也提到了，他们自己弄一份却不继续公开。
向上游提交代码被拖延，以及自己弄一份却不公开，这两件事都很可疑。
先说后一件事情，自己弄一份但不公开。这让人怀疑到底是不是夹杂了见不得光的私货，比如监视并记录用户在使用软件过程中的一举一动。
对了，公开代码夹带私货且成功提交，事实上早就有人做过成功的实验。
明尼苏达大学就做过实验，故意往Linux项目提交漏洞代码，并且成功了，在成功之后就公开实验结果。
虽然这件事导致明尼苏达大学被Linux项目“拉黑”，但这个实验向大众证明，人总会有疏忽的时候。
往公开项目提交私货代码往往需要相当高的技巧，因为不能被项目组的人一眼看出，并且也不能被其他人轻易地看出。最好能拖上五年十年甚至更长时间才被发现。
就举个近期的漏洞事件，cURL这个工具存在长达24年的漏洞（还好单纯是作者的无心之失），直到本月初（2022年9月）才被发现。这个漏洞的具体情况可以自己查一查，说到底其实就是某些人对cURL的使用方法、配置方式超出了作者的想象，以至于作者本人都没想过会有人这样用。可以放心的是，cURL的这个漏洞是用来对服务器发动洪水攻击的，而不是被人悄悄地入侵自己的电脑，所以大家可以继续放心使用。但我还得提醒一句，看懂后别拿去用来攻击他人的机器。
可想而知，如果第三方的人想要故意插入漏洞而不被发现，就需要让私货代码显得符合「正常使用」的逻辑，并且触发漏洞的方式必须出乎意料。
而深度公司内负责Wine的开发者显然达不到这种水平，看看Wine社区的开发者所写的评论就可以得知——“有些贡献，但是不多”、“经常是为了刷 KPI ，质量不高”、“并不积极修改完善”。
也许就因为这样，深度公司索性就自己闭门造车，并且由于完全闭门，真就可以说随便怎么干都行。
这就顺理成章地回到第一件事情，“向上游提交代码被拖延”。
目前来看，Wine项目暂时还是安全的，Wine开发者对代码的检查仍算负责。
————————————分割线————————————
同样需要小心的是，「深度」和「统信」，还有「华为」、「腾讯」等公司都是Linux内核的代码贡献者，我不知道他们有没有向Linux内核提交过水平够高、能瞒天过海的漏洞代码。
但Linux内核有已经出现了污染组件了，这就是「SM」（商密）系列的「国密算法」，SM2、SM3、SM4都已经内置于Linux内核当中，用来给墙内厂商提供方便。
当初这条消息出现时，我是很担心的，因为除了算法设计者，没人知道SM算法有没有故意设计的漏洞，第三方专业人士都很难验证，更何况内核代码把关人未必都是算法专家。
后来发现情况还好，只要不用「国密算法」，那就没事。
而「深度deepin」和「统信UOS」，毫无疑问，都主动使用了「SM国密算法」。
