[Qgis-developer] import proprietary code inside a python plugin
Alex Mandel
tech_dev at wildintellect.com
Mon Mar 26 18:12:54 EDT 2012
QGIS + QGIS plugin (GPL) <-> data <-> Arcpy script (LGPL, MIT, BSD)
Yes it's ok as long as they don't directly import each other.
Thanks,
Alex
On 03/26/2012 03:07 PM, Noli Sicad wrote:
>
> QGIS + QGIS plugin (GPL) + Arcpy script (LGPL, MIT, BSD) = might be OK.
>
> Noli
>
>
> On 3/27/12, G. Allegri <giohappy at gmail.com> wrote:
>> Perfect. I find thinking in the terms of process space a clear criterior.
>> This makes dynamic and static linking equivalent...
>>
>> So, going back to SEXTANTE, it can be given an LGPL license but it cannot
>> use non-free code when used through Qgis, while it's free to do it when
>> used through, e.g., ArcGIS.
>> Please, tell me it's right, otherwise I end the day with another doubt! :)
>>
>> giovanni
>>
>> 2012/3/26 Vincent Picavet <vincent.ml at oslandia.com>
>>
>>> Hi,
>>>
>>>> Ok, going through hyopthesis things are getting clear:
>>>> my plugin is ok until it doesn't load something proprietary in its
>>> process
>>>> space. As soon as it happens I must be able to provide the source of
>>> every
>>>> code running in the same process. Right?
>>> Right.
>>> Importing esri python module falls into that category.
>>> Vincent
>>>
>>>>
>>>> giovanni
>>>>
>>>> 2012/3/26 Vincent Picavet <vincent.ml at oslandia.com>
>>>>
>>>>> Hi,
>>>>>
>>>>> Le lundi 26 mars 2012 21:32:31, G. Allegri a écrit :
>>>>>> Ah, Tim, it's getting clear. Thanks.
>>>>>> The key point is distribution, as always with GPL.
>>>>>> In my case I won't distribute the ESRI geoprocessing libraries,
>>> they're
>>>>>> part of the ArcGIS distribution, which is only availbale to users
>>>>>> having
>>>>>
>>>>> it
>>>>>
>>>>>> installed on they're computers.
>>>>>>
>>>>>> The import satement will success only if the user have the ArcGIS
>>>>>> product installed, otherwise it will fail. As a consequence I felt I
>>>>>> could
>>>>>
>>>>> freely
>>>>>
>>>>>> distribute my plugin as it doesn't strictly require the proprietary
>>>>>> side
>>>>>
>>>>> to
>>>>>
>>>>>> run.
>>>>>
>>>>> No you are wrong, as soon as your plugin is distributed and linked
>>>>> with
>>>>> arcgis, you have to licence everything as GPL and therefore provide
>>>>> sources.
>>>>>
>>>>>> Doesn't GDAL do the same with ECW?! Ok GDAL are LGPL. Is this the
>>>>>> key
>>>>>> difference?
>>>>>
>>>>> Yes
>>>>>
>>>>>> Moreover it doesn't expose the QGis APIs to ArcGIS, and viceversa,
>>>>>> so
>>>>>> it only bridges the two world to interchange the data.
>>>>>
>>>>> Bridging with an import is a link. If you want to exchange data, do it
>>>>> without
>>>>> the import and separate your modules.
>>>>>
>>>>> please re-read my post and mentionned the FSF faq. Everything is in
>>>>> there.
>>>>>
>>>>> Vincent
>>>>>
>>>>>> giovanni
>>>>>>
>>>>>>
>>>>>> 2012/3/26 Tim Sutton <lists at linfiniti.com>
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Mon, Mar 26, 2012 at 4:52 PM, G. Allegri <giohappy at gmail.com>
>>>>>
>>>>> wrote:
>>>>>>>> Through the various considerations on this topic there are two
>>>>>>>> positions
>>>>>>>
>>>>>>> the
>>>>>>>
>>>>>>>> seems contradictory to me:
>>>>>>>>
>>>>>>>> "I did some research on this, and the conclusion is that import
>>> is
>>>>>>>> functionally and legally equivalent to linking during
>>> compilation,
>>>>>>>> so everything that imports qgis must be GPL." [1]
>>>>>>>
>>>>>>> So if you plan to distribute although technically possible to link
>>> to
>>>>>>> a proprietary module, its not legall possible.
>>>>>>>
>>>>>>>> then
>>>>>>>>
>>>>>>>> "you can import/link proprietary code into gpl code, provided
>>>>>>>> you
>>>>>
>>>>> have
>>>>>
>>>>>>>> a license to do it."
>>>>>>>
>>>>>>> So if you have the license to ESRI etc. to use their libraries you
>>>>>>> are welcome to make yourself a QGIS frontend to ArcSomething, but
>>>>>>> you cant legally distribute that.
>>>>>>>
>>>>>>>> They probably mean different things and they're not in
>>>>>>>> contradiction.
>>>>>>>
>>>>>>> Being
>>>>>>>
>>>>>>>> an important point to me, could you help in understanding it?
>>>>>>>
>>>>>>> Above is my understanding of those points anyway....
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Tim
>>>>>>>
>>>>>>>> thanks a lot,
>>>>>>>> Giovanni
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>
>>>>>>>
>>> http://lists.osgeo.org/pipermail/qgis-developer/2012-March/018976.htm
>>>>>>> l
>>>>>>>
>>>>>>>> [2]
>>>>>>>
>>>>>>>
>>> http://lists.osgeo.org/pipermail/qgis-developer/2012-March/019000.htm
>>>>>>> l
>>>>>>>
>>>>>>>> 2012/3/26 G. Allegri <giohappy at gmail.com>
>>>>>>>>
>>>>>>>>> I think you're right but watch the reality from a worldwide
>>> point
>>>>>>>>> of
>>>>>>>
>>>>>>> view.
>>>>>>>
>>>>>>>>> I work mostly with foreign countries, not EU/USA. National
>>> offices
>>>>>
>>>>> and
>>>>>
>>>>>>>>> agencies budgets are far beyond the license fees, so they don't
>>>>>>>>> care
>>>>>>>
>>>>>>> for it
>>>>>>>
>>>>>>>>> very much. They pay yearly for something that already do the
>>> work
>>>>>
>>>>> they
>>>>>
>>>>>>> need,
>>>>>>>
>>>>>>>>> without having to do contracts for development, define
>>>>>>>>> requirements,
>>>>>>>
>>>>>>> etc.
>>>>>>>
>>>>>>>>> This is the reality. In my courses, even those based on ESRI
>>>>>
>>>>> software,
>>>>>
>>>>>>>>> I always introduce FOSS solutions. Sometimes it raises
>>>>>>>>> interest,
>>>>>
>>>>> most
>>>>>
>>>>>>>>> of
>>>>>>>
>>>>>>> times
>>>>>>>
>>>>>>>>> they don't care. They want the job done, and they don't pay for
>>>>>>>>> the
>>>>>>>
>>>>>>> license.
>>>>>>>
>>>>>>>>> That's it.
>>>>>>>>>
>>>>>>>>> Anyway, if I wouldn't think that (most) of times a free
>>>>>>>>> solution
>>>>>
>>>>> could
>>>>>
>>>>>>> be
>>>>>>>
>>>>>>>>> the best way, I wouldn't be here to talk about it ;)
>>>>>>>>>
>>>>>>>>> giovanni
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/3/26 Sandro Santilli <strk at keybit.net>
>>>>>>>>>
>>>>>>>>>> On Mon, Mar 26, 2012 at 03:31:53PM +0200, G. Allegri wrote:
>>>>>>>>>>> I totally agree with you, but reality is a bit different.
>>> Many
>>>>>>>>>>> agencies,
>>>>>>>>>>> corporates, etc. are not considering to leave they're
>>>>>>>>>>> infrastructure.
>>>>>>>>>>
>>>>>>>>>> It's their choice, they'll have to bear the consequences of
>>> that.
>>>>>>>>>>
>>>>>>>>>>> I suggest solutions to interoperate, not to switch the whole
>>>>>
>>>>> thing.
>>>>>
>>>>>>>>>> What I'm saying is that it just costs more. And rightly so.
>>>>>>>>>> It is no interest of the free software users to make it any
>>>>>
>>>>> cheaper,
>>>>>
>>>>>>>>>> IMHO.
>>>>>>>>>>
>>>>>>>>>>> It would be easier, and a lot cheeper, if everybody talked
>>> one
>>>>>>>>>>> language.
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>>> But we have hundreads of languages in the world, and we have
>>> to
>>>>>>>>>>> deal with
>>>>>>>>>>> this.
>>>>>>>>>>
>>>>>>>>>> People grow up learning the language of their mothers.
>>>>>>>>>> Nobody has to pay a license to _use_ that language.
>>>>>>>>>> And anyone can learn.
>>>>>>>>>> We're really not talking about the same thing.
>>>>>>>>>>
>>>>>>>>>> --strk;
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Qgis-developer mailing list
>>>>>>>> Qgis-developer at lists.osgeo.org
>>>>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>>>>>
>>>>>>> --
>>>>>>> Tim Sutton - QGIS Project Steering Committee Member (Release
>>>>>>> Manager) ==============================================
>>>>>>> Please do not email me off-list with technical
>>>>>>> support questions. Using the lists will gain
>>>>>>> more exposure for your issues and the knowledge
>>>>>>> surrounding your issue will be shared with all.
>>>>>>>
>>>>>>> Visit http://linfiniti.com to find out about:
>>>>>>> * QGIS programming and support services
>>>>>>> * Mapserver and PostGIS based hosting plans
>>>>>>> * FOSS Consulting Services
>>>>>>>
>>>>>>> Skype: timlinux
>>>>>>> Irc: timlinux on #qgis at freenode.net
>>>>>>> ==============================================
>>>
>>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
More information about the Qgis-developer
mailing list