摘要

  • GIMP 于 2013 年把 Windows 安装包的主要下载地点迁至自有服务器，但旧网页上的链接仍指向 SourceForge。
  • SourceForge 把旧 GIMP-Win 项目页改为由自己管理的镜像，并于 2015 年 5 月在少数镜像项目试用附带第三方软件的下载器。GIMP 表示，自己的安装包被包进未经许可的下载器。
  • SourceForge 于 5 月 27 日结束测试，6 月 18 日移除未与原开发者共同维护的镜像，且为上游网站已停运的情况保留例外；它称被移除镜像的流量已转向项目正式网站。

一条旧链接，两份下载决定

网站搬走，路标却还钉在原处。GIMP 的 Windows 安装包就是这样进入 2015 年的争议。

GIMP 说，它在 2013 年 11 月把 Windows 安装包的主要分发地点移到 download.gimp.org。多年累积的网页链接不可能随之整齐改写。为了让循旧址而来的用户仍能找到文件，项目继续把安装包留在 SourceForge。旧页面因此没有随迁移失去作用：它仍是一些人抵达软件的入口。

入口由谁管理，便成了下一步的关键。2015 年 5 月 27 日，GIMP 公告称，其 Windows 安装包维护者已无法管理 SourceForge 上的项目页；循该路径下载的用户得到的，是一个会带入其他软件的小型安装器。GIMP 随后的正式声明说，SourceForge 在项目文件外加上自己的下载器，既未告知项目，也未取得同意。项目担心的并非下载按钮是否够醒目，而是按钮后面的文件由谁决定。

SourceForge 当天给出另一套叙述。它说 GIMP-Win 项目页于 2004 年 10 月注册，原作者 2013 年已停止用它分发新安装包。托管方据此把页面改成从别处分发版本的镜像，并把管理权改到自己手中。SourceForge 称页面的镜像身份会被明确标示，原始下载始终可用；其 5 月 28 日更新说，GIMP-Win 镜像下载已不再附带其他软件的推广内容。

双方对于一件事没有分歧：旧页面的管理权已经转到 SourceForge。争执发生在这项管理权的边界。SourceForge 把一个不再由原作者维护的托管条目称为“弃用”，并认为镜像有助于用户取得当前版本。GIMP 则仍在开发和发布软件，只是已把正式下载地点迁走。一个旧托管条目的状态，不能自动替活跃项目决定用户该收到怎样的安装器。

托管方能保留文件，也能占住门口

GIMP 的要求具体到 HTTP 行为。正式声明要求托管网站允许项目删除页面和文件，不再另建替代镜像，并将旧地址用永久 301 重定向导向项目选定的位置。项目要的不是让 SourceForge 把附加软件先撤掉、隔日再谈，而是获得处理旧入口的最后决定权。对一个仍被大量旧链接指向的地址，重定向本身就是分发权。

SourceForge 先收回了附加内容的做法。6 月 1 日，它宣布已停止在未维护的项目上展示第三方软件推广，之后只会对开发者明确同意的项目，或本来就自行捆绑此类内容的项目展示。它仍主张镜像有保存旧版本和让用户取得软件的价值。至此，两个问题被拆开：镜像能否保存文件，以及镜像能否把自己的商业下载步骤放到文件前面。

6 月 18 日的公告又改变了镜像本身的规则。SourceForge 称，它曾在五个镜像项目短期测试第三方推广，测试于 5 月 27 日结束。6 月 17 日，其镜像目录有 295 个项目；这个数字是镜像项目数，绝非 295 个附带软件的安装器。它说，凡未与至少一名原开发者共同维护的镜像，已于次日移除，上游网站停运者除外。被移除镜像的访问流量则转往软件正式网站。管理者是否得到原开发者参与，终于成为分发决定的一条边界。

2016 年 2 月，SourceForge 新业主又宣布结束 DevShare 计划。该计划为参与项目提供捆绑式安装器。新业主说，结束计划是重建用户信任的第一步。这是后来对更广泛业务模式的处理，不能倒写成 2015 年五月那五个镜像项目的即时结果。

双方公开材料没有逐个旧网址的转向日志，也没有涵盖测试期间每一次 GIMP-Win 下载的安装包哈希；要确认某一用户实际收到了哪份文件，需要这些记录。现有原始声明已经勾勒出冲突：软件作者换了发布地址，旧链接却继续召唤用户；掌握旧页面的托管方可以改变用户抵达文件前经过的步骤。

软件项目可以离开一台服务器，旧链接却不会主动办理离职手续。GIMP 要求的 301 重定向，正是替这些链接补上去向。SourceForge 6 月的调整把部分旧流量送回项目正式网站。那场争执留下的问题很直白：当一个项目搬家，留在原址的招牌究竟该继续替房东揽客，还是负责把人带到新门口？

来源