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

[sloknyyz]

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

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

[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 ）手段，即提起诉讼。当然我个人不会考虑追诉，因为这太耗费精力而且得不偿失。