[log in to unmask] writes:
> Ole Streicher wrote:
>> It may also happen that someone fixes a bug in the SOFA source
>> code.

> If that happens, we definitely don't want the library to fork at
> that point.  It's vital that the bug is reported to SOFA and fixed
> at source. 

I brought this example to show that a change in the code may be an
improvement and not something that makes it worse.

Ofcourse, it is better if the bug is fixed in the original code, but
there may be reasons that this does not happen. You mentioned one reason:

> That's not to say that some temporary arrangement can't be made to
> allow whoever is affected to acquire the fixed version without delay.

but it may also happen, that the original author is not responsive. This
is obviously not the case for SOFA in the moment, but this may change in
some (distant) future. The idea behind Free Software is that the further
development does not depend on the future responsiveness or good-will of
the original author.

>> To prevent this, there is §3a and §3c of the SOFA license which
>> require that the change track is clearly indicated.

> I think relying on people reading that stuff is unwise.  They will
> just glance at the function name.

Are you sure?  To use Java as an example, if on your computer
"java.util.LinkedList" does not behave properly, would yoou just blame
Sun^UOracle for this, or would you first look who the actual author of
the package is? 

To make the concrete example DS9: Assume, something goes wrong with the
positioning there. People would write this to either me (as the Debian
Maintainer), or to the DS9 programmer. The latter would not be able to
reproduce it (since their code is still based on SLA), and I would look
(or ask) what library they actually used, try to reproduce the bug and
file the bug report to the corresponding upstream author. I would not
just blame someone just because a random function name starts with "iau", 
"sla" or "java".

It is today common to distinguish between a programming *interface*
(function names, calling conventions) and the *implementation*. And it
is quite clear that there may be different implementations for the same
interface. 

[requiring a name change of the whole library instead of the function names]
>> this would look a good compromise for me.
> Good.

This is what I would propose to the SOFA board when the discussion comes
to this topic.

>> So, you would basically prevent AST to be linked with SOFA.

> There is nothing to stop AST being supplied with renamed and
> appropriately adapted versions of the SOFA functions, while
> observing the SOFA stipulations on preserving license text.

The discussion was here about the acknowledgement clause (§4). AST
cannot remove this clause from a changed SOFA source, so if it wants to
link to SOFA, it would need to put such a clause into its own license
(because otherwise the users of AST would not be forced to acknowledge
SOFA if it was used for the results). AST is on the other hand bound to
GPL, which is not compatible with such an additional clause.

Therefore, the acknowledgement clause makes it impossible to link AST
with SOFA.

>> If it is not a legal restriction, it should be not in the
>> license.

> I think you're confusing "legal" with "enforceable".  The license
> conditions can be anything the SOFA Board stipulates.

Please look into
<http://www.gnu.org/licenses/gpl-faq.html#GPLOutput> which describes
this case.

Best regards

Ole