#include <hallo.h> * Joerg Schilling [Sat, Mar 18 2006, 10:10:55PM]: > > > You did write (easy to proof as) false claims many times in the past. > > > Just remember the case where you did call Sun Studio C "rubbish" just > > > because > > > it flags bad code that GCC let's pass. > > > > He? I cannot remember writting this, and I would not use the word > > "rubbish". > > Let me quote you: > > ----> > Das behauptest du EINFACH SO, weil dein Compiler ein Paar irrevelevante > Meldungen ausgespuckt hast? Amen. > <---- > > Looks similar to what I had in mind.....
Jeez, you have ways of finding "similarities". I would hardly translate that as "rubbish" especially because of the context - it has been on the same polemic levels as your claims about gcc because of beeing less pervasive than Sun's compiler. Even then, is that all of my "false claims" that you can find? Maybe you better your own ways of checking the correctness of a program? I still wonder how you can declare hidding of filename truncation "okay", for example. Or maybe you would like to stop with digging the old graves and return to the current issue? > > > Have a look at http://www.us.debian.org/social_contract and try to > > > understand > > > what section 9. "License Must Not Contaminate Other Software" means: > > > > > > > > > The license must not place restrictions on other software that is > > > distributed along with the licensed software. For example, the > > > license > > > must not insist that all other programs distributed on the same > > > medium > > > must be free software. > > > > > > In our case, the "medium" is the tar archive that is used to publish > > > cdrtools. > > > > Hear, hear. And what does the file "COPYING" with the GPL license text > > do there, in the main directory of your "medium"? Is it not supposed to > > cover the whole thing, as in "placing restrictions on other software"? > > YOU placed the license file there and I interpret your statement as a > > direct proposal to separate the split the package into the "code" and > > "build system" parts. Correct? > > ??? What is so hard to understand? If you declare your source package as "medium" than it is okay to split it into atomic source packages with different license, following YOUR interpretation. In this case we have a build system package and a code package. But that code package does not have a component required to be built, which is required by the GPL! You may not like the conclusion but it is built from what you said. If you wish to change that, license the whole tarball under the GPL and we have the old situation. Or double-license that parts with GPL as alternative (as done by perl, now we are back to my first mail). Otherwise, we we have only few options: - remove cdrtools from Debian and put it into Debian/non-free - replace the RULES/* part with an excerpt of an older cdrtools version - replace the build-system with something else, autoconf version created in the dvdrtools fork looks quite useable Which one do you prefer? > > > But before you do that, it would make sense to think whether the claims > > > of the > > > OP make sense at all..... > > > > If you follow the extreme GPL-interpretation of the OP you are clearly > > violating the GPL and any contributor to cdrtools has the right to sue > > you. I do not read it that way and I know your role in the cdrtools > > development, but you do not make it easy :-( > > Nice to see: Now we are back to the content of my first mail..... I don't see how. > Iff Debian would follow the extreme GPL-interpretation of the OP, Debian would > need to call the GPL clearly non-free because it then would violate the DFSG > Section 9. Now we are back to my second mail. "distribute along" either means two separate works on the same medium or two different works. GPL does not affect separate works which are just distributed along on the same medium, so there is no violation of section 9 if you like the components to be seen as separated works (if you don't, we have an case of license inconsistency which needs to be resolved or the package becomes unsuitable for Debian). So if the components are to be separated, we have to do this. When we do this, we have a CDDL component (okay, we may reuse this package for star later), and we have a unbuildable cdrtools code package, which needs a GPL-compatible build system (as required by the GPL). Now please would you show me one faulty link in this chain of conclusions. And I mean that literally, please answer without another "because I say so and because FOO violates <random excerpt> and therefore I am right". > As Debian calls the GPL "free", the claims of the OP obviously do not > apply from Debians view. Sorry, who exactly is representing Debian here? > So let us close this for now, or do you like to start an endless discussion? We have to resolve that issue, and the length of this discussion depends on the time where you begin to defend your position by arguments rather than rants against our official documents. As said, the alternative is kicking cdrtools out of Debian which may be not a considerable option for many people. > The CDDL is clearly accepted by OSI and I did not yet hear that Debian > DFSG rules have become different from the OSI rules. > > Why should Debian have problems with the CDDL? Ehm... because OSI and FSF are different organisations? I do not like GPL either and I try to avoid it for my free works without possible, that in this case you have already GPLed cdrtools and a resolution must be found. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
