放置部分被贴吧无断削除内容的备份。
方秃子还是不专业啊。
伦理问题：哪来的砖家有钦定清楚CCR5基因缺陷和非缺陷相比哪个一定更“正常”？系统发生学什么时候有能耐制造伦理出来了？
法律问题：哪部现行法律有反人类罪的管辖？
已被楼主删除，归档。
看起来你没有看懂问题。
问题的第一部分是：为什么干不掉？其实很简单，首先是因为没能力干掉。
常识：重许可只有 copyright holder 才能做到，而 Linux 的 copyright holder 不止一个。
只要有其中有一个不同意改掉 GPLv2 ，那就改不了，除非排除并替换掉相关代码。
这个困难和替换成什么许可证无关——最明显的，LBT 抵制 GPLv3 （特别地，抵制其中关于 tivoization 的观点）。
第二部分是，为什么换成 OSI approved 许可证。很简单，因为 copyright holder 不愿意。至于为什么不愿意，这不是问题的内容。
你给的文章只给出了很间接的理由回答这半个问题，而且不怎么到点上。
顺便你给的这文章，文法极其糟糕，还不利于阅读（比如，不会使用脚注甚至括号）；甚至还有低级错误，例如认为 (OSI) approved 是“推荐”。
链接的参考文章也比较混乱，以至于和文章的观点相悖。例如，指称“Linux kernel”这个写法是错的，结果拿来当论据的 CoC 报道却使用了这种“错”的写法，也没见抵制。
还有不少技术谬误。
如技术角度上说，Linux kernel 并没有什么问题。尽管 Linux 是个 kernel 项目，但其中维护的内容并不全是 kernel 代码。反过来，钻牛角尖点，使用 kernel.org 钦定只有 Linux 才算 kernel 之嫌，误导比起来还更大。
Android kernel 的说法是明确有误导性的，Android 项目本身不包含 kernel ，但是被称为 Android 的产品中分发的内容可以包含 Linux kernel 。
而 Windows kernel 则真的是错的。现代 Windows 中相当于其它一些系统的 kernel 的东西主要是 NT executive 。所谓 Windows 的 kernel 跟其它系统的 kernel 对比是很不严格的叫法。Windows 中真正叫 kernel 的，实际上指的是被 executive 使用的一小部分内核模式组件。
题外话，RMS 的说法同样是另外的技术意义上有误导性的。
尽管 RMS 明确地承认“自由”的说法有缺陷（会引起误解），但仍然坚持定义什么叫“自由”，理由仅仅是找不到比“自由”更合适的字眼；这一定程度上本身已经阻碍了自由，例如，关于选择许可证的自由。因为许可证这种依赖 contract law 机制无法逾越 copyright law/patent law/... 的限制无法保证这种自由而不强调，这尚且还能视为不可抗力而差强人意；但是彻底无视这种自由乃至在自由的定义中直接排除是什么意思？
一个简单的测试：2-clause BSD license 和 GNU GPLv2 相比，是不是同等的“自由”？
（提示：这和 copyleft 无关。例如，考虑 Theo de Raadt 反对 LLVM 重新许可为 Apache License 2.0 的理由；何者的“自由”更受限制？）
您好，您发布的内容包含违规信息，所以被系统删除，请您下次注意哦~
2019-08-08 17:04:11
回复 幻の上帝 :如果只按你看到的事实而忽视另外的事实存在，那和掩耳盗铃没有丝毫的区别。所以shame hall通常都需要当事人来举证确认。
没话找话的扯蛋逻辑。
我说过了，经过法庭质证的程序可以在诉讼中认定事实。某些自认带法官钦点的事实是没有排面的。
能确认的事实就是没谁找到公开的其它授权。然而这跟谁来举证根本上没关系。
回复 幻の上帝 :著作权法案不论在哪个国家和地区都是需要当事人举证才是有效的，别说什么著作权法的意义是什么，先问问法律的意义是什么？任何第三方都可以代替著作权者进行维权，社会就会彻底乱套，还觉得视觉中国和上海知桥这样的碰瓷骗子不够多？
继续法盲扯蛋。法律的效力由当事人的行为之后再确定？笑死人了。
搞清楚当事人权利跟法律的效力之间有什么区别了没？（要不是看到了，我是没法想象怎么把这两坨缝合到一起的……）
回复 幻の上帝 :喷子的基本特征就是以为“我”即世界，说了这么多还是基于自己认定的事实，可能忘了现代法律的公理中，任何自然人均对自己的言论有负责的义务，除非同时声明我说的话就是个p，不要在意。出现这种情况，可以向相关方面提起侵权的主张，而无权认定侵权的事实。
自嘲完美。
所谓“现代法律的公理”，不知是谁家的法律带出来的。有承担责任的义务却不说承担什么责任，这算空气法律口嗨？
“无权认定侵权的事实”我可没主张所谓“认定”有多少法律效力，无权具有这种观点的表达是哪条法律规定的？……还是说，你就是带法官？
回复 幻の上帝 :搞笑，“认定”只是你自己心里的认定，现在你已经把这些内容发到了公网上面，也就意味着你的所谓“认定”已经对后来者的判断有了影响。至于什么法律条文，基于的是客观事实而不是你自己认定的事实。
任意的“影响”责任论，这是法律发明家的又一力作么。
回复 幻の上帝 :在华为和linaro还有gcc三方自行举证著作权并未受到侵犯之后，对方也有权对你现有的评价言论提出指控，不然不会有所谓转发500次的条文。
然而并没卵用。看来也不关这位带精神律师的什么事。
回复 幻の上帝 :果然言论自由的前提条件都没搞明白，任何自然人要对自己的行为负责。按这种理论，500次转发就是恶法。
前提？要冲塔承担违宪责任我不拦着。
见识技校？技校还能把原来会说人话的教得连人话都不会说了？
看来是 LZ 是对这行的上限理解得太肤浅了。
首先自学本来就是家常便饭。至少编程这方面你想指望学校学习而不是混文凭本身来顶什么用，那说明是你对行业近乎完全不了解。培训班只能临时抱佛脚，你不朝着钻营简历的方向上用功，也很难用得上这方面的特有技能来缩小和别人的差距，反而跟会自觉自学的人比起来效率上被吊打。
然后，我跟你实话实说，大学阶段（不管本硕博不管什么学校什么精品课程）会用的编程的基础教科书的作者一半以上都是不入流的，摆一道 spec 两眼一抹黑的那种水平，你觉得学这种东西，还不能自己发现纰漏改正的会有什么加分项？
所以我说会把本科专业履历基本视为零，因为大部分时候不整一遍根本没法用。而整起来的成本嘛……
技校课业再不咋地，至少基本上不会有某种自己不知道就当别人是外行的蜜汁优越感，重新培训改造的时候反而省事。（当然这种案例不常见，总之一般来讲没特别关系的，本科以下都是过个场，能录用都不大在乎是啥了……）
再是关于培训班，我只能先告诉你，光是市场认同就更呵呵。
另外再说一句，往上爬到一定阶段以后，光凭你不能忍受环境影响就不能集中注意力自学这个能力缺陷，就已经是撸瑟了。翻倍投入精力都未必能克服这个劣势。
能力越大，责任越大。作为被依赖的上游项目，影响地位本来就是一种能力的体现。与之匹配的，应当是清楚的项目目标，和支持这个目标的合理设计。
不被项目目标需要的过度设计不是合理设计；但允许被非特定第三方复用的提供重量级公共基础设施的项目，因为不可避免地会争用有限的资源，总是隐含了一个项目宣传上以外的目标：减少不够成熟的竞争项目的必要和重新制造轮子的借口。
因此，不论发起项目的直接动机、重点和特色是什么，不便被复用的设计，就不可能是合理到哪去的设计。这根本上是作为 DE 这样的问题领域决定的。（另外的一个例子是通用语言的实现。）
须知，即便用户能更清楚自己的需求为何不能被满足，甚至有更强的技术实力完全替代上游设计和实现，因为已有的历史和习惯，实际利用上游项目和上游能做到的并不对等——至少本来依赖上游的其它分支项目会因此承受更大的风险。
从这个意义上来讲，越是影响力大的上游项目，道义上应该越支持模块化配置的复用。即便这种模块化对项目自身的维护和提供支持没有明确的帮助，减少增加本不必要的下游怎么都不容易做好的 fork ，已经是充分的理由。
清算起来，不够模块化可能归咎为能力和资源不足，但不应该以和项目目的矛盾作为借口。否则，一开始它就不应该获得资源来占据这个位置——挤占了其它本可能更好满足所有人需要的项目的资源。（特别地，靠支持特性和选择的自由来吸引用户，后来却整个砍掉支持，比一开始就不支持在结果上更加恶劣。）
结果是，光看项目影响的问题领域的影响地位，就总是蕴含足够明确的模块化的必要性——并且很大程度是客观上不可避免的，不因维护者多想把这个目的排除出去而转移。
真正要拒绝自认为不必要的模块，能做的就是提供更加可能被广泛复用的模块直至标准化接口，而排除没有其它明确技术优势的类似设计的必要性。
与这个做法相反，在没有可用标准方案的情况下，只是在项目边界内部逃避模块化，或者仅仅就是不自觉地使用不够模块化的设计，减少下游项目和最终用户的可用选择，却又没有能力在业界消灭 fork 自身的合理理由，都只会让整个所谓的生态更加糟糕。这是方向和方法论上的原则错误。
关于依赖处理的问题，除了 C 本身的历史渣滓不在此老调重弹，其实 Linux 本身的设计就应该被盯到耻辱柱上——至少它开了个坏头。
始作俑者毫无疑问是 Linus Torvalds 。最近，在回复一个质疑为什么不移除过气系统调用（他本人称为 historical garbage 的 sched_yield ）的问题上，他如此回复：
The number one priority for Linux has been "don't break existing users". I have seen way too many projects that think that in order to make progress, you have to break things ("We're happy to announce version X, and you will now have to recompile everything to a new model to use it").
And I just don't believe in that "you need to break a few things to improve" model of development. We may change things internally, and break assumptions inside the kernel, but we do so without breaking old interfaces, even if we might find them very inconvenient.
...
And yes, some people disagree about that rule, but it's a rule that Linux will continue to follow at least when I maintain it. Because I think that the one thing that DOS and Windows did right ware not about technology, but about backwards compatibility. People ran DOS and Windows not because they loved DOS and Windows, but because they fidn them useful thanks to all the programs available. Breaking those programs breaks the whole point of an OS.
单独来看，这个策略似乎很合理，在项目内部来说这个策略也无可厚非。但是，其它操作系统项目（至少能和 Linux 的零头相提并论的）都没有这样采用把系统调用接口和内部 API 粗暴二分的不着边际的做法。这虽然简化了项目的维护，但对可用性实际上是灾难性的——一些时候就意味着 GPL'd or die ，如后面有用户提问：
Recently, an important kernel fpu symbol was declared GPL-only, causing significant issue for ZoL project.
How do you feel about? Can you speak about the motivation behind this decision.
而回复是：
……
Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me.
只有 licensing 本身算是外部不可抗力的合理因素。Linus Torvalds 并没有对剩余非技术因素的关键可用性缺失的问题提供明确的解决方案，也没有继续回复用户的问题：
I don't want to praise ZFS over other filesystem, but the only Linux filesystem with similar feature is BTRFS which, on my workload (virtual machine hosting) is exceptionally bad (just consider how the official suggestion is "disable CoW for VMs", when doing that will disable checksum and snapshots automatically re-enable CoW to works).
VDO+thinp+XFS is a good alternative, albeit missing some feature (self-healing, send/recv).
这只是个例，但体现的已经不只是具体项目应该如何满足特性的问题。根本上，如 API 划分策略为代表，这里 Linux 自己的问题是在项目演进策略上的自以为是的过早的优化。因为，要满足 don't break existing users ，并不需要这样做。例如，可以捆绑默认不启用的 legacy 虚拟化环境，让用户自己选择兼容性配置，这种配置完全是可以做到自动化和透明——只是显然某些人宁可偷懒放着辣鸡接口不维护而不去提供真正能更接近实际需求的解决方案而已。
这里不移除个别系统调用的决策也是类似“不想做”而不是技术障碍的问题。具体来讲，可以 ENOSYS ，造成的兼容性问题是用户空间中间 API ——如 libc 来变通。这实际上就是处理这个层次上的 historical garbage 的标准套路，历史上 Linux 也有先例可循。所以不予移除其实就是借口。
另外，关于 Windows ，Linus Torvalds 提到的说法是错的。Windows 至少已经移除了 NTVDM 。对通常的用户来讲，还很显然做得不够——凭什么用户非得忍受 CreateProcess 里面那么多的真正更配得上是 historical garbage （兼容 Win16 ，实际就是连误用都几乎没人用）的东西？
（这里面还有个漏洞是不再兼容 i386 算不算 break ，不过这个后面有补充，略。）
跳回 Linux 之外。大部分社区推动的项目这方面的现状是什么？其决策者的技术和政治水平，大多还远远不如 Linus Torvalds （比如连鼓吹 don't break existing users 都不会，这显然是比会吹 don't break existing users 但没法让用户自然接受还低不止一个档次）。这就很遗憾了。如果大众知道这些项目在这些缺陷上都是存在过错的，是因为妥协而做得不够好，那么姑且还能仅视为遗憾；但是，非得欺骗大众要求把这种作为工程实现细节的妥协视为是用户理应承受的问题而不是缺陷，甚至把自己都骗进去信了的话，可能就不得不该多让这些人反省，到底是谁活该了。
更大的一个话题是哲学路线的争论：Worse is Better vs. the MIT approach 。30 年过去了，这个问题根本上还没有消停过，甚至（因为跟风转行的问题）越来越多的开发者连讨论这个话题的资格都不够了。
至少对我来讲这本来其实是个不值得一提的问题。沉湎于表面的项目成功而不顾长期的做法，怎么说都很没品。我再次要强调的是，这首先就是人祸——见识上的缺陷。
和传统调调不同的是，我针对的不只是个别人，而是要着重攻击继承这些衣钵的“主流”工程人士的学艺不精——仅仅是在古董 PDP abstract machine 的 programming model 上搞的屑语言上想倒腾几个可移植性？想疯了。
当然，正如发明这些术语的 Richard P. Gabriel 本人的 Unix and C are the ultimate computer viruses 的态度一样，鼓吹 simplicity 的 UNIX 阵营的用户无论是当年还是现在普遍都不大能很清楚地认识到自己所谓的成功是哪来的，这点在真正有充分体系结构及软件开发常识和/或想象力“圈外人”的眼中，是没有多少门槛可言的。
进一步讲，想用被表面上的简单和可实现性欺骗最终用户，只能是骗得了一时，骗不了一世。这是时间问题。不过，在此之前，只要是没能力反了的，管你是不是开发者，那就老实当炮灰吧——反正你还得用，不是么？
但是，即便退一万步讲，为了要恰饭而不得不颠倒黑白，请至少不要怂到骂娘都不会了。
补充说明一下，一直说的没钱，指的是平台，而不是观众。不知道你思维还停留在哪个年代，一提到没钱张嘴就是“观众没”，从来没有人说观众姥爷OK？说的是a站（平台）没，b站（平台）有，开个激励计划视频按流量算钱，甚至于人家还提供工作窗口让你接广告赚甲方的钱，为什么别人人多，2021年了早就不是单一的up主观众双线模式了OK？思维不要停留在要钱就是找观众OK？a站已经是快手子公司了，b站也是上市企业了
我会提观众姥爷，是因为你没有显示出平台运营和创作者的立场，只能默认你是全然外行的观众姥爷身份了。
（其实一些不得不“用爱发电”的局面，观众姥爷还是有点责任的，像尊重版权之类的问题。不过这个不是重点。）
平台没钱首先是平台自己的问题。
要从平台捞钱也不是不可以，但一些 up 也应该反省为什么非得指望从平台捞钱而客观上助长垄断，坑人坑己坑观众。
根本上，平台主要是提供内容分发服务，在内容生产这种副业上捞钱起到的是中介的作用（当然有些平台转型自己介入内容生产，这是另一回事），并不足以构成产业的核心环节，某种程度上本应是可有可无而随便能找到备胎的一环。
然而现实不是。某些场合上，平台话语权和影响力已经达到了匪夷所思的地步（譬如，仅仅是因为“知道大多数用户之前看了什么”就能架空内容提供方变相独断“用户之后应该付费看什么”）。这和产业中的分工形成了显著的错位。
形成垄断的平台两头抽税反而降低内容生产方的效率，破坏行业生态。现在在线视频平台暂且因为各种原因还不那么成气候，看看app商店渠道商就知道以后内容供应商的地位了。
把这种发展模式视为理所当然的 dssq ，是缺乏常识的表现，反过来还好意思嘲讽质疑者“思维停留在哪个年代”，那只能说夏虫不可语冰了。
从运营的角度来说，抱平台大腿是当前畸形流量环境中没办法的办法。
但是创作者其实并不需要和平台绑定。非得站队整成莫名其妙的统一战线，把更专业的业务经济企业架空，或者选择和放任跪舔平台的运营合作，乃至自己下场舔平台，其实都是损人不利己的自绝后路的行为艺术了。
（观众也一样。这个就不需要多说了。）
