I don't think we should officially sanction anything that does not have a functioning ASF PMC behind it. Anyone can fork any of our current or retired projects at any time. A newly constituted PMC can also vote to revive code from the attic. All of that is already possible. I think we should actually go in the opposite direction - making end of life assertions earlier and more consistently. That is what commercial software companies do and it makes it very clear what is supported and what is not. As many of us have said publicly and we said collectively to the US government, it is the responsibility of system owners to upgrade or replace end of life software in their systems. Giving false hope without an active PMC is a bad idea, IMO which could backfire badly for both the ASF and downstream users. The fact is that all software eventually reaches end of life and the responsible thing to do as a software producer is to make end of life statements clearly and as early as possible. The idea of "afterlife" is like paying for extended support for end of life commercial products - tends to end badly.
Note that all of the above applies to "product lines" such as foo x.y. The responsible thing to do, which Tomcat and others do well, is to announce EOL early and then retire the stuff that is no longer maintained. Again, this is exactly what commercial software companies do. Their decision is based on pretty much the same considerations as ours. There is no "afterlife." The Attic docs look clear and complete to me, including info on how to fork / revive or include code in another project. Phil On Thu, Apr 7, 2022 at 8:07 AM Dirk-Willem van Gulik <[email protected]> wrote: > We have the various conversations of what we can do better today with > regard to our vulnerability, release and supply-chain proceses. > > However, reading between de lines of the questions we get from the various > powers that be - and their emphasis on societies/civic infrastructure - I > think there is also a third area that we should tackle - what is the > afterlife of code. And for which we have little policy today. > > And that is for projects who are important to some; but have insufficient > volunteer capacity at the ASF to be responsibly maintained and released. > > I think that the setting / presumption here is (some of this we already > make explicit, some is implied but perhaps should be made explicit) is that: > > 1) An Apache release 'you can get' has gone through the usual > processes and is `fit for purpose' and meets a set of standards. > > 2) One of these is that the (latest) download contains no known > vulnerabilities -- or if they contain known (minor) issues - such is very > loudly called out in the release notes. > > If the ASF find that a project has losts it ability to maintain its > software responsibily (including responding to security issues; have > sufficient governance not dependent on one person, be under oversight of > the board/report as they should) then we move that project to the Attic > > The Apache Attic was created in November 2008 to provide process > and solutions to make it clear when an Apache project has reached its end > of life. Specifically to be: > > "responsible for the oversight of projects which otherwise would > not have oversight; and be it further ... is not authorized to actively > develop and release the projects under its oversight" > > (Quoting from https://attic.apache.org/). With a good set of trigger > rules. > > My proposal would be to add something extra here; namely the ability for > any interested party to 'take over' an attic process on a non-exclusive > basis. And it is entirely up to that party to self-fund, find volunteers, > etc, etc. So I think that just means a few extra process step and some form > of policy. > > Firstly I would suggest we add two process steps - namely that the > community -and- our general apache announce list (and/or a new legacy/attic > list) is to be informed pro-actively. > > Secondly - that we offer, for a period of 3 months, to bring any > interested party that contacts us in touch with any of the others if they > so desire. > > And finally - that we offer a non-exclusive license to the name (but > without the apache prefix), trademark and full provenance/code history; to > any party that wants to take over; provided they abide by the Apache > license. > > And that we will inform the existing community by our usual means (email, > a long term URL/redirect/etc). And that we will maintain the key > provenance data behind the code base (CCLAs, iCLAS, identity of the > committers) -and/or furnish them with some sort of blanket transfer > statement to the effect that the (code)history is complete and known up to > that date and `our responsibility'. > > With the option; e.g. after 1 or 2 years; for that new community to > petition the board for the actual trademarks, domain names and what not. > > So basically - we add an Afterlife option to the Attic which is outside > the ASF. And this is in addition to, of course, a normal fork of the attic > data under a new effort their own name. > > With kind regards, > > Dw. > > > > >
