当然不是，app 就是 application software 的意思，九十年代出生的人从来没听说过（应用）软件必须提供隐私声明的。

@sloknyyz #172

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

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

@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 并判断。

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

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

@sloknyyz #161

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

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

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

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

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

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

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

这听起来是你骗了别人。

@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

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