Licensing choices dont exist in a vacuum, they are made with a business climate in mind. I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world. In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).
> I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world.
The anti-consulting provision in th Commons Clause license pretty clearly indicates that it's crafters do think that we are living in that world, and that (as numerous people have observed for at least a couple of decades) the advantage in that market with open source isn't necessarily with the developer but often with the entity with the most developed professional services organization and relationships.
> In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).
I don't think that's actually a problem, nor do I think that, to the extent it is a problem, the Commons Clause really addresses it in any general way. Software with such a clause ab initio simply would not get wide adoption in “the cloudy world” you refer to; what the Commons Clause aims to solve is the problem of ”how to capture revenue via technical lock-in after first building broad adoption through the attractiveness of open source when you as a development firm haven't developed the capacities that would leave you well positioned to capture associated services sales with open source”. But it doesn't seem all that likely to be successful in more than the short term, since it incorporates the main problems of classic proprietary software in the cloud domain.
