On Thu, Apr 7, 2022 at 6:07 PM 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.

FWIW: I've always felt that the very fact that we DO have an attic is
a huge value add since it clearly signals something about a code base
-- mainly that it is abandoned by the community.

I do, however, agree that for an outsider it may not be as clearly
labeled "DANGER" as we would need.

> 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.

Agreed.

> 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.

Not sure I get what exactly is being proposed here.

> 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.

Hm. This may be the one on which a much more general feedback from the
membership would be warranted.

> 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.

Like the general direction -- not sold on the (tm) part (but would be
willing to discuss).

And speaking of discussions -- why is this on sec-discuss@ and not dev@attic ?

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to