You are viewing a plain text version of this content. The canonical link for it is here.
Posted to security-discuss@community.apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 2022/04/07 15:07:21 UTC
Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
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.
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Mark J Cox <mj...@apache.org>.
On Thu, Apr 21, 2022 at 1:18 PM Jonathan Leitschuh <
jonathan.leitschuh@gmail.com> wrote:
> I did some polling of the community and it seems like a CVE to indicate
> that a project is no longer supported would be appreciated and appropriate.
>
> -
>
> https://twitter.com/jlleitschuh/status/1503422152028078082?s=21&t=K6iRHZ4asuBTyDf7JlQI4A
> -
>
> https://www.linkedin.com/posts/jonathan-leitschuh-94553661_log4shell-security-software-activity-6911695338818969600-iRnU?utm_source=linkedin_share&utm_medium=ios_app
>
> This could be done under "CWE-1104: Use of Unmaintained Third Party
> Components (4.6)"
>
At the moment the CVE rules would not allow this, so ASF or any CNA
couldn't today issue a CVE for "$Vendor $Product $Version is now EOL".
However it's definitely worth exploring as it solves many of the issues we
have with inconsistent (across vendors and event projects) on the handing
of vulnerabilities in EOL products. There's cons as well as pros though
and some things to think about (should this only be issued the first time
there is a CVE, otherwise you're potentially flagging something as a
security concern even though there are no reported issues, what about
projects that continue to provide updates for software beyond the vendors
own EOL - like Linux Distros for example). But the alternatives all have
pros and cons too. This is something we should bring up with the CVE
program. We are looking at creating a group for interfacing with
researchers such as yourself [1] and this would be a perfect thing to
discuss there; and if that group doesn't happen (or doesn't happen quickly)
we can raise it in one of the other working groups.
Mark
[1]
https://cve.mitre.org/community/board/meeting_summaries/30_March_2022.pdf
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Jonathan Leitschuh <jo...@gmail.com>.
I did some polling of the community and it seems like a CVE to indicate
that a project is no longer supported would be appreciated and appropriate.
-
https://twitter.com/jlleitschuh/status/1503422152028078082?s=21&t=K6iRHZ4asuBTyDf7JlQI4A
-
https://www.linkedin.com/posts/jonathan-leitschuh-94553661_log4shell-security-software-activity-6911695338818969600-iRnU?utm_source=linkedin_share&utm_medium=ios_app
This could be done under "CWE-1104: Use of Unmaintained Third Party
Components (4.6)"
Cheers,
Jonathan Leitschuh
On Sun, Apr 10, 2022 at 12:35 PM Mark Thomas <ma...@apache.org> wrote:
> On 10/04/2022 17:08, Dirk-Willem van Gulik wrote:
> >
> > On 10 Apr 2022, at 18:02, Mark Thomas <ma...@apache.org> wrote:
> >> On 07/04/2022 16:07, Dirk-Willem van Gulik wrote:
> >>
> >> <snip/>
> >>
> >>> 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.
> >>
> >> With my VP Brand hat on: -1
> >>
> >> There are various reasons why a project enters the attic. Whether to
> allow the name to be used is a decision that needs to be taken on a case by
> case basis. It isn't a situation where a general rule can be applied.
> >
> > Just to clarify/understand - you are also concerned about this from a
> brand perspective if the apache prefix (e.g. Apache FooBar) is removed as
> per the original proposal. So it is the ability to call it ‘FooBar’ ?
>
> Yes.
>
> > You would also be against licensing that (so it is not a transfer) on a
> non exclusive basis - perhaps with the insistence that they prefix it with
> something like; like ‘CivicFoundation FooBar’ ?
>
> Yes.
>
> I am against any general rule that says "We will always do XXX with the
> trademarks associated with a project that is moved to the attic.".
>
> This doesn't happen anywhere near often enough to expend the effort
> documenting a policy that covers a reasonable majority of the use cases.
>
> To date, the less than a handful of instances where this has happened
> have each been sufficiently different there is not sufficient data from
> which to extract some typical cases that we can address with a policy.
>
> I am happy to continue to look at requests on a case by case basis.
>
> >> <snip/>
> >>
> >>> 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.
> >>
> >> Again: -1
> >>
> >> We can't do this. At least not with out an awful lot of expensive legal
> hoop jumping. Trademarks are an asset. As a US charity it is legally
> complex to transfer one of our assets to another entity.
> >
> > Right - but the expenses I am not too concerned about - they can be
> covered by the receiving party - in the rare cases that we’d want such an
> exclusive transfer as opposed to the non-exclusive just ‘license’ case
> above.
>
> That depends on whether the receiving entity can afford the associated
> costs. In the few instances where the project name has continued in some
> form outside of the ASF, it is highly unlikely the associated entity
> could have afforded the associated legal fees had a trademark transfer
> been an option.
>
> >> We have had situations like this in the past. My aim as VP Brand is
> always to try and do whatever is in the best interest of the project
> community whether that community wants its home to be at the ASF or outside
> it.
> >
> > Right - but the issue is that we’ve lost the (nexus) of the community at
> the ASF - and there is some group of people outside it that wants to
> continue & build a new one — perhaps with different governance.
>
> Yes, this has happened before and - where appropriate - we have figured
> out a way for the name to continue to be used outside of the ASF.
>
> > As it is the latter that may likely be needed in the sort of cases where
> the software has become too core to society - yet no longer of interest to
> volunteer maintainers labouring under ASF governance.
>
> That isn't an issue. Anyone can always fork an ASF project. Whether they
> can use the name will depend on the circumstances and is something that
> we will continue to look at on a case by case basis.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
> --
Jonathan Leitschuh
OSS Security Researcher
Dan Kaminsky Fellowship @ Human Security
GitHub Star <https://stars.github.com/profiles/jlleitschuh/>
Twitter - JLLeitschuh <https://twitter.com/JLLeitschuh>
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Mark Thomas <ma...@apache.org>.
On 10/04/2022 17:08, Dirk-Willem van Gulik wrote:
>
> On 10 Apr 2022, at 18:02, Mark Thomas <ma...@apache.org> wrote:
>> On 07/04/2022 16:07, Dirk-Willem van Gulik wrote:
>>
>> <snip/>
>>
>>> 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.
>>
>> With my VP Brand hat on: -1
>>
>> There are various reasons why a project enters the attic. Whether to allow the name to be used is a decision that needs to be taken on a case by case basis. It isn't a situation where a general rule can be applied.
>
> Just to clarify/understand - you are also concerned about this from a brand perspective if the apache prefix (e.g. Apache FooBar) is removed as per the original proposal. So it is the ability to call it ‘FooBar’ ?
Yes.
> You would also be against licensing that (so it is not a transfer) on a non exclusive basis - perhaps with the insistence that they prefix it with something like; like ‘CivicFoundation FooBar’ ?
Yes.
I am against any general rule that says "We will always do XXX with the
trademarks associated with a project that is moved to the attic.".
This doesn't happen anywhere near often enough to expend the effort
documenting a policy that covers a reasonable majority of the use cases.
To date, the less than a handful of instances where this has happened
have each been sufficiently different there is not sufficient data from
which to extract some typical cases that we can address with a policy.
I am happy to continue to look at requests on a case by case basis.
>> <snip/>
>>
>>> 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.
>>
>> Again: -1
>>
>> We can't do this. At least not with out an awful lot of expensive legal hoop jumping. Trademarks are an asset. As a US charity it is legally complex to transfer one of our assets to another entity.
>
> Right - but the expenses I am not too concerned about - they can be covered by the receiving party - in the rare cases that we’d want such an exclusive transfer as opposed to the non-exclusive just ‘license’ case above.
That depends on whether the receiving entity can afford the associated
costs. In the few instances where the project name has continued in some
form outside of the ASF, it is highly unlikely the associated entity
could have afforded the associated legal fees had a trademark transfer
been an option.
>> We have had situations like this in the past. My aim as VP Brand is always to try and do whatever is in the best interest of the project community whether that community wants its home to be at the ASF or outside it.
>
> Right - but the issue is that we’ve lost the (nexus) of the community at the ASF - and there is some group of people outside it that wants to continue & build a new one — perhaps with different governance.
Yes, this has happened before and - where appropriate - we have figured
out a way for the name to continue to be used outside of the ASF.
> As it is the latter that may likely be needed in the sort of cases where the software has become too core to society - yet no longer of interest to volunteer maintainers labouring under ASF governance.
That isn't an issue. Anyone can always fork an ASF project. Whether they
can use the name will depend on the circumstances and is something that
we will continue to look at on a case by case basis.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 10 Apr 2022, at 18:02, Mark Thomas <ma...@apache.org> wrote:
> On 07/04/2022 16:07, Dirk-Willem van Gulik wrote:
>
> <snip/>
>
>> 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.
>
> With my VP Brand hat on: -1
>
> There are various reasons why a project enters the attic. Whether to allow the name to be used is a decision that needs to be taken on a case by case basis. It isn't a situation where a general rule can be applied.
Just to clarify/understand - you are also concerned about this from a brand perspective if the apache prefix (e.g. Apache FooBar) is removed as per the original proposal. So it is the ability to call it ‘FooBar’ ?
You would also be against licensing that (so it is not a transfer) on a non exclusive basis - perhaps with the insistence that they prefix it with something like; like ‘CivicFoundation FooBar’ ?
> <snip/>
>
>> 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.
>
> Again: -1
>
> We can't do this. At least not with out an awful lot of expensive legal hoop jumping. Trademarks are an asset. As a US charity it is legally complex to transfer one of our assets to another entity.
Right - but the expenses I am not too concerned about - they can be covered by the receiving party - in the rare cases that we’d want such an exclusive transfer as opposed to the non-exclusive just ‘license’ case above.
> We have had situations like this in the past. My aim as VP Brand is always to try and do whatever is in the best interest of the project community whether that community wants its home to be at the ASF or outside it.
Right - but the issue is that we’ve lost the (nexus) of the community at the ASF - and there is some group of people outside it that wants to continue & build a new one — perhaps with different governance.
As it is the latter that may likely be needed in the sort of cases where the software has become too core to society - yet no longer of interest to volunteer maintainers labouring under ASF governance.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Mark Thomas <ma...@apache.org>.
On 07/04/2022 16:07, Dirk-Willem van Gulik wrote:
<snip/>
> 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.
With my VP Brand hat on: -1
There are various reasons why a project enters the attic. Whether to
allow the name to be used is a decision that needs to be taken on a case
by case basis. It isn't a situation where a general rule can be applied.
<snip/>
> 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.
Again: -1
We can't do this. At least not with out an awful lot of expensive legal
hoop jumping. Trademarks are an asset. As a US charity it is legally
complex to transfer one of our assets to another entity.
We have had situations like this in the past. My aim as VP Brand is
always to try and do whatever is in the best interest of the project
community whether that community wants its home to be at the ASF or
outside it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 7 Apr 2022, at 18:02, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> And speaking of discussions -- why is this on sec-discuss@ and not dev@attic ?
Because I did not think of that :) -- seeing this more as a security and governance issue. But right you are. It should.
Will put a summary mail to dev@ and will CC that list in.
Dw
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Apr 7, 2022 at 6:07 PM Dirk-Willem van Gulik
<di...@webweaving.org> 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: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Mark J Cox <mj...@apache.org>.
I'm in agreement with Phil here. And if there is a community comes
together wanting to take over support of an Attic project (or even an EOL
version of a non-Attic project) then we should totally encourage that
inside of the ASF. This is totally a discussion to be having on the Attic
PMC list.
Where it touches security are the things we've highlighted in the
Brainstorm document. Firstly making sure we're absolutely clear to our
users what is EOL and what isn't. Secondly on the policy for assigning CVE
names to issues in EOL projects. This is harder, but in scope here.
So let's say Apache Porcupine is in the Attic. We get a report of a
security issue in it. But there might be no one left to determine if that
issue is real or not and do the initial investigation. To prepare a CVE
you really need to create reasonable quality information on versions
affected, mitigations, severity, and so on. Around half the issues that
are plausible-looking that get reported to ASF end up being non-issues
(either bugs with no security consequence, or fixed in some later version
already, or outside the threat model, or where the issue reporter didn't
understand something).
If you accept every report that comes in to an old project then it's still
not zero cost to our security team, there's still work has to be done on
every one. And, in the current climate, researchers want to collect CVE
like Pokemon for their resumes, for their third party bug bounties, and so
on, so if you allocate a CVE for every one I'd expect floods of low hanging
low severity issues reported to us in decade-old projects.
And vulnerability scanners rarely have metadata to report that versions
they detect are EOL - so you really need at least one CVE name per EOL
project just so companies get some notification that there are unfixed
vulnerabilities. It's almost like you need one CVE for "is EOL and has
unfixed vulnerabilities" perhaps even with a watermark "of highest severity
X".
I've been wondering how to solve this for a while for ASF. Rather than
rejecting reporters with their EOL issues we could redirect them and have
them post them somewhere public. That way anyone still using an EOL
product (say a Linux distro shipping in an Enterprise product) could still
hear about issues, assist in the investigation, help guide CVE issuance.
Perhaps for Attic issues it's a public security list @attic. For EOL
versions of non-Attic perhaps it's the dev list. That may also suit the
researcher who will get the credit (and may be careful to make sure they
post issues they've spent time looking at so they don't appear foolish in
public), provides a public reference that can be used in a subsequent CVE
request, etc.
Regards, Mark J Cox
ASF Security
On Fri, Apr 8, 2022 at 7:33 AM Giovanni Bechis <gi...@paclan.it> wrote:
> Absolutely agree here, we should list on our project's web pages
> which version are EOL (like httpd and other projects already do)
> and which one are supported in order to make it clear that we
> cannot provide support for old releases and to make
> users upgrade to more secure versions of our softwares.
>
> Giovanni
>
> On Thu, Apr 07, 2022 at 01:03:44PM -0700, Phil Steitz wrote:
> > 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 <
> dirkx@webweaving.org>
> > 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.
> > >
> > >
> > >
> > >
> > >
>
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Giovanni Bechis <gi...@paclan.it>.
Absolutely agree here, we should list on our project's web pages
which version are EOL (like httpd and other projects already do)
and which one are supported in order to make it clear that we
cannot provide support for old releases and to make
users upgrade to more secure versions of our softwares.
Giovanni
On Thu, Apr 07, 2022 at 01:03:44PM -0700, Phil Steitz wrote:
> 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 <di...@webweaving.org>
> 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.
> >
> >
> >
> >
> >
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by Phil Steitz <ph...@steitz.com>.
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 <di...@webweaving.org>
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.
>
>
>
>
>
Re: Life after Apache/Attic (Was: Request from the European Commission (Log4J fallout/improvements)
Posted by David Nalley <da...@gnsa.us>.
On Thu, Apr 7, 2022 at 11:07 AM Dirk-Willem van Gulik <di...@webweaving.org>
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.
>
>
>
>
>