This is a great outcome. The point that Dieu raised about anyone in the community being able to step in to become the maintainer of a CFF project when an existing project's committers want to move the code to the attic is exactly the right way for everyone to think about how the community should be operating!
The TL;DR part is above... below is more background for future situations. Feel free to ignore this part if you don't care about questions if intellectual property management.
Dieu's point about moving a project out of the CFF managed orgs is important. The CFF itself as a non-profit corporation is here for the entire community's benefit primarily as a place to share intellectual property (amongst other functions). In order to protect the community, our bylaws require that the board of directors approve any asset transfers (which includes intellectual property, like copyrights). In practice this has meant that we have avoided moving repos from a CFF managed GH org to any other GH org. This has, in the past, resulted in a move to the attic and then a fork from that attic copy for the code to evolve elsewhere.
In digging deeper into that scenario, there is (were we to ever want to do something like move a repo to a non-CFF org) an approach we *can* use that would allow issue / PR history to be retained. Essentially, the CFF won't "dispose" of the copyright held on the collective work (this is the term used when a CLA assigns rights to contributions, then an org copyrights the whole codebase). However, we license that collective work to the public via the ASLv2. In doing so, we are licensing forks to use and modify the code in any way a person or company would want. That means someone can fork a CFF project and continue development in a new direction. To make this easier in cases where we might want to help that fork become the canonical home of the code long term, we can (1) modify the CFF version's NOTICE file to note an end date to the CFF copyright, (2) fork the repo into the attic (so that we have a retained copy), and then (3) *move* the repo to the intended target (which lets a non-CFF community continue work).
Things do get much more complex when a project has a name, which is considered a trademark. I won't get into that scenario here though... that's for another time.
All that said, no reason to not continue developing the repos in question as CFF projects if there is someone willing to do so.
Thanks Dr. Nic!
Chip Childers
Executive Director
Cloud Foundry Foundation
