Let me see if I have this straight.
In the beginning, there was cdrtools. Most everybody used it, and nobody had any complaints.
Then in 2006, the programmer changed the license from the GPL to the CDDL, although I don’t know why.
All is well except for Debian, whose grand poo-bahs say, “Hey, that there ain’t in line with our philosophies.” Although I don’t know why.
So in what could only be called a coup d’état, the Debian masterminds scalp the last GPL-licensed release of cdrtools, dub it cdrkit, and promise to keep stride with whatever happens in the original. Although I get the general idea why.
So now there were two symmetric projects, and sometimes one is available in your distribution. Sometimes the other. Sometimes … both! Although I don’t know why.
Here’s where things get even more blurry for me. Along comes cdrskin, which is part of a separate project, but is designed as a drop-in replacement for cdrtools’ original cdrecord program.
So there’s a CD burner project, plus another that mimics it but is licensed differently, and yet a third that pretends to be the original, but actually comes from a completely different direction. And I don’t know why.
Now there is a strong possibility that some or all of this little drama has been misunderstood on my part. If so, my sincerest apologies.
But in short, if I’m right, all three should look roughly the same.
And this time … maybe I know why. 😐
After losing at least half a dozen blank CDs to various bugs in cdrkit on Ubuntu, I did some searching and found this semi-rant by the original developer of cdrecord. I installed cdrecord from the PPA and viola, never lost a CD since then.
The link seems to have disappeared from my comment. You will find the page I’m referring to by googling for “Many Linux distributions now come with broken variants of cdrtools” (WITH the quotes) and following the first link.
I think I fixed it for you. If that’s not the page you want, e-mail me with a link and I can insert it for you. Thanks! 😉
I am the author of cdrskin. It exists as a convenience
interface to libburn for those frontends which already
use Joerg Schilling’s cdrecord. cdrskin does not pretend
to be the original but rather an emulation that is
compatible with most use cases of cdrecord.
Newer frontends may well use the libburn API or the
interfaces provided by xorriso.
The reason for the fork of cdrkit was the interpersonal
incompatibility of Joerg Schilling and the wider Linux
developer community.
The reason for my involvement in libburn was the fear
that at some degree of quarrel there would be no tool
to do CD TAO on Linux. On DVD and BD media, i do not
agree with how cdrecord handles them (i.e. with Joerg’s
interpretation of MMC specs).
BTW: The similarity between cdrskin and the others
would become more obvious with the output of
cdrskin -help with a single dash. Double dashed –help
shows the extension options which are not compatible
with cdrecord.
Have a nice day 🙂
Thomas
Thanks Thomas. That helps me understand a lot. I was still new to Linux when the cdtools-cdkit drama happened. I appreciate the explanation.
I should have checked
cdrskin -h
but didn’t think of it. I will try it next time I burn a CD! 🙂Cheers!
K.Mandla
Pingback: dirsplit: A hidden hero | Inconsolation
I am the Author of cdrtools and I am a victim of anti-social behavior
from Debian (like the Linux uers are).
Putting cdrtols under a free license was planned for a long time,
but the attacks from Debian finally triggered the change.
In 2004, a new packetizer at Debian tried to force me to add a
patch to mkisofs that would have introduced serious bugs. When
he realized that I am not willing to destroy my software he started
a diffamation campaign against me and the cdrtools project and
in May 2004 created his defective fork that includes the broken
patch.
I asked Debian to replace the hostile packetizer to no avail.
In Summer 2005, Debian started a red herring by claiming that
there was a license change in cdrtools and that cdrtools violate
the GPL. Note that at that time no license change was applied to
cdrtools and cdrtools was of course still 100% GPL. The red herring
from Debian made it obvious that you will not get help for GPL code
from the community in case that hostile people like Debian start a
diffamation campaign.
As a result, I relicensed cdrtools under CDDL – Debian continued
to claim that cdrecord was violating the GPL even though 100% of
cdrecord was under CDDL….
The problem with some people that claim being part of the Linux
community is that these peopleare never seen at community
events but rather hide and just spread attacks to the net. The debian
people Eduard Bloch and Jörg Jaspert are such community incompatible
persons. Fortunately, these community incompatible people claiming
to be Linux guys are rare, but as they are very active with spreading
their hate texts, people may believe that they represent a majority.
BTW: the SCSI related tasks of cdrtools are privileged operations
and for this reason, writing a related library is inapropriate as you would
need to make any application that uses them suid root or similar and
audit the whole code. This e.g. prevents a GUI to from directly using
such a library as you cannot do a security audit for something as complex
as a GUI.
Cdrtools are audited….
Besides the obvious problems with the Debian “fork”, many people did not
notice that cdrtools aprox. tripled code and features since September 2004,
which is the origin of the code currently used by Debian.
Thanks very much for your side of the story. I know a lot of this is ancient history, but it explains the split between the two packages, and with Thomas’s side, the appearance of cdrskin. Thanks again. 🙂
You are a victim of debian politics Jörg. All this legal bs about license incompatibility is baseless and wrong.
Pingback: simpleburner: Of dubious ability | Inconsolation
Tried recently to clone CD audio bitperfect, readom and wodim failed – the copy wasn’t bitperfect (EAC accuraterip checksum mismatch). Readcd and cdrecord cloned the cd perfectly – even cuesheet generated by EAC was the same as generated from the oryginal CD, which was hard to achieve even with cdrdao different modes read-toc, read-raw etc. Anyway, I don’t see why they are so stubborn to stick with inferior and of worse quality package, having the possibility to use cdrtools, which have been evolving through these years. The quality of code and being open source should be the priority.