As someone who has done several for-pay projects (both big and small) to combine proprietary and foss4g code, I can give a summary from a set of anecdotal evidence and trends that I have noticed from a US-based consultant point of view.
>From my experience, the adoption of an open source project obviously depends a lot on the license and the *environment* it is going to be deployed on. Let me explain. When offering a solution to a customer, it is easy to convince them that changes/enhancements to a particular component they "are getting for free" should be released out back to the community. It takes 1 minute to convince them of this. No friction there. What is much more difficult is to convince them that *all* the code they have been building for sometime now, needs to also be released under the same terms (think GPLv3). *That*, I can certainly say that 99.99% of the time they feel really strongly against! When consuming full-blown GPL-licensed code, the situation when somebody has to also license their entire code base under the GPL depends on the environment. Let me take the example of LGPL and full blown GPL (forget about Affero GPLv3 for this discussion). For server-side and desktop technologies, take the example where the processes are running separate. Changing GPL code is effectively "enhancing that component I got for free", which they understand (they may not understand in-proc or out-of-proc). From a practical stand-point, the restrictions/obligations are similar to that of LGPL because "the client's code" is separate from "open source project's code", so adopting an open source project under GPL or LGPL is of "low friction". For components that are running in-proc, then the license matters much more. An LGPL licensed project still gives them the concept of "I just need to release the fixes that I make to the library I got for free", so it is an easy-sell. GPL-licensed code goes beyond this, so every single customer I've had where I offered to consume GPL-code in-proc said 'no' (except for one in academia, but that was a special case). For customers where I have built iOS apps for, it gets really really tricky. iOS does not allow shared linking of code (it is all static linking), in that scenario, LGPL becomes "the new GPL". Some people argue that you can http://stackoverflow.com/questions/459833/which-open-source-licenses-are-compatible-with-the-iphone-and-app-store use a special provision of LGPL to be able to use LGPL-licensed code in the Apple App Store. But there is no legal precedent for that yet (and thus, as of right now, it is a theoretical argument), so most businesses that respect licenses (or don't want to run the risk) will stay away from it altogether. For web development development, it is a different story and a much longer discussion because of the various ways you can consume open source projects. Now for MIT, Apache, and similar licenses, you don't have any of these implications. It is much easier to convince somebody to consume a project of this kind. Afterwards, you can always give arguments for why it is beneficial to open source a generic component and, so far, I have never encountered friction against this. The FileGDB and ArcObjects GDAL drivers are examples of this. As far as GitHub vs Sourceforge, I think it is hard to argue that any new open source is far more likely to adopt GitHub vs any other repo kind out there. The reasoning, besides the technological implications, are IMHO, rooted in generational-gap arguments. My two-cents, - Ragi -- View this message in context: http://osgeo-org.1560.n6.nabble.com/The-importance-of-a-project-s-license-tp4991223p4991456.html Sent from the OSGeo Discuss mailing list archive at Nabble.com. _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
