Ragi, Thank you very much for sharing your experience. You've saved me a lot of time
-- Mateusz Loskot (Sent from phone, apology for any top-posting or broken quoting) On 27 Jul 2012 21:11, "rburhum" <r...@burhum.com> wrote: > 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 >
_______________________________________________ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss