 |
 |
[log in to unmask] writes: > Ole Streicher wrote: >> The discussion is still not finished yet, bit it seems that >> SOFA is not dfsg compilant and therefore cannot got into Debian. > I think the SOFA Board will be relaxed about this. Anyway, why > can't it go in contrib? It's not obfuscated this time. "contrib" contains only software, that is compliant, bot depends on other software. If SOFA must go to "non-free", ds9 would need to be in "contrib". Neither "non-free" nor "contrib" are part of Debian. Debian just provides infrastructure for them, see <http://www.debian.org/doc/debian-policy/ch-archive.html>. >> They dont allow that a changed version uses the same function >> names. > This is because hobbyist changes may well cause damage - this stuff > is extremely slippery - This may happen, ofcourse. It may also happen that someone fixes a bug in the SOFA source code. > and a recipient would naturally assume the IAU screwed up. To prevent this, there is §3a and §3c of the SOFA license which require that the change track is clearly indicated. What is compliant (and may be a compromise here) is that the changed library itself is forced to use another name -- this would look a good compromise for me. >> This contradicts §3 of the DFSG. > You might want to look at pragmatic easing of some of the DFSG > restrictions. Debian seems far more doctrinaire than other Linux > distributions. I am not an official Debian Developer, I am just a volunteer -- not even an experienced one. However, since Debian collects by far most of packages of the distibutions (~29000 in the moment), this seem not to prevent packages going in. In fact, many of other scientific packages -- especially newer ones -- are DFSG compliant. >> It may be evaded by renaming all function names in the library >> once, f.e. use the prefix IAU_ instead of iau, > If using "IAU_" is SOFA-compliant this is an oversight, and to > exploit it would in my opinion be sharp practice. The *spirit* of > the stipulation is perfectly clear.) But if you choose something > else entirely, then I think what you are proposing is perfectly > acceptable, and what SOFA intended. > Much depends on whether you value the continuing cooperation of the > authors of the software. I have choosen this example to show that the license in its current form does not hinder anyone from destroying its spirit while formally completely fullfilling all requirements -- 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". >> 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. > There are lots of things that are not actually illegal but are > nevertheless avoided by people with manners. The intention behind > the stipulation is clear. There are good reasons for that: imagine one has a program that uses these functions extensively, and he wants to replace the core by some vector functions (SSE, or AVX). This requires changes (or a completely new version written from scratch) of the source code, and therefore requires that every program that uses this library needs to be changed and recompiled. Providing a program that may use both versions would be almost impossible (as long as you don't #define one function name with the other), so you need to distribute two programs. Having a similar problem with another library of your programs would double the number of versions again. Requiring a renaming of function names may be a somehow acceptable solution if people just include the source code of a few functions, but for libraries -- especially for shared libraries it is a hell. Imagine that the Java developers would require that only their original "java.util.List" source code may be called "List" -- porting a program to another implementation (like IBM) would be a pain. >> These completely independent libraries are in no manner better >> than changed versions of the original libraries. > You misunderstand: the restriction is because the changed version > may well be worse. .... than a new library written by a greenhorn like me from scratch?? >> In my opinion, this is a funny rule, > It is not unlike the convention that exists for scientific papers. I know that it was intended to be modeled like that. However, software is not a scientific paper. One cannot just adopt the rules of scientific publications to software. The example I have shown (SOFA->PAL->AST->DS9) shows this clearly. >> If someone now publishes a paper, based on some DS9 images, how >> should he know whether the result was done using SOFA? > There are practical limits to compliance, but an appropriate chain > of acknowledgements should not be hard to arrange. This would require that SOFA allows linkage only to programs or libraries that themself include such a rule. LGPL does not. PAL is (L?)GPL, AST is GPL, and at least AST cannot be changed since it has contributions from third parties. So, you would basically prevent AST to be linked with SOFA. >> It is questionable whether this is a legal restriction at all > Possibly not, but it's what well-mannered scientists actually do. If it is not a legal restriction, it should be not in the license. It should be in the README. >> I tried to contact the SOFA board, but still didn't get an answer. > A reply has been drafted (not by me) and is in circulation. You can > be sure that the Board will respond in due course. (This message is > from me ad hominem.) Thank you very much for discussing your opinion with me. I will wait for the answer of the board and hope that we can find a good compromise. Best regads Ole