Re: [OSGeo-Discuss] Using ArcGIS Desktop with PostGIS [SEC=UNCLASSIFIED]
Hello Bruce, I have not worked on this since January of last year, but I have an ArcGIS Extension I wrote that enables ArcMap to read/write to any GDAL datasource. I think if you recompile it for 10.2 it should work - even if you only have the ArcGIS Basic license. https://github.com/rburhum/arcgis-ogr Contributions are welcomed. - Ragi -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Using-ArcGIS-Desktop-with-PostGIS-SEC-UNCLASSIFIED-tp5150586p5150734.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
Re: [OSGeo-Discuss] The importance of a project's license
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
Re: [OSGeo-Discuss] The OGC: clueless, uncaring, and still rocking to Prince.
Dear Adrian, I recently saw a reply that you made to a blog post I wrote recently. Although the criticism were meant to be directed to the *OGC* as an *organization*, I can tell by your comments, descriptions and overall tone, that you felt *personally* attacked and offended. You have my sincere apologies if you felt that way. This was never meant to be a personal attack. I would be happy to elaborate, with far more detail, each single one of my comments/points. We can do this either publicly or in a private e-mail exchange (whatever you feel is best). Based on your responses though, I have to admit that we have fundamental disagreements in several aspects – and some serious ones at that. - I would be happy to discuss XML vs JSON vs MessagePack conversations and why the first of those is (lately) not adopted by any modern API. JSON is the real winnder nowadays (for good reasons). In terms of serialization frameworks, MessagePack has implementations in Ruby/Python/Perl/C/C++/Java/Scala/PHP/Lua/JavaScript/Node.js/Haskell/C#/Objective-C/Erlang/D/OCaml/Go/LabVIEW/SmallTalk/etc. I dare to say it is “somewhat” supported. - I would be happy to discuss why security is more than certificate exchange or username/password submission during requests. - I would be happy to discuss why complexity of specifications hinders adoption. There are technical reasons why geojson and mbtiles are gaining traction without much effort and GML is not. (Much love to all my friends that were involved with GML – I apologize if this offends you). - I would be happy to discuss why I think SQL (SQL:1999, or SQL:2003, or SQL:2008 or SQL:2011) is a better choice for an API than a full fledged OGC query language that tries to abstract querying. As a side comment, you are correct at thinking that my reasoning here came from experience. Around 10 years ago I was sitting at my ESRI office and a co-worker came into the office and asked me for help since he was in charge of implementing one of the OGC WFS version specs. The nicest thing that I can tell you is that “it was painful and unreasonable in many regards” and that it ended up requiring to hire an “OGC consultant” to try to implement the spec as close as possible (to *explain* – not to implement) - I would be happy to accept the fact that OGC does not have “reference implementations”. That is, of course, as soon as the OGC itself stops using that those terms. I think there was a misunderstanding with the reference implementation licensing comment. Let me just say that there is plenty of Open Source that is BSD or Apache licensed (for example, AFAIK, *everything* from the Apache Foundation http://projects.apache.org/indexes/alpha.html). But please, let’s leave licensing talks for the end. - I would be happy to explain the different between a stateful and a stateless architecture and why websockets are a paradigm shift for the web. If you want to implement the same concepts of a spec without “being tied to the web” or “web browsers” feel free to take “web” out of “websockets” and just use sockets. The same stateful vs stateless architecture argument remains. - I would be happy to explain why SPDY is not “another protocol” but one of the inspirations/guides for httpv2. We are still talking http here. - I would be happy to explain WebSQL even though it died. Why you may ask? Because there was only one implementation of the standard (sqlite) and the standards organization (W3C) refused to make it a standard without a competing implementation. I hope the irony of this situation doesn’t escape you. - I would be happy to explain why the OGC doesn’t have to fully re-invent the wheel when it comes down implementing a Spatial DVCS. The fact that it is “spatial” doesn’t mean it needs to be completely different. I would talk to the GeoCouch guys that have a perfectly good replication model that works or would also look at things like Git, Mercurial, PostgreSQL, MySQL or even the ESRI Versioning and replication system. Replication/versioning is a solved problem. We just don’t have a *standard* that defines how everyone should implement it. Ironically, I can point out a couple of OGC members that are experts in this field. - I would be happy to explain why perhaps, after all these years, it is time to stop ignoring temporal datasets and addressing some of the not so “low hanging fruit”. - I would thank you for calling me young! Although I am not sure I am confused all the time. Well, perhaps 70% of the time I am! In all honesty, I have to admit though, the original post was written as a quick reaction to another set of e-mails I received in regards to some OGC decisions as of late. The truth is that, until last week, I equated the OGC as a standards body that was meant to be equivalent to the W3C (except, of course, for GIS). Sadly, this also means that I would expect a similar behavior/quality of decisions from the OGC (maybe this is a mistake on my part?). If you look at the worki
