Porting ERFA to different languages - licensing

[helgee]

Over at JuliaAstro/AstroBase.jl we are currently in the process of porting several ERFA functions to Julia. The rest of AstroBase.jl is published under the MIT license. We are now asking ourselves how we can acknowledge the ERFA heritage. According to the internet, it is not really clear to what degree a port is a derivative work as long as it is not an automatic or line-by-line translation.

My new-jerk reaction would be to adapt our LICENSE file like shown below and put a reference to the respective ERFA source code in the function docstring:

$ASTRO_BASE_LICENSE (MIT)
--
Some functions in AstroBase.jl are based on ERFA which is published under the following license:
$ERFA_LICENSE

But IANAL 🤷‍♂ and thus I would like to ask you folks how you want this to be handled.
Many thanks in advance!

[mhvk]

@helgee - I think to help others it is worth ensuring that somewhere in the license it refers to the actual source, which is SOFA (ERFA is just a copy of it with a different license; see ERFA license file).

A more astronomy comment is that, if at all possible, I would think it is substantially better to use the code directly (i.e., wrap the library) rather than reimplement it; there are changes now and then (including simple things like leap seconds) and you'll save yourself hassle if you don't have to keep on checking whether anything changed that was important. Indeed, at a basic level, that was the whole point for the IAU to create SOFA: that there would be standard routines for basic astronomical transformations, etc. Certainly, for astropy, we are trying quite hard to ensure we always use a SOFA/ERFA routine if possible. For this purpose, we wrap the C functions as numpy ufuncs for vectorization. We have scripts that scrape the source and headers to create the wrappers - might it be possible to do something similar for Julia?

[helgee]

We have had a complete wrapper for a while: https://github.com/JuliaAstro/ERFA.jl

While Julia is based on LLVM and it is thus quite easy to call C code, it stops the compiler from performing certain optimizations. Our approach has been to use the ERFA wrapper to automatically validate our implementations during unit testing.

[mhvk]

That sounds great!

[helgee]

We have dealt with this licensing issue by re-licensing AstroBase.jl: JuliaAstro/AstroBase.jl#42

The fundamental problem was that the original MIT license of AstroBase.jl is more permissive than the BSD license used by ERFA. Which means that you can't incorporate BSD-licensed code into an MIT-licensed project (according to Wikipedia). Thus we re-licensed under the MPL-2.0 which is compatible with the BSD license.

We have added file-specific copyright notices that properly acknowledge ERFA's copyright, see e.g. here: https://github.com/JuliaAstro/AstroBase.jl/blob/master/src/earth_attitude/nutation.jl#L8

[mhvk]

Very belatedly, this sounds great! I'll close this issue, but obviously do let us know if you ever have problems (in the larger context, cross-testing between JuliaAstro and astropy would seem quite worthwile...)

[helgee]

Thanks for the encouragement! We'll keep you posted...

[cjordan]

Hi there @mhvk . Apologies for the noise, aside from making a whole new github issue, this seemed like the most appropriate place to announce this.

I've just created a Rust package for ERFA available here: https://github.com/cjordan/erfa-sys

It can optionally compile the ERFA source from an unpacked tarball, but defaults to using the available ERFA system library. So this package more or less just makes ERFA available to Rust users conveniently; I'm not interested in adding new functionality outside of the existing C library, and I certainly don't want to be stepping on toes in a legal sense!

Depending on how the liberfa github group feels about it, I think that these language "spinoffs" should be under the same branch. The biggest reason is visibility to the wider community, but also how releases are maintained. Rust packages ("crates") are made available on https://crates.io, and in the absence of other maintainers, if I could no longer maintain erfa-sys, then the erfa-sys name is taken forever. (For similar reasons, I won't release erfa-sys on crates.io until I'm certain that it works as intended.)

So, let me know what you think. I'm very happy for my repo to be moved under the liberfa umbrella, if that's what the group wants.

[mhvk]

@cjordan - that is great! Since we now have a pyerfa for bindings to python, an 'rust-erfa' or so with bindings to rust seems reasonable -- to me, the main question would be one of having some guarantee that someone will maintain it. But let me ping co-conspirators @sergiopasra, @astrofrog, and also @avalentino for their thoughts.

[avalentino]

@cjordan , @mhvk I don't know rust at all so I don't think I can help in this case, Sorry.

[astrofrog]

I think it could make sense to include bindings for different languages in the org as long as it's clear who is responsible for maintaining each one

[mhvk]

@avalentino - no need for help, but good to have input! In a sense, you're an example, as you came in to help with the python/numpy bindings.

Indeed, @cjordan, in analogy to that, are the rust bindings a base that is being used in larger rust-based astronomy projects?

@helgee - as you may still be CC'd on this anyway, is having julia bindings under the liberfa umbrella something that would make sense?

[cjordan]

@mhvk - For now, my work on erfa-sys is toward re-writing an important calibration software we use for the Murchison Widefield Array (https://github.com/MWATelescope/mwa_hyperdrive/tree/devel/core).

At the moment, the code is still in heavy development and a little bit opinionated toward what I need rather than something general. But, with time (and motivation), I'm sure my foundation could be adapted to something more general. This might eventually look like an erfa package in the Rust ecosystem that has native types for e.g. RADec, HADec and their transformations, etc. This has already been done with the cfitsio library, for example.

I'd say that in terms of scientific work, Rust is still pretty immature. But, in my humble opinion, the benefits of working in Rust have meant that I've been able to quickly and confidently implement complex algorithms that outperform their C/C++ counterparts, so I hope that Rust catches on.

On a side note, I think that even if someone in the liberfa team does not have knowledge of Rust, it's still helpful to have them listed as a crates.io collaborator, just so that the erfa-sys package isn't hampered by having only a single user.

[mhvk]

@cjordan - I think for liberfa, one would not necessarily want native types, etc., but just bindings so that other rust code can use it at all. For python, we bound the routines via numpy so that they can handle arrays, but beyond aggregating error and warning codes, we do not add anything; the rest is in astropy (we actually had more but removed it so that it is very clear what pyerfa does).

p.s. I've got a colleague who similarly switched from C++ to Rust and is clearly not looking back. I'm a bit more intrigued by Julia myself. My initial coding was in fortran, but after python/numpy, I never again want to have to write loops over arrays, or parse input/output in a language not set up properly to deal with strings...

[cjordan]

@cjordan - I think for liberfa, one would not necessarily want native types, etc., but just bindings so that other rust code can use it at all. For python, we bound the routines via numpy so that they can handle arrays, but beyond aggregating error and warning codes, we do not add anything; the rest is in astropy (we actually had more but removed it so that it is very clear what pyerfa does).

I think what you describe here is what I've done with erfa-sys. It merely makes the ERFA C library available to Rust. An additional "nice" layer on top of that would be similar to what you describe with pyerfa and numpy; the functions would take native Rust types (like a vector or reference to one) instead of a raw pointer (which is supported but discouraged because of the lack of memory safety). In any case, as originally stated, I think it would be great to have erfa-sys (which should probably be named rust-erfa-sys, thinking on it) and similar projects under the liberfa team's umbrella. Anything else can/should be discussed later.

On that note, I'm going to be moving a little slowly in the near future, as my wife gave birth yesterday!

p.s. I've got a colleague who similarly switched from C++ to Rust and is clearly not looking back. I'm a bit more intrigued by Julia myself. My initial coding was in fortran, but after python/numpy, I never again want to have to write loops over arrays, or parse input/output in a language not set up properly to deal with strings...

I don't like evangelising too much on anything, but I would personally encourage you to try anything and everything (of course, that takes time and effort 😄) I haven't spent much time with Julia, but I personally hope it's a better fit for me than Python (which I generally loathe).

[mhvk]

@cjordan - congratulations, hope all is going well!

And I think overall it sounds like a good plan to hold various interfaces under the liberfa umbrella - what you describe sounds just the right thing.

[helgee]

@helgee - as you may still be CC'd on this anyway, is having julia bindings under the liberfa umbrella something that would make sense?

Belated answer: There is a strong tradition in the Julia ecosystem of keeping packages in Julia GitHub orgs, e.g. JuliaAstro for ERFA.jl. So it makes more sense to keep it there IMHO and there are enough people who could take over if I would run off and join the circus (I am not the original maintainer myself).

Nevertheless, maybe having a list of links to "external" wrapper projects somewhere around here would be a good idea to spread awareness?

[mhvk]

Thanks; for the moment, I just raised a new issue, #80