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

@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 是版权持有人和“最终用户”（因此只能是自然人，而不是法人）之间的协议。另一个情况是，你在帮助另一个人安装此软件，那么你需要可以代表另一个人进入该协议（简单的答案：不要帮别人点“同意”）。

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

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

🤔️ Apple Store 的订单如何别人付款？有类似淘宝找人代付的功能？如果对方要访问你的 Apple ID 才能代付的话，可能目标是盗取 Apple ID 。

我听说康熙部首还是易烊千玺公关技巧事件。

不在电脑上，目测康熙部首

@vain #1 有来源吗？我看到的是“需要为……负责”而不是“犯有……罪行”，这是赔偿问题而不是定罪问题。我当时看到新闻的时候也很疑惑，不过查了一下资料意识到追诉期已经过了，或许就不再追究刑事责任了。

开源是一种软件开发模式，旨在切实构建强大、高质的软件。对开源的宣传基于功利主义。

如果单纯是觉得自己的项目可以对别人有用，那么并不需要开源也可以分享。

如果你认为和开源相关的某项事物是文化，那么你可能想说的是一种政治理念、一种价值观念，它叫做“自由”，此时应该用“自由软件”而不是“开源软件”。

关于开源和自由软件的区别，请参考 FSF 的文章。

Disclaimer 之：我不是开源运动和自由软件的拥趸，虽然我认同他们的一些想法。

Explorer 查看到的文件类型来自于注册表，内部数据已经是 UTF-16 LE ，这说明设置文件关联的程序没能正确储存文件类型的显示名。

目前 .txt 的文件关联是哪个程序？

我记得食品安全问题赔偿既可以向销售方索取也可以向生产方索取，这一条款的目的是防止销售方和生产方踢皮球。至于销售方和生产方代表都在受害者面前，受害者是否有权利选择任意一个，而不是向前两者协商好的代表，索赔，我不知道是否有相关要求。

销售方和生产方的协议（谁支付赔偿）不影响受害者的权利，到底是销售方还是生产方（最终）支付，无需告知受害者。

我不太理解楼主为什么认为“第三方柜员”要赔偿的意思是她个人赔偿，从楼主的描述，我自然的想法是她是“第三方”的代表，获得的赔偿来自中间经销商，至于中间经销商和生产方、最终销售方如何分配（最终）赔偿责任，那是他们自己的问题。

关键词是 federated sign-in, federated identity

把内容写在邮件里，或者把文件作为附件发送，就表明放弃了追踪的能力，这项选择也是对收件人的信号——收件人现在可以确认自己是否查看邮件内容和附件是自己的隐私。破坏这种契约不可取。

建议和自己和解、和 GUI 和解，或者 https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging

技术无阻碍不代表合法

@kumiko #26 通常来说支票入账只需要 1 工作日。支票扣款的账户所有人可以在账单邮寄后 30 天内确认支票是否是伪造（从支票扣款开始，最长有 60 多天的时间），而且实际操作中（只要支付支票的银行愿意）不一定限于 30 天。

让第三人做中间收款付款的操作都很坑，因为这为第三人引入了风险。