 |
 |
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. 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. > 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. > this would look a good compromise for me. Good. > what means that the current license *as a legal document* just > does not help you. So, in principle, you could replace these > paragraphs by recommended "best practices". No, they're conditions for using the software. >> the changed version may well be worse >.... than a new library written by a greenhorn like me from > scratch?? No: worse than the original. The SOFA software is in a very low-entropy state. The sort of thing we must guard against is someone changing constants in a SOFA function because they found something newer on Wikipedia. > 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. > 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. Patrick Wallace ____________________________________________________________________ Space Science & Technology Department +44-1235-531198 STFC Rutherford Appleton Laboratory Harwell Oxford Didcot, Oxfordshire, OX11 0QX, UK [log in to unmask] ____________________________________________________________________