10k+ star 的项目也搞假开源

[sloknyyz]

项目名：immersive-translate
这个项目最开始是这个仓库 https://github.com/immersive-translate/old-immersive-translate, 并且 fork 的另一个项目
有名气后，换成了这个仓库 https://github.com/immersive-translate/immersive-translate 并且不再提交源代码, 只提交 build 后的文件

说实话，插件不错，我也是用了看到开源才来看的，但没想到搞假开源。

[1423]

挺好的,感谢楼主公开质疑,也感谢作者公开澄清

[theowenyoung]

@jianguoni 如果我没理解错的话，层主想找个开源的替代品..

[MeMoDiv]

支持合理质疑，作者也确实有义务对合理质疑作出回应。但除此之外，大部分回复确确实实拉低了 V 站的平均水平，能搞清楚开源协议的不足一半，了解开源转商业流程的十不足一，很难想象 V 站这样一个优秀项目层出不穷、开源贡献者数不胜数的社区，仍然走不出开源洼地，究竟来源于内心的自卑还是国人开发者的原罪真的很难评。

[xifangczy]

变现得方式很多 选择了一个最恶心得方式。。

[momo1pm]

可能觉得在 GitHub 放着默认开源？不应该去看下协议吗...

[jomalonejia]

洼地人就是这样的 习惯了

[litguy]

别说你这些玩具，青云还是上市公司，当初说要开源自己的分布式存储
你去 github 上面也只能看到几个 cli 工具的 code
core 部分完全没公开
so ，接受就行

[enpitsulin]

真心希望"没有调查，就没有发言权"和"github !== 开源"这两件事人人都能理解，喜欢上来就扣帽子还有攻击群体的还真是素质高

[sloknyyz]

@theowenyoung 如果不开源至少应该在 readme 中说明，正如一些层主说的，项目名后缀带 release 这样的字样，而不是装的自己是开源的，欺骗小白不懂，硬吃开源红利。就我个人而言，如果我觉得你是开源的，我会对你这个插件有好感，如果还做的不错，更会想去尝试使用。我想肯定有不少人都是这样的。至于你说的避免拿去被卖，这和加个说明完全不冲突。还是那句话，开不开源都无所谓，但不要又当又立，让人以为是开源的，骗赞，这种事我看到了还是会发出来说，就是看不惯。

[sloknyyz]

@saucer 你以为我一直闲着没事干啊

[ma836323493]

上传 build 后的文件, 哈哈哈很行很行, 学到了

[belin520]

发现挺好用的，感谢推荐🤣

[9ki]

先说结论, 反感 immersive-translate 假开源行为, 支持楼主质疑.

像 Clash for windows( https://github.com/Fndroid/clash_for_windows_pkg) 同样也不开源, 但是别人也没有把开发用的文件传来上, 而是只传了 readmd.md.

反观 immersive-translate 上传了 custom.css Makefile, 给人一种开放源代码的错觉, 如果没有研究代码的打算就不会发现源代码未开放, 严重误导用户.

[mdn]

建议大家在使用任何项目前，先看下 LICENSE ，当年 react 修改项目许可引起了很大影响，后面改回了 MIT

npm 包也有很多问题这样的问题

1. npm 包很多只上传编译后代码，无源码地址（腾讯小程序相关的包）

2. npm 包也有协议，使用的 GPL ，就规定了使用 GPL 源码的人必须也得开源，商用小心律师函

[evemoo]

OP 怎么不回作者了

[nothingistrue]

theowenyoung #93
首先，你自认了你的新项目是「重构」而不是「静室开发」，那么你的新项目，仍然是原始项目的下游，需继续遵循 MPL-2.0 协议。

当然，开源协议是君子协定，没人会像商业项目那样去较真，你换成 EULA 协议的新项目，甚至不用偷偷摸摸，就是明目张胆的把项目名称定义成{原项目名称}-Pro 、{原项目名称}-New ，都没人会在意。但是然后，你把原项目改成了 old-{原项目名}，用新项目顶替了老项目的名字。

这种开自爆大卡车的行为，对你想「借老开源项目的名气，骗人收购你具备严重知识产权纠葛的新项目」的念头，可没有帮助。


这俩明显是拖：
saucer #95
qianji201712 #96

[Vraw5]

有一些朴素的小白认为：上 github 的东西就是开源的东西。这句话，当成正话、反话听都能说的通

[koast]

这个仓库的目录结构，还有那个自托管的脚本(安装界面除了压缩的一行代码之外还能看到很长一段 css ，明明可以都压用 minify 的，为什么还要留点 css 不压缩呢？)，就真的看上去很像是一个开源项目，我相信作者真的没有在任何地方声明过这是一个开源项目。但就像 OP 说的，这并不妨碍大家因为支持页面挂个 Github 链接，点开之后还能看到 issue ，release ，4 天前的 commit 等等，而主观判断这就是一个开源项目，直到像 OP 一样真的想看下代码才会发现 Github 这个代码托管平台上托管了 dist ，doc ，script ，license ，readme ，makefile ，但是就是没有 src 。这些迹象都在暗示这是个开源项目，至于作者是不是在有意暗示，这也许只有作者自己才知道。

[sloknyyz]

@evemoo 选择性眼瞎

[geelaw]

@sloknyyz #109 听起来你认为“源代码可用”就是“开源”，这是完全错误的理解。建议减少望文生义和想当然。

[evemoo]

@sloknyyz 乐了，人家回答的全在点子上，你还硬扯开不开源。人家从头到尾就没说是开源项目，自己臆想别人假装开源吃红利 balabala 是谁眼瞎？还跑这单向输出还觉得很对是吗？

[sentinelK]

@sloknyyz “欺骗小白不懂，硬吃开源红利。”

作者既没有吸纳公众的合并请求，又没有宣传自己是开源程序来吸引眼球，请问他享受什么红利了？

[dnL]

@nothingistrue 人家说的是用 ts 重写，你别给人偷换概念成“重构”

[lyxeno]

我看了半天 readme 也没看见 `开源` `Open Source`这样的字样啊，谁说闭源就一定要标注出来？
用的人很多的 clash for windows 也是直接在 release 里上传构建后的二进制文件（虽然 cfw 的结构一眼就能看出不是开源的,实在很多）

[coderwl]

既然有很多人喜欢用开源的，那不如大家整个开源项目实现这个功能

[rev1si0n]

我就做了一个你说的这个事情，这个项目分了两部分，服务端程序没有开源，客户端程序以及工具，代码是开源的，而且 README 里也明确标注了服务端没有开源，你是不是也要骂一下我，被你一吓我得看看是不是该把这个提示放到 README 最前面了。

[kkadmin]

很理解 op ，主要打着开源幌子的人不在少数

[evemoo]

OP 在没理解开源真正含义的情况下臆测作者假装开源，对作者关于 License 和 重构的正面回应一个没有，也拿不出更多确凿的证据论证“假开源”。判定为个人垃圾情绪单向输出，已 Block

看到这里的各位也不用继续回了，推垃圾话题上去污染环境没必要。

[wjfz]

在 GreaseFork 翻到这个项目的，https://greasyfork.org/zh-CN/scripts/457196-immersive-translate

详情页说出了新版，要用脱离 GreaseFork 平台的链接单独安装，对这种操作就很抵触。

[sloknyyz]

@evemoo 我说你眼瞎是你说我没回复作者，说话可以过过脑子吗？然后你再看看 118 楼，再说我是臆想 OK ？我跑这单向输出我乐意，这种行为我看着不舒服 OK ？

[sloknyyz]

@evemoo 至于你说的 license 和重构的回应，这和假开源有关系吗？看看 118 楼。不就是欺负小白不懂代码吗？你判定你的，关我啥事。

[konnnnn]

不能理解给原项目改名...这不是挪用吗？
一个新的商业化的项目占据一个开源项目的名字，这件事能发生只是因为控制项目的人是同一个人

[angrylid]

立场鲜明反对这种装模作样传个 Makefile 的行为，但更反对楼主这种虚空打靶输出情绪的做法。

首先 GitHub 是允许上面只托管 release 甚至是托管和软件无关的太子党关系网络，托管到 GitHub 本来就不等价于开源，纯粹是你的主观认识。

然后楼主又说“不就是想利用大众认为的开源的是更好的吗”，拜托，你的根据在哪里？我觉得你只能代表你自己认为开源的是更好的。“欺骗小白不懂，硬吃开源红利。”，这里红利又是什么，指的是 Stars 还是你上文主观认为的“大众认为开源很好”的好感度？

[Pipecraft]

GitHub 可以用来管理代码以外的东西（文档，issues 等），GitHub 可以有 private 项目，上 GitHub 不等于开源。
都上 V2 了，大家不可能不知道吧。
上面替作者洗的人为什么那么多人要提这个？难道 OP 真的不懂才说这个事情吗？

这个项目有 10K star ，见过几次出现在 GitHub Trending 上面，说明很多人认为（而且让人误认为）它是一个开源的项目。这个插件很好用，用户看到有 GitHub 链接，以为是开源的，给个 star 很正常吧。认为是开源的有错吗？为了给个 star 还必须翻一下代码？
我想说的是，一定有很多人不深入了解的话，会以为这是一个开源的项目。
dist 文件夹里的代码没有 minify ，没有混淆, 说它开放了源代码，也说得过去。

上面有人提开源协议。它现在是 End-User License Agreement (EULA)，4 月 20 日以前是 GNU AFFERO GENERAL PUBLIC LICENSE Version 3 。看到 GNU AGPL 认为它是开源的也有吧。而且 dist 里还有”源代码“。

这个项目，目前有 677 个 fork ，只有 22 个 PR 。fork 一个文档项目为了自己部署文档吗？
大概看了一下，22 个 PR 大部分是修改 README 的，其中有 2 个是修改代码的。一个被 close 了，一个还是 open 状态。
那个 open 状态的 PR 的是一位国外开发者提交的，说明写的非常认真，让人敬佩。https://github.com/immersive-translate/immersive-translate/pull/773
可惜他们不知道自己修改的是 dist 文件夹下面的代码。

还有说没有吃开源的红利的，这个不可能一点没有。在 V2 见过几次有人说它是开源的插件，推荐使用的。V2 外面也有很多这么宣传的。
不能说开源的就更好，但插件这东西，能看到源码才更让人安心使用吧。一个插件，能在所有网站执行，与服务器有通信，不开源，作者信不过的话，你能放心用吗？
还有，如果是开源的，同是程序员，想支持一下的心还是有的。

我认为闭源没有问题，但不要让人误解为是开源的。误解为开源的人，也没有罪。

[victimsss]

@koast 这个项目确实有意思，首先是项目是 fork 另一个项目，协议是 MPL-2.0 。然后开源项目改名 “old-immersive-translate”，新项目用老项目的 “immersive-translate”。这个和白嫖不白嫖没啥关系，我很不理解为啥这两个项目非得换一个名，举个例子，很多博客或者文章介绍的开源项目（ old-immersive-translate ）的链接不是都跳转到这 https://github.com/immersive-translate/immersive-translate 上面了吗。

[sloknyyz]

@angrylid 看看 134 楼再说有没有吃开源红利吧。大部分人对开源的项目至少比对闭源的更有好感，毕竟源码在那，自己不看也会比较放心。

[sloknyyz]

@angrylid 还有说我虚空打靶？我那里虚空了，假装开源不是事实吗？

[fishjar]

原来有旧项目代码可以参考，真的现在才知道。。。。害我黑灯瞎火的从头摸索撸了一个开源的。。算了，算了，反正第一版鲁完能用了。。

有需要开源的，到这里自取：
https://github.com/fishjar/kiss-translator

[sloknyyz]

我从始至终反对的都是这种假装开源的做法。不开源完全没问题，readme 说明，项目后缀加个 release 都能直接表明。

@angrylid

[qianji201712]

@evemoo +1 ，很多人连看 License 的习惯都没有

[yjd]

@Pipecraft 在上个月 v2 看到的，以为开源的。打开 github 页面看到目录结构容易误解为开源。

[theowenyoung]

@sloknyyz 谢谢，建议已采纳，已在 README 添加相关说明。

[mdn]

@konnnnn 还是见少了，商标侵权案比比皆是，好听好记的名称大家都想用，iphone ios 的商标最开始也不是苹果的，直到 iPhone 发布后，思科发现侵权谈判给苹果

开源项目请求转让 GitHub 、npm 项目名称的事也很常见

虽然 原项目名称不修改，新项目改为 xxx-pro 更好，但是名称复用，给出解释说明也算正常

[konnnnn]

@mdn 和我描述的不是一个情况...有什么闭源商业化 replace 开源名字的例子吗

取 pro 才是可能接受的行为

[moonrailgun]

上面有人说用 github 项目不看授权。我仔细想了想确实，因为只比较熟悉常见的开源协议，这种 github 识别不出来的协议确实不熟。

所以我仔细看了下协议内容，想问问懂协议的，我看到协议有两条比较不能理解，求解惑:

1. If you are entering into this EULA agreement on behalf of a company or other legal entity, you represent that you have the authority to bind such entity and its affiliates to these terms and conditions. If you do not have such authority or if you do not agree with the terms and conditions of this EULA agreement, do not install or use Immersive Translate , and you must not accept this EULA agreement.

上文所说使用沉浸式翻译就相当于签署 EULA 协议，那什么情况下属于代表公司签署协议？在公司内部用？还是公司自己开发了一个浏览器然后内置沉浸式翻译？因为公司是一个抽象实体，并不具备下载软件这个行为。所以我不理解这种情况


2. You are not permitted to:
Use Immersive Translate for any purpose that the creators of Immersive Translate considers is a breach of this EULA agreement.

如果我高度遵守该协议，我是否每次使用沉浸式翻译都应当去询问创造者我是否可以在某些地方使用？因为该规定比法律中的“等”更加抽象。所有的决策权取决于创建者本人的想法，如果他认为你不应该这么做，那么你就是违反了该协议。但是没有任何前置的告知。如法律中规定"等"的法律解释是等是包含大众认知的比前面举例情况同类且更加严重的情况。

就类似最终解释权归创建者所有，只要你使用了就可以在任何时候起诉你这样的规定？我不是很确定因为我对这方面不了解。有了解的同学可以帮忙解释一下类似条文的目的么？

[mdn]

@konnnnn #144 Emby 前期开源，后期闭源，用的同一个名字

你可以这样理解原项目 v1.x 开源，v2.x 闭源，作者可能是想去掉 fork ，顺便 archived

[pkwenda]

popclip 也不开源，但是 github 仓库还让大家贡献插件，这么多年怎么没人喷。

[ruquanz]

插言，开源闭源都支持开发者，每行代码都是心血。起初项目都是从 fork 开始吧，你比如 B 站的播放器仓库多少公司在用啊，哪个公司给你开源了。

[ntop]

@zsj1029 你这种人就是技术圈的肿瘤，我都懒得反驳。

[ntop]

二进制项目放在 Github 上就是恶心人的，这就是技术圈的肿瘤，你要做开源就好好做开源，不做开源可以使用私有仓库，在 Github 上弄一个项目传二进制，就是存粹的恶心人～～ 你可以说自己的行为没有法律问题，但是就是素质很低的表现！

[konnnnn]

@mdn Emby repo 还在 github 只是 18 年后没更新，也没有变成 old emby

[mdn]

@konnnnn #151 没必要钻牛角尖，作者已经接受意见在项目 README 中写明闭源，仓库就算是 release 用的吧，或者你去提个 issus ，建议改个名叫 xx-release

[geelaw]

@Pipecraft #134 Good point. 这说明 4 月 20 日更新前的版本依然可以拿出来作为自由软件、开源软件使用。由此我们也应该问：4 月 20 日修改 AGPL 为 EULA 是合法的吗？我严重怀疑不是，因为 4 月 20 日之前接受了他人的贡献，如果其他贡献者没有明确同意修改协议，那么 4 月 20 日之后所有的版本都是在侵犯版权（违反自由软件协议、违反开源软件协议）。

这个问题应该仔细追究。

不过，这个问题不影响楼主喜欢想当然。

>这个项目有 10K star ，见过几次出现在 GitHub Trending 上面，说明很多人认为（而且让人误认为）它是一个开源的项目。这个插件很好用，用户看到有 GitHub 链接，以为是开源的，给个 star 很正常吧。认为是开源的有错吗？为了给个 star 还必须翻一下代码？

从这段论述可以推断，你认为 GitHub Trending 的项目必须是开源软件，请问这种理解有何依据？

@konnnnn #144 （软件）名字如何使用，终极答案是商标持有人的权利，没有商标的时候，没有理由认为某人在开源软件上使用了一个名字，另一个软件就不能再用。

@konnnnn #144 @ntop #149 采用“道德判断”是很容易“站不住脚的”，请参考自己是否依 FSF 的定义“道德”——创造任何非自由软件在 FSF 看来都是不道德的——我不支持这种判断。

@moonrailgun #145 第一个问题，我认为如果你是为了在工作中使用，那么公司需要收到协议的约束，但这很奇怪，因为通常来说 end-user license agreement 是版权持有人和“最终用户”（因此只能是自然人，而不是法人）之间的协议。另一个情况是，你在帮助另一个人安装此软件，那么你需要可以代表另一个人进入该协议（简单的答案：不要帮别人点“同意”）。

第二个问题，这种条款通常不可执行，所以就当不存在就行了。最糟糕的后果就是法院判决你不能继续使用该软件。

[konnnnn]

@mdn 不是你举例我提出疑问吗，我不觉得是钻牛角尖
在一个 开源主导 的社区，闭源是不是应该一开始就应该更醒目直接的明示暗示？
作者应该有几次被 issue 问到是不是/能不能开源，应该足够算一个提醒做出改动吧（免得重复回答）

[fowoyaki]

CFW

[mdn]

@konnnnn #154 作者为什么会改名，就如我之前说的，应该是想去掉 fork ，作者认为项目已经和上游没有关系了，虽然可以通过 GIthub 去掉，但会比较复杂，去掉之后在一个项目下闭源也是可以的，继续更新项目的 docs README 等

[konnnnn]

@geelaw 法律的归法律，作者作为 repo 控制人可以做他想做的任何事，就像流行库的作者也可以上传恶意代码影响下游，开源的世界除了一点 license 基本没有成文的条例，我的道德判断也无所谓，但是社区对一些 practice 是有倾向的，显然作者的 practice 不会被大部分人认为是 out of good faith （ ok 基于我的偏见）

[Pipecraft]

@geelaw #153

> 从这段论述可以推断，你认为 GitHub Trending 的项目必须是开源软件，请问这种理解有何依据？

不要随意揣测别人的话语，我哪里说是必须是开源软件？请问这种理解有何依据？

我提到“很多人”认为，这个说法没有问题吧？
相对于非开源项目，人们为一个开源项目点 star 更容易，更慷慨。所以一个非开源项目，能进 GitHub Trending 很不容易。

刚刚还特意翻了一会儿 GitHub Trending ，不论日排行，周排行，月排行，我看到的都是有源代码的开源项目。
如果你能找到很多闭源项目，请指点一下。

[asyncd]

@evemoo #128 我也 block 下你

[geelaw]

@geelaw #153 @Pipecraft #134 我针对该软件曾经以 AGPL 发布提出了 issue： https://github.com/immersive-translate/immersive-translate/issues/794

这里我觉得有必要解释一下用户针对 immersive-translate 的权利。

最初，该软件以 MPL 2.0 发布。2022 年 12 月，该软件以 AGPL 3.0 发布。2023 年 1 月，该软件接受了外人的 pull request 。4 月，该软件的新版本以专有协议发布。

我假设该软件在 2023 年 1 月之前的版本完全是作者 @theowenyoung 自己创作的，作者本身（准确来说是版权持有人）并不受 MPL 2.0 和 AGPL 3.0 的约束，因此得到该软件的用户无权依 AGPL 3.0 请求源代码。当然，如此一来得到该软件的用户就没有得到自由软件、开源软件。

2023 年 1 月接受 pull request 的时刻，该软件的版权持有人变成多人，因此 Owen Young, Inc. 一旦发布该软件，就要受到 AGPL 3.0 的约束。任何从 Owen Young, Inc. 得到该软件的用户，都有权依 AGPL 3.0 第 6 节向 Owen Young, Inc. 请求源代码，并可以在 AGPL 3.0 的约束下使用它。依此条款我在 issue 里请求了 2023 年 1 月到 4 月所有版本的代码。

2023 年 4 月修改协议为专有协议很可能是非法行为，此时该软件已经有多名贡献者，除非有明确的版权赋予协议，否则 Owen Young, Inc. 无权以专有协议发布该软件（这是 AGPL 3.0 的限制）。

如果作者拒绝 issue 794 的请求，那么该软件是“假开源”，并且存在法律扶正（ remedy ）手段，即提起诉讼。当然我个人不会考虑追诉，因为这太耗费精力而且得不偿失。

[sloknyyz]

@geelaw 我不知道你说我的想当然是什么，指我想当然的认为仓库应该开源吗？我说了很多遍了，开不开源都无所谓，就算你用 GPL 协议不开源我都不在乎。如果你说的是我想当然的认为这个仓库是开源的，那你可以看看 134 楼我为什么想当然的认为这个仓库是开源的。我反感的是这种"假装开源"的行为，仓库明明没有源代码，却搞得一副开源的样子，利用大众的认为开源的是更好的心里，来骗 star ，做推广，骗小白。你可以说作者从来没说过项目是开源的，但就我来说，我发现我被骗了，我感觉很恶心。因为我也给别人推荐过这个插件，对别人说是开源的。

[geelaw]

@Pipecraft #158 我无法理解为什么在 trending 上就说明很多人认为它是开源的——主要原因是我不知道如何读心（知道别人是否认为这是开源项目）以及我没有统计数据支持。另外你可能要考虑一下，Pr[开源 | GitHub Trending] 和 Pr[开源 | GitHub] 之间是否有明显差异——GitHub Trending 上有很多项目是开源的，可能只是因为 GitHub 上有很多项目是开源的，或者开源项目比较吸引人，不代表非开源项目就不能上 GitHub Trending 。

>我提到“很多人”认为，这个说法没有问题吧？

请问这种理解有何依据？

我刚刚看了一下前 10 个，有 3 个都不是开源的：

https://github.com/bregman-arie/devops-exercises/blob/06976ddb5ddb1f0b979e0fd24286fa573a81645f/LICENSE
https://github.com/langgenius/dify/blob/e18211ffeadb1ddb475136e17176d401a8874d91/LICENSE
https://github.com/Ignitetechnologies/Mindmap/tree/452ac9eb22bb0f542cce048993eadb7597f8bd68

第一个不是软件，自然不能是开源，而且它的协议也不允许你“adapt”之，很可能无法达到“开源软件”迁移到其他类型工作上的标准。
第二个的协议有太多的限制，不是开源——即使你可以查看源代码，也不代表这就是开源软件。
第三个根本没有协议，自然不是开源。

[geelaw]

@sloknyyz #161

>如果你说的是我想当然的认为这个仓库是开源的，那你可以看看 134 楼我为什么想当然的认为这个仓库是开源的。

你可以查看我的其他回复，尤其是 #160 和那个仓库里的 issue 。

>我反感的是这种"假装开源"的行为，仓库明明没有源代码，却搞得一副开源的样子，利用大众的认为开源的是更好的心里，来骗 star ，做推广，骗小白。

这句话里面就有很多想当然和望文生义，最严重的就是我已经说过很多次的——“开源”和“可以查看源代码”是相当不同的概念，而且“开源”也不需要“源代码自动伴随着软件出现”。另外你为什么认为大众都认为“开源更好”呢？又为什么认为作者在“骗”呢？

>你可以说作者从来没说过项目是开源的，但就我来说，我发现我被骗了，我感觉很恶心。

或许没有人骗过你，是你自己想当然了？

>因为我也给别人推荐过这个插件，对别人说是开源的。

这听起来是你骗了别人。

[geelaw]

@geelaw #163 >这听起来是你骗了别人。

这是按照楼主的想法解读的（即归谬论证），我个人认为无意的错误论述并不是欺骗，在我看来“骗”需要故意。

[sloknyyz]

@geelaw 我说了是”假装开源”，还有我认为的开源就是要开放“核心源代码”，不是搞些乱七八糟的东西就可以说是开源。
你随便上网搜下“开源是什么”，基本上都是说要开放源代码。
如果你非要拿你认为的“开源”和“可以查看源代码”是相当不同的概念，而且“开源”也不需要“源代码自动伴随着软件出现”, 我只能说你有独特的见解好吧。

[Pipecraft]

@geelaw #162
> 另外你可能要考虑一下，Pr[开源 | GitHub Trending] 和 Pr[开源 | GitHub] 之间是否有明显差异

我觉得是有差异的。上面说过的，相对于非开源项目，人们为一个开源项目点 star 更容易，更慷慨。我可以随意浏览几个项目，如果是开源的，还不错，就会给 star ，然而闭源的，除非对我很有用，我不会轻易给 star 。我不知道这样是不是主流，如果是的话，闭源能上 GitHub Trending 应该是很难的，当然不是不可能。

>>我提到“很多人”认为，这个说法没有问题吧？

> 请问这种理解有何依据？
同上。

上面提到的 3 个 repo ，
第一个不是软件，不是代码，但它是多人协作的知识文档，允许人们贡献，免费拿走。人们给它 star ，我认为是与开源项目是相同的。
第二个 Apache License 2 上面加了一些限制，你觉得它是开源软件，但从 star 与 PR 数来看，我觉得很多人认为它是。给个 star 没必要扣那么仔细吧。
第三个，人家 Twitter 有 137.5K 粉丝，不停的在那里推广，repo 自然能有那么多 star ，能上 GitHub Trending 了。这与开源还是闭源没有关系了。这种难道不就是 GitHub 上面的毒瘤吗？它只是拿 GitHub 当文件托管所，得 star 获得更多人的信赖。

今天摸鱼时间到此为止。
再次声明，我认为闭源没有问题，GitHub 可以有闭源的。也可以有像上面第三种的，虽然恶心，但可以有。

[Pipecraft]

@Pipecraft #166
@geelaw #162
而且上面第三个项目，谁一眼看了都知道这个不是开源项目。与这个帖子的情况完全不同。

[geelaw]

@sloknyyz #165 很多人望文生义不代表望文生义就是正确的，如果你支持开源运动（当然，你无需支持开源运动），你应该选择 Open Source Initiative 的定义，我强调的定义就是 Open Source Initiative 的定义。我认为“开源”这个名字起得确实容易引人误解就是了。如果你希望自己定义“开源”的意思当然没问题，只是这就不是“开源运动”的“开源”了。

“开源”蕴涵着“源代码可以查看”，但是并不代表源代码一定要伴随着可执行软件一起发布——你似乎都没有尝试去请求源代码。此外可以查看源代码并不代表就是“开源”——“开源软件”赋予你更多权利。

@Pipecraft #166

>我可以随意浏览几个项目，如果是开源的，还不错，就会给 star ，然而闭源的，除非对我很有用，我不会轻易给 star 。我不知道这样是不是主流，如果是的话，闭源能上 GitHub Trending 应该是很难的，当然不是不可能。

你看，你也无法判断这是否是主流。

>第二个 Apache License 2 上面加了一些限制，你觉得它是开源软件，但从 star 与 PR 数来看，我觉得很多人认为它是。给个 star 没必要扣那么仔细吧。

是否“开源”不是你我可以“觉得”的。帮您 Google 一下，开源的定义是 https://opensource.org/osd/ 此外从 star 和 PR 数量并不能判定是否是开源，不开源的软件也可以贡献 PR ，只要作者开心就好了（ FSF 圣斗士肯定不会就是了，但普通人又不是 FSF 圣斗士）。

另外为什么 GitHub 不能当文件托管所呢？我认为这样做没什么 inherently 恶心的。

>而且上面第三个项目，谁一眼看了都知道这个不是开源项目。与这个帖子的情况完全不同。

如何确定“容易判定是否开源”的边界？我提出的判断方法是这样的：如果这个项目在 GitHub 上显示“有名字”的 license ，那我认为这个项目应该是开源；否则阅读 license 并判断。

[magicdawn]

@sloknyyz 没有开源, 何来假开源! 所谓开源不过是你自己的臆想

[a90120411]

@theowenyoung #93 挺好用，支持一波。

[sloknyyz]

@magicdawn 对啊，就是没开源，但是整个仓库装的和开源了一样，项目目录，star 贴图，我这种经常逛 github 的都被误导了，可想有多少小白不明就里的就 star 。这就是我所说的“假开源”，“假装开源”，OK ？懂了吗？如果还不能理解，那你就按照你自己想的 OK ？你觉得这种行为没问题，你直接说没问题就行了，OK ？我很反感这种操作，懂了吗？

[sloknyyz]

@geelaw
1. 很多人望文生义就是会导致意义的实际转变，这在语文中很常见，你自己去搜搜，文字是为人服务的，不是一成不变的。
2. 我就是开源运动的支持者，这种假装开源的行为我就是反感，作者能做，我也能说。
3. 你自己现在说了““开源”蕴涵着“源代码可以查看””， 我尝试了，我下载了仓库，但是仓库里除了一些乱七八糟的东西，没有源代码。如果你说的“尝试”还包括向作者联系索要，这算哪门子开源？你自己去看看 github 上的开源仓库，哪一个不是随便下载，随便看的。
4. license 是限制源代码的使用，代码都没有的仓库 license 有什么用？喜欢咬文嚼字可以，但不要本末倒置了，license 是为代码服务的，没有代码的仓库你把所有的 license 放进去也啥都不是。

[geelaw]

@sloknyyz #172

1. 技术词汇并不会流变。宣传“开源”的望文生义义很明显是阻碍开源运动的行为。
2. 如果连开源的定义都不知道，如何支持开源运动？
3. OSI 认为 GNU GPL 是开源协议，然后 GNU GPL 3.0 第六节明确表示提供软件的时候不需要伴随源代码，只要以几种允许的方式，让用户可以请求并得到即可。你所支持的开源运动和 OSI 所发起的不是同一个？
4. 你对开源运动达到其目的的方式有很大的误解，一个没有代码的仓库也可以用来发布开源软件，只要它的许可协议授予用户足够的权利就可以了。另外许可协议不但可以用来限制源代码的使用，也是让客户可以合法使用软件和它源代码的必备条件；没有许可协议，只有源代码的仓库，修改其源代码是侵犯版权的行为。

另外，在 issue 794 讨论中，我被人提醒：这个仓库应该理解为这个插件的分发、宣传网站的代码，而不是这个插件本身。

[saucer]

@nothingistrue 逆天，和你意见不同就是托

[RockShake]

确实后续的一些观点让我之前的认识有了一些刷新，我特地又去看了各种开源协议。但同时我也理解楼主的观点，项目本身的操作给了用户误导，建议直接在 Readme 中写明，避免误解。

同时新的库的 License 刚提交的时候也是 Mozilla 的 License ，后来又变成 AGPL ，到 4 月份改成商用 License ，这明显是不合规的操作。

[huiyifyj]

@windyboy #72
水还好，有些 star 是骗和偷出来
参考 https://www.v2ex.com/t/534800

[Nnq]

头次听说假开源

[sloknyyz]

@geelaw 我感觉从始至终你可能连我想说什么都不知道，我坚持的核心观点都是“这种没有代码的仓库却装作有代码的样子是很恶心的”
这更像一个道德问题，没有任何规定说不能这么做，但我就是觉得这种行为很恶心。
作者开不开源都无所谓，用什么 license 都无所谓，但不要恶心程序员, 他能这么做，我就能说出来。

[mercury233]

不如 Dism++官网写“开源是一种美德”但自己软件本体不开源（虽然他们开源出来的几个库看起来也挺强的）

[geelaw]

@sloknyyz 我的观点之一是您有错误的判断，认为作者在“装”这种判断在我看来没什么依据。您给我的观感是有很强的 entitlement 感。

[AItsuki]

我刚刚看了下项目确实没看出来是闭源的，有点恶心了

[skiy]

很多软件都是用 GitHub 作为 issue 收集工具，代码并不开源（国内外的项目都有），所以并不觉得用 GitHub 作为“存储”有什么关系。

另外，那个 old 项目是 MPL2 的，如果代码没有重大变更，依然是在此代码的基础上开发，按理不能再闭源的。但若是重构，应该可以闭源吧？而且，对比了下源项目和 old 项目，差别看起来还挺大的。

而且，标题的 10k star 的项目是，新开这个项目之后拿到的，并不是继承旧项目的 star 。可以说它“骗 star”，但是是那些 star 和 fork 的人自己的问题了。

---

另外，我有点好奇，一个基于 MPL 的空项目（即包含 MPL 协议文件），fork 之后，并且写了一个完整的项目，能不能闭源？如果不能闭源，那么可以新开一个项目，并且不包含那个 MPL 协议文件，这样可以吧？

[sloknyyz]

@geelaw 你认为我的判断没依据，你可以看看 134 楼，34 楼, 看看我有没有依据。
这些都是很明显的误导，诱导，客观事实摆在哪里，还非要说我没有依据。
如果这都不算依据，我不知道你说的依据, 到底是什么，到底什么才算依据。你来说说到底什么才能算“假装开源”的依据。

[xrr2016]

为什么代码放 Github 就一定要开源?

[Pionxzh]

用了好久，一直以为是开源的，不想多评价什么
唉 改用上面 V 友的版本了

[enpitsulin]

@sloknyyz #171 我觉得你的问题在于明明是自己错误的将别人的仓库当作开源仓库后，但是后来发现并不是开源产品而产生了恶意，并加之臆想觉得开源有所谓红利，吸引到了其他和你一样产生错误想法的人。

但实际上这个产品吸引到的用户绝大多数只是因为体验好，而其中一部分群体看到了有所属仓库顺便给的 star ，人家产品的成功恰恰是因为命中用户痛点还有体验确实比同类产品好，而不是你臆想中的开源红利。

你的一切评价 都是基于你个人的想法，比如"装作开源"、"误导小白"……,完全就是一个固执己见的程序员形象，为什么不去看看 chrome 应用商店有多少用户呢？我帮你看了 20k 用户 并且 edge 扩展商店和火狐这边都同样 10k ，这些人都是看到开源才使用吗？我只能说 你可能有点懂开源 但是完全不懂用户和产品

[dongguagua]

这不是很明显的假开源么？为什么还有很多人在那狡辩，说什么为什么放在 GitHub 上就一定要开源。拜托，这不是放不放在 GitHub 上的问题，这是误导消费者的问题。像 clash 、obsidian 、zed 、sublime 、reqable 、raycast 、orbstack 、fakelocation 等等等等，都是把 GitHub 当作 issue track 工具，这无可厚非，但人家只放一个 readme 啊。我不是没见过 GitHub 上的闭源软件，而且我认为闭源放在 GitHub 很正常。但你看他是怎么做的？把 nodejs 编译过的直接放上去，还有.gitignore ，makefile 。一个闭源的放这些有啥用呢？还有模有样地做 star history ，这不是欺骗消费者么？我看到这个仓库就感觉它是开源的，说明它完全知道消费者的心理，并且故意伪装成开源项目骗取信任感。这还有理了？

[sloknyyz]

@enpitsulin 我是不懂产品和用户，所以我只是从程序员的角度看，我觉得这种“没代码却装的有代码”的样子很恶心，
这是程序员中的毒瘤，作者能做，我就能说。你如果不是程序员，你无法理解很正常，我也没说要你一定
跟我观点相同，你觉得这种行为没问题就没问题， 你也不要义正言辞的说“我觉得你的问题在于明明是自己的错误”, 作者误导和诱导都是有判断依据的，你可以看看
134 楼和 34 楼，我这种经常逛 github 的都被骗了，我把这件事发出来说完全没问题。

[itechnology]

@dongguagua 我也觉得这已经算假开源了，不懂为什么回复里有几个人为啥会认为是 op 自己的问题。我第一眼看到他的目录结构就会认为这是开源的，相信有不少人会这么认为。这种让人误导的行为不是假开源是什么？

[sloknyyz]

@enpitsulin 你再看看 187 楼. 还是那句话，你觉得这种行为没问题就没问题。但我看着不爽，我就要说出来。

[enpitsulin]

@sloknyyz #188 评价可以，但是上来就是扣帽子人生攻击？而且你的评价体系只是你自己的凭什么代表程序员？先不说初期 tg 上完全可以参与源代码开发这算不算开源？为什么开源就是把源代码丢到一个代码托管平台才叫开源？什么叫装作有代码？放个目录结构就叫有代码？目录结构就代表一切？把所有源文件平铺到根目录提交就不是开源？
很多概念 @geelaw 都给你解释的清楚了，开源不等于把一个特定的目录结构+源码文件提交到一个代码托管平台才叫开源，再说的清楚点，我往 ftp 服务里丢个二进制文件 + README 写一个邮件地址说源码通过邮件自动回复获取也是开源，别拿你概念里的那种开源碰瓷了，真的很丢份

[enpitsulin]

@dongguagua 看到这个仓库就 **感觉** 它是开源的🤣

[shakukansp]

@enpitsulin 我觉得你搞错了一个问题

本身讨论的不是开源项目的定义

也不是程序员经过定睛一看能看出这个项目不是开源

一开始说的就是“不管是不是程序员一眼看过去这个项目像不像开源项目”

这和这个项目到底是不是开源项目是两码事

[shakukansp]

"我往 ftp 服务里丢个二进制文件 + README 写一个邮件地址说源码通过邮件自动回复获取也是开源"

那你是不是会把这句发邮件自动获取 一个井号 最大号加粗字写在 reame.md 的前几行呢

作者的 readme 中闭源是昨天看到帖子才加上去的，而且不再 readme 一眼看得到的位置

op 喷的点大致是如此。

反之其他关于这个仓库是否算假开源的讨论都不在点上

质疑的是仓库 owner 如此做的真实意图

这个帖子就是针对人的，而不是针对事的也不是针对仓库的

[enpitsulin]

@shakukansp "不管是不是程序员一眼看过去这个项目像不像开源项目" 意思就是:
"我"发现一款很优秀的产品因为看到了 github 页面"我"自己觉得是开源产品就心安理得的使用了，后来"我"才发现，这个所谓的"我"觉得的开源产品，它的 github 页面"我"一眼看过去不是开源的产品，但是"我"感觉被欺骗了，随之"我"跑到公共领域痛斥受到欺骗，给别人扣帽子，甚至人身攻击，"我"还要说"我" have a right to say anything
所有都是"我"的臆想，但是我就是要扣帽子人身攻击。
那你是对的

[shakukansp]

@enpitsulin 那我确实对

[shakukansp]

@enpitsulin 质疑就是质疑，你可以认为他表达的方式欠妥

但是质疑这个行为本身没有任何问题

[enpitsulin]

@shakukansp #194 先不说你觉得是 .md 就是 .md? 没见过纯文本 README ?

那 OP 在这恶意揣测他人意图然后发帖扣帽子+人身攻击，先不说这个产品有没有从一小部分人错误的理解为开源项目中获得所谓的开源红利，后面别人作者做出正面回应了，按要求补充写了不是开源项目，还在后面与别人争论自己臆想造成的误解，完全一副我特别有理的样子，是应该的吗？

[shakukansp]

@enpitsulin 是应该的

假如这个项目不是一个浏览器翻译扩展，而是一个 ssh shell
你猜这帖子会变成什么样

[enpitsulin]

@shakukansp #197 如果能证明这个产品确确实实受到了所谓的开源红利或者人家真的拿开源宣传了，质疑没问题，完全可以，但是我只看到了一个恶意揣测他人意图并扣帽子+人身攻击的人而不是做出合理质疑的人