@
icaolei #279 接下来的话会让很多开源软件用户或愤怒或笑死,但我相信会有相当一部分开源贡献者愿意认可。
所以说这就是一种对开源的误解。你可能曾经在哪里听到开源软件这个概念的时候,了解到有这么一群人致力于让所有人都用上自由的软件,还有不被大公司掌控一切云云,但你忽视了自由软件就像其他一切自由一样都是有成本的。这个成本指的不是你需要牺牲什么东西,而是说你不能看到有人说这个东西是开源就认为是开源的好东西,你必须有基本的代码审计能力来判断它是否开源,否则对你来说更好的选择是根据这个产品是否好用、是否解决你的需求来决定是否继续使用,而不是是否开源。
对于大公司、NGO 和其他社会团体、开发者而言,开源精神意味着有足够多种类权责分明的协议来约束行为、赋予权利,而他们应该把协议作为底线和遮羞布,这一点开源协议和国际法倒是有相似之处。
对于普通用户而言,应该清楚认识到开源虽然最终是为了让所有人都用上自由软件,但这是一个虽不能至,然心向往之的境界,任何时候都应该想清楚自己为什么信任一个软件项目。
简单来说,你要么相信大公司的商业信誉,要么相信著名开发者的个人形象,不然你就必须相信你个人的代码审计能力。如果你缺乏对项目是否开源的判断能力,那你不需要(可能也不应该)把是否开源作为你选择工具的依据。
你在了解到这是个开源项目之后,首先应该确认项目的主要功能相关代码都已经展现在你的电脑屏幕上,然后你才能确认这是个开源项目。Talk is cheap, show me the code. 此外你还应该查看此项目的 LICENSE 文件,了解你是否应该通过其他方式获取源代码。
用户使用一款产品时,作者/产品/社区不应该要求用户具备侦探能力,不应该要求用户去研究产品本身的开闭源历史,不应该要求非开发者身份的用户去研究产品开源协议。而进一步讲,用户在没有能力关心的时候,也就不应该关心这些问题。
-------------------------------------------------------------------------------------------------------------
前面不认同 OP 的人,大多数都持有差不多的观点:你不能因为一个开源项目看上去是开源项目就认定它是开源项目,我认为这也是一个普通用户在步入开源社区之后应该树立的第一个观念,也是理解开源精神和开源运动的第一步。
关于很多人为了证明开发者有把新项目伪装成开源项目的嫌疑,举出的“在 GitHub 只放
README.md 所以一眼就知道是闭源软件”这种例子,这也只是建立在“能读懂几行代码”这种相对较低门槛之上的一种区分“真闭源”和“假开源”的方式。
举个例子:
https://github.com/ripperhe/Bob 这个项目相信很多人有了解
https://i.imgur.com/E81823r.png 看到这个文件目录,会有人认为这是个开源项目吗?
是真的会。
https://i.imgur.com/T6gzJ0e.png 你点进这个人的主页甚至会发现他能够熟练运用 Import repo 、Action 等功能,也能根据自己需求修改代码,根据项目内容修改/新增
README.md 内容,他不是一个 GitHub 新手,但他完全不知道开源是什么,就像本帖中很多回复一样认为 GitHub 上的所有东西都是完全开放源代码的。
你或者 OP 想把开源的门槛拓宽,可能出发点是好的,想让所有人都用上自由软件,但多想一想就知道,你只能把门槛拓宽到自己的认知水平上,其实你只是要求开发者做到让 ``你`` 一下子就知道这是不是开放源代码的项目。评论中也有人提到,有没有做到在
README.md 最顶端写清楚此项目不是开源软件?即便做到了,仍然会有一大票从来不看
README.md 的用户,甚至他们中间还能分出看到软文就直奔 release 的、看到软文就直奔 Chrome/Edge 应用商店的、看到软文就直奔 GreasyFork 的、看到软文就直奔 bilibili 打开视频安装教学的各种能力层次。如果你做过一个面向大众的产品,自己做过客服工作,你就知道唯一的解决方案就是在任何平台上开始运行之前,先弹窗用红色加粗字体警告三次:本项目 **不是** 开源软件,详情请见
google.com ,任何目前仍认为本项目开放源代码的用户 **禁止使用** !!!
这也是我在之前的回复中多次提到“开源洼地”一词的原因,即使在 V 站这样一个社区,即使在 OP 和所有支持者也认为 GitHub 不是一个下载站的环境里,仍然有大多数人把 GitHub 当成一个软件包下载站去使用,不会思考开源精神为什么能做到不仅仅是一句口号。
正好今天也回复了另一个帖子《为什么国内开源项目普遍是先有英文文档,后才有中文文档甚至有的没有中文文档?》,和开源问题在某种程度上是共通的。当你把是否开源作为自己选择工具的要素之一,却不捍卫自己使用自由软件的权利时,你也应该思考一下为什么 GitHub 上的简中环境会是现在这样。
-------------------------------------------------------------------------------------------------------------------
为了防止有人说我不就事论事,最后强调一下,关于沉浸式翻译项目是否应当开源、开源转闭源的过程是否合法、如何申请知识产权保护和独立代码审计等问题,前面的回复讨论足够清晰,至少我阅读之后不存在更多的疑问,建议参阅。我仅就“为什么不能因为一个开源项目看上去是开源项目就认定它是开源项目”这一疑问给出解释。