I thought I'd cover some old ground for hopefully one last time - portability.
In the software as a service and cloud computing world, portability depends upon having access to ALL of the necessary data and an alternative provider. The are however three main issues to be considered with any alternative provider. First such a provider has to exist, secondly it has to interpret ALL the code and data you provide from the original service in the same way (interoperability) and lastly the process of switching has to be useable. Without all of this, portability is practically worthless to the vast majority of people.
This ideal of portability will only be practically achieved when multiple providers comply to a standard that is an open sourced implementation of the application or service to be provided. If we want to have competitive markets, avoidance of monopoly, portability between providers, minimisation of adoption fears, second sourcing options and limitation of risks then open source is the only answer.
Open standards (as in "open" APIs - a questionable term - and open formats) might be extremely helpful in providing access to data but they don't provide portability. As history teaches us, it's a delusion to believe they will. In the world of SaaS (Software as a Service), open standards could actually limit portability by enabling companies to describe themselves as being open without actually being so.
If you want portability in this future world of software services, then you need the service to be open sourced. This is what needs to be the standard.
However this isn't a problem because we're talking about a world where competition is based upon service rather than product. Such a world is based around thriving ecosystems of providers with portability between them. If you wish to build such an ecosystem, then you will need to minimise the barriers to participation, ensure portability between providers and at the same time maximum competition and the freedom for providers to make service improvements. Fortunately we have the perfect software license designed to do just that, it's called GPLv3.
GPLv3 allows for providers to take an open sourced environment, provide it as a service and modify it without releasing the improvements back to the community, hence allowing maximum competition or freedom for improvement. However the modified version cannot be released as a product which should minimise branching. By combining GPLv3 with trademarks and a compliance / assurance authority, it is also possible to ensure that this maximised freedom does not interfere with portability. You can achieve similar effects with more permissive licenses (Apache) by use of a compliance / assurance authority but the license, whilst good enough, is not ideal.
GPLv3 is the ideal license when mixed with a trademarked compliance / assurance authority for such services because it contains the "SaaS loophole" and hence allows for :-
GPLv3 is the ideal license when mixed with a trademarked compliance / assurance authority for such services because it contains the "SaaS loophole" and hence allows for :-
- Competition through operational efficiency on service (hence encouraging competition in the market)
- Limits differentiation on function through the compliance authority (hence maintaining portability)
- Limits alternative products (hence minimising forking to different standards)
An alternative to this approach is to use AGPL. It is often cited as fixing the "SaaS Loophole" as though that was something beneficial but in reality it has little or no relevance in this world. The license misguidedly enforces the release of all improvements back to the community which is likely to stop potential providers ever adopting and providing a service under this license. AGPL severely limits competition in return for little or no benefit. In my view it's a hangover from a product centric world.
It seems I'm not alone in this viewpoint. Ted and I both agree that the "SaaS Loophole" is a good thing. Ted asks a question of whether you could use trademarks and reputation in place of IP protectionism. In the software as a service world, the short answer is no. Trademarks and reputation could be used to ensure portability between providers but not IP protection of the code itself.
Is there a need for another license other than than AGPL or GPLv3? Personally, I believe the GPLv3 is the only license we need in this world. What we need more of today is a service mindset rather than a product one. I suspect that leap is one which will be too far for many companies.
-- additional note [27th Feb 2013]
It's five years on and I've changed my view ever so slightly on the above. The use of permissive licenses such as Apache can make it less problematic for some companies to adopt and hence it can be seen as more reasonable or pragmatic. It does run a greater risk of forking of the codebase and community with alternative proprietary versions.
Forking of the codebase is no bad thing when the changes are contributed back as it allows for experimentation. Forking of the community is what you want to avoid. In many cases a project which contains many contributing forks does appear less likely to fragment as a community and so this is beneficial. Hence the balance of power between less and more permissive licenses rests in whether this helps maintain or destabilise the community.
In practice I've seen permissive licenses run the risk of a collective prisoner dilema with different companies attempting to differentiate to the disadvantage of the whole. At the same time I've seen companies more willing to get involved with permissive licenses. Hence I tend to side with GPLv3 as the ideal license but accept a compromise of a more permissive license with a strong compliance / assurance group.
However, whilst I accept it, the reasoning above still stands for me. The dual nature of GPLv3 being permissive with services but restrictive on products was why I originally commented to Eben on the benefits of keeping the SaaS loophole. That hasn't changed.
-- additional note [27th Feb 2013]
It's five years on and I've changed my view ever so slightly on the above. The use of permissive licenses such as Apache can make it less problematic for some companies to adopt and hence it can be seen as more reasonable or pragmatic. It does run a greater risk of forking of the codebase and community with alternative proprietary versions.
Forking of the codebase is no bad thing when the changes are contributed back as it allows for experimentation. Forking of the community is what you want to avoid. In many cases a project which contains many contributing forks does appear less likely to fragment as a community and so this is beneficial. Hence the balance of power between less and more permissive licenses rests in whether this helps maintain or destabilise the community.
In practice I've seen permissive licenses run the risk of a collective prisoner dilema with different companies attempting to differentiate to the disadvantage of the whole. At the same time I've seen companies more willing to get involved with permissive licenses. Hence I tend to side with GPLv3 as the ideal license but accept a compromise of a more permissive license with a strong compliance / assurance group.
However, whilst I accept it, the reasoning above still stands for me. The dual nature of GPLv3 being permissive with services but restrictive on products was why I originally commented to Eben on the benefits of keeping the SaaS loophole. That hasn't changed.