data does, so I think it's tough to do it as a list of questions.

### Evaluation of the [[Storage API|UseCases/StorageAPI]]

FIXME: This is assessment of what the API for storing the accounting data

does, so I think it's tough to do it as a list of questions.

### Evaluation of the [[Community Health|UseCases/CommunityHealth]]

- Is the [[license both determined as Free Software by FSF and OSI-approved|USeCases/CommunityHealth#license-approved]]?

- Is the [[license GPL-compatible||UseCases/CommunityHealth#gpl-compatible]]?

- Does the project

  [[require assignment of copyright or a CLA to get code upstreamed|UseCases/CommunityHealth#no-cla-for-profit]]?

- Is there good [[developer documentation|UseCases/CommunityHealth#dev-docs]]?

- How easy it to [[engage as a developer with the community|UseCases/CommunityHealth#dev-welcoming]]?

If the project has a CLA other than inbound=outbound, or has copyright

assignment, the beneficiary has to be a 501(c)(3) non-profit, as non-profit

contributors may not be legally permitted to give away code assets to a

for-profit entity or an entity with a different tax status.

Even for 501(c)(3)'s requesting a CLA or copyright assignment, there would

need to be a confirmation that the missions of the orgs were sufficiently

aligned.

Given that the project is going to solicit support and contributions from

501(c)(3)'s, this issue is particularly important.

<a id="dev-docs"></a>

The right choice has to have an accessible codebase.  Since no accounting

package yet deals with the issues specific to non-profit organizations, this

project will have to focus on bringing developers *to* the new project.

<a id="dev-welcoming"></a>

As such, the codebase needs to be accessible.  Communication with the

core developers should be possible and interactive.  The project should

be willing to accept new contributors who might want to make substantial

changes to the codebase.