随笔

⚠️ 免责声明

这是一篇我关于著作权和版权的个人研究，内容未必准确，并非法律建议。

最近和一位小伙伴聊起了一个很有意思的版权问题：如果一个作品本身已经进入了公有领域（比如某国发表超过 50 年的单位作品），但它的「现代扫描件」还不到 50 年，那么直接使用这个扫描件，或者基于这个扫描件获取知识，算不算侵权？

我的观点是这样的：如果直接拿着这个高清扫描件去商用或分发，可能会存在侵权风险；但是，如果你只是提取了扫描件里传递的「知识」（也就是原本那份 50 年前的公有领域作品的内容），并且在自己的创作中没有照搬扫描件独有的特性（比如扫描者加的水印、特定的色彩修复等），那么应该认为这一作品是派生自已经进入公有领域的知识，而非受著作权保护的该知识的这种表现形式，因而并不构成侵权。

打个比方：如果有人拍了一张 17 世纪世界名画的高清照片，我看着这张照片，临摹了一幅仿制画。我认为我并没有侵犯摄影师的版权。除非我连摄影师独特的打光、其独特的拍摄角度，甚至照片上的噪点纹理也都一起画进去了。

今天，结合美国和世界各国的著作权处理原则，水一篇关于版权边界的思考。当然，本人并非法律专业，虽然工作中经常需要和授权许可打交道，但这些仅仅是个人理解，并非法律建议。

随着年龄的增长，我已经不怎么正经玩游戏了，不过由于独立日这段时间有两个星期只有我自己在家，加上最近在 YouTube 上看到了游戏中第三章男女主酒吧对手戏的片段感觉制作相当不错，所以在 Steam 上买了一份。

情感反诈模拟器（原名「捞女游戏」）是一款真人互动式影游，其剧情画面是活的演员预先录制而非即时渲染。这种形式有点类似于九十年代出现的互动式DVD（DVDi），不过看起来分支可以比那时复杂许多，甚至可以加入一些业务逻辑。这个游戏本身看起来是用 Electron 实现的，对代码做了少许混淆（bytenode），在运行过程中大部分时间实际上是在播放影像。早期版本曾经可以直接在游戏启动器（使用的是明文的 JavaScript）中暴力注入一段启用远程调试的代码，从而用一个单独的浏览器就可以调试游戏了，后来更新的版本中游戏制作者将入口堵住了🤣。不过，这个游戏吸引我的并不是它采用的技术，所以关于技术的讨论到此为止。

🚨 警告

以下内容可能包含剧透，并且可能涉及不适合未成年人观看的内容，请仔细斟酌是否要继续阅读。

转载自 khsing 今天在 python-cn 发表的公告。

我本人早年也曾经参与过啄木鸟社区的维护，在此特别声明，我与现在的这个 woodpecker.org.cn 没有任何关系。

除此之外，本人之前在啄木鸟社区发表的内容采用的是 CC BY-NC-SA 1.0 许可，从未授权商业使用，本人保留在法律许可范围内向目前域名的所有者，以及在美国境内为其提供网络服务的供应商进行追索的权力。

今年二月的时候，我发过一个段子：

「你是什么时候意识到自己可能需要休假了？」

「有一天我临睡前在家里的票务系统里给自己开了票，要求在家里的DNS域上添加 staging，preprod 等几个子域来符合最佳实践，然后在第二天醒来以后看到系统发出的今日待办事宜邮件的时候。」

段子归段子，我认为搭起票务系统是我在疫情期间干的最改善生活品质的一件事了。这里分享一下我的一些个人经验。

为什么你有可能会需要一套票务系统？或者说，票务系统能帮我干什么？

事务追踪系统，或者，由于其中的事务往往也被称作「票」（ticket），我个人也常戏称为票务系统，在成规模的团队软件开发中是经常使用的一种工具。票务系统可以记录开发期间的各类任务，将任务分解成多个可操作的子任务、为这些任务排列优先级，并将其分配给具体的人。对任何工作而言，将工作拆解到较为具体的、可以由一个人完成，并且具有优先级和依赖关系属性的子任务，都有助于帮助人们迅速、高效地完成工作。

在工作中我个人也很喜欢使用事务追踪系统来跟踪一些开发以外的事务性活动，并且将事务追踪系统作为一种类似笔记的工具使用，在「票」中关联一系列相关文档，这有助于在事后总结经验或将重复性的事务性工作整理成更容易使用的形式（例如作弊条文档，或是将常用的重复部分变成程序等等）。

上回书 说到留言板的问题时提到留言板当时没有解决，在文内的模板中可以看到我当时是采用了一种非常对付的方法：直接将之前的评论直接作为文章内容输出出来。这导致了页面不太美观。

趁着周末我把之前 Movable Type 的数据库重新捋了一下，把其中的 2256 条留言用类似 isso迁移时的方法转换成了 json，然后就可以在 remark42 中导入了。中国有句俗话叫三搬一火，意思是搬三次家大约等于失一次火，这次留言内容搬家我也丢掉了一些东西：Remark42 的一项设计理念便是尽量不保存可以追踪用户的数据，例如用户的 E-mail 在 Remark42中只会保存一个与之对应的 SHA1，对于网站的主人来说，这意味着他们不能直接从这些保存的数据中获得用户的 E-mail 地址（当然，实际情况中，这类单向函数并不能阻止他们在知道这些信息的情况下验证某个 SHA1是不是某个 E-mail 地址，但总归这要比把数据存在数据库里安全得多），因此这个迁移过程也就意味着所有相关的明文数据消失了。除此之外，Movable Type还保存了许多类似于用户网站地址这样的信息，我在转换时考虑了一下，由于许多人的网站都已经不在了，迁移的意义不太大，因此最终决定不迁移这些数据了。

考虑到现在还在用 Movable Type 的人应该已经没有几个了，我感觉我的方法可能对其他人没有太大的参考意义，这里只是简单做个记录。代码写的比较乱，就不拿出来丢人了。

这几天收到了几次来自 Facebook 的通知，第一次是 “Request for Information/Action” （最早申请时还没有 Privacy Policy，但后来补上了），但过了几天之后系统表示无法完成compliance review，并直接禁用了该 App。

Telegram 最近宣布了其订阅付费计划。说起来我也不是特别信任其安全/隐私方面的特性(*)，不过作为一个跨平台即时通讯软件来说，其在不同平台上的功能基本上做到了完全一致，并且在这个礼崩乐坏 的时代，能够在不同平台上都做到不狂吃CPU/内存，在不同平台上的界面行为上高度一致，并且完全没有各种令人抓狂的智障设计（举例来说：随便干什么事情都弄个二维码还非让你扫描一下借此获得摄像头权限、多机登录时以手机为主并且时不时就得再扫描一次二维码、完全无法回溯的会话引用、没头没脑地给一条「有人@你」的通知，却无法迅速定位到消息等等），并且公开客户端源代码以便第三方进行代码审计，确实是十分难得的。

我觉得这事必须得记一笔。

去年9月的时候，我和张师傅在 eBay 上团购了两台 Juniper NFX250-S2。昨天周师傅问我当时付了多少钱，于是我就打开了浏览器准备去 eBay查一下交易记录。

诶？右上角那是啥？使用 Gmail 账户登录？这比他们自己那个 2FA 实现好多了啊，我于是想都没想就点了一下。

上个月初带娃去佛罗里达那边休假，在机场租了辆车。这次的租车公司相当先进，完全不需要去排队或是在租车公司的触摸屏上再次确认，直接在手机应用中确认之后，系统就直接给出了车的位置、型号（Ford Mustang），直接过去开门上车就可以出发了。

开始导航，一会谷歌地图显示去目的地基韦斯特 (Key West) 岛发生了大堵车。

「这题我会」，我想，顺手掏出了另一部手机上的苹果地图导航，发现果然也是出现了堵车。

此地是自古华山一条路，如果桥上发生事故，堵车实属正常。正想着，谷歌地图通知我说您稍微绕一下可以节省四个小时。「太及时了！」看到堵车地点位于罗纳德里根收费公路附近，我毫不犹豫地跟随指示朝西开去。

走着走着，车的胎压报警突然亮了起来，配合了一段文字：「胎压传感器故障（Tire pressure sensor fault） 」。这一路上估计车速会比较快，我不敢怠慢，赶快找了附近的一家加油站下车检查。先是目测，发现轮胎没有显著的变扁，用手使劲按压也没发现什么问题，于是到气泵处拿气泵带的压力表测了一下，发现胎压完全正常。

最近一段时间 Twitter 上开始流行了一个字谜游戏 Wordle，与此同时也出现了许多与之类似的游戏比如 拼音猜成语 等等。基本上，这类游戏要求玩家根据一些有限的信息（目前的这些实现通常是会告诉他们是否有字母猜对了，或是字母存在但位置不对等等）来推测可能的结论。