Hi Stef, I have spent a month off - skiing.
Nice to hear from Funambol that all companies below the scale of mobile network carrier companies are SMB businesses. But that it is not really surprising me, I don't know if Funambol is not willing or able to offer commercial licences to other businesses than OEM and mobile carrier companies. You are calling your one and only commercial license Funambol Carrier license, this makes your product less attractive e.g. to (not so small) multi-national insurance companies who on the one hand have comparably low user numbers but on the other hand some of their employees have a much higher demand for advanced data synchronization applications. In this field applications built around Funambol DS have to compete with SAP MI (Mobile Infrastructure) and Oracle Database Lite solutions with both offer advanced data synchronization functionality out of the box. If for these "smaller" enterprise scale deployments you have to license a "Carrier Edition", customers may feel greatly misunderstood because their business needs are a little bit different from what carriers offer to consumers and rather small shops. You simply cannot compare carrier scale PIM synchronization with e.g. a management information and support applications, that should also work on a long business flight, where mobile web applications would fail totally. Funambol Carrier Edition is definitely no special offer in these scenarios, especially because we could assume that many not so small enterprises are already Oracle or SAP costumers, if they aren't they have often licensed at least Microsoft Exchange Server, which also offers upto some degree mobile business data synchronization (Exchange Stores). Perhaps you may now see that neither a "Carrier Edition" (, which costs US$ 120,000,) nor the fee-less "Funambol Community Edition" copyleft license are hot candidates, if you want to tell a customer the F/OSS business case, that he should invest into an open-source mobile business infrastructure instead of taking established big-name products. Telling the enterprise clients the F/OSS business case, is in most cases more complicated than telling them that they could save license fees - that's often a minor aspect. They are used to get what they pay for and they compare what they get from different vendors for their money. These customers often use a software solution much longer than a consumer his favourite electronic toy, they often expect that they use it as long as 15 years and even longer. And that's the point where SyncML becomes interesting, it's simply XML over any network protocol you like. You are not trapped into difficult to understand product specific binary protocols, which might produce a lot of headache if you have either to reverse-engineer them or to migrate to something totally new. You are right it is too early to talk about what impact the AGPLv3 will have on products that are licensed under this license. I have discussed this with some colleagues, we think that this will have on the one hand a positive effect on the revenue of some open- source companies, because some customers will feel the need to either change to a commercial license or to less restrictive licensed products, at the end of the day the only interesting numbers in business life are your expenses and what you get in return, so counting paying customers makes really sense. But the down-side of changing to a more restrictive license is that the product has to compete with the commercial products of the big- names. And even more worse it may reduce the number of open-source professionals among the community members. Of course you may try to compensate this with making little money gifts to others but that's often seen as a big taboo, because then you make people to become second-class workers of your enterprise, which work for less than your own regular employees. In any case where an in-house solution is a competitive differentiator, there is a strong need to protect its internals from disclosure. If your enterprise is split into legally independent companies, which is quite often the case in today's larger multi-national enterprises, AGPLv3 is definitely a show-stopper, because ... -) you cannot withdraw this license from a group company that leaves the group but has used the AGPLv3 poisoned product. -) you cannot outsource parts of the operational aspects of using the AGPLv3 poisoned product. -) you cannot practice the "no need to know" principle between legally independent business entities of your enterprise group, if you use the AGPLv3 poisoned product, even if it has been developed in-house. Funambol is a product AFAIK that has a quite good reputation. I do not see a reason why you should not also target "smaller" multi- national enterprises beside network carriers and OEM , of course they do not need the same feature set as Carrier Edition customers, their needs are little bit different. ;-) Your practice to force community members to make a copyright assignment to a commercial company instead of assigning their rights to an ethical higher integrity entity as the Free Software Foundation (FSF), is definitely not the best choice because it interferes with the original philosophy behind free software. People who believe that it does not matter to whom you assign all your natural rights as a open-source contributor, should better think twice if that's really true, companies who want to make them believe that, are in my eyes not really honest to the open-source community, because they will be never doing the same, they will never assign their rights to the FSF, they are only using FSF licenses for their own commercial benefit, without contributing them self a single line of code to the great foundation of GNU software. They do not share honestly at all with the community. They reserve themselves rights that allow them to fully control their open-source contributors work, a quite popular trick is to use a protected trademark as a package name, which makes it legally impossible to create a fully compatible vendor independent fork, but patents work also really well. The ethical rights of the open-source community would be better protected if you would allow community members to assign their copyrights directly to the Free Software Foundation. No one knows who will own Funambol in a few years, it is not a privately hold business, it's financed by venture capital, so no one at Funambol can make promises, that Funambol will always offer and maintain an open-source edition. It would not be the first time where people become quite unhappy when they have to learn that open-source companies and some of their products may disappear if they get acquired by one of big name companies. Open-source governance matters - not only for the community but also for commercial licensees. It is beneficial to all users of an open-source product if the project is ruled by an open community instead of a single company behind. That's a strong advantage of Android it's backed up by a large GROUP of industrial leading companies and Google is also building actively a free open-source community around it. It would be quite interesting to see if this would have been also possible using a strong copyleft license. I am in doubt, because strong copyleft licenses can have unpredictable economic side-effects, in cases where a single commercial entity has the right to determine the future of an open-source product, they can simply stop development and maintenance of the open-source version, and worse they may publish lists of security issues which they have patched for their commercial users and recommend users who are using the discontinued open-source version to become commercial licensees. Many managers share my concerns about using strong copyleft licensed software to implement critical business processes, you have to examine really carefully not only the impact of the license itself but also try to estimate the projects individual risks, that can be a tough task because you have to gather a lot of informations about the projects copyright owners, if it is not a community ruled project. Sometimes even a single big name is no guarantee for the projects open future. I am just thinking of a very large German software vendor who has decided to discontinue his open-source SQL data base. If you have trusted their promises bad luck for you and your business. Cheers George On 3 Mrz., 11:25, StefM <[EMAIL PROTECTED]> wrote: > Hi Jay, > > On Feb 27, 4:28 pm, JayR <[EMAIL PROTECTED]> wrote: > > > But the really unlucky ones are the customers who get tricked. > > I don't think that 'trick' is the right word to use.Funamboldoesn't > want to trick anybody and its business model is quite honestly > described in many circumstances. Even on ski trips, Fabrizio talks > about it :) > > http://blogs.cnet.com/8301-13505_1-9883898-16.html?part=rss&tag=feed&;... > > > I see it may be a little bit tricky to add "smaller" licenses to > >Funambol'scommercial portfolio. > > Funambolmade a strategic choice to focus selling to big enterprises: > network operators, manufacturers, etc. You are right that this leaves > many smaller companies not served. Probably that's a market > opportunity for others to pick. If you think there is business there, > you could start serving it usingFunambolfree/libre software offer. > Nothing prevents you to do that, right? The only thing thatFunambol > asks in exchange is that you contribute back the modifications to the > code, adhering to the copyleft principles. > > You mentioned in another message that copyleft license forces your > clients would have to disclose internal secrets. I'm not sure that > this is necessarily true, but I'm willing to investigate more and > discuss this with our management. Have you already found a case where > the AGPLv3 prevented you to offer to your SMB client a solution based > onFunambol? > > thanks > stef --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
