[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DKFIUARAP211.1Z3GE57JB9DYK@redcoat.dev>
Date: Mon, 03 Aug 2026 19:31:12 +0100
From: "Emily Shepherd" <emily@...coat.dev>
To: <oss-security@...ts.openwall.com>
Subject: Re: Some Changes to GNOME Security Tracking
On Mon Aug 3, 2026 at 5:33 PM BST, David A. Wheeler wrote:
> Please allow me to point you to the actual announcement & project
> page, which explains what is *actually* going on instead.
>
> The Akrites announcement here:
> https://www.linuxfoundation.org/press/linux-foundation-and-industry-leaders-launch-akrites-to-defend-critical-open-source-software-against-ai-enabled-cyber-threats
> instead says, "Bug fixes flow back into each project’s original home, on maintainers’ terms. Where a critical package HAS NO ACTIVE MAINTAINER [emphasis mine], Akrites will serve as maintainer of last resort so fixes to the latest version reach everyone in a timely fashion."
>
> Note that the "last resort" ONLY applies when there is NO active
> maintainer.
Whether a project is actively maintained or not does not change its
licence and retained copyright rights.
The point referenced by the pkgconfig example clearly points out that a
licence may allow forks and subordinate works to be created (as
pkgconfig does) but may well not grant others to use the project name or
pass of subordinate forks *as the project*. In the pkgconfig example,
their licence would quite explicitly not allow that.
I fail to see how an organisation unilaterally declaring themselves a
maintainer of last resort, regardless of what the project licence says,
is going to work out well. The intentions may be noble, but copyright
doesn't care about intention, it cares about what the licence says.
In this age of AI, the industry as a whole appears to be suffering a
severe case of collective amnesia over the fact that the people who make
a creative work get to decide how that creative work is used or amended.
Emily
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
