#include <hallo.h> *Joerg Schilling [Sun, Dec 10 2006, 10:38:15PM]: First, sccsids are unused code. They have been removed for technical reasons, and because no usual user and no regular program seem to use them (see below). And they are disturbing the QA work by triggering compiler warnings. But what should I teach you? You know that perfectly well, the '#ifndef lint' cludge indicates a workaround for that problem already.
They can be readded easily (but then with a special flag to tell GCC to be quiet about unused code). Whether we should do that is not my decission. > Stop abusing the Debian Bug tracking system! > > There is a serious Copyright violation in the current SVN for "cdrkit" > caused by the fact that Copyright notices have been removed without > permission > >from the Authors. So you accuse us of breaking the law while we have not done it [1]. Even IF someone could follow your "special" logics and think that not adding stuff to unused machine code is some violation... uhm, we are not distributing object code yet, are you blind? Why do you open invalid bug reports in the Debian BTS? Maybe to give them more Google hits and get more publicity for your propaganda? > The notices in question that have been removed make sure that the binaries > compiled from the sources still carry the Copyright notices. The GPL tells to add copyright notices to the source, and the law (UrhG) tells to add copyright holder information on visible places. Source headers and documentation are such places. Binary code internals are not such places. Why not? Because they are not visible for "normal" people. Sccsids are aliens in the GNU world. Nobody looks for them in the binary code. Uhm... compare it to use the invisible tint in the books in the real world. There is no "regular system tool" to extract them. AFAICS there is only one free clone of this proprietary SCCS system that one has to explicitely install (and it is not called sccs anyway). Hardly anyone would use it to retrieve copyright information. Uhm... so the magic light needed to see your invisible tint is available in the hands of few secret service people, and few hobbyists that created a clone of that light without permission. And compilers could legally throw such stuff away so this method of information distribution is not really reliable. But program documentation and source code headers are, and that is what GPL talks about. And what we care about. There is no additional "choice of compiler" restriction in the GPL. If want to make the choice of compiler and compiler flags to be a part of your license, then the license is non-free. Do you want to say it is non-free? But why should I teach you? You and your fellows distribute SchilliX. I looked at it and the first non-standard binary coming to my mind (wget) had no sccsid strings inside. How comes? You are violating a license even by your standards? And there are more of that kind. And on regular GNU systems ONLY FEW binaries in /usr/bin/* provide such information. And the most verbose/penetrant ones are those from you or where your code is involved (cdrdao). Are you going to say that every distributor is violating the license of 99.9% (guessed number) of copyright holders around? Or let's look at your cdrtools source. Many mkisofs' files have scssid but there is no indication about all copyright holders. Even on those not written by you. So you are violating Eric's license in write.c? And in udf.c you added yourself and only yourself to the sccsid string but the the headers primarily says 'Written by Ben Rudiak-Gould (2001)'. If the sccssid mean as much as you claim, does your sccsid string mean that you hide Ben's copyright? Sorry Joerg, your own actions are so self-contradictory that nobody can take your claims seriously. Eduard. [1] Einst hast du mich auf die gleiche Weise der üblen Nachrede beschuldigt. Soll der Boomerang jetzt zurückkehren? -- <miro> ich bin ja auch ein sehr ueberzeugter windoze nutzer <miro> ja windoze ist toll! <miro> samba ist scheisse <miro> ich versteh nicht warum ihr das nicht begreift...
