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

Reply via email to