The decision of releasing SeaClouds as open source was clear from the beginning of the project, based on commercial success of similar strategies as well as previous FP7 experiences in positioning post-project results for uptake.
The end-goal of this strategy is to foster an enabler for SeaClouds partners and stakeholders (both in supply and demand of cloud resources) to leverage the assets and achieve the potential impact of SeaClouds.
Regarding the specific type of open source licensing, certain criteria was needed:
- Cloud-Demand Open Source Interests: Application developers and service providers see the open source licensing as a mark of security-via-transparency community acceptance. Potential uptake of multi-cloud application management solutions that are based on SeaClouds components will benefit.
- Cloud-Supply Open Source Interests: Cloud providers will not only need an open source solution for potential integration of SeaClouds assets, but will need a liberal license such as Apache 2.0 to be able to freely modify these assets within their commercial licensed offerings. Although not necessary IaaS and PaaS providers, 3rd-party solution in cloud management or monitoring (e.g. Apache Brooklyn, RightScale, NewRelic, etc.) would have the same preference to freely create commercial opportunities with SeaClouds, whether integrated into a larger solution, or as a further developed standalone product. Similarly, standards bodies such as CAMP and TOSCA have similar requirements, as it is essentially a parallel channel that seeks cloud vendor adoption and would be greatly limited if held under a copy-left license.
The above criteria led the consortium to apply the Apache 2.0 license to all of its resulting components, allowing partners and stakeholders to use the software for any purpose, to modify it, and to potentially distribute modified versions of the software via commercial offerings, under the terms of the license, without concern for royalties, access-rights-for-use, or limitations of exploiting only specific components – all of which could act as adoption barriers.
The success of open source repositories such as GitHub, or incubators such as the Apache Foundation, have brought a new level of transparency expected from adopted solutions.
This transparency is best used at the beginning of development, and not as simply licensing foreground after closed development. Even if not contributing directly to the code, potential adopters track the transparency of the development roadmap as a measure of external validation, setting a context if SeaClouds’ is indeed a legit and secure solution via peer review and collaboration.
