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