The following discussion is based around legal issues, but is not legal advice and is not written by a lawyer or legal professional.
A significant factor in license strategy will be based on whether or not products from OSC sub-projects will be combined into larger works. If so, license compatibility is a significant issue. Generally, it is very difficult to combine licenses due to incompatible restrictions that they often have about derivative works, distribution, etc.
It is the recommendation of the OSC to utilize strong copyleft licenses, such as the GPL or AGPL for all community projects. The most important factor applied to this decision was that of the social mission of the organization. Because OSC has expressly chartered its community by stating its value that access to technology is key to development of communities and individuals around the world, many funders and/or contributors within the community may feel that their contributions are being “exploited” to some extent by those who would adapt the open source project and improve upon it for profit without also contributing back those changes to improve the upstream product. (Indeed, this risk may be a tax liability for certain types of non-profit organizations, and in certain jurisdictions.) Further, because of the service-based nature of many OSC projects, the AGPL is specifically recommended as it requires those who would make improvements upon the code (such as an implementing organization funding developers) to offer those changes back at the point where they “distribute” their derivative work by deploying it to a server. (Otherwise, such organizations would not necessarily have to distribute their changed source code if it is confined within their organization.) It is also noteworthy that some licenses, such as the Mozilla Public License (MPL), allow its code to be combined with and further licensed with GPL-licensed code, as long as the larger work is licensed under GPL.
In order to change the license of an open source project, it is typically necessary to get the permission of all copyright holders. Unless the project was operating under a Copyright Assignment Agreement (CAA) or some types of Copyright License Agreement (CLA) for contributors, this means you would have to go back to the project’s past contributors and get them to agree to the re-licensing. This effort is likely to take significant time and energy, and may prove unsuccessful. For this reason, moving multiple OSC projects into an organization like Apache Software Foundation (ASF) is unlikely to be successful because of an organization-wide requirement to use the Apache Public License (APL). For mentored small projects with only a few committers, however, it is worth attempting to relicense the code by getting permission from those copyright owners.
From an ease-of-implementation perspective, the path of least resistance is to host projects in an organization that allows any license approved by both the OSI and the FSF, who maintain the canonical “approved license” lists for the industry. However, the burden in this approach is mostly placed upon people who would like to contribute to multiple sub-projects within the community – they will need to be much more vigilant about checking licenses for each project and ensuring they commit their code with the proper license. Using multiple licenses is liable to create confusion for all but the most experienced contributors; projects should ensure they do not merge code with an improper license.
In summary, for mentored projects, OSC should begin by officially embracing the copyleft GPL & AGPL licenses, officially encourage their use as a default, and then accept other free & open source licenses on a case by case basis. During a project’s mentorship process, it should be evaluated on the practicality of switching to these licenses, either on a short term or longer term timeline. Should that not be possible or reasonable, other licenses can be considered, with preference first toward weak copyleft licenses, and then other permissive licenses.