已经 push 到托管服务的 commit ，客户通常难以控制何时删除——在 GitHub 里，即使 force push 之后某个 commit 已经不可达，使用 commit hash 依然可以访问未被删除的 commit （见 #3 的链接）。

最好的补救措施就是让错误提交的数据无意义。避免错误提交的方式，除了先写好 .gitignore 之外就是不要 git add .，而是复核修改之后再添加（我一般用 GUI 工具）。

如果你没有主动在 GoDaddy 操作说明你的账户被别人访问了。这个授权码一般在即将转出到另一个域名服务商的时候才请求，不想转的时候不需要也不应该知道，而且应该保持域名处于不可转移的锁定状态。

安装 Office 并使用 Word 的 component object model 可以实现批量 docx 转 pdf https://learn.microsoft.com/en-us/office/vba/api/word.document.exportasfixedformat

合并多个 PDF 可以用 LaTeX https://tex.stackexchange.com/questions/105589/insert-pdf-file-in-latex-document

@ntop #149 #386 :) cc @Livid

功利的原因是先进的技术是先用英语写出来的，哲学的原因是没有在这方面追求文化认同。

提升到先进生产力（自由软件、开源软件、科研都是某种先进生产力），我最近的实践是两者结合，写文章还是会用英文，在国内学校作报告会坚持用汉语。

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

当然不是，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 。