Re: cdrtools alternatives
On Tuesday 15 August 2006 13:17, Nathanael Nerode wrote: Florian Weimer wrote: * Nathanael Nerode: In reality, as user A, I switched to using cdrdao for making serious audio CDs and CD-RWs, and for burning disks from .iso files: this uses Schilling's scsilib, but not the rest of cdrecord. What about mkisofs? Heh -- that's a point. Actually, I don't use it when creating audio CDs (for obvious reasons), and I don't usually create data CDs except by burning *other people's* .iso files, since I use DVDs instead lately. But I noticed that growisofs *does* use mkisofs as a backend. We definitely need a functional mkisofs in Debian. mkisofs is certainly part of cdrtools. But not of cdrecord. Nothing in mkisofs has weird conditions on the GPL, unlike other parts of cdrtools (libscg, cdrecord.c), so it should be straightforward to make a free fork. And it was originally written by Eric Youngdale. Likewise cdda2wav. It looks like the cdrecord package contains all the 'problem areas', and the other packages built from the cdrtools source package contain no problem areas. It's actually tempting to fork those two out as fully independent source packages. They have little to do, code-wise, with CD recording. Right, forking up mkisofs only is one way to go, unless you find out that mkisofs code is a little bit of mess and find it hard to maintain, but it is not so bad anyway to stay there till a complete replacement matures enough to take it over. Fortunately there is a libburn (which contains libisofs) library to write optical dics recorders and iso filesystem-creators apps on the top of that like the recently packaged cdrskin. Unfortunately two libburn teams and source trees exist [1] which makes their users to maintain an enhanced snapshot for their own purposes, like cdrskin currently does. It currently lacks tao, audio, multi features, and writes CD-R and CD-RW only, but the upstream is active, very cooperative and tries to push improvements to the pykix fork of libburn. There is a nice attempt to post an empty hull of genisofs [2] (which is intended to be based on libisofs) to the pykix fork ticket system. Currently icculus's libburn is packaged in Debian, but it might be a good idea to switch to pykix fork at some point. While looking at #272644 it has been discovered that the open(2) manpage does not describe completely how O_EXCL option acts on a block device. I.e. what happens if an app using open(2) with O_EXCL | O_CREAT is run on the top of an old kernel which does not contains that O_EXCL functionaly. We found that post to lkml and I think that it would be nice to extend open(2) manpage with that important information. I will file a wishlist bug against manpage-dev at some point later. [1] the original effort http://icculus.org/burn/ (already packaged in Debian) and a recent fork at http://libburn.pykix.org [2] http://libburn.pykix.org/ticket/24 http://libburn.pykix.org/wiki/GenIsoFs [3] http://lkml.org/lkml/2006/2/5/137 -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools alternatives
* Nathanael Nerode: In reality, as user A, I switched to using cdrdao for making serious audio CDs and CD-RWs, and for burning disks from .iso files: this uses Schilling's scsilib, but not the rest of cdrecord. What about mkisofs? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools alternatives
Florian Weimer [EMAIL PROTECTED] writes: * Nathanael Nerode: In reality, as user A, I switched to using cdrdao for making serious audio CDs and CD-RWs, and for burning disks from .iso files: this uses Schilling's scsilib, but not the rest of cdrecord. What about mkisofs? So far JS has not made any trouble about mkisofs that I know of. Not like cdrecord flaming anyway. You still use that. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools alternatives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Weimer wrote: * Nathanael Nerode: In reality, as user A, I switched to using cdrdao for making serious audio CDs and CD-RWs, and for burning disks from .iso files: this uses Schilling's scsilib, but not the rest of cdrecord. What about mkisofs? Heh -- that's a point. Actually, I don't use it when creating audio CDs (for obvious reasons), and I don't usually create data CDs except by burning *other people's* .iso files, since I use DVDs instead lately. But I noticed that growisofs *does* use mkisofs as a backend. We definitely need a functional mkisofs in Debian. mkisofs is certainly part of cdrtools. But not of cdrecord. Nothing in mkisofs has weird conditions on the GPL, unlike other parts of cdrtools (libscg, cdrecord.c), so it should be straightforward to make a free fork. And it was originally written by Eric Youngdale. Likewise cdda2wav. It looks like the cdrecord package contains all the 'problem areas', and the other packages built from the cdrtools source package contain no problem areas. It's actually tempting to fork those two out as fully independent source packages. They have little to do, code-wise, with CD recording. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE4Z9IRGZ0aC4lkIIRAmLxAJ0eER+arucHyFwThcIAalBTfN+OQgCdGz7X pfAsiX2FHk081X8TMVmtfg8= =DMWp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Riku Voipio [EMAIL PROTECTED] wrote: On Mon, Aug 14, 2006 at 04:09:33PM +0200, Joerg Schilling wrote: This is of course a lie.or why don't you like to prove it: http://cdrecord.berlios.de/old/private/problems.html Come back to reallity, the k3b maintainers did already give up with Debian versions of cdrtools and use self-compiled unmodified originalsources. This is of course a lie.or why don't you like to prove it? You are of course lying... Neither upstream or debian packaging k3b includes unmodified originalsources of cdrtools, nor give instructions to users to use unmodified sources. Well, I have a private mail exhange that proves my claim. Come back to reality, stock Debian K3B burned just some minutes ago a fine bootable cd. *Thanks* to the patches in debian cdrtools that allows it to work with recent 2.6 kernels. But then again, we are probably in different realities anyway. Come back to reality: Cdrecord from Debian does not work correctly _because_ of the broken patches. Try to understand that the fact that it _may_ work under certain conditions does not make it work for all cases and with all drives. The Linux Kernel people decided to filter away important SCSI commands I need with cdrtools. The Debian patches do nothing but to _hide_ the warnings, cdrecord and other programs from the cdrtools emit in order to inform the user that something went wrong. My current version of cdrtools on the other side include a _solution_ for the problem caused by the Linux Kernel folks (incompatibly changing interfaces). Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Florian Weimer [EMAIL PROTECTED] writes: * Thomas Bushnell: As a countermeasure, the FSF tries to extend copyright to interfaces, so that you do create a derivative work merely by programming to a specific interface of a library written by someone else, without copying their code. I'm not sure if this is such a bright idea. Interface copyright attempts to prohibit making a second implementation of the same interface. That is not what is going on here. I think you mean *user* interface copyright. Interfaces between pieces of interoperable software often have no clear distinction between the roles of user and program. Nothing I said was specific to user interface copyright. And to some extent, the FSF must claim that it's not possible to escape the GPL with a second implementation (so that programs linking to readline must still be GPLed, even though you could use libedit as a mostly-transparent replacement, for instance). No, the FSF does not claim this in fact. However, if you are Debian and distributing a binary that depends upon the readline library and is in fact linked against that library, then the GPL's restrictions come into play. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
* Thomas Bushnell: As a countermeasure, the FSF tries to extend copyright to interfaces, so that you do create a derivative work merely by programming to a specific interface of a library written by someone else, without copying their code. I'm not sure if this is such a bright idea. Interface copyright attempts to prohibit making a second implementation of the same interface. That is not what is going on here. I think you mean *user* interface copyright. Interfaces between pieces of interoperable software often have no clear distinction between the roles of user and program. And to some extent, the FSF must claim that it's not possible to escape the GPL with a second implementation (so that programs linking to readline must still be GPLed, even though you could use libedit as a mostly-transparent replacement, for instance). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On 8/14/06, Florian Weimer [EMAIL PROTECTED] wrote: And to some extent, the FSF must claim that it's not possible to escape the GPL with a second implementation (so that programs linking to readline must still be GPLed, even though you could use libedit as a mostly-transparent replacement, for instance). Well, if you ship a binary linked against readline, it's not totally unthinkable that the source of the program should be available under a GPL-compatable licence. On the other hand, if you ship the binary not linked against readline, or linked against editline instead, there's no reason that the source has to be distributed under a GPL-compatable licence just because the program _could_ be compiled against readline. If the source is not under a GPL-compatable licence, doesn't that just mean the resulting binary is not distributable at all? The GPL only give rules about redistribution, it doesn't change the licence of anything. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Hubert Chan [EMAIL PROTECTED] wrote: The GPL (section 3) does restrict distributions of binaries (object code or executable form, to use the words of the GPL, to be more accurate, since the GPL only uses the term binary once, and only to refer to a completely different issue) and states that such binaries must be distributed under the terms of sections 1 and 2 (which seem to be the important parts of the GPL as far as Debian is concerned). ... please _read_ GPL §2, it talks about less code than GPL §3 does and even a reference from GPL §3 to GPL §2 does not change things in GPL §2 and only the parts of the code mentioned in GPL §2 needs to be put under GPL I did never claim that any possible combination of CDDL GPL code is permitted. ... Understood. I think that we all agree that, say, taking code licensed under the CDDL and linking it to a GPLed library is not allowed. (And we all agree that that is not the situation that we're talking about.) ANd what I do: GPL code uses CDDL license seems to be accepted by e.g. Eben Moglen. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Joerg Schilling [Sun, Aug 13 2006, 12:28:15PM]: The original sources do not have such bugs and many Debian users that Most of that is true if and only if the users follow your recommendations and strictly use kernel 2.4.x, ide-scsi emulation and install your programs as suid-root. You again prove that you are uninformed. If you did really work as Debian cdrtools maintainer, you would have read the bug reports (in special Debian bug #374685): /*--*/ I am not sure if I understand you the right way, but the facts are: - On previous Linux versions, it was possible to make cdrecord work without root-privs in case you did compromize security on that system and in case you did not care about coasters or write quality. - With Linux 2.6.x, it is impossible to run cdrecord without root privs. Do not believe single persons who claim otherwise as Linux-2.6.x filters away random SCSI commands when cdrecord does not have root-privs and as cdrecord heavily depends on the fact that the SCSI protocol depends on SCSI commands that fail because they are not supported by the actual drive in order to correctly support the features of the actual drive. It is definitely impossible to support correct DVD writing without having root-privs. - Recent cdrecord versions (see ftp://ftp.berlios.de/pub/cdrecord/alpha) include workarounds for the incompatible interface changes on recent Linux versions and allow you to use cdrecord in case it has been installed suid-root. - The latest cdrecord version on Debian is definitely broken. My suggestion is: - get a recent copy of the original cdrtools source from ftp://ftp.berlios.de/pub/cdrecord/alpha and compile it. - Install the cdrecord/cdda2wav/readcd binaries suid root. /*--*/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Goswin von Brederlow [EMAIL PROTECTED] wrote: Do you really believe that you are able to deflect from the main problem: The original sources do not have such bugs and many Debian users that did write bug reports against the Debian version of cdrtools did already switch to a self compiled original source in order to get a working cdrecord. Why don't you read my reply? I rather burn my own CDs/DVDs and see for myself if the program works. Your source: total failure. Debian source: works perfectly for years. Conclusion: Debian patches are GOOD. And that for years and years. Nice try for trolling: This is of course a lie.or why don't you like to prove it: http://cdrecord.berlios.de/old/private/problems.html Come back to reallity, the k3b maintainers did already give up with Debian versions of cdrtools and use self-compiled unmodified originalsources. Guess why? It is the Debian variant that dioes not work while the original works out of the bix. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
- With Linux 2.6.x, it is impossible to run cdrecord without root privs. Do not believe single persons who claim otherwise as Linux-2.6.x filters away random SCSI commands when cdrecord does not have root-privs and as cdrecord heavily depends on the fact that the SCSI protocol depends on SCSI commands that fail because they are not supported by the actual drive in order to correctly support the features of the actual drive. Perhaps this stupid feud can soon become a thing of the past. http://lwn.net/Articles/193516/ indicates that future versions of the kernel will allow userspace to control the list of SCSI commands that are filtered. The cdrecord package can simply empty this list during bootup. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Mon, Aug 14, 2006 at 04:09:33PM +0200, Joerg Schilling wrote: Goswin von Brederlow [EMAIL PROTECTED] wrote: Do you really believe that you are able to deflect from the main problem: The original sources do not have such bugs and many Debian users that did write bug reports against the Debian version of cdrtools did already switch to a self compiled original source in order to get a working cdrecord. Why don't you read my reply? I rather burn my own CDs/DVDs and see for myself if the program works. Your source: total failure. Debian source: works perfectly for years. Conclusion: Debian patches are GOOD. And that for years and years. Nice try for trolling: This is of course a lie.or why don't you like to prove it: http://cdrecord.berlios.de/old/private/problems.html Well, that's a nice page isn't it... rather than try to assist in the distribution of your software with the major players, instead you decide to slag them all off in one go. Congratulations. You are an anally retentive muppet. Come back to reallity, the k3b maintainers did already give up with Debian versions of cdrtools and use self-compiled unmodified originalsources. *YAWN* - so, does k3b in debian use a non-debian version of cdrecord? really? are you sure? because k3b worked fine for me last time I was in need of it (doesn't happen often). Guess why? It is the Debian variant that dioes not work while the original works out of the bix. Weird, debian version works fine for me... Maybe it's muppets like the upstream for cdrecord... yes, that's you Joerg... that makes it so that people just give in - you have an inane ability to really really annoy the hell out of very many people - here's hoping that all remnants of your crappy, half baked software with dumb licencing gets removed from the debian archive soon - maybe then you'll shut the hell up and let everyone continue with life. Thanks, -- Brett Parker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, Aug 11, 2006 at 10:57:45PM +0200, Joerg Schilling wrote: Joerg Jaspert [EMAIL PROTECTED] wrote: You should look at the video I pointed you at. You just accused me of being a liar. If i would have your low level I would now do the same you I did look at this video: it verifies what I say! If you carefully look at the video, you see that Simon is angry with Danese because she does not tell the truth but he does not like to correct her in the public. Woah, hang on... so lemme get this straight - rather than actually using the *content* of the video, we're supposed to believe your interpretation of someones body language that's NOT EVEN SPEAKING?! Err - right - yeah, lets do that. Muppet. -- Brett Parker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
interface copyrights, was: Re: cdrtools
Hello, On Sat, 12.08.2006 at 20:40:37 +0200, Florian Weimer [EMAIL PROTECTED] wrote: As a countermeasure, the FSF tries to extend copyright to interfaces, so that you do create a derivative work merely by programming to a specific interface of a library written by someone else, without copying their code. I'm not sure if this is such a bright idea. I'm quite sure that this is *NOT* a bright idea and hope that they don't do this. If they really pursue that route, they will imho break their own neck by eg. legitimizing claims and demands brought forward against the Samba crew. I have a hard time imagining that this is what they really want, at least right now, but then, a lawyer might point out my errors in understanding this... Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Mon, Aug 14, 2006 at 04:09:33PM +0200, Joerg Schilling wrote: This is of course a lie.or why don't you like to prove it: http://cdrecord.berlios.de/old/private/problems.html Come back to reallity, the k3b maintainers did already give up with Debian versions of cdrtools and use self-compiled unmodified originalsources. This is of course a lie.or why don't you like to prove it? Neither upstream or debian packaging k3b includes unmodified originalsources of cdrtools, nor give instructions to users to use unmodified sources. Come back to reality, stock Debian K3B burned just some minutes ago a fine bootable cd. *Thanks* to the patches in debian cdrtools that allows it to work with recent 2.6 kernels. But then again, we are probably in different realities anyway. Cheers, Riku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
This one time, at band camp, Riku Voipio said: On Mon, Aug 14, 2006 at 04:09:33PM +0200, Joerg Schilling wrote: This is of course a lie.or why don't you like to prove it: http://cdrecord.berlios.de/old/private/problems.html Come back to reallity, the k3b maintainers did already give up with Debian versions of cdrtools and use self-compiled unmodified originalsources. This is of course a lie.or why don't you like to prove it? I'm not trying to pick on you, Riku, but please, let's stop. It's clear that on the one side, there's the JS point of view: Debian only exists to steal my time My code is so portable it will run on anything except kernels that have been maliciously modified by upstream to thwart me It is absolutely OK to mix incompatible license, you can tell by some guy's facial expression when the license's author is talking On the other hand, there's the rest of the world: Put down the crack pipe and step away slowly These two points of views seem unlikely to be reconciled, so can we just end the discussion and move on? At least some versions of cdrecord are under a free license, and are there for forkable, some upstream whimsical interpretations notwithstanding. Let's just get on with it. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
cdrtools alternatives (was Re: cdrtools)
Eduard Bloch wrote: Then let's see what a user of your software would do, in a not-so-uncommon use case: User A wants to burn a CD-ROM. She gets cdrtools, In reality, as user A, I switched to using cdrdao for making serious audio CDs and CD-RWs, and for burning disks from .iso files: this uses Schilling's scsilib, but not the rest of cdrecord. (Actually, it can be configured not to use scsilib. So if there are concerns about the licensing of scsilib, it looks like this can be done any time. cdrdao-1.2.1/dao/ScsiIf-linux.cc could use some updating and improvement of course, since the sg driver has changed since version 2.2.6) For DVD burning, of course, I use dvd+rw-tools. This is completely independent of cdrtools. And data CD-RWs are handled out of the box with packet writing as block devices by the kernel as of kernel 2.6.10 (the so-called pktcdvd module), also independent of cdrtools. So what does that mean? That means that cdrtools is needed only for TAO writing of CD-R and CD-RW media. The only usage cases for this which are not better served by a different tool are: * incremental additions for data CD-Rs * incremental additions to audio CD-Rs * incremental changes for audio CD-RWs While it would be nice to have a tool in Debian to do those three things for those who want to, it is really not essential. I have stopped using it entirely: for incremental work, I use DVD+RW or DVD+R media, and for archival work I make CDs in DAO mode with cdrdao. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Goswin von Brederlow [EMAIL PROTECTED] wrote: Joerg Schilling [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] wrote: Why do you insist on programming bugs into cdrtools that linux distributions have to fix by patching? You should inform yourself about reality Are you willing to put money where your mouth is and offer a reward for finding a bug like the tex author does? Do you really believe that you are able to deflect from the main problem: The original sources do not have such bugs and many Debian users that did write bug reports against the Debian version of cdrtools did already switch to a self compiled original source in order to get a working cdrecord. Why don't you read my reply? I did never claim that cdrecord is free of bugs, but it works out of the box on Linux while the version Debian publishes does not because Debian introduced bugs into cdrtools that are not present in the original. See bugs caused by Debian's malicious patches: 374685, 297027, 309250, 330506, 347596, 360295, 295593, 297514, 392803, 309812, 317793, 325766, 328308, 330180, 339459, 335253, 335253, 350330, 350342, 370603, 374345, 377069, 377421, 377588, Problems cause by the fact that Debian is unmaintained and does not use recent cdrecord original versions: 302717, 293953, 295698, 347596, 372486, 330180, 330459, 350330, 350342, 377069, 377421, 249621, Problems caused by the fact that malicious Linux kernel people crippled the Linux kernel interfaces to the disadvantage of cdrtsools: 310689, 147504, 234013, 295698, 150113, 335253, 350330, 350342, 377069, 377421, 381137, Bugs that newer have been present, that may be caused by defective drives or have been fixed long ago in the original. Note that the fact that the Debian bug list still contains these bugs verifies that the Debian Maintainer is not doing real work but the only goal of Debian is to steal my time by pulling me into useless discussions: 262486, 143963, 278071, 288091, 292381, 299562, 306073, 307274, 311181, 312062, 340429, 342085, 360496, 360831, Note that some of the bugs from the last category have been posted because Debian gives wrong usage advise to their users (advise that contradicts the official documentation). Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
#include hallo.h * Joerg Schilling [Sun, Aug 13 2006, 12:28:15PM]: The original sources do not have such bugs and many Debian users that Most of that is true if and only if the users follow your recommendations and strictly use kernel 2.4.x, ide-scsi emulation and install your programs as suid-root. Every attempt to persuade you of going along with mainstream development and accept the existence or more recent user requirements leads only to reading your usual text blocks about bad, evil, inept kernel developers and recommendations to install as suid-root and so in defacto no progress. And don't tell me I am lying, our BTS is full of them. I did never claim that cdrecord is free of bugs, but it works out of the box on Linux while the version Debian publishes does not because Debian introduced bugs into cdrtools that are not present in the original. Then let's see what a user of your software would do, in a not-so-uncommon use case: User A wants to burn a CD-ROM. She gets cdrtools, compiles it and tries to burn a CD. User A belongs to the group cdrom on a machine with a stable kernel 2.6.x (because kernel 2.4 does no longer work on this two years old system) and has write permissions to /dev/cdrw (whatever that device is). User A is not root and there is no sudo shortcut or so. Using your original software there is no solution for this most simple case. And so there is no point in throwing hot air, talking about bugs, broken, ..., as long as you are not willing to provide one. See bugs caused by Debian's malicious patches: 374685, 297027, 309250, 330506, 347596, 360295, 295593, 297514, 392803, 309812, 317793, 325766, 328308, 330180, 339459, 335253, 335253, 350330, 350342, 370603, 374345, 377069, 377421, 377588, From the unreleased branch developed in spring: Closes: 271114 278894 283794 295438 304230 309250 310689 310689 312062 312062 314139 317793 325766 326138 342085 344214 33 350254 350739 353176 353403 355291 and some recently reported duplicates can be closed along with them. Problems cause by the fact that Debian is unmaintained and does not use recent Not unmaintained but blocked... guess why... Eduard. -- Im Leben muß man zu rechnen verstehen, aber nicht auf die anderen -- Paul Jean Toulet -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] wrote: Joerg Schilling [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] wrote: Why do you insist on programming bugs into cdrtools that linux distributions have to fix by patching? You should inform yourself about reality Are you willing to put money where your mouth is and offer a reward for finding a bug like the tex author does? Do you really believe that you are able to deflect from the main problem: The original sources do not have such bugs and many Debian users that did write bug reports against the Debian version of cdrtools did already switch to a self compiled original source in order to get a working cdrecord. Why don't you read my reply? I rather burn my own CDs/DVDs and see for myself if the program works. Your source: total failure. Debian source: works perfectly for years. Conclusion: Debian patches are GOOD. And that for years and years. I did never claim that cdrecord is free of bugs, but it works out of the box on Linux while the version Debian publishes does not because Debian introduced bugs into cdrtools that are not present in the original. Bugs caused by upstream relicensing the source to something considered non-free by debian and being too stubborn to work with the kernel developer together or at least follow developement or anyone other Troll for that matter: All of them. Anyway, all our bugs belong to us. It is Debians BTS and not yours. What do you care? The Debian cdrecord clearly states that is it modified just like you demand in the source. It followed all your requirements. Note that the fact that the Debian bug list still contains these bugs verifies that the Debian Maintainer is not doing real work but the only goal of Debian is to steal my time by pulling me into useless discussions: It takes two to tango. If you don't want to disguss then stop. Jörg MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Sun, Aug 13, 2006 at 12:28:15PM +0200, Joerg Schilling wrote: Goswin von Brederlow [EMAIL PROTECTED] wrote: Joerg Schilling [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] wrote: Why do you insist on programming bugs into cdrtools that linux distributions have to fix by patching? You should inform yourself about reality Are you willing to put money where your mouth is and offer a reward for finding a bug like the tex author does? Do you really believe that you are able to deflect from the main problem: The original sources do not have such bugs and many Debian users that did write bug reports against the Debian version of cdrtools did already switch to a self compiled original source in order to get a working cdrecord. Please stop trying to distract us from the important work of replacing your inconsistently-licensed cdrecord in Debian with software that isn't asshole-encumbered. kthx, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Daniel Schepler [EMAIL PROTECTED] writes: According to the GPL, section 0: The act of running the Program is not restricted... And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the mere aggregation clause of section 2. This does not mean that anything that happens when you run the program is not restricted. For example, the act of running GNU cp and sed is not restricted, but that cann't possibly mean that the GPL gives you carte blanche to go ahead and violate the GPL through use of cp and sed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Thu, Aug 10, 2006 at 11:25:11PM +0200, Joerg Schilling wrote: 1)Throw out Eduard Bloch. rotflmao. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Jean Parpaillon [EMAIL PROTECTED] wrote: Beside the licensing issues, why do you care so much patched version of your software to be distributed with big WARNINGS, a different name and tutti quanti ? Why do Linux distributions insist in applying patches that introduce bugs into cdrtools? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
* Daniel Schepler: And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the mere aggregation clause of section 2. As a countermeasure, the FSF tries to extend copyright to interfaces, so that you do create a derivative work merely by programming to a specific interface of a library written by someone else, without copying their code. I'm not sure if this is such a bright idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Gunnar Wolf [EMAIL PROTECTED] wrote: the author's official module). You say that I don't have the right to distribute this under the name PDF::API2 in Debian, do I understand correctly? Please tell me: This module is a Perl library. If I modify it to become PDF::API2::Debian, how will our users' code be portable? You are a funny person. You like to talk avout portabilitiy but the patches that Debian aplies to cdrtools are only from two categories: - Patches that introduce bugs that cannot be found in the original software - Patches that make the Debian version incompatible to the official version and thus prevent portability of scripts and GUI programs What I request from distributors is only a result of the malicious ways well known distributors go. There was no need to add these requirements in case that all distributors would be cooperative. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Florian Weimer [EMAIL PROTECTED] writes: * Daniel Schepler: And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the mere aggregation clause of section 2. As a countermeasure, the FSF tries to extend copyright to interfaces, so that you do create a derivative work merely by programming to a specific interface of a library written by someone else, without copying their code. I'm not sure if this is such a bright idea. Interface copyright attempts to prohibit making a second implementation of the same interface. That is not what is going on here. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling [EMAIL PROTECTED] writes: Jean Parpaillon [EMAIL PROTECTED] wrote: Beside the licensing issues, why do you care so much patched version of your software to be distributed with big WARNINGS, a different name and tutti quanti ? Why do Linux distributions insist in applying patches that introduce bugs into cdrtools? Jörg Why do you insist on programming bugs into cdrtools that linux distributions have to fix by patching? Why do you to typos? Why do you stumble sometimes or trip over something? Do you see how stupid your question is? Nobody intentionaly introduces bugs here. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling [EMAIL PROTECTED] writes: Gunnar Wolf [EMAIL PROTECTED] wrote: the author's official module). You say that I don't have the right to distribute this under the name PDF::API2 in Debian, do I understand correctly? Please tell me: This module is a Perl library. If I modify it to become PDF::API2::Debian, how will our users' code be portable? You are a funny person. You like to talk avout portabilitiy but the patches that Debian aplies to cdrtools are only from two categories: - Patches that introduce bugs that cannot be found in the original software - Patches that make the Debian version incompatible to the official version and thus prevent portability of scripts and GUI programs What I request from distributors is only a result of the malicious ways well known distributors go. There was no need to add these requirements in case that all distributors would be cooperative. Jörg How is the weather today? I told you, the grass is green. Please try to read, understand and answere the question asked in a mail. Hint: The question wasn't about cdrtools patches. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Goswin von Brederlow [EMAIL PROTECTED] wrote: Why do you insist on programming bugs into cdrtools that linux distributions have to fix by patching? You should inform yourself about reality The original sources do not have such bugs and many Debian users that did write bug reports against the Debian version of cdrtools did already switch to a self compiled original source in order to get a working cdrecord. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling wrote: Nice to see that this video clip verifies my statements in case you carefully listen to Simon Phipps: - Sun did not make the CDDL incompatible by intention to the GPL Are you talking about what he's saying at approx. minute 36? That's the closest thing I could find to what you're claiming he said, but he's talking there about why they didn't release OpenSolaris under the GPL. He's not saying anything about whether or not the CDDL is incompatible with the GPL. - The only thing that prevents Linux to use the DTrace code in Linux is the different threading model Actually, what he's saying is that the different threading model prevents you from cut-and-pasting code. He's saying that in order to port DTrace to Linux, due to the different architecture, you would have to basically rewrite it, and so the CDDL would not cause any problems in that case, since you are rewriting, and would not be creating a derivative work. What he's saying is that the technical problems are bigger than the legal problems, and that the most sane way to get around the technical problems are to do so in such a way that the legal problems no longer apply. He is not saying that there are no legal issues. - Eben Moglen tells you that what I do in cdrtools is OK: They the FSF and Moglen have only be in fear that people could interpret the GPL in a wrong way and for this reason added the OS exception, but the GPL does allow to link a GPLd project against libraries under other licenses. He's specifically talking about the so-called operating system exception in the GPL v2, and what the GPL v3 refers to as System Libraries. He's not talking about any random library. -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] wrote: Why do you insist on programming bugs into cdrtools that linux distributions have to fix by patching? You should inform yourself about reality Are you willing to put money where your mouth is and offer a reward for finding a bug like the tex author does? Every programm has bugs. Some more, some less. Tex being a the verry end of less with very very few others. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Sat, Aug 12, 2006 at 09:48:55PM +0200, Goswin von Brederlow wrote: Joerg Schilling [EMAIL PROTECTED] writes: Please try to read, understand and answere the question asked in a mail. Hint: The question wasn't about cdrtools patches. Please try to take off-topic threads to appropriate mailing lists or to private mail exchange. Consider it part of PP. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On 10742 March 1977, Joerg Schilling wrote: Reply-To and M-f-T set to my address, whoever answers please respect this and let this thread die on -devel, its the wrong medium for this discussion, thank you. I am sorry, but I cannot believe that you like to make serious proposal with the text you wrote. Do you believe anything thats not written by you is serious? Let me make a proposal that makes sense for now and the future: 1)Throw out Eduard Bloch. He has been the biggest problem for Debian in the past years. Find a new maintainer with the following properties: I know that you cant work with him (and he with you). 2)Update to a recent cdrtools source, do not hide interesting new features from Debian users and (this may be even more important to Linux users) workarounds for recent Linux kernel self-incompatibilities. You combine CDDL and GPL, and that doesnt work, the two are incompatible. The CDDL is intended to be GPL incompatible. If you dont believe that - even people from Sun, like Simon Phipps and Danese Cooper (now working at Intel, but one of the authors of CDDL) are aware of the incompatibility of the two licenses, and Simon and Danese also said at this years Debian Conference that this is intended. (We had both Simon and Danese there, talking with us about different things including the CDDL). They stated that the GPL incompatibility is *part of the design of the CDDL* If you dont believe that please watch [1] (or [2] if you prefer an mpeg over an ogg). Skip to minute 13 if you dont want to hear all of it, as not everything is interesting for this topic here. Then skip to minute 27 as this is is the more interesting part for the incompatibility, where Danese basically says that they built the CDDL following the Mozilla license *because* it is incompatible with the GPL.. [1] http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/theora-small/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.ogg [2] http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/mpeg1-pal/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.mpeg [3] http://www.sun.com/aboutsun/media/bios/bios-phipps.html And if thats not enough, its not only Debian or Sun stating it, its also FSF, which you can read on http://www.gnu.org/licenses/license-list.html - the relevant text there is: --8schnipp-8--- Common Development and Distribution License (CDDL) This is a free software license which is not a strong copyleft; it has some complex restrictions that make it incompatible with the GNU GPL. It requires that all attribution notices be maintained, while the GPL only requires certain types of notices. Also, it terminates in retaliation for certain aggressive uses of patents. So, a module covered by the GPL and a module covered by the CDDL cannot legally be linked together. We urge you not to use the CDDL for this reason. Also unfortunate in the CDDL is its use of the term intellectual property --8schnapp-8--- There is something else non-free, or at least problematic, in your cdrtools tarball, taken from AN-2.01.01a09: Libscg: - Changed from GPL to CDDL This code may only be used together with other code that is under an approved OpenSource license, see http://www.opensource.org/. That's in my understanding at least *very* problematic. And goes against CDDL3.4 which says You may not offer or impose any terms on any Covered Software in Source Code form that alters or restricts the applicable version of this License or the recipients rights hereunder. (The rest of it talks about warranty, support, indemnity or liability, which is irrelevant. The thing is that 3.6 allows me to use the CDDL licensed work with anything else I want to do, as long as I make sure the requirements of this License are fulfilled for the Covered Software. So, your added statement makes it incompatible with the license shown *and* also with DFSG 5/6, as I may want to combine it with something commercial, following the license rules for the libscg part but not using an OSI license for my software. Another thing with CDDL is §3.3, which is similar to invariant sections of GFDL and one of the reasons why the FSF considers it GPL incompatible as cited above - and the GFDL is not allowed in Debian with such a restriction. Also the choice-of-venue is a nice cost bomb. 3)Remove the unneeded Debian changes as the unmodified original source does not need any changes in order to work correctly. We wouldnt have them if there wouldnt have been a situation where someone needed it. You know, this is what free software is about - the right to change a software if it doesnt work for you. 4)If someone at Debian likes to work on enhancements, make sure that these changes are done in a way
Re: cdrtools
On 10743 March 1977, Joerg Jaspert wrote: [1] http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/theora-small/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.ogg [2] http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/mpeg1-pal/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.mpeg Well, thats meetings-archive.debian.net -- bye Joerg exa There is no point in trying to fix bugs if I won't have an account. Sorry. pgpaS2Oga8fab.pgp Description: PGP signature
Re: cdrtools
Joerg Jaspert [EMAIL PROTECTED] wrote: On 10742 March 1977, Joerg Schilling wrote: Reply-To and M-f-T set to my address, whoever answers please respect this and let this thread die on -devel, its the wrong medium for this discussion, thank you. If we did agree on continuing the mail exchange on a private base, there youle be not problem, but unfortunately, you did send some lies in your mail that need to be corrected first I am sorry, but I cannot believe that you like to make serious proposal with the text you wrote. Do you believe anything thats not written by you is serious? This looks confused. If you do not make a serious proposal you cannot expect that people would take you for serious. Let me make a proposal that makes sense for now and the future: 1) Throw out Eduard Bloch. He has been the biggest problem for Debian in the past years. Find a new maintainer with the following properties: I know that you cant work with him (and he with you). I am willing and able to cooperate with any reasonable person. Eduard Bloch has absolutely no clue and on the other side implicitely claims in his arrogant habbit that he knows more about cdrtools than I do. This makes it impussoble to cooperate with him. 2) Update to a recent cdrtools source, do not hide interesting new features from Debian users and (this may be even more important to Linux users) workarounds for recent Linux kernel self-incompatibilities. You combine CDDL and GPL, and that doesnt work, the two are incompatible. The CDDL is intended to be GPL incompatible. If you dont believe that - even people from Sun, like Simon Phipps and Danese Cooper (now working at Intel, but one of the authors of CDDL) are aware of the incompatibility of the two licenses, and Simon and Danese also said at this years Debian Conference that this is intended. (We had both Simon and Danese there, talking with us about different things including the CDDL). They stated that the GPL incompatibility is *part of the design of the CDDL* Claiming that Sun did make the CDDL incompatible with the GPL is a deliberate lie. The rest of your claims from above include several other untrue assertions: - You claim wrong authors: the authors of the CDDL are Claire Giordano (a lawyer) and Andy Tucker (the former chief engineer for OpenSolaris). - You claim that Simon Phipps sayd at this Debian Conference that an incompatibility was intended. This is definitely not true, I did ask him in a private mail and he replied that he did not say more than that he believes that there are some issues. I am sorry, but it easier to believe him than to believe you. - The general claim that The CDDL is intended to be GPL incompatible. is definitely not true: I had a long private talk (~ 3 hours) with Andy Tucker (in September 2004 at a joint dinner) and I had a 1.5 hour phone call with Claire Giordano and Andy Tucker in December 2004. Since that time I know that Sun had/has no such intention. Andy did tell me that it makes absolutely no sense, trying to forbid that the OpenSolaris code may be used in other OS. The only rules for creating the CDDL have been to allow Sun Solaris to be build on top of OpenSolaris and that the license has a strong copyleft. Also note: the result of the phone call with Claire Giordano and Andy Tucker was that 3 of 4 changes on the CDDL text made in January 2005 have been done on my requests. If Debian people did have issues with the first CDDL draft, they could have done like me. As they did not, it is obvious that Debian peole have no problems with the CDDL. I am not sure who did start spreading the FUD about intended incompatibility, but many Sun people who definitely know better are willing to answer questions about the CDDL in order to avoid rumors about the CDDL. And if thats not enough, its not only Debian or Sun stating it, its also FSF, which you can read on http://www.gnu.org/licenses/license-list.html - the relevant text there is: --8schnipp-8--- Common Development and Distribution License (CDDL) This is a free software license which is not a strong copyleft; it has some complex restrictions that make it incompatible with the GNU GPL. It requires that all attribution notices be maintained, while the GPL only requires certain types of notices. Also, it terminates in retaliation for certain aggressive uses of patents. So, a module covered by the GPL and a module covered by the CDDL cannot legally be linked together. We urge you not to use the CDDL for this reason. Also unfortunate in the CDDL is its use of the term intellectual property --8schnapp-8--- Sorry, but I do not believe people
Re: cdrtools
On 10743 March 1977, Joerg Schilling wrote: If we did agree on continuing the mail exchange on a private base, there youle be not problem, but unfortunately, you did send some lies in your mail that need to be corrected first Yeah. Eduard Bloch has absolutely no clue and on the other side implicitely claims in his arrogant habbit that he knows more about cdrtools than I do. This makes it impussoble to cooperate with him. You know that this is Rufschädigung übelster Art? Claiming that Sun did make the CDDL incompatible with the GPL is a deliberate lie. You should look at the video I pointed you at. You just accused me of being a liar. If i would have your low level I would now do the same you did with a co-maintainer of the Debian cdrtools package and threat with a lawsuit if you dont take it back. I dont. I just add you to my ignore filter and go on. Which means removal of cdrtools from Debian and later readdition of a free fork. The rest of your claims from above include several other untrue assertions: - You claim wrong authors: the authors of the CDDL are Claire Giordano (a lawyer) and Andy Tucker (the former chief engineer for OpenSolaris). Read http://en.wikipedia.org/wiki/Danese_Cooper *and* look into the video I pointed you at. I even gave you exact times where to look. - You claim that Simon Phipps sayd at this Debian Conference that an incompatibility was intended. This is definitely not true, I did ask him in a private mail and he replied that he did not say more than that he believes that there are some issues. I am sorry, but it easier to believe him than to believe you. Watch the video, the minutes I pointed you at. Danese, who was one of those drafting the CDDL had some very clear words. Sorry, but I do not believe people that put things into a GPL FAQ that are obviously wrong. Yeah, you dont believe those people who have written the GPL... I am willing to have a private discussion in case it would make sense and will not be a waste of time. This means that I will immediately stop the discussion in case that you e.g. again claim that Sun did make the CDDL incompatible to the GPL by intention or that you quote the GPL incorrectly in hope to prove claims about the incompatibility of the CDDL and the GPL. As you obviously stay with your opinion and doesnt even consider stuff people sent to you, including video proof, that would be a waste of time. -- bye Joerg Linus: Wenn Darl McBride die Macht hätte, würde er wahrscheinlich die Ehe als Verletzung der Verfassung auslegen, weil sie ganz klar die kommerzielle Natur der menschlichen Interaktion entwertet und damit ein großes Hindernis für die kommerzielle Entwicklung der Prostitution darstellt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Jaspert [EMAIL PROTECTED] wrote: On 10743 March 1977, Joerg Jaspert wrote: [1] http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/theora-small/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.ogg [2] http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/mpeg1-pal/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.mpeg Well, thats meetings-archive.debian.net Nice to see that this video clip verifies my statements in case you carefully listen to Simon Phipps: - Sun did not make the CDDL incompatible by intention to the GPL - The only thing that prevents Linux to use the DTrace code in Linux is the different threading model - Eben Moglen tells you that what I do in cdrtools is OK: They the FSF and Moglen have only be in fear that people could interpret the GPL in a wrong way and for this reason added the OS exception, but the GPL does allow to link a GPLd project against libraries under other licenses. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Jaspert [EMAIL PROTECTED] wrote: Eduard Bloch has absolutely no clue and on the other side implicitely claims in his arrogant habbit that he knows more about cdrtools than I do. This makes it impussoble to cooperate with him. You know that this is Rufschädigung übelster Art? I am sorry but this is the truth.. Claiming that Sun did make the CDDL incompatible with the GPL is a deliberate lie. You should look at the video I pointed you at. You just accused me of being a liar. If i would have your low level I would now do the same you I did look at this video: it verifies what I say! If you carefully look at the video, you see that Simon is angry with Danese because she does not tell the truth but he does not like to correct her in the public. did with a co-maintainer of the Debian cdrtools package and threat with a lawsuit if you dont take it back. I dont. I just add you to my ignore You are lying here again by quoting the lies of the well known troll Eduard Bloch. You are just going to lose your credability if you spread this kind of lies. As I mentioned already many times, I did not do what Eduard claims! [a lot of nonsense deleted] Sorry, but I do not believe people that put things into a GPL FAQ that are obviously wrong. Yeah, you dont believe those people who have written the GPL... I do not believe the people who did write the FSF GPL FAQ, this is different. I am willing to have a private discussion in case it would make sense and will not be a waste of time. This means that I will immediately stop the discussion in case that you e.g. again claim that Sun did make the CDDL incompatible to the GPL by intention or that you quote the GPL incorrectly in hope to prove claims about the incompatibility of the CDDL and the GPL. As you obviously stay with your opinion and doesnt even consider stuff people sent to you, including video proof, that would be a waste of time. As I said: I am willing to have an openminded discussion. In case you verify that you are not willng to do the same, this discussiion ends. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Friday 11 August 2006 14:48 pm, Joerg Schilling wrote: The FSF GPL FAQ e.g. incorrectly claims: Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination. The GPL does not contain the term combined work, so this is an invalid claim. The GPL rather talks about a derived work and simply linking two modules together does definitely not make module B a derived work of module A if module A calls code from module B but module B does not call code from module A. Let's put aside for the moment that the FAQ is not meant to be a legal document as opposed to the GPL itself, and that the FAQ is not saying B would be a derived work of A, but rather that the combination would be... I have a general question about how the GPL is construed to cover the case of dynamic linking. According to the GPL, section 0: The act of running the Program is not restricted... And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the mere aggregation clause of section 2. (Of course, you would have to be very careful about any inline functions, etc., from the non-free headers...) As a hypothetical example, let's say that program A uses library B, both licensed under the GPL. Now the author of B decides he doesn't want anybody selling B at all, so he releases a newer version under a non-free license, and Debian decides to package the old version of B as B-free and the new version in non-free. Is Debian allowed to keep distributing A, while distributing B-nonfree at the same time, given that some users might not end up installing B-free? Suppose that later B-free is considered old and buggy enough that we refuse to support it, so B-free is removed from the archive. Now does Debian have to stop distributing A as well? Even if by this point nobody actually had B-free installed any more? (I think my answers would be: distributing A with B-free and B-nonfree is permissible, but once B-free went A would have to go as well. Of course, there would also be the solution we already have with B-free = lesstif and B-nonfree = libmotif, but let's say for the sake of argument B's maintainer doesn't take that course, and instead makes libB1-nonfree: Provides: libB1.) On the other hand, since the FSF is the author of the license, and their own FAQ states that they consider dynamic linking to fall under the terms of the license, distributing GPL programs dynamically linked against GPL-incompatible libraries would clearly be exploiting a loophole under any definition of that term that I know of. And exploiting a loophole in the GPL would hardly be a way to endear oneself to the free software community. Thus, I'm hoping that the above is more of an academic question than anything else. In any case, static linking clearly falls under the definition of a work based on the Program in section 0, so you cannot e.g. extend GPL'd program A to use non-free library B, then distribute a resulting binary with B statically linked in. (Which is not the same thing as saying this would make B a derived work of A.) -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Jorg Schilling wrote: [...] Sorry, but I do not believe people that put things into a GPL FAQ that are obviously wrong. Let me give a single example to avoid wasting too much time: The FSF GPL FAQ e.g. incorrectly claims: Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination. The GPL does not contain the term combined work, so this is an invalid claim. The GPL does, however, contain the term work based on [the Program]. Calling it a combined work based on [the Program] does not change the fact that it is a work based on [the Program]. The combined is merely a clarification on the term. The GPL rather talks about a derived work and simply linking two modules together does definitely not make module B a derived work of module A if module A calls code from module B but module B does not call code from module A. No, but the combined work (A+B) (i.e. a binary produced by linking module A with module B) is a work based on A, and hence (A+B) must be distributable under the terms of the GPL. Distributing the sources of A with the sources of B may be fine, but Debian would not be legally allowed to distribute a binary produced by linking A with B, since this would not be mere aggregation. You brought up the question of Cygwin in a previous message, but that is covered by the exception given in the second-last paragraph of section 3. -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Hubert Chan [EMAIL PROTECTED] wrote: No, but the combined work (A+B) (i.e. a binary produced by linking module A with module B) is a work based on A, and hence (A+B) must be distributable under the terms of the GPL. Distributing the sources of A with the sources of B may be fine, but Debian would not be legally allowed to distribute a binary produced by linking A with B, since this would not be mere aggregation. If you try to again post claims that have already proven to be wrong, I see no reason to continue this discussion, it only wastes time... The GPL is a source license. The fact that you are thinking about the license for a binary verifies that you did not understand the GPL. The GPL only restricts things (and requires the whole work to be put under GPL) in case you try to put other peoples GPLd work _into_ your your work and create a work based on the other code. This is obviously not true for the case I am talking of. Again: if you continue to bend my statements I get the impression that you are not interested in a real discussion but in stealing my time. I did never claim that any possible combination of CDDL GPL code is permitted. The combination I am using however is OK for me _and_ for binary redistributors. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPL question [Was: Re: cdrtools]
Daniel Schepler [EMAIL PROTECTED] writes: Let's put aside for the moment that the FAQ is not meant to be a legal document as opposed to the GPL itself, and that the FAQ is not saying B would be a derived work of A, but rather that the combination would be... I have a general question about how the GPL is construed to cover the case of dynamic linking. According to the GPL, section 0: The act of running the Program is not restricted... And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the mere aggregation clause of section 2. (Of course, you would have to be very careful about any inline functions, etc., from the non-free headers...) I believe that the totaly interchangable option of specifying -static or not should not change the free-ness of the source or resulting binary. So if you link static and you agree that it is a violation that way then you should not be able to get away with it by linking dynamically. The GPL is viral in nature and specificaly made to work across linking boundaries. People should not be able to add non-free portitons to the source by hiding them in libraries. My 2c, Goswin PS: For proof or disproof ask a lawyer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
You did write: ... I have a general question about how the GPL is construed to cover the case of dynamic linking. According to the GPL, section 0: ... I am sory to see that you did remove me from the Cc: list you are the first person at Debian who starts to think the right way... If you read the GPL again, you will find out that the GPL doeas not contein the term linking. It is obvious that there is no difference between static and dynamic linking in terms of the GPL. So everything that is possible with dynamic linking is also possible with static linking. Linking a GPLd program against a non-GPLd library does not make the library a derived work of the GPLd program. You may either call this mere aggregation or in the worst case call the GPLd program a derived work of the library but not vice versa. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 2006-08-11 at 23:55 +0200, Joerg Schilling wrote: Linking a GPLd program against a non-GPLd library does not make the library a derived work of the GPLd program. but it does mean you may distribute the resulting binary only if you make the library source available under the GPL, and if the library's license does not allow this then you may not distribute the binary -- Edward Allcutt [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: cdrtools
Hi, On Fri, Aug 11, 2006 at 07:04:51PM -0400, Edward Allcutt wrote: On Fri, 2006-08-11 at 23:55 +0200, Joerg Schilling wrote: Your discussion is off-topic for debian-devel, please kindly take it elsewhere. Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Fri, 11 Aug 2006 23:25:52 +0200, Joerg Schilling [EMAIL PROTECTED] said: Hubert Chan [EMAIL PROTECTED] wrote: No, but the combined work (A+B) (i.e. a binary produced by linking module A with module B) is a work based on A, and hence (A+B) must be distributable under the terms of the GPL. Distributing the sources of A with the sources of B may be fine, but Debian would not be legally allowed to distribute a binary produced by linking A with B, since this would not be mere aggregation. If you try to again post claims that have already proven to be wrong, I see no reason to continue this discussion, it only wastes time... The GPL is a source license. The fact that you are thinking about the license for a binary verifies that you did not understand the GPL. The GPL (section 3) does restrict distributions of binaries (object code or executable form, to use the words of the GPL, to be more accurate, since the GPL only uses the term binary once, and only to refer to a completely different issue) and states that such binaries must be distributed under the terms of sections 1 and 2 (which seem to be the important parts of the GPL as far as Debian is concerned). Section 2b also then states that anything ... derived from the Program ... must be licensed under the terms of the GPL, and I can't see how a binary is not derived from the Program. The only place in the GPL that restricts its terms to applying to sources is section 1, which refers to verbatim copies of the Program's source code as you receive it. The GPL is a source license in the sense that it does not make sense to apply it only to a binary, due to section 3. But that does not mean that its terms do not apply to binaries as well. [...] I did never claim that any possible combination of CDDL GPL code is permitted. ... Understood. I think that we all agree that, say, taking code licensed under the CDDL and linking it to a GPLed library is not allowed. (And we all agree that that is not the situation that we're talking about.) -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL question [Was: Re: cdrtools]
On Friday 11 August 2006 18:10 pm, Goswin von Brederlow wrote: I believe that the totaly interchangable option of specifying -static or not should not change the free-ness of the source or resulting binary. So if you link static and you agree that it is a violation that way then you should not be able to get away with it by linking dynamically. The GPL is viral in nature and specificaly made to work across linking boundaries. People should not be able to add non-free portitons to the source by hiding them in libraries. I agree, but then should and is sometimes disagree. But after thinking about it some more, I believe a dynamically linked binary together with the corresponding shared libraries should be considered as a distribution method for the complete program that gets assembled in a common address space. Consider for example the case of EvilCo, back before dynamic linking was widespread, trying to use a GPL'd library in their non-free program. They try to get around the GPL by distributing their compiled program code in a single .o file in a mere aggregate along with the GPL library .a file, and ask users to link the program themselves. This is obviously bogus; they've just created an alternate means of distribution of the resulting binary, and so the binary itself must be distributable under the terms of the GPL, which it isn't. And the case of a dynamically linked executable with shared libraries is almost exactly the same as this scenario, only it's the system dynamic linker doing the work instead of the user doing it manually. Anyway, as somebody else pointed out, this is off-topic for debian-devel, and I apologize. Please direct any replies to debian-legal (too bad kmail doesn't let me set Followup-To afaik). -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Wouter Verhelst [EMAIL PROTECTED] wrote: On Wed, Aug 09, 2006 at 03:44:57PM +0200, Joerg Schilling wrote: Indeed, you are not free to add whatever piece of crap to the Debian archive regardless of the license. Call it a non-free project if you want, but this would only look like a calumniation campaign against us. If you continue to spread this kind of personal insults, Err, ENOPARSE. How is the above paragraph a personal insult? We are talking about my software and you are talking about a piece of crap, I am sorry but this is insulting. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Josselin Mouette [EMAIL PROTECTED] wrote: Le mercredi 09 août 2006 à 15:44 +0200, Joerg Schilling a écrit : You are again trying to intentionally tell us untrue things about my software! The Debian project accepted the clauses in cdrecord ~ 4 years ago. That doesn't mean the project still considers them acceptable *NOW*. So you like to tell me that Debian is not trustworthy? And note: the CDDL is one of 9 preferred licenses: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd One of the preferred licenses *by the OSI*. Debian has nothing to do with the OSI and doesn't not rely on the OSI to be told what is free or not. Can't you even understand something that simple? I understand things but if Debian people have problems to understand that the OSI is the only independend institution that deals with OSS Licenses, you are obviously a bit out of order. Note that the CDDL has been chosen because it is a first class license as it allows to combine CDDL code with other code and that the GPL only is in this list because the GPL is widely used but not because of the quality of the license. BTW: The GPL is definitely non-free if someone makes use of GPL § 8. It has no problem with any of the DFSG requirements. Many people have expressed complaints about the choice-of-venue clause and think it is not acceptable for Debian. I am not one of them and I believe the CDDL to be free, but I would surely not claim there is consensus around that in the project. I repeat: currently no CDDL project has been accepted yet. Well then help to explain these other people that only a malicious distributor or licensee needs to be in fear of this clause and that the clause protects the Author for malicious licensees. If the Authors will not be protected, we will end up with no OSS in the future... If you claim different things, you are obviously speading FUD and not a serious discussion partner - sorry. Why is anyone disagreeing with you necessarily spreading FUD, lying, trying to hurt your reputation, or anything like this? Bear with it: most people disagree with you. I do not know a SINGLE Debian developer who believes your license combination to be distributable. Does that make only hundreds of trolls who are just trying to spread FUD against you? Well this is strange. I did not invent this idea by myself and I did ask many people about their opinion. What I see is that only a few people from Debian have a different opinion and they are even unable to prove their claims by correctly quoting the parts pf the GPL that they believe prevents what I am doing. Stop the paranoia. People disagree with you, and you have to accept that. They are not disagreeing with you just to hurt you *personally*. This is why you should listen to these criticisms instead of throwing them away by calling them FUD. No one is going to listen to you if you are still unable to listen to anyone. Sorrry, the people from Debian need to stop _their_ paranoia as they are a minority with a strange opinion. I listen to people but if I see that they spread FUD instead of offering useful and traceable information I believe at some point that is does not make sense to continue a discussion. The Debian people should just read their DFSG rules and try to understand them DFSG §9 claims that a license is only free if it does not conaminate other software on the same medium. The medium in case of cdrtools is the tarball. The cdrtools distribution is based on two cases to allow a combination of different licenses: 1) Mere aggregation. This applies for The Schily Makefilesystem and other software as well as with e.g. cdda2wav and cdrecord. 2) GPLd software uses CDDLd libraries. This is done in a way that does not make the CDDLd software a derived work of the GPL software. This is done for mkisofs an libschily/libscg. If Debian sees a problem with 1) bedause of their interpretation of the GPL, then they need to clearly call the GPL a non-free license. BTW: any GPL software that makes use of GPL §8 clearly violates the DFSG, so I would not call the GPL a generaily free license. If Debian has a problem with 2) they would need to call things like Cygwin a violation of the GPL and would be in contradiction to usual GPL interpretations. If you are so braindead not to understand that this license combination is perfectly OK, I cannot help you. It seems that I did waste already too much time with you. A discussion only makes sense in case that the other side is able/willing to understand simple explanataions... Your simple explanations are wrong. I'm not going to re-explain what Wouter explained better than I would. If you cannot understand that the CDDL is incompatible with the GPL, you should stop talking about licenses and only keep coding, a task for which you seem to have more talent. You still did not read
Re: cdrtools
Goswin von Brederlow [EMAIL PROTECTED] wrote: Joerg Schilling [EMAIL PROTECTED] writes: Josselin Mouette [EMAIL PROTECTED] wrote: GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. Sorry, but you say your software is free. That means Debian (or anyone else) is free to bastardize cdrecord as much as they want. That is called freedom. You can require proper notice or even a name change of the software when such bastardization is done but when you start forbiding such changes then your software is no longer free. I am sorry but it seems that you miss to read the Urheberrecht AND e.g. the GPL. Both forbid to damage the reputation of the original author. As I _did_ already receive coplaints against cdrecord that have been e.g. based on the fact that Linux distributoions change the name for the file /etc/default/cdrercord and the fact that the basterdized behavior is incompatible with the (officially) documented behavior, these Linux distributions cause harm Free software gives you the right to change software but free software definitely does _not_ give you the right to use the originam _name_ of the software in case you apply incompatible changes or in case that you introduce bugs. The license is related to urheberrecht, using the original name of the software is related to trade mark right If people at Denbian are missing this kind of basic knowledge, how would it be possible to discuss license issues in a serious way? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling wrote: The Debian project accepted the clauses in cdrecord ~ 4 years ago. That doesn't mean the project still considers them acceptable *NOW*. So you like to tell me that Debian is not trustworthy? The requirements of the project changed. That is called progress. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Goswin von Brederlow [EMAIL PROTECTED] wrote: If you don't know that you just need to use a clearly _different_ _name_ for such a fork, I can't help you. Read the preamble from the GPL to understand your fault. So all we need to do to apeace you is to call is debianrecord? If that is all that is needed for you not to complain that we include unsupported dvd support and the like then that can easily be aranged. This is really funny.. The oficial cdrecord _does_ support DVD writing. Why do you like to first hide this feature from your users and then later add broken DVD support? But then please just say so. The GPL alone does not require such a rename, only that the modified files to carry prominent notices stating that you changed the files and the date of any change. The GPL does not allow you to use the original name.. This is related to different things (trade mark right). You should just add a requirement for renaming the software instead of your invariant section and extra printing code requirement. Note that the name dvdrecord is illegal too as this name is too close to the name cdrecord and many people use the name dvdrecord for the newer versions of cdrecord that include DVD writing although I did never mentioned this name for my software. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Hi Joerg, Le 09.08.2006 15:33, Joerg Schilling a écrit : If you don't know that you just need to use a clearly _different_ _name_ for such a fork, I can't help you. Read the preamble from the GPL to understand your fault. Beside the licensing issues, why do you care so much patched version of your software to be distributed with big WARNINGS, a different name and tutti quanti ? AFAIK, each Linux distribution have a huge bag of patches it applies on the Linux kernel and the reputation of the kernel devels is not compromised. And it's quite the same about gcc and many pieces of free softwares. Aren't you afraid that your reputation is _far_ more about the issues to ditribute your software than about the quality of your software ? Regards, Jean Parpaillon -- _ / La science a fait de nous des dieux \ | avant même que nous méritions d'être | | des hommes. -+- Jean Rostand| \ (1894-1977) -+- / - \ ^__^ \ (**)\___ (__)\ )\/\ U ||w | || || -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
And note: the CDDL is one of 9 preferred licenses: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd One of the preferred licenses *by the OSI*. Debian has nothing to do with the OSI and doesn't not rely on the OSI to be told what is free or not. Can't you even understand something that simple? I understand things but if Debian people have problems to understand that the OSI is the only independend institution that deals with OSS Licenses, you are obviously a bit out of order. Debian has no problem understanding that they will independently determine what licenses are suitable to Debian. If you want your software in Debian, use a currently Debian approved license. On 10/08/06, Joerg Schilling [EMAIL PROTECTED] wrote: Goswin von Brederlow [EMAIL PROTECTED] wrote: Note that the name dvdrecord is illegal too as this name is too close to the name cdrecord and many people use the name dvdrecord for the newer versions of cdrecord that include DVD writing although I did never mentioned this name for my software. Surely you jest... then again, perhaps you don't. It is highly unlikely (that any jurisdiction would recognise) that there could be any restriction on use of the name dvdrecord resulting from the existence of another highly generic name cdrecord: cdrecord and dvdrecord are generic names, describing what the software does... granted you may have a claim to cdrecord having named your software thus, but even this might be challenged by close similarly generic cdrecordtype variants... it is questionable whether cdrecorder or recordcd for example would be protected... you cannot by virtue of using the generic type name cdrecord control variants of the genric term let alone (yet) another name that is as generic (and different): dvdrecord. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] wrote: If you don't know that you just need to use a clearly _different_ _name_ for such a fork, I can't help you. Read the preamble from the GPL to understand your fault. So all we need to do to apeace you is to call is debianrecord? If that is all that is needed for you not to complain that we include unsupported dvd support and the like then that can easily be aranged. This is really funny.. The oficial cdrecord _does_ support DVD writing. Why do you like to first hide this feature from your users and then later add broken DVD support? ftp://ftp.berlios.de/pub/cdrecord/ProDVD/README NOTE: the DVD-recording drivers have been added to the OpenSource part on May 15th 2006 with cdrtools-2.01.01a09. It is nice that you finaly made this free but it is a rather recent change given: ** NEW: On March 9th, we are celebrating 6 years of cdrecord-ProDVD Sorry that I'm not totally up to date. But then please just say so. The GPL alone does not require such a rename, only that the modified files to carry prominent notices stating that you changed the files and the date of any change. The GPL does not allow you to use the original name.. This is related to different things (trade mark right). So you agree with me that it is not a GPL issue. If you have a trade mark on cdrecord and want to enforce it that is your decision. But it is not GPL related as you seem to claim in the source file. You should just add a requirement for renaming the software instead of your invariant section and extra printing code requirement. Note that the name dvdrecord is illegal too as this name is too close to the name cdrecord and many people use the name dvdrecord for the newer versions of cdrecord that include DVD writing although I did never mentioned this name for my software. So is using IBM or Coca-Cola. What has that got to do with it? Jörg MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling dijo [Thu, Aug 10, 2006 at 02:49:36PM +0200]: As I _did_ already receive coplaints against cdrecord that have been e.g. based on the fact that Linux distributoions change the name for the file /etc/default/cdrercord and the fact that the basterdized behavior is incompatible with the (officially) documented behavior, these Linux distributions cause harm Free software gives you the right to change software but free software definitely does _not_ give you the right to use the originam _name_ of the software in case you apply incompatible changes or in case that you introduce bugs. The license is related to urheberrecht, using the original name of the software is related to trade mark right If people at Denbian are missing this kind of basic knowledge, how would it be possible to discuss license issues in a serious way? I am currently maintainer (co-maintainer for most of them) for 70 packages, most of them quite easy and low-maintenance. However, some of them have patches, maybe adding a specific functionality the author didn't want to include in his official version, maybe fixing some idiosyncratic differencies (i.e. PDF::API2 comes to mind - It defines sections in its documentation which don't cleanly map to what's used in regular manpages, so I did the changes, but I must keep patching the author's official module). You say that I don't have the right to distribute this under the name PDF::API2 in Debian, do I understand correctly? Please tell me: This module is a Perl library. If I modify it to become PDF::API2::Debian, how will our users' code be portable? How can other pieces of code link against this one and not be Debian-specific? A compromise we have reached in some cases is to change the _version_ number (i.e. in Mail::IMAPClient, where I had to remove some non-free files from the distributed tarball) appending '+deb' to it (so for us it's now 2.2.9+deb-4). It clearly shows it's not the original author's code, but that the code _is_ contained. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On 10742 March 1977, Joerg Schilling wrote: Both forbid to damage the reputation of the original author. Free software gives you the right to change software but free software definitely does _not_ give you the right to use the originam _name_ of the software in case you apply incompatible changes or in case that you introduce bugs. The license is related to urheberrecht, using the original name of the software is related to trade mark right Oh god, Im so sick of all this cdrecord flaming. So, how about the following (and please read it completly before you answer, it contains multiple options): - We go and take cdrecord and modify it with whatever we believe we may need *and* * remove your name completly from any output the programs give, and also mention that anyone who has problems has to contact us, not you. Your name stays in the source, of course. * or alternatively leave your name in the output, in a form similar to this is based on *** originally written by and then also mention to contact us for problems. Now, the name for this. One could imagine a lot of things. There is a possibility of naming it debian-burn, debianrecord or just burntools. The names of the other included parts shouldnt change, ie it should stay mkisofs and cdda2wav. For the short term the package would mention in its description that its based on cdrtools (and have a Provides: cdrtools in its technical part), so we do not make too much problems for the next release, as thats scheduled to be soon, after that release (schedule for december this year) we could/would also drop that. Future development should merge changes from you wherever possible and also give back patches, if we have something you might be interested in. What do you say, what name would not be ok in your opinion and which of the two options should we take? (Note that one of the first steps would be to remove the CDDL parts, as - if you like it or not - the license is not compatible with GPL. Having it approved by OSI is worth nothing, as not OSI is the standard we take for inclusion into Debian, Debian itself (and basically the DFSG together with a bit of common-sense) is.) For all those interested in the Debian part of it when this starts (Joerg, you can skip this): I will open an alioth project for it, import the full source and start with it. Anyone who wants to help is free to join. -- bye Joerg Wie gesagt, mein /proc/kcore ist 536MB gross und ich würde meinen Rechner gern davon befreien. Ein rm -f schlägt fehl! Ein Reboot hat auch nix geholfen. -- [EMAIL PROTECTED] pgpxTLWqKrs9N.pgp Description: PGP signature
Re: cdrtools
Joerg Jaspert [EMAIL PROTECTED] wrote: So, how about the following (and please read it completly before you answer, it contains multiple options): I am sorry, but I cannot believe that you like to make serious proposal with the text you wrote. Let me make a proposal that makes sense for now and the future: 1) Throw out Eduard Bloch. He has been the biggest problem for Debian in the past years. Find a new maintainer with the following properties: - Some basic knowledge in C - Some basic knowledge in software engineering and interfaces between kernel and userland - Some basic knowledge in CD/DVD writing - Some basic knowledge in SCSI - Some basic knowledge in software quality assurance - Able and willing to cooperate 2) Update to a recent cdrtools source, do not hide interesting new features from Debian users and (this may be even more important to Linux users) workarounds for recent Linux kernel self-incompatibilities. 3) Remove the unneeded Debian changes as the unmodified original source does not need any changes in order to work correctly. 4) If someone at Debian likes to work on enhancements, make sure that these changes are done in a way that does not contradict the current planned behavior and make sure that the quality of the code is sufficient to allow integreation. Read the file: ftp://ftp.berlios.de/pub/cdrecord/CONTRIBUTING and follow the instructions in that file. 5) Find someone to read the original GPL text in depth who did not yet read the wrong FSF GPL FAQ. Let this person be prepared and willing to have a serious fact based discussion in case that there are still any issues to discuss. 6) Find someone to read the original CDDL text in depth and in addition read the DFSG text. Let this person be prepared and willing to have a serious fact based discussion in case that there are still problems to understand why the CDDL meets all requirements of the DFSG. Do not try to raise conditions that are not written down in the DFSG. Be prepared to have a serious discussion with people from Sun who are waiting for such a discussion and are willing to explain how the CDDL has to be understood. Try to accept that the CDDL is a first class OS license and treat it in the same open way as you treat the GPL and the BSDl. 7) Finally: learn that I am spending a lot time on cdrtools and on my other OSS activities. Understand that I am neither willing to waste my time with useless discussions with Debian people nor being forced to give up useful ways of defending me against malicious users or distributors of my code. Believe me that it does not sound serious when reading again and again silly things like we need to fork cdrecord I am now working for 10 years on cdrecord, I am now working for exactly 20 years on libscg and I am working for 24 years on star. Many people did claim to start a fork on my tools, nobody did yet even come to a serious first step in this direction not speaking about serious work on extensions... 8) Understand that all my software is highly portable and that it is not acceptable to chage it in a way that make them behave different on different platforms. 9) Help me with defending against silly artificial limitations in the Linux kernel that makes life on Linux hard. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Hi fellow Debian people, On Thu, Aug 10, 2006 at 11:25:11PM +0200, Joerg Schilling wrote: Let me make a proposal that makes sense for now and the future: Whoever answers to this proposal will be mocked publically. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, 09 Aug 2006 15:44:57 +0200 Joerg Schilling [EMAIL PROTECTED] wrote: Stuff deleted for brevity All of this, without even taking into account your brain-dead licensing mix between CDDL and GPL - which are intentionally incompatible licenses, according to Sun guys. If you are so braindead not to understand that this license combination is perfectly OK, I cannot help you. It seems that I did waste already too much time with you. A discussion only makes sense in case that the other side is able/willing to understand simple explanataions... I have just spent the last half hour reading this thread and nowhere have I seen you give ANY explanations, simple or complex. You have simply stood on your hind legs and declared that you are right and everyone in the Debian group is wrong and evil in their intent or just plain stupid. So, can you actuall construct an explanation that does not include all the inflamitory statements you have assigned to your opponents here at Debian? I have been with the Debian group since very early in the project (when I joined there were about 75 of us) and while I have not agreed with every decission this group has made over the years. I DO agree that the decissions have been made in a thoughtful and deliberate manner that supports the DFSG and our goals for Software Freedom. Other proponents of Software Freedom don't always agree with us, or us with them. For me that is part and parcel of the concept of Freedom in a diverse society. If you are going to debate, it is more useful for you to provide clear points of view about the concepts being discussed. All I have seen is juvenile name calling and useless bile. Please grow up! Luck, Dwarf Sometimes known as the voice of reason ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
This one time, at band camp, Michael Banck said: Hi fellow Debian people, On Thu, Aug 10, 2006 at 11:25:11PM +0200, Joerg Schilling wrote: Let me make a proposal that makes sense for now and the future: Whoever answers to this proposal will be mocked publically. Even if we mock the proposal? You're no fun at all. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: cdrtools
Gunnar Wolf [EMAIL PROTECTED] wrote: GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. Any free license allows for forking, allows for us modifying and redistributing your work. If we consider some parts of your code unfit, and you say you write Free Software, you should not have a problem accepting us to distribute those changes to your sources. Why are you so bitter about it to call bastardizing what should be called distributing modified versions of? If you don't know that you just need to use a clearly _different_ _name_ for such a fork, I can't help you. Read the preamble from the GPL to understand your fault. There are definitely NO issues with the CDDL. The CDDL gives at least as much freedom as the GPL does and the CDDL is a first class OSS license. It has been accepted by the OSI and this is sufficient for anybody. ...By OSI. That's an important part, but not all of, the Free Software camp. In case you don't know, the CDDL is one of 9 preferred: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd The CDDL has no problem with any of the DFSG requirements, so in case some people at Debian do not like to accept the CDDL, this needs to be called pure evilness. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Josselin Mouette [EMAIL PROTECTED] wrote: Le lundi 07 août 2006 à 10:56 +0200, Joerg Schilling a écrit : My software is definitely free and has no license problems. You may think so, but the Debian project doesn't. For example, a recent GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for cdrecord. Furthermore, there are issues with the CDDL and currently no CDDL-licensed project has been accepted. You are again trying to intentionally tell us untrue things about my software! The Debian project accepted the clauses in cdrecord ~ 4 years ago. The Debian people at that time _did_ know that the cdrecord source does not contain invariant sections. You need of course chose a clearly different name (e.g. kindergarten) instead of cdrecord in case you like to apply specific changes And note: the CDDL is one of 9 preferred licenses: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd It has no problem with any of the DFSG requirements. If you claim different things, you are obviously speading FUD and not a serious discussion partner - sorry. All of this, without even taking into account your brain-dead licensing mix between CDDL and GPL - which are intentionally incompatible licenses, according to Sun guys. If you are so braindead not to understand that this license combination is perfectly OK, I cannot help you. It seems that I did waste already too much time with you. A discussion only makes sense in case that the other side is able/willing to understand simple explanataions... People from Debian are interested in building a free distribution, not in trolling with software authors crying out loud because they aren't able to understand how licenses work. We decide what's acceptable for our project, and you don't have a single word to say about that. If this was true, why don't you talk with me with in a serious way but troll instead? Indeed, you are not free to add whatever piece of crap to the Debian archive regardless of the license. Call it a non-free project if you want, but this would only look like a calumniation campaign against us. If you continue to spread this kind of personal insults, _you_ are a person that I don't like to talk with anymore in future. I am sorry, but I cannot waste my time with trolls like you. I am however still in hope that the Debian project is not full of trolls but that there are reasonable people in Debian Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, Aug 09, 2006 at 03:44:57PM +0200, Joerg Schilling wrote: Indeed, you are not free to add whatever piece of crap to the Debian archive regardless of the license. Call it a non-free project if you want, but this would only look like a calumniation campaign against us. If you continue to spread this kind of personal insults, Err, ENOPARSE. How is the above paragraph a personal insult? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Le mercredi 09 août 2006 à 15:44 +0200, Joerg Schilling a écrit : You are again trying to intentionally tell us untrue things about my software! The Debian project accepted the clauses in cdrecord ~ 4 years ago. That doesn't mean the project still considers them acceptable *NOW*. And note: the CDDL is one of 9 preferred licenses: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd One of the preferred licenses *by the OSI*. Debian has nothing to do with the OSI and doesn't not rely on the OSI to be told what is free or not. Can't you even understand something that simple? It has no problem with any of the DFSG requirements. Many people have expressed complaints about the choice-of-venue clause and think it is not acceptable for Debian. I am not one of them and I believe the CDDL to be free, but I would surely not claim there is consensus around that in the project. I repeat: currently no CDDL project has been accepted yet. If you claim different things, you are obviously speading FUD and not a serious discussion partner - sorry. Why is anyone disagreeing with you necessarily spreading FUD, lying, trying to hurt your reputation, or anything like this? Bear with it: most people disagree with you. I do not know a SINGLE Debian developer who believes your license combination to be distributable. Does that make only hundreds of trolls who are just trying to spread FUD against you? Stop the paranoia. People disagree with you, and you have to accept that. They are not disagreeing with you just to hurt you *personally*. This is why you should listen to these criticisms instead of throwing them away by calling them FUD. No one is going to listen to you if you are still unable to listen to anyone. If you are so braindead not to understand that this license combination is perfectly OK, I cannot help you. It seems that I did waste already too much time with you. A discussion only makes sense in case that the other side is able/willing to understand simple explanataions... Your simple explanations are wrong. I'm not going to re-explain what Wouter explained better than I would. If you cannot understand that the CDDL is incompatible with the GPL, you should stop talking about licenses and only keep coding, a task for which you seem to have more talent. People from Debian are interested in building a free distribution, not in trolling with software authors crying out loud because they aren't able to understand how licenses work. We decide what's acceptable for our project, and you don't have a single word to say about that. If this was true, why don't you talk with me with in a serious way but troll instead? I have yet to be shown how it is possible to discuss with you in a serious way. Indeed, you are not free to add whatever piece of crap to the Debian archive regardless of the license. Call it a non-free project if you want, but this would only look like a calumniation campaign against us. If you continue to spread this kind of personal insults, _you_ are a person that I don't like to talk with anymore in future. Where is there a personal insult in this paragraph? I am sorry, but I cannot waste my time with trolls like you. You are the one bringing this discussion on the Debian development mailing list. You are wasting the time of people reading this list. I am however still in hope that the Debian project is not full of trolls but that there are reasonable people in Debian If reasonable means who agree with you, I have yet to see them. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: cdrtools
Joerg Schilling [EMAIL PROTECTED] writes: Josselin Mouette [EMAIL PROTECTED] wrote: GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. Sorry, but you say your software is free. That means Debian (or anyone else) is free to bastardize cdrecord as much as they want. That is called freedom. You can require proper notice or even a name change of the software when such bastardization is done but when you start forbiding such changes then your software is no longer free. Specifically in cdrecord you write: * Begin restricted code for quality assurance. * * Warning: you are not allowed to modify or to remove the * Copyright and version printing code below! * See also GPL A7 2 subclause c) GPL 2c: c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) 'IF THE MODIFIED PROGRAM NORMALLY READS COMMANDS INTERACTIVELY WHEN RUN...' Where does the original or any modified cdrecord run interactively? This section just does not apply to cdrecrod. In accordance to that I can just remove your copyright printing in cdrecord since it is not interactive. * If you modify cdrecord you need to include additional version * printing code that: *... Too bad the printing code itself can be removed completly anyway sparing the user the anoying text. You demand that I write additional code here, that might be totaly unsuitable for my use, severly limits my freedom to use the source. That is not covered by the GPL, not in 2c as you claim at all. So even though your intentions are fine your wording is not. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling [EMAIL PROTECTED] writes: Gunnar Wolf [EMAIL PROTECTED] wrote: GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. Any free license allows for forking, allows for us modifying and redistributing your work. If we consider some parts of your code unfit, and you say you write Free Software, you should not have a problem accepting us to distribute those changes to your sources. Why are you so bitter about it to call bastardizing what should be called distributing modified versions of? If you don't know that you just need to use a clearly _different_ _name_ for such a fork, I can't help you. Read the preamble from the GPL to understand your fault. So all we need to do to apeace you is to call is debianrecord? If that is all that is needed for you not to complain that we include unsupported dvd support and the like then that can easily be aranged. But then please just say so. The GPL alone does not require such a rename, only that the modified files to carry prominent notices stating that you changed the files and the date of any change. You should just add a requirement for renaming the software instead of your invariant section and extra printing code requirement. ... The CDDL has no problem with any of the DFSG requirements, so in case some people at Debian do not like to accept the CDDL, this needs to be called pure evilness. You may call that evil but everybody (including Debian) has the right to their own opinion. Jörg MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Hi, On Wed, Aug 09, 2006 at 05:39:12PM +0200, Goswin von Brederlow wrote: Joerg Schilling [EMAIL PROTECTED] writes: Josselin Mouette [EMAIL PROTECTED] wrote: GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. Sorry, but you say your software is free. That means Debian (or anyone else) is free to bastardize cdrecord as much as they want. That is called freedom. This discussion has nothing to do with debian development, kindly stop or continue on another list. thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Sun, Aug 06, 2006 at 01:04:41PM +0200, Joerg Schilling wrote: Wouter Verhelst [EMAIL PROTECTED] wrote: I can quote major parts of it by heart since a few years, does that help? If you like to discuss the GPL with other people, it is irrelevent whether you know it by heart in case you did not understand it yet... *sigh* If everybody else interprets it significantly different from you, isn't it more likely that *you* do not understand it? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Wouter Verhelst [EMAIL PROTECTED] wrote: On Sun, Aug 06, 2006 at 01:04:41PM +0200, Joerg Schilling wrote: If you like to discuss the GPL with other people, it is irrelevent whether you know it by heart in case you did not understand it yet... If everybody else interprets it significantly different from you, isn't it more likely that *you* do not understand it? As you seem to be unable to prove _your_ claims by _correctly_ quoting the GPL, it is obvious that _you_ did not understand the GPL or that you prefer to bend the GPL to your wishes. I am still in hope that there are people at Debian who are able to understand license issues without bending things the way they like but by correctly following the words in the license text. My software is definitely free and has no license problems. If people from Debian continue to publish untenable assertions on my software, it is obvious that those people from Debian are only interested in a calumniation campaign aganst me. Note that this makes Debian incredible. If it is impossible to find a reasonable person at Debian, I will need to inform other people about the problems in the Debian project. The way _you_ and other people from Debian currently act, makes Debian a definitely non-free project :-( Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Hi, On Mon, Aug 07, 2006 at 10:56:24AM +0200, Joerg Schilling wrote: I am still in hope that there are people at Debian who are able to understand license issues without bending things the way they like but by correctly following the words in the license text. Joerg, this discussion is off-topic for the debian-devel mailing list, which is concerned with development issues, not licensing trivia. Please (preferably) stop this discussion, or take it to debian-curiosa or debian-legal. Thanks, Michael -- No other topic of discussion in our circles has matched even a fraction of the gravity and profundity of this observation. I appreciate it greatly. -- Roland McGrath -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Le lundi 07 août 2006 à 10:56 +0200, Joerg Schilling a écrit : My software is definitely free and has no license problems. You may think so, but the Debian project doesn't. For example, a recent GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for cdrecord. Furthermore, there are issues with the CDDL and currently no CDDL-licensed project has been accepted. All of this, without even taking into account your brain-dead licensing mix between CDDL and GPL - which are intentionally incompatible licenses, according to Sun guys. If people from Debian continue to publish untenable assertions on my software, it is obvious that those people from Debian are only interested in a calumniation campaign aganst me. People from Debian are interested in building a free distribution, not in trolling with software authors crying out loud because they aren't able to understand how licenses work. We decide what's acceptable for our project, and you don't have a single word to say about that. Note that this makes Debian incredible. If it is impossible to find a reasonable person at Debian, I will need to inform other people about the problems in the Debian project. The way _you_ and other people from Debian currently act, makes Debian a definitely non-free project :-( Indeed, you are not free to add whatever piece of crap to the Debian archive regardless of the license. Call it a non-free project if you want, but this would only look like a calumniation campaign against us. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: cdrtools
Josselin Mouette [EMAIL PROTECTED] wrote: Le lundi 07 août 2006 à 10:56 +0200, Joerg Schilling a écrit : My software is definitely free and has no license problems. You may think so, but the Debian project doesn't. For example, a recent As long as people from Debian are on calumiation campaigns aginst OSS authors, Debian needs to be called non-free. Debian must either be able to clean itself from people who use Debian for such campaigns against OSS authors, or Debian needs to be called a higly suspect and non-free project. GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. But note: you are again spreading lies! You should better inform yourself on the Debian project and about the GPL. The phrases that are inside cdrecord, have been clearly accepted by Debian more than 4 years ago and they have been 100% GPL compatible as long as cdrecord was published under GPL. Note that there are no invariant sections in my sofware. As long as you do not create problems with my reputation (which meand that you may need to call cdrecord e.g. kindergarten, you may apply any changes you like). cdrecord. Furthermore, there are issues with the CDDL and currently no CDDL-licensed project has been accepted. There are definitely NO issues with the CDDL. The CDDL gives at least as much freedom as the GPL does and the CDDL is a first class OSS license. It has been accepted by the OSI and this is sufficient for anybody. All of this, without even taking into account your brain-dead licensing mix between CDDL and GPL - which are intentionally incompatible licenses, according to Sun guys. The more such lies you write, the more I get the impression that you are a really bad troll. Sun did definitely NOT create the CDDL to be incompatible to the GPL. What you are doing here is FUD of the worst kind! I am still in hope that this is a problem with people like you only and not a general problem with Debian. Note that Debian has been a respectable project in the past. If Debian does not dissociate from people like you, Debian will soon become completely incredible. If people from Debian continue to publish untenable assertions on my software, it is obvious that those people from Debian are only interested in a calumniation campaign aganst me. People from Debian are interested in building a free distribution, not in trolling with software authors crying out loud because they aren't able to understand how licenses work. We decide what's acceptable for our project, and you don't have a single word to say about that. So why do they allow you to troll in the name of Debian? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Michael Banck [EMAIL PROTECTED] wrote: Hi, On Mon, Aug 07, 2006 at 10:56:24AM +0200, Joerg Schilling wrote: I am still in hope that there are people at Debian who are able to understand license issues without bending things the way they like but by correctly following the words in the license text. Joerg, this discussion is off-topic for the debian-devel mailing list, which is concerned with development issues, not licensing trivia. People from Debian did start this discussion by starting a calumniation capaign against me and the CDDL. As long as this list is abused to spread lies on my software, I would need to have right to correct the related incorrect claims. If you don't like this discussion to be continued here, make sure that the people who are spreading lies on me and my software are not allowed to do this on this list anymore. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Mon, 07 Aug 2006, Joerg Schilling wrote: Debian must either be able to clean itself from people who use Debian for such campaigns against OSS authors, or Debian needs to be called a higly suspect and non-free project. You troll around on debian-devel, you troll around on lkml, you seem to be more intelligent, wise, knowledgable, fluent in licenses, all-mighty than *ALL* *OTHER*: - linux kernel developers (quite a lot) - debian developers (quite a lot) Do you really believe this yourself?!?! If yes, go for a therapist, please, I would even pay the first hour! Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PIMPERNE (n.) One of those rubber nodules found on the underneath side of a lavatory seat. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Norbert Preining [EMAIL PROTECTED] writes: On Mon, 07 Aug 2006, Joerg Schilling wrote: Debian must either be able to clean itself from people who use Debian for such campaigns against OSS authors, or Debian needs to be called a higly suspect and non-free project. You troll around on debian-devel, you troll around on lkml, you seem to be more intelligent, wise, knowledgable, fluent in licenses, all-mighty than *ALL* *OTHER*: - linux kernel developers (quite a lot) - debian developers (quite a lot) Do you really believe this yourself?!?! If yes, go for a therapist, please, I would even pay the first hour! Please keep non-constructive messages and flaming off debian-devel (and the same applies to you, Joerg Schilling). Take this off debian-devel to private mail or to a more appropriate list. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please sign and encrypt your mail. pgpz3KUkA410Q.pgp Description: PGP signature
Re: cdrtools
Norbert Preining [EMAIL PROTECTED] wrote: You troll around on debian-devel, you troll around on lkml, you seem to be more intelligent, wise, knowledgable, fluent in licenses, all-mighty than *ALL* *OTHER*: - linux kernel developers (quite a lot) - debian developers (quite a lot) Do you really believe this yourself?!?! If yes, go for a therapist, please, I would even pay the first hour! You are a really bad troll! Any sane person who did follow this mail thread knows that the trolls from Debian did only send junk and obvious lies while I tried to give technical based explanations. I do not need to comment your insane scribbling, only people who are as insane as you are will believe you. And it is interesing to see that the same applies to the LKML trolls as does apply to the Debian trolls: When they run out of arguments, they either stop replying or start with personal infringement. You are obviously from the second category. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Joerg Schilling dijo [Mon, Aug 07, 2006 at 12:24:57PM +0200]: As long as people from Debian are on calumiation campaigns aginst OSS authors, Debian needs to be called non-free. It's not like publishing software under an allegedly free license makes you a saint, you know? GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. Any free license allows for forking, allows for us modifying and redistributing your work. If we consider some parts of your code unfit, and you say you write Free Software, you should not have a problem accepting us to distribute those changes to your sources. Why are you so bitter about it to call bastardizing what should be called distributing modified versions of? You should better inform yourself on the Debian project and about the GPL. The phrases that are inside cdrecord, have been clearly accepted by Debian more than 4 years ago and they have been 100% GPL compatible as long as cdrecord was published under GPL. Note that there are no invariant sections in my sofware. As long as you do not create problems with my reputation (which meand that you may need to call cdrecord e.g. kindergarten, you may apply any changes you like). Thing is that different programmers will look differently at the same problem - And if most people looking at your approach feel it should not be done that way, what's your big problem with them modifying your logic? They are not creating problems with your reputation. They label the software as originally written by you, but maintained for Debian by another Joerg, an Eduard and a Steve. There are definitely NO issues with the CDDL. The CDDL gives at least as much freedom as the GPL does and the CDDL is a first class OSS license. It has been accepted by the OSI and this is sufficient for anybody. ...By OSI. That's an important part, but not all of, the Free Software camp. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Le lundi 07 août 2006 à 12:24 +0200, Joerg Schilling a écrit : As long as people from Debian are on calumiation campaigns aginst OSS authors, Debian needs to be called non-free. Why do you have to be so self-centered? This is not a calumniation campaign, this is not about YOU. We just think your software isn't fit to be distributed by us. If you really want that badly that we distribute your software, you should just comply with our requirements, that's all. Debian must either be able to clean itself from people who use Debian for such campaigns against OSS authors, or Debian needs to be called a higly suspect and non-free project. On what grounds? Because you don't like us? GR stated that invariant sections aren't acceptable for the specific GFDL case, and there is no reason why they would be acceptable for If Linux Distributions would not distribute bastardized versions of cdrecord, there was no need to add the statements you might be talking about. This is free software or this is not free software. If you don't like when people distribute modified versions of your software, you should not try share them with the free software community. For example, I don't like when people distribute buggy modified versions of my packages, like this happened with Knoppix or Ubuntu. However I won't stop making my packages free for such a frivolous reason. But note: you are again spreading lies! You should better inform yourself on the Debian project and about the GPL. I am obviously better informed than you about the Debian project and about the GPL. You don't know the former at all and you haven't read the latter enough to understand it. The phrases that are inside cdrecord, have been clearly accepted by Debian more than 4 years ago But the result of the GFDL GR implies that we should reconsider this acceptance under the light of what the project currently thinks of invariant sections. and they have been 100% GPL compatible as long as cdrecord was published under GPL. No. The GPL explicitly forbids to add any additional restriction. Note that there are no invariant sections in my sofware. As long as you do not create problems with my reputation (which meand that you may need to call cdrecord e.g. kindergarten, you may apply any changes you like). That's not any changes we like, sorry. cdrecord. Furthermore, there are issues with the CDDL and currently no CDDL-licensed project has been accepted. There are definitely NO issues with the CDDL. The CDDL gives at least as much freedom as the GPL does and the CDDL is a first class OSS license. It has been accepted by the OSI and this is sufficient for anybody. Debian is not the OSI. Debian decides what is acceptable for Debian, not the OSI. As the OSI has repeatedly accepted blatantly non-free licenses in the past, we have no reason to trust them on this matter. All of this, without even taking into account your brain-dead licensing mix between CDDL and GPL - which are intentionally incompatible licenses, according to Sun guys. The more such lies you write, the more I get the impression that you are a really bad troll. Sun did definitely NOT create the CDDL to be incompatible to the GPL. What you are doing here is FUD of the worst kind! No, this is from first hand, real-life discussion with Sun people at DebConf. A part of the staff wanted to use the GPL, but the developers, who were old times BSD fans, didn't want a copyleft and they didn't want a GPL-compatible license. The CDDL was the compromise they found, and it was *intentionally* written to be incompatible with the GPL. I am still in hope that this is a problem with people like you only and not a general problem with Debian. Note that Debian has been a respectable project in the past. If Debian does not dissociate from people like you, Debian will soon become completely incredible. There is an expulsion procedure documented there: http://lists.debian.org/debian-devel-announce/2005/08/msg5.html If you can convince enough developers to start an expulsion procedure against me, this should be fine. So why do they allow you to troll in the name of Debian? I am not doing anything in the name of Debian. I am just trying to be patient and taking some of my precious time to explain you how things work, but given your reaction, it just looks like a waste of time. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: cdrtools
Debian must either be able to clean itself from people who use Debian for such campaigns against OSS authors, or Debian needs to be called a higly suspect and non-free project. As an outsider of the Debian project, you probably have little knowledge of all the people you're debating with currently. What's really funny is that several of these people are indeed people who sometimes have radically different opinions about licensing, freeness and all these things. You see the Debian project as a monolithic project with only one voice, which is everything but true. But, here, what is even more funny is that most of these very often incompatible people seem to agree that the licensing of your software makes it unacceptable for the project. Even those people that are not known to be freeness zealots think it (count me among those people...several here will confirm this to you). This would make anyone with a reasonable sense of debate at least question his/her reasoning. Which you do not seem ready to do, standing in your ivory tower (at least this is my understanding of this thread, please forgive me if that's untrue and if your really ready to discuss the parts that Debian considers questionable in you licensing). That's really infortunate, of course.and the only option I see here for Debian is to use some forks of your project that would use some more reasonable licensing.unless you seem ready to reconsider it. If you're not, there's probably not much point wasting our respective time. signature.asc Description: Digital signature
Re: cdrtools
Wouter Verhelst [EMAIL PROTECTED] wrote: I can quote major parts of it by heart since a few years, does that help? If you like to discuss the GPL with other people, it is irrelevent whether you know it by heart in case you did not understand it yet... [...] GPL§3 clearly says what you may do when you distribute binary versions of the Program, and gives you three options: But this is unrelated to the problem Debian seems to construct. You should read the GPL more carefully. Actually, no. The main problem which Debian has with you and your relation to the GPL is related to GPL§3. If you believe that there is a problem with GPL §3, why don't you explain this problem? Instead of writing such acusations, _you_ should try to find a non-prejudiced relation to software licenses... What I am subjected to by Debian is a real bad calumniation campaign :-( People repeatedly claim that there are problems with my but are unable to explain where the problems should be. If the Debian Pproject does not like to lose credibility, people from Debian should finally explain their problems or _correcty_ admit that there is no problem. As you still seem not to understand the GPL, let me give you a final explanation of the relevent statements from GPL §2 and GPL §3: - The GPL §2 talks about a work, but does not give a definition for the term work. So I am free to decide (within reasonable limits) where the work ends. The GPL §2 requires the work to be put under GPL in case that the work has been created by including other peoples GPLd work in a new or bigger project. The GPL §2 does _not_ mention a restriction in case that a GPLd work is based on a NON-GPL work or includes parts from a NON-GPL work. As the GPL gives a general permission to use the GPLd code, this is the point where the GPL opens a way to combine CDDL code with GPL code. This is the way I am going with mkisofs. - The GPL §3 uses a definition about the complete source which differs from the term work which is used in GPL §2. If you publish binaries from a project, then the GPL §3 requires that the complete source needs to be published but does not name a license for the parts of the complete source that are not covered by the work (as mentioned in GPL §2). The file COPYING in the root directory of the cdrtools project explains which _sub_projects_ are published with the cdrtools project and lists the location where the various sub-projects could be found in the directory structure. The schily makefile system is definitely not part of the mkisofs project. The schily makefile system is project independent and it is _also_ published separately from any other project. The schily makefile system is more than 100x as big as the project specific makefile mkisofs/Makefile and the project specific Makefiles are published under the same license as the related project. As the GPL allows mere agregation, this is what I do with the schily makefile system. The schily makefile system is under CDDL and the file mkisofs/Makefile is under GPL. If people from the Debian project believe that the GPL is to interpreted otherwise, then the Debian project would need to immediately mark all GPLd projects non-free as the GPL then seems to violate DSFG §9. In case you did read the GPL carfully enough you should know that GPL §2 and GPL §3 speak about differnt things. GPL §3 speaks about complete source, while GPL §2 speaks about the work which from what GPL §3 sais is _less_ than the complete source. They both speak about the Program, though, which is what really matters. The license applies to the Program, which is defined in §0. It does not apply to the work or anything remotely similar. That term is only used to define rules that you needt to follow /when modifying the Program/. These rules are outlined in §2. If you did not understand what a program is in terms of the GPL, you should read GPL §0. In addition, I encourage you to read GPL §2 and GPL §3 again until you manage to understand in which relation the term program is used there. It is obvious that the term program applies to parts of the source that end up in iditificable parts of the binary. The GPL §2 talks about the limitations in case you put other peoples GPLd source or parts from it into your peoject. IOW, if you are creating an original work (as you are) instead of modifying an already existing work, then §2 /does not even apply to you/. See above, you seem to start understanding GPL §2. ... but it would take some time for you to understand enough of the GPL in order to be able to discuss things related to the GPL with me. does not mean more than: make 'the work' available under GPL (in
Re: cdrtools
Wouter Verhelst [EMAIL PROTECTED] wrote: You should better _read_ the GPL and try to understand it. Good plan. Did you have some time to make your plan reality meanwhile? GPL §2 defines what the work is and requres to publish the whole work under the GPL in case that that work incorporates other peoples work under GPL. (*) The GPL allows to publish the scripts used to control compilation and installation of the executable. under _any_ license as the scripts are not part of the work. These scripts are referred to in GPL§3, not §2. So much for reading the GPL. Wow, so it seems that you did read at least parts of the GPL... GPL§3 clearly says what you may do when you distribute binary versions of the Program, and gives you three options: But this is unrelated to the problem Debian seems to construct. You should read the GPL more carefully. Additionally, it defines source code as follows: === 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 scrips used to control compilation and installation of the executable.[...] === In case you did read the GPL carfully enough you should know that GPL §2 and GPL §3 speak about differnt things. GPL §3 speaks about complete source, while GPL §2 speaks about the work which from what GPL §3 sais is _less_ than the complete source. /*--*/ 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, /*--*/ does not mean more than: make 'the work' available under GPL (in case 'the work' is a 'derived work' and make the rest for the 'complete source' available under any license you like. I fail to see how your claim holds, given the above, but I'm willing to be educated. You ned to carefully read the GPL as long as you need in order to understand it by your own. Do not read GPL FAQs, as most of them (including the one from FSF) are not 100% correct. Note it is unclear whether the makefiles could be called scripts Unproven assertion. Unproven claim! and that in case of cdrtools, the build system is even a _different_ work that has been published _before_ the first cdrecord came out. If you're referring to smake here, then I cannot help but disagree with you. It would help a lot if you did educate yourself about the problem _before_ you try to comment it... Surely automake, GNU make, bash, and so on, were written before most of the projects that use them. However, that does not mean that the build system is a totally different work; the particular version of configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that are part of the source tarball are part of the build system, even if the interpreters that are used to run them are not. This is completely irelevent, why did you write it? In the same way, smake is indeed a different work, but the makefiles that are shipped with cdrecord are not. Am I missing something? You did miss nearly everything of importance :-( I encourage you to look at _cdrtools_ and not at any random other project. While smake is of course older than GNU make, it is (currently) not needed in order to compile cdrtools. This may change in future in case that I need features that are not present with GNU make. Note that smake could have died 10 years ago, but I needed to maintain and enhance it in order to get a really portable make program. GNU make is unmaintained since at least 7 years, it has many bugs that make it extremely user-unfriendly when used together with The Schily Makefilesystem and GNU make is far less prtable than smake. This is why I recommend smake to compile my software. It is obvious that it makes more sense to put effort in an own project than wasting time with un-responsive GNU make maintainers. smake is not part of cdrtools but another project I am working on: The Schily Makefilesystem is. This is definitely a project that is _separate_ from cdrtools but included as a sub-project. - This project (The Schily Makefilesystem) contains 300 kB of _project-independent_ makefiles/rules. - The Makefile that is e.g. part of the mkisofs project is only 2477 bytes in size. Only 1243 Bytes in this file are specific to mkisofs and not copied from a (project-independent) template. -
Re: cdrtools
On Wed, Aug 02, 2006 at 04:32:58PM +0200, Joerg Schilling wrote: Wouter Verhelst [EMAIL PROTECTED] wrote: You should better _read_ the GPL and try to understand it. Good plan. Did you have some time to make your plan reality meanwhile? I can quote major parts of it by heart since a few years, does that help? [...] GPL§3 clearly says what you may do when you distribute binary versions of the Program, and gives you three options: But this is unrelated to the problem Debian seems to construct. You should read the GPL more carefully. Actually, no. The main problem which Debian has with you and your relation to the GPL is related to GPL§3. Additionally, it defines source code as follows: === 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 scrips used to control compilation and installation of the executable.[...] === In case you did read the GPL carfully enough you should know that GPL §2 and GPL §3 speak about differnt things. GPL §3 speaks about complete source, while GPL §2 speaks about the work which from what GPL §3 sais is _less_ than the complete source. They both speak about the Program, though, which is what really matters. The license applies to the Program, which is defined in §0. It does not apply to the work or anything remotely similar. That term is only used to define rules that you needt to follow /when modifying the Program/. These rules are outlined in §2. IOW, if you are creating an original work (as you are) instead of modifying an already existing work, then §2 /does not even apply to you/. /*--*/ 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, /*--*/ does not mean more than: make 'the work' available under GPL (in case 'the work' is a 'derived work' and make the rest for the 'complete source' available under any license you like. You seem to have a very strange sense of English. You may copy and distribute the Program (or a work based on it (...) ) (...) provided that you also do one of the following: a) Accompany it with the complete machine-readable source code (...) It says the Program, not the work. It says the *complete* machine-readable source code (emphasis mine), not the source code of just the part of which you're providing binaries. I fail to see how your claim holds, given the above, but I'm willing to be educated. You ned to carefully read the GPL as long as you need in order to understand it by your own. My point exactly. Note it is unclear whether the makefiles could be called scripts Unproven assertion. Unproven claim! The point was: can you give me any sane description of script that does not hold for Makefiles? [...] Surely automake, GNU make, bash, and so on, were written before most of the projects that use them. However, that does not mean that the build system is a totally different work; the particular version of configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that are part of the source tarball are part of the build system, even if the interpreters that are used to run them are not. This is completely irelevent, why did you write it? Because they are also build systems that were written before projects that use them. It is not completely irrelevant; it works exactly the same way as your claim. [...] GNU make is unmaintained since at least 7 years, GNU make has seen at least 227 updates since 2000 alone, some of which are *very* significant. How does that count as unmaintained, other than They do not incorporate Joerg Schilling's patches? Would you incorporate any random patch for cdrecord which I would send your way, /even/ if it is not an evil patch that tries to circumvent whatever you try to do with cdrecord? You know, I knew about your reputation, but was willing to forget all about it, just for the remote chance that you might see the light for once. I was being silly: it has many bugs that make it extremely user-unfriendly when used together with The Schily Makefilesystem Doctor, I have a headache when I drink coffee with the spoon still in the cup Don't do that, then. I've been using GNU make for over six years now. I've never come into contact with a feature of which I thought gee, this is
Re: cdrtools
On Sun, Jul 30, 2006 at 08:28:04PM -0500, Matthew R. Dempsky wrote: On Sun, Jul 30, 2006 at 10:03:14PM +0200, Wouter Verhelst wrote: On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote: Note it is unclear whether the makefiles could be called scripts Unproven assertion. How is something proven unclear? 'unexplained', then. Whatever. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Anthony DeRobertis wrote: Erast Benson wrote: I do not need to make the build system available under GPL (GPL §3 requires me to make it available but does not mention a license) GPL 3(a) requires the complete corresponding source code [be] distributed under the terms of Sections 1 and 2 above. GPL 3 defines the source code to include the the scripts used to control compilation and installation of the executable. Again a person who tries to bend the GPL to his wishes.. You should better _read_ the GPL and try to understand it. GPL §2 defines what the work is and requres to publish the whole work under the GPL in case that that work incorporates other peoples work under GPL. (*) The GPL allows to publish the scripts used to control compilation and installation of the executable. under _any_ license as the scripts are not part of the work. Note it is unclear whether the makefiles could be called scripts and that in case of cdrtools, the build system is even a _different_ work that has been published _before_ the first cdrecord came out. *) It does not even require to publish the whole work under the GPL in case that you add code to a GPL project! In this case the added code may under _any_ license (even Closed source). AGAIN: If you like to understant/interpret a contract like the GPL, you need to read it carefully word by word and are not allowed to add claims that are not written in the GPL. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote: Anthony DeRobertis wrote: Erast Benson wrote: I do not need to make the build system available under GPL (GPL §3 requires me to make it available but does not mention a license) GPL 3(a) requires the complete corresponding source code [be] distributed under the terms of Sections 1 and 2 above. GPL 3 defines the source code to include the the scripts used to control compilation and installation of the executable. Again a person who tries to bend the GPL to his wishes.. Gee, that sounds familiar somehow. You should better _read_ the GPL and try to understand it. Good plan. GPL §2 defines what the work is and requres to publish the whole work under the GPL in case that that work incorporates other peoples work under GPL. (*) The GPL allows to publish the scripts used to control compilation and installation of the executable. under _any_ license as the scripts are not part of the work. These scripts are referred to in GPL§3, not §2. So much for reading the GPL. GPL§3 clearly says what you may do when you distribute binary versions of the Program, and gives you three options: 3a) accompany it with complete source code, to be distributed under the terms of Sections 1 and 2 above (i.e., under the GPL); 3b) accompany it with a written offer to offer the source under the terms of Sections 1 and 2 above (i.e., under the GPL); 3c) pass on an already existing written offer as defined in 3b), under certain conditions Additionally, it defines source code as follows: === 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 scrips used to control compilation and installation of the executable.[...] === I fail to see how your claim holds, given the above, but I'm willing to be educated. Note it is unclear whether the makefiles could be called scripts Unproven assertion. and that in case of cdrtools, the build system is even a _different_ work that has been published _before_ the first cdrecord came out. If you're referring to smake here, then I cannot help but disagree with you. Surely automake, GNU make, bash, and so on, were written before most of the projects that use them. However, that does not mean that the build system is a totally different work; the particular version of configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that are part of the source tarball are part of the build system, even if the interpreters that are used to run them are not. In the same way, smake is indeed a different work, but the makefiles that are shipped with cdrecord are not. Am I missing something? *) It does not even require to publish the whole work under the GPL in case that you add code to a GPL project! In this case the added code may under _any_ license (even Closed source). Could you quote the part of the GPL on which you base this assertion? It is not clear to me. AGAIN: If you like to understant/interpret a contract like the GPL, The GPL is a license, not a contract. you need to read it carefully word by word and are not allowed to add claims that are not written in the GPL. Exactly. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
This one time, at band camp, Wouter Verhelst said: On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote: Again a person who tries to bend the GPL to his wishes.. Gee, that sounds familiar somehow. Haven't we reached the point where we have noticed that all posts by JS are understood as being based in a special fantasy land only inhabited by him and a few fanboys? Can we move on? I am slightly bored with having my various mailboxes filled with fantastical interpretations of licenses, and would like to move on to new and different flamewars, if we could. Thanks all, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: cdrtools
On Sun, Jul 30, 2006 at 10:03:14PM +0200, Wouter Verhelst wrote: On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote: Note it is unclear whether the makefiles could be called scripts Unproven assertion. How is something proven unclear? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Erast Benson wrote: I do not need to make the build system available under GPL (GPL §3 requires me to make it available but does not mention a license) GPL 3(a) requires the complete corresponding source code [be] distributed under the terms of Sections 1 and 2 above. GPL 3 defines the source code to include the the scripts used to control compilation and installation of the executable. Section 2(b) requires third parties to publish derived works under the GPL (to be licensed as a whole at no charge to all third parties under the terms of this License.). Section 2 also states [T]he distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Le mercredi 12 juillet 2006 à 01:02 +0100, Matthew Garrett a écrit : Now, this can quite easily be worked around by Joerg agreeing that all of the software in the cdrecord tarball can be treated under the terms of the CDDL (assuming that he has the right to do so, of course - any significant patches that have been contributed by people under the terms of the GPL would have to be rewritten or permission granted by the authors). Then it just ends up being a Is CDDLed material acceptable for Debian? argument, which is much more straightforward but not really suited for the debian-devel mailing list. As long as he keeps the you cannot change this part of the code blurb, the most problematic issue remains. The GFDL GR made it very clear that we won't accept invariant sections, and this is even more true for code. This is a fundamental disagreement between Joerg Schilling and the project, and unless he removes that blurb there is no way recent cdrecord versions can be packaged in main. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: cdrtools
Hello, [ I'm leaning somewhat out of the window here w/o being a law expert ] On Wed, 12.07.2006 at 12:46:51 -0700, Erast Benson [EMAIL PROTECTED] wrote: Joerg clearly stands that: 1) Makefiles != scripts or at least it is unclear whether Makefiles may be called scripts: ... Makefiles are programs written in a non-scripting language: I call this language make. It is a non-algorithmic language but but he and you are dead wrong on that, imho. For me at least, a script is anything that can be executed using shebang, and makefiles _can_, as your famous debian/rules file demonstrates. This means in other words: If I take other people's GPL code and create a derived work from that code, I need to make the whole work available under GPL. I do not need to make non-GPL code available at all, if GPL code is derived on that code. I do not need to make the build system available under GPL (GPL §3 requires me to make it available but does not mention a license) and the build system is not code that is derived from the GPLd project. This is imho a very broken interpretation because the build system is usually an intimate part of the whole, and often enough, source code with no idea about how to tie everything together is not nearly half as useful as a full source is. Think of KDE w/o a build system, or the Linux kernel, for instance... which would almost certainly defeat the purpose of enabling others to change and expand on given code, and also open the door for all kinds of abuse. Maybe we should solicit the legal opinion of the FSFE or so on this matter. But in reality, this all belongs on [EMAIL PROTECTED] Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
* Mike Hommey ([EMAIL PROTECTED]) wrote: On Wed, Jul 12, 2006 at 03:58:13PM -0400, Eric Dorland [EMAIL PROTECTED] wrote: Some examples and test files are licensed under Mozilla-sample-code. Uh, is that actually a license? Yes it is: BEGIN LICENSE BLOCK Version: Mozilla-sample-code 1.0 Copyright (c) 2002 Netscape Communications Corporation and other contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this Mozilla sample software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Contributor(s): END LICENSE BLOCK That's just the MIT license renamed it would appear. If you want a full licensing status on the mozilla code base, take a look to http://packages.debian.org/changelogs/pool/main/x/xulrunner/current/copyright which I actually need to update, I saw that some files changed to tri-license between 1.8.0.1 and 1.8.0.4... Wow, I should really update the copyright file in firefox. The most problematic files are in xpcom/reflect/xptcall/src/md/unix. This directory contains assembler code for xpcom on several platforms. While a lot of these files are not of any use for us (irix, vms...) some are indeed used: xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and xptcinvoke_asm_sparc_linux.s are NPL only ; xptcinvoke_asm_mips.s is MPL. Even if we don't use the irix, vms, etc files, if they're problematic license-wise, we'd need to strip them out or get the license fixed. The point was that in the worst case scenario, we can't remove the files I listed without removing support for these architectures. The others can be removed without harm. Indeed. Another thing that is a bit annoying is that the LICENSE file in the upstream tarball is the MPL license text. It'd be better for everyone if they'd make it clear that everything in the tarball, except external libraries such as expat, libpng, etc. are tri-licensed. Should we file a bug? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: cdrtools
On Fri, Jul 14, 2006 at 02:50:27PM -0400, Eric Dorland [EMAIL PROTECTED] wrote: Another thing that is a bit annoying is that the LICENSE file in the upstream tarball is the MPL license text. It'd be better for everyone if they'd make it clear that everything in the tarball, except external libraries such as expat, libpng, etc. are tri-licensed. Should we file a bug? I'm in contact with Gerv about all these issues. Stay tuned. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, Jul 12, 2006 at 03:58:13PM -0400, Eric Dorland [EMAIL PROTECTED] wrote: Some examples and test files are licensed under Mozilla-sample-code. Uh, is that actually a license? Yes it is: BEGIN LICENSE BLOCK Version: Mozilla-sample-code 1.0 Copyright (c) 2002 Netscape Communications Corporation and other contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this Mozilla sample software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Contributor(s): END LICENSE BLOCK If you want a full licensing status on the mozilla code base, take a look to http://packages.debian.org/changelogs/pool/main/x/xulrunner/current/copyright which I actually need to update, I saw that some files changed to tri-license between 1.8.0.1 and 1.8.0.4... The most problematic files are in xpcom/reflect/xptcall/src/md/unix. This directory contains assembler code for xpcom on several platforms. While a lot of these files are not of any use for us (irix, vms...) some are indeed used: xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and xptcinvoke_asm_sparc_linux.s are NPL only ; xptcinvoke_asm_mips.s is MPL. Even if we don't use the irix, vms, etc files, if they're problematic license-wise, we'd need to strip them out or get the license fixed. The point was that in the worst case scenario, we can't remove the files I listed without removing support for these architectures. The others can be removed without harm. Another thing that is a bit annoying is that the LICENSE file in the upstream tarball is the MPL license text. It'd be better for everyone if they'd make it clear that everything in the tarball, except external libraries such as expat, libpng, etc. are tri-licensed. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, Jul 12, 2006 at 12:46:51PM -0700, Erast Benson wrote: Joerg clearly stands that: 1) Makefiles != scripts or at least it is unclear whether Makefiles may be called scripts: GPL §3 requires the scripts for compilation to be provided but as a first note, it is unclear whether Makefiles may be called scripts. Er, wait. This is complete nonsense: the very definition of a makefile is compilation script. Makefiles are programs written in a non-scripting language: I call this language make. It is a non-algorithmic language but a rule based language (like e.g. CDL2). The word script in computing came from theater, previously meaning screenplay, listing the things actors have to do, in a particular order. Makefile does exactly that, lists what compiler/linker/etc have to do, in a given order. Thus, a makefile is certainly more a script than for example a Perl module, and if it's not a compilation script, then I don't know what is. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Erast Benson writes (Re: cdrtools): Joerg clearly stands that: 1) Makefiles != scripts or at least it is unclear whether Makefiles may be called scripts: GPL §3 requires the scripts for compilation to be provided but as a first note, it is unclear whether Makefiles may be called scripts. This is an absurd interpretation. `The scripts used to control compilation and installation of the executable' would be an empty set for much GNU software if it didn't include the Makefiles. It is obvious that that phrase was included in the GPL specifically to ensure that the build system is covered. If it's not obvious to someone then that person is either (a) dishonest or (b) astonishingly out of touch with reality. Ian.
Re: cdrtools
On Thu, 2006-07-13 at 12:59 +0100, Ian Jackson wrote: Erast Benson writes (Re: cdrtools): Joerg clearly stands that: 1) Makefiles != scripts or at least it is unclear whether Makefiles may be called scripts: GPL §3 requires the scripts for compilation to be provided but as a first note, it is unclear whether Makefiles may be called scripts. This is an absurd interpretation. `The scripts used to control compilation and installation of the executable' would be an empty set for much GNU software if it didn't include the Makefiles. It is obvious that that phrase was included in the GPL specifically to ensure that the build system is covered. If it's not obvious to someone then that person is either (a) dishonest or (b) astonishingly out of touch with reality. I don't want to insist on (1) too. But I must agree with Joerg that it is unclear if Makefiles could be called as scripts for compilation. Makefiles are programs written in non-scripting language. To understand what non-scripting language is, I googled this: I'd define a scripting language as one which requires you to put $ or whatever in front of variable names, and makes quoting strings an optional construct, and does string variable substitution inside string constants unless you force it not to with odd escape characters. A non-scripting language is one which has simple, clear-cut lexical conventions and parsing syntax. Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Jul 13, 2006 at 16:06, Erast Benson praised the llamas by saying: I don't want to insist on (1) too. But I must agree with Joerg that it is unclear if Makefiles could be called as scripts for compilation. Makefiles are programs written in non-scripting language. To understand what non-scripting language is, I googled this: I'd define a scripting language as one which requires you to put $ or whatever in front of variable names, and makes quoting strings an optional construct, and does string variable substitution inside string constants unless you force it not to with odd escape characters. A non-scripting language is one which has simple, clear-cut lexical conventions and parsing syntax. You run an interpreter[0] which loads the source script files[1] and executes it. The language is a mixture of declarative and iterative programming. It clearly falls in the remit of scripts for compilation. Your paragraph appears to make python a non-scripting language. [0] make(1) [1] Makefile -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
