Tim Jenness <[log in to unmask]> writes:
>> PAL will need SOFA, and for me it is still unclear whether SOFAs license
>> is dfsg compliant.
> The SOFA licence seems to be far more relaxed now than when I looked
> at it in 2008. Can you take another look?

The discussion is still not finished yet, bit it seems that SOFA is not
dfsg compilant and therefore cannot got into Debian.

Its main problems are:

1. They dont allow that a changed version uses the same function names.

This contradicts §3 of the DFSG.

It may be evaded by renaming all function names in the library once,
f.e. use the prefix IAU_ instead of iau, and create compability by a
header file with definitions like

void IAU_foo(...);
#define iauFoo IAU_foo

According to their license, this should be allowed.

This "you must rename the lib" is IMO completely stupid: anyone can
write his own library and name the functions starting with "iau" (or
"sla" or whatever), and neither IAU nor Patrick are legally able to stop
them. These completely independent libraries are in no manner better
than changed versions of the original libraries. So, the restriction is
useless. 

2. They require that any results achieved from using the library should
acknowledge this fact.

In my opinion, this is a funny rule, especially in my case: SOFA will be
linked to PAL, which will be linked to AST, which will be linked to
DS9. 

If someone now publishes a paper, based on some DS9 images, how should
he know whether the result was done using SOFA? And I think that it is
totally unrealistic that he is aware of this at all. It is questionable
whether this is a legal restriction at all -- I got a pointer to 
<http://www.gnu.org/licenses/gpl-faq.html#GPLOutput> for a similar case.

*If* this is a valid license item, it would contradict §9 of the DFSG
(License Must Not Contaminate Other Software) -- since it contaminates
the DS9 program.

I tried to contact the SOFA board, but still didn't get an answer. I
have the hope that we can work out these problems (Patrick: could you
help here?) This would be quite good, since having the "official"
implementation distributed via Debian would be definitely an advantage
for standardization.

If this does not work out, I definitely have a problem in putting the
changed astLib into Debian (and I would probably stick to the 6.0.1
version).

Best regards

Ole