@leo_song 我认为就像可维修权，应当立法硬件厂商必须在设备发布后一定时间内（如两年）提供软件支持。如果在此期间因为倒闭等原因做不到、超过法定期限后停止软件支持，就应开源有关代码。
@fulkrum 事实上他们确实支持了一定年限，但我们都知道这些旧设备实际能工作的年限远远更长。我看了半天，总觉得矛头应该指向Linux内核。
@fulkrum@qoto.org @leo_song@mastodon.social Project Treble 确实给老设备更新带来了便利，但只有 4 个版本的支持周期又导致了新的问题 —— SoC 厂商一旦发布某个 SoC 以后就再也不会更新其 HAL 实现的接口版本。如果你新购买的设备使用了一年前的 SoC, 那么你实际上最多只能享受到这 4 个大版本支持周期中的 3 个大版本。而这些所谓的“新的” HAL 接口版本往往只是非常小的改动，比如 modem HAL 里加上专门关闭 2G/3G 支持的接口，然而就连这样的改动也会导致更老的接口版本失去支持。如果这些 HAL 开源的话，更新到这些新的接口最多只是一两行代码的改动而已。
@fulkrum@qoto.org @leo_song@mastodon.social 注意这里讨论的都是 Android 用户态意义上的“驱动”，而不是内核驱动。这些驱动失去支持的速度比 LTS 内核要快不知多少倍。
🏳️⚧️
@fulkrum @leo_song 但是代价就是被白嫖，都想着用，没人想着贡献上游。那些使用 BSD 的商业公司给 BSD 项目提供的人力和资金还不如微软多（可以去看 FreeBSD 基金会的财报和 FreeBSD 的提交历史）。
@coelacanthus @leo_song 我有两点看法。
自由软件项目的发展局面好坏，时势、项目在业界的地位或者说「生态」比GPL与否重要得多。人们常以BSD系统半死不活、商业公司反馈代码少证明GPL之于Linux地位的重要性，这是常见的误区（myth）。许可影响确实有，但真正重要的是专利纠纷让386BSD错过了x86个人机飞速发展的几年，等诉讼结束Linux这架纸飞机已经上天拉客了。今天在FSF外，你会更多见到MIT等非GPL协议，LLVM、Python……没人担心代码反馈率，只有厂商自己担心闭源分支能否持续维护。扯远些，语言设计同理，Julia再好也卖不过114514种Numpy兼容实现。
此外，我们应该正视商业社会需要闭源这一现实，逃避这点只会带来更多的麻烦，往往也无益于获取更多的自由。你以为GPL能倒逼硬件厂公开驱动，最后得到的就是加上隔离层的闭源驱动，同时用户体验极差。相比这样互相折磨，或许不如走立法途径，可维修权运动珠玉在前。比如规定产品发售若干年后，应公开必要的资料和代码，以资维护。这部分观点政治意味浓些，不过说到底自由软件运动本就是场政治运动。
@fulkrum@qoto.org @leo_song@mastodon.social 在 Android 的语境下，设备支持周期和内核的关系真的不太大。Android 的所谓 "Linux" 内核本来就和 mainline 差别巨大，而 Android 本身并不那么依赖更新的内核（除了近期的 BPF/eBPF 要求以外）。Android 设备的更新问题是 Google 自己的 HAL 层造成的，因为很长时间这一层连稳定的 API 都没有（甚至都不用谈 ABI）。等有了 Project Treble 稳定 API/ABI 以后，Google 又主动 deprecate 所有大于 4 个版本之前的 API/ABI。