Hi Georg, John et al,
- The Blind Solver software itself is published under GPL v2, see http://www.astrometry.net/use.html. As I understand GPL, it would not be ok to link this (or derived work) with a close sourced product. And PI is closed source...
I don't see this in the same way. I may be wrong —interpretation of the GPL is always a complex matter—, but let me explain how I understand open-source development on the PixInsight platform, in relation to GPL.
As you know, PixInsight is a modular system. The PixInsight Core application provides just the infrastructure to build an image-processing platform: three user interfaces (command-line, graphical and scripting interfaces) plus an application programming interface to communicate with
external modules. The whole processing capabilities are implemented by installable modules in PixInsight. A PixInsight module is a dynamically linked shared object (a .so, .dylib or .dll file on UNIX/Linux, Mac OS X and Windows, respectively) that communicates with the PixInsight Core application through a free, publicly released and fully documented API: the PixInsight Class Library (PCL). A PixInsight module works following the client-server paradigm: the modules are clients and the PixInsight Core application is a server with a known set of resources, which are publicly accessible and can be used by its clients. The PixInsight Core application never works as a client of any PixInsight module.
You can release an open-source software product on the PixInsight platform, just as you can do the same on Windows, Mac OS X or commercial UNIX systems, which are —to greater or lesser extents— closed-source, proprietary operating systems. This is possible thanks to dynamic linkage.
What the GPL license prohibits explicitly is a closed-source software product utilizing a GPL'ed library to implement some part of its own functionality. In other words, a closed-source software product
cannot depend on an open-source product released under the GPL. A software product P depends on a software product Q if by removing Q, P ceases to work as P has been defined initially (that is,
before the existence of Q). This basically prohibits static linkage against a GPL'ed library, as in such case there is no way to demonstrate that the closed-source product could continue working exactly in the same way after suppression of the GPL'ed library. For example, linking astrometry.net code statically to the PixInsight Core application would force me to release the whole source code of PixInsight under the GPL, for that reason.
However, building a PixInsight module that follows a publicly released, fully documented API (PCL in this case), and releasing it under the GPL, is no problem at all IMO. This is because (i) the PixInsight module uses exclusively dynamic linkage to access the services offered by the PixInsight Core application, and (ii) the PixInsight Core application does not depend on the PixInsight module. You can uninstall a PixInsight module and PixInsight Core can continue working exactly in the same way. Of course, if you uninstall a module, the PixInsight platform,
as a whole, ceases to offer the functionality implemented by the module in question, but this does not alter or limit the functionality inherent in PixInsight Core. PixInsight Core is an image processing application, with and without, before and after, the module in question.
From the user's perspective, the GPL says that the user must have the freedom to modify the source code of a GPL'ed software product, to adapt it to his/her own needs, or just to inspect it. The user must also have the freedom to replace a GPL'ed software product with his/her own version without limitations, in the same context as the original product. Both conditions are perfectly fulfilled with a PixInsight module released under the GPL. The question here is the definition of "product": the product covered by the GPL is the PixInsight module in this case, not the PixInsight Core application.
For open-source purists, the only problem could perhaps be static linkage to the PCL. Actually, there should be no legal problem here as the PCL does not depend on the GPL'ed code, and linking statically against the PCL does not change the fact that it is exclusively the GPL'ed module what is using PCL code to implement its own functionality. Anyway, I can release a new version of the PCL with an open-source part and a small proprietary part. The open-source part would be released under a dual GPL/LGPL license (in Qt's fashion), and would implement the whole low-level API for communication between PixInsight Core and PixInsight modules. In this way, open-source modules could be linked statically against an open-source PCL library. In fact, I plan on doing exactly this with PCL 1.1; this would only accelerate a bit what I already want to do.
Having said all this (sorry for the lenghty story), I must say that I would
never start a project like this one without the author's blessings.
The pre-build databases provided by astrometry.net are based on a cleaned version of the USNO-B catalog. The astrometry team apparently gives non-commercial users access if you ask them. The use conditions are formulated in http://trac.astrometry.net/browser/trunk/src/astrometry/GETTING-INDICES. The key sentence here is: ...
As I understand this, it is unlikely that those databases can be redistributed with PI.
Indeed. A hypothetical astrometry.net PixInsight module could not distribute these databases, unless the authors provide explicit permission to do so.
In my opinion, everybody would benefit if some astrometry.net functionality were implemented as a PixInsight module. astrometry.net is the best astrometry engine, which could be used by all present and future PixInsight users. You and Vicent have pointed out some of the many and exciting possibilities that this integration could give rise to. I honestly think that we offer an excellent infrastructure, where astrometry.net would benefit from direct portability to Linux/UNIX, Mac OS X and Windows, a rich and modern user interface, and integration with a solid and evolving platform. Georg's excellent script clearly shows this.
A completely different thing is how difficult this integration could be, in strictly technical terms. It surely wouldn't be the easiest task but, well, we already have done quite a few difficult things with PixInsight...
