#include <hallo.h> * Joerg Schilling [Wed, Mar 22 2006, 03:16:26PM]: > Eduard Bloch <[EMAIL PROTECTED]> wrote: > > > #include <hallo.h> > > * Joerg Schilling [Mon, Mar 20 2006, 11:21:30PM]: > > > > > It seems that you never did read and understand the GPL :-( > > > > > > The GPL is as holey as a Swiss cheese when talking about the compile > > > environment: > > > > ... > > > > Joerg, could you please stay ontopic and not flame? We try to discuss > > with you... > > Sorry, I definitely did not flame but I don't have impression > that you are intrested in a discussion! > > So please reply to my mail instead of adding unrelated new stuff.
Well, why do you not reply to my mail first instead of stripping everything away including the uncomfortable but pretty relevant questions? Why do you think that you are the only one allowed to give the direction of the discussion? How should we get the answers for the actual topic if you avoid giving them? > > And we *do* understand the GPL, and its not only one interpretation of > > the GPL. You can read our -legal list too see much more of that, please > > look at [URLS] for more information. > > Sorry, but the way you are arguing shows that you obviously have problems > to understand the GPL. As said before, our understanding of the GPL conforms with what most Debian developers think. Why do you think that your "interpretation" is the only valid one? > ----> Please tell me why you are trying to use the "majestetis pluralis"? Of course: because I consulted our internal cdrtools maintainer group and I am also refering to the comments of debian-legal people. I am not your lone crazy opponent. > **** Unrelated stuff removed ***** > > > And finally, in the last mail I have already presented the exact chain > > of conclusions, including the intent of the OP. I expect you (as > > programmer knowing how logic works) to be able to find the wrong link > > there -- so would you consider answering this (uncomfortable) question? > > > > URLS: > > http://lists.debian.org/debian-legal/2006/03/msg00362.html > > The person did not understand the GPL and is writing unrelated stuff. So your only explanation is that most people out there did not understand the GPL while you do? Even if we explain to you in detail how we believe the GPL should be interpreted? Giving the best opportunity to demonstrate the inconsistencies or wrong conclusions in this explanation? > See my last mail for more information. It did not contain anything new, you are repeating your views and "interpretations" but that does do not make them more true or valid. > > http://lists.debian.org/debian-legal/2006/03/msg00391.html > > Unrelated to our discussion. Indeed, it adresses another problem with the cdrecord source, but the issue is not that different. The presense of GPL-incompatible invariant sections is well related to our discussion. Since you seem to have read read our official guidelines, DFSG and the Social Contract I guess you know that "we do not hide problems" is one of the primary principles there. We consider incompatible license mixtures to be a such problem. For the cdrtools package, we can only state: Either it is GPL or it is not, we do not accept incompatible mixtures. Like restrictions hidden somewhere in the code like a wulf in sheep's clothing. Please stop telling us that all your license modifications can be fully explained with a valid interpretaton of the GPL. None of the supposed holes in its wording gives enough room for making such obfuscated "interpretations", you can hardly convince anyone of the validity of such claims (and not of an artificially created restrictions). You do not even care about showing any good precedent case when calling GPL "holey as a Swiss cheese". > > http://lists.debian.org/debian-legal/2006/03/msg00376.html > > This is what I did explain in my last mail! > > Why don't you read my last mail? Why don't you read mine before? I doubt you will answer this honestly so I repeat the things said there: |- It requires scripts to be present, but makefiles are no scripts, | they are just code in a different language. The common definition for "script" is a list of connected commands interpreted by a native application. Even much more sophisticated languages like Perl/Python/... interpret files called scripts (referring to their documentation). Your "code" is written in plain text, containing mostly program invocations or closely related instructions, and the whole thing is interpreted by a native application. Everything required for beeing declared as "script" in terms of GPL is there. |- Sources based on the Schily Makefilesystem require 'smake' to | compile on all platforms. Smake is not part of the source packages | and not required by the GPL. On some of the platorms GNU make | may help you but as GNU make is extremely buggy, you will have | problems on almost every platform although GNU make claims to | run enywhere. GNU make is not even present on mostz platforms. Remember, this discussion is not about smake. Please come back to the current topic. And you have already said all that before. And that is what I have explained before. And you still do not understand or refuse to realize, simply ignoring the explanation. So again: - if cdrecord is licensed under GPL and you officially state that it is official GPL without artificial restrictions, then you must provide the build system (at least all required "scripts") required for the compilation, licensed under the same license (GPL). GPL says that quite explicitely. Please read it if you have not done yet. So where is the GPL compatible build system? Not there? In this case we need to add a GPL-compatible build system or, alternatively, remove the package from Debian because of license violation. - if your license is not GPL but a modified version of it, please show us your complete license text. Then we will need to investigate how far the GPLed source in the cdrtools package is infected it by it to know whether we need to remove all cdrtools programs or just cdrecord. |- The GPL does not require the Compiler or other needed programs | to be part of the sources although they may be needed. GPL specifies with sufficient precision which parts of the build environment belong to this exception. Your build system is certainly not among them since nobody (or hardly anyone) distributes it together with the usual OS distribution. Quoting GPL section 3: | "The source code for a work means the preferred form of the work for | making modifications to it. For an executable work, complete | source code means all the source code for all modules it contains, | plus any associated interface definition files, plus the scripts | used to control compilation and installation of the executable. | However, as a special exception, the source code distributed need | not include anything that is normally distributed (in either source | or binary form) with the major components (compiler, kernel, and so | on) of the operating system on which the executable runs, unless | that component itself accompanies the executable. > > > If you would understand enough from the topic, you would understand that > > > the "related" makefiles of my software are always present under the same > > > license as the rest of the project but the unrelated (because project > > > indepentent) makefilesystem is just available under it's native license. > > > > Somehow all our other GPLed software has "related build software" either > > licensed under GPL compatible license (*) or beeing that far different that > > its maker can declare the outcome as a product rather than a derivate > > (compilers). > > See above, you did not read the mail you are replying to..... > > Let me explain it another time: > > "cdrecord/Makefile" is no script but a program used to control compilation > of the sub project cdrecord. This file is part of the cdrtools project as well > as "TARGETS/cdrecord" is. That is not what the GPL says. You play with definitions of "part" and "project" and "medium", trying to navigate between facts and constraints that are written down. GPL is not a one-way license. Please show the build scripts which we can use to build cdrtools and which are licensed under the GPL. Please do that now, instead of redirecting the discussion into another loop. > "RULES/rules1.top" is part of another project and not part of the project > cdrtools. This file may be under a different licernse for this reason (unless > you define the GPL as a licence that is voiolating the DFSG). I still do not understand why you keep refering to DFSG. We talk about GPL compliance all the time. If the Schilly build system is a strong prerequisite required to build the GPLed software, then it must be licensed under the GPL. If you insist on declaring it as a different project than it should be separated. And in this case we need a GPL compatible build system, as said above. > The smake source is also another project and _not_ even included although you > need smake on most platforms. We do not talk about smake. Please come back to the current discussion. > Please do not reply again unless you have new arguments that are really > related > to the claims of the OP. All arguments have been presented to you. Now it is time to decide whether cdrecord is licensed under the GPL and you follow its terms (and so also everyone else is allowed to follow them without restrictions) or to choose another license. You have been told what the consequences of your decission will be. Repeating again: we consider removing cdrtools from Debian. This is the usual practice and we normaly place problematic licensing over all other things (at least for the main section), including useability. It's as easy as that, it has been done before in cases of license cheating or license conflicts, see http://www.google.com/search?q=debian+gpl+qpl for one famous example. There is no shame in changing the attitude, Trolltech was hardly harmed by double-licensing Qt at that time. So, in the same way we cannot force you to change the license (without an expensive lawsuit about the GPL interpretation) you cannot force anyone to distribute your software. And you shall not be allowed to abuse our resources while trying to restrict the freedom of software. Now it's your turn. We plan to wait few weeks for a competent and complete answer or a release of cdrtools without any invariant sections ("invariant" as in: having comments forbidding people to modify code parts. GPL already states what the obligations are, there is no need for additional comments). MfG, Eduard, spoken on behalf of Debian cdrtools maintainers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
