On Thu, Apr 7, 2022 at 11: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. > So, the trademarks are an asset (and one of our larger asset classes from a valuation perspective). As a public benefit charity, we have some restrictions on how we dispose of assets, and essentially we can't give them away unless it's to another charity. The only way we can dispose of artifacts outside of that, is to sell the asset for fair market value. I know that's not the situation you're proposing - you're offering a non-exclusive license to the name - but allowing anyone to use the trademark effectively is giving away the asset (short of us enforcing quality standards) Also - I'll note that you can abide by the terms of ALv2 and still make things proprietary because ALv2 supports sub-licensing. > > 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'. > Unfortunately our brands get a high degree of attraction and are pretty tightly coupled with the Apache brand. This feels like a risk to the Foundation's reputation. People who 1) Don't or can't build a community at Apache AND 2) want to go off somewhere else to build something with no oversight/governance/quality guarantees already have a method available. They can take the code today, adopt a new name and deliver things. We should not make our users/consumers have any doubt of what they are getting when it comes to one of our products, or what used to be one of our products. > > 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. > > > > >
