= OpenVPN 2.4/3.x =

* Contributor license agreement (CLA)
 * This is required to get OpenVPN to Apple !AppStore and possibly other stores (Windows Marketplace?) due to their incompatibility with the AGPLv3 license
 * We need to minimize the scope of the agreement (see below)
 * Android contributor license agreements look fairly good and we can assume lots of legal expertise and resources have been thrown at them

* Permissing licensing
 * At this point it's not clear if use of a permissive license would fully negate the need for a CLA
 * BSD/Mit/Apache licenses
 * If OpenVPN 3.0 was released under a permissive license, there would be the risk that (big) companies might fork it, and we'd end up with tons of probably incompatible forks
  * One way to combat this potential fragmentation would be to standardize the OpenVPN protocol
  * There would be significant overhead in managing the standardization

* Minizing the scope of the CLA
 * This minimizes the risk of fragmentation, forks and loss of contributions
 * Maximize the possibility of extending OpenVPN using isolating APIs
  * Plugins and such would not be covered by the CLA
 * OpenVPN 2.x extension mechanisms
  * The plugin API
  * Management interface
  * SSL library abstraction
  * Platform support (isolated by #ifdefs
 * OpenVPN 3.x extension mechanisms
  * SSL library abstraction
  * ... and others
 * We could possibly split the server-side code from the client-side code, in which case only the client-side code would be covered by the CLA

* Public release date for OpenVPN 3.x codebase
 * There is an old tar.gz source packages available
 * James will try to release this in next couple of weeks

* Future of OpenVPN 2.x and 3.x
 * At this point moving to the AGPLv3-licensed OpenVPN 3.x codebase makes most sense, provided that the negative effect of the CLA is minimized 
 * We will need to keep 2.x around until 3.x is a (near) complete replacement for 2.x
  * This will probably mean releasing at least 2.4, and possibly 2.5