[AstroPy] POLL: vision for a common Astronomy package

Erik Tollerud erik.tollerud at gmail.com
Wed Jul 6 04:56:06 EDT 2011


I suspect the most challenging part of the SOFA license is this
clause: "The source code of your derived work must contain
descriptions of how the derived work is based upon, contains and/or
differs from the original SOFA software."  This implies that all work
derived from it needs to describe explicitly how SOFA is used/altered.
 I suspect that's incompatible with most other open source licenses
(although I'm certainly no lawyer, and for that matter I don't know if
the SOFA board or IAU pay attention to this too closely).

Regardless, though, Mark's interpretation is the one we had in mind
for the vision - external C libraries could be used in Astropy, but as
an optional feature, not as a requirement for the main functionality.

The particular instance of SOFA, though, is perhaps an example of the
problem we facing in wrapping existing libraries.  IMHO, they are
usually quite un-pythonic in both implementation and interface, and
wrappings typically follow similar forms (e.g. pysofa follows the sofa
interface very closely). If the goal here is a python library and
framework, we want to leverage the advantages of the language itself
in terms of style and programming idioms.  And especially given the
compilation/packaging issues noted by Mark, Ole, and many others, it
has to be worth the trouble to write wrappers that end up with such in
interface... SWIG is great at making direct wrappings, but I haven't
really seen it go beyond that.  More recent schemes like ctypes or
Cython seem to be easier to compile and are easier to make more
pythonic, but at some point it becomes more efficient to just
implement the algorithm using numpy (possibly with the help of a small
C extension if speed is a problem).

This doesn't mean there isn't a place for such official libraries,
though - they certainly should be involved in the debugging and test
suite of the Astropy implementations.  After all, they are meant to be
reference implementations.  And if an externally sanctioned/supported
library really can be wrapped in a way that matches the community's
needs and is simple and portable to compile/package, it certainly
could have a place in the core. I personally am just a bit skeptical
that this can or often will be done.


On Tue, Jul 5, 2011 at 11:19 PM, Prasanth <oneaufs at gmail.com> wrote:
> Hello,
>
>>
>> Are you proposing that I must agree to the SOFA terms
>> of use (which are more restrictive than GPL or BSD licensing) before I
>> can use Astropy?
>
>
> I think that the SOFA license and terms of use are much more liberal than
> GPL. The only requirement is that the developer retains the copyright
> notice, and none of the derived components carry the prefix "iau". It can be
> used for commercial purposes. Also, I couldn't find anything in the SOFA
> license that prevents a developer from even making a closed source
> application.
> Prasanth
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>



-- 
Erik Tollerud



More information about the AstroPy mailing list