54 lines
2.4 KiB
Markdown
54 lines
2.4 KiB
Markdown
# Health of the Development Community
|
|
|
|
## Good License and Legal Requirements Choices
|
|
|
|
<a id="license-approved"></a>
|
|
Obviously, code that's not under a license that is both
|
|
[OSI approved](http://opensource.org/licenses/alphabetical) and is not
|
|
[approved by FSF as a Free Software license](http://www.gnu.org/licenses/license-list.html#SoftwareLicenses)
|
|
is completely useless to us.
|
|
|
|
<a id="gpl-compatible"></a>
|
|
It would also be quite preferable if the code were under a
|
|
[a license that FSF has determined is GPL-compatible](http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses),
|
|
so that code from GPL'd projects can be easily shared and GPL'd applications
|
|
can be built on top of anything we build. Code not under a GPL-compatible
|
|
license would face a high burden (i.e., the code would really have to be
|
|
absolutely wonderful in all other respects) to dictate such a license choice.
|
|
|
|
<a id="no-cla-for-profit"></a>
|
|
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.
|
|
|
|
## Developer Documentation and Community
|
|
|
|
<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.
|
|
|
|
<a id="dev-count"></a>
|
|
|
|
A project with just one or two active developers, or where all the current
|
|
developers appear to be employed by one company, has serious community health
|
|
issues. Building a community around such a codebase is an uphill battle. If
|
|
we build on such a project, we should be prepared to become the maintainer of
|
|
the project if we have to, since the company or few individuals could move on
|
|
with short notice.
|