[OSGeo-Discuss] The importance of a project's license

[rburhum]

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.