[AstroPy] POLL: vision for a common Astronomy package

[Tom Aldcroft]

On Wed, Jul 6, 2011 at 4:56 AM, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> 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).

This publication clause seems a little worrying here because (as I
believe Mark alluded) there needs to be way for users of astropy to
know they they used the SOFA library:   "In any published work or
commercial products which includes results achieved by using the SOFA
software, you shall acknowledge that the SOFA software was used in
obtaining those results."  Of course this is a somewhat theoretical
matter, in reality astronomers rarely acknowledge the software they
used and nobody is going to sue them for this.

I don't believe the intent of the SOFA license is that every code that
calls unaltered SOFA becomes tainted with the SOFA license, but rather
to make sure that no user distributes C/Fortran routines that *look*
like official SOFA-endorsed algorithms but are actually altered.

> 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.
> <SNIP>

Assuming that astropy will include a full-featured date and time
capability in the core, there is a lot of useful functionality in
SOFA.  Taking advantage of legacy, well-tested software is a good
thing (libwcs, LAPACK, etc) and can save a lot of developer time.
There is certainly an opportunity to put a nicer Pythonic interface
around the library, and this is the kind of project that could attract
developers (as opposed to the tedious mechanics of doing time
conversions and getting it right).

I should make it clear that I'm not advocating the SOFA library per se
(maybe there is another library that has similar functionality and
more agreeable license terms), but just being practical about using
legacy code where it makes sense.  There will always be a trade-off
between time spent writing something from scratch and the pain of
repackaging existing code.  Maybe someone will step up in a big way
and volunteer to re-implement the SOFA functionality in Python??

- Tom