I'm on the fence with this one. My definite preference would be to enable the SSL libraries on the all versions, so that we can use proper security and access web services that require SSL - I suspect the need for this function to grow rapidly as more and more web services move over to tighter security models - the right balance of openness and incentive to upgrade would be include ssl in the free versions but easy stack level encryption in paid models.
This debate is parallel to the debate between different types of open source license - GPL or more liberal licenses like MIT. In this debate there is a trade off between encouraging businesses to adopt, and encouraging code to flow back to the community. In this context RunRev are using features of the engine to do the equivalent of what the GPL / MIT licenses do - the MIT license allows you to lock your code additions away and not feed them back, the GPL forces everyone to feedback. The argument for removing the ability to password protect stacks is a good one (thanks capellan) - but just like the GPL, the debate is open with regard to whether it has a greater effect on stimulating the creation of robust public domain/open source libraries than more liberal licenses. For marketing reasons alone, whichever the choice of strategy, I've long encouraged RunRev to adopt a clear open source strategy. A very clear signal would be sent if they explicitly built in the ability to license and publish code from within the editor. Allowing / disallowing certain features in the engine can also express / help enforce the same policy - but it is more important to work with the community and encourage clear licensing arrangements. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
