cdrtools

The first releases of cdrtools were called cdrecord because they only included the cdrecord tool and a few companion tools, but not mkisofs nor cdda2wav. In 1997, a copy of mkisofs[3] (developed at that time by Eric Youngdale) was included in the cdrecord package. In 1998, a copy of an experimental version of cdda2wav[4] (developed at that time by Heiko Eißfeldt) was included in the cdrecord package.

In 2000, Jörg Schilling changed the name of his package from "cdrecord" to "cdrtools"[5] to better reflect the fact that it had become a collection of tools.

DVD writing support (cdrecord-ProDVD) in cdrecord started 1998, but since the relevant information required a non-disclosure agreement and DVD writers were not publicly available, it was not included in the source code. In 2002, Jörg Schilling started offering free license keys to the closed-source variant cdrecord-ProDVD for educational, and research use, shortly thereafter also for private use. Unregistered free licenses were initially limited to single-speed writing and would expire every year. On 15 May 2006, support for DVD writing was added to the open-source version 2.01.01a09 after switching the license to CDDL; thereby removing the need to get a license key. Blu-ray disc support was added starting 2007.

The lack of open-source DVD writing support in 2001 led to heated discussions on the mailing lists, and to a number of unofficial patches for supporting the Pioneer DVD-R A03, the first DVD writer to reach mass market, and forks of cdrecord: Mandrake shipped a version called cdrecord-dvdhack,[6] whereas Redhat had dvdrecord.[7]

Unlike cdrkit and libburnia, which use device files to access the hardware, cdrtools uses a different method known as CAM (for Common Access Method),[8] which is available on many operating systems, including some which lack device files or only allow the kernel to access them. This difference has turned into a controversy: some Linux users claim that the method used by cdrtools is not appropriate, while some Linux users claim that the users of cdrtools do not need to know which method is used.

In cdrtools, burning optical media (such as CDs, DVDs and Blu-rays discs) is done through the SCSI interface. Users of systems with more than one burning device need to provide a SCSI device (which is identified by a triplet of numbers, scsibus,target,lun). Users of systems with only one burning device, however, do not need to specify the SCSI device since cdrtools is able to find it. By 2002 more and more burners were using the ATAPI interface. Linux 2.6 allowed the users to detect the SCSI ID of a device from its UNIX device path (/dev/hdX) and a patch was published that made identifying the burner device for cdrecord simpler by allowing the user to specify the /dev/hdX device name (or even default to a udev managed link such as /dev/cdrw). Schilling, however, rejected this approach as well as other modifications used by Linux distributions, with the rationale that it would make the software more complex and less portable as this function was not available on other UNIX systems.[9] Linus Torvalds states that SCSI LUNs should not be used for addressing devices on Linux,[10] because these numbers are not unique,[10] and do not make sense for many devices anymore[11] (many devices will report 0:0:0 fake numbers[11]). Instead Torvalds recommends that devices should be addressed via their UUID, physical connection, or an alias symlink[11] as managed by udev on Linux. Torvalds pointed out that the ioctl's have been kept to ensure cdrecord compatibility[12] and do not return a meaningful value.[13]

By 2004, Linux distributions were maintaining a number of unofficial changes – such as allowing the use of /dev/hdX device names and (limited) DVD writing support – that were rejected by Schilling,[9] who repeatedly demanded that distributions stop shipping "bastardized and defective" versions of his "legal original software".[14] Starting with version 2.01.01a09 in May 2006, most code from cdrtools has been relicensed under the CDDL, while mkisofs remains licensed under the GPL.[15] This change led to an ongoing disagreement about whether distribution or use of precompiled cdrtools binaries is legally possible (the GPL permits collective works, but not derivative works; and the Makefiles used to build mkisofs are CDDL licensed). The following are one-sentence summaries of the different positions:

• Jonathan Corbet, founder of the LWN.net news source argued that, in the eyes of Debian developers, this change makes it impossible to legally distribute cdrtools binaries, because the build system used is CDDL licensed (interpreting cdrtools as derivative work of GPL and – GPL-incompatible – CDDL code) and the GPL requires "build tools and scripts also be released under the GPL".[16]
• Jörg Schilling denies a license problem in cdrtools. In his interpretation, it consists of independent works and thus does not mix incompatible licenses (i.e. it is a collective work, not a derivative work). According to his interpretation, binary versions may be distributed.[17]
• Fedora says the cdrtools is a "incompatible mix of the GPL and the CDDL"[18] and Schilling's opinion is a "set of unorthodox opinions on licensing which are not shared by the FSF or Red Hat Legal"[18] and thus cdrtools is forbidden on Fedora.
• As is common with the GPL and other open source licenses, very little case law exists to provide guidance to users and provide a definitive answer on whether binary versions are distributable.

As of November 2015, in consequence of this discussion:

• Debian,[19] Red Hat,[20] Fedora[21] and Ubuntu[22] dropped the versions of cdrtools with CDDL code from their distributions and switched to the Debian project created cdrkit, a fork of the last GPL-licensed cdrtools version.[23]
• Joerg Schilling continues to develop his version of cdrtools under the CDDL and GPL (mkisofs) licenses, whereas the cdrkit fork has received next to no updates since Cdrkit 1.1.11,which was released in 2010.
• Independent development efforts happen in libburnia which does not contain cdrtools source code, but includes a wrapper "cdrskin" to offer some command line compatibility with cdrecord and is available in many Linux distributions.
• Slackware and Gentoo Linux are unaffected, as the potential licensing issue only affects the distribution of precompiled binaries and these distributions compile from source code. They offer both versions as well as libburnia.
• Mandriva Linux, which had dropped its cdrtools package in 2007,[24] was returned by Mandriva to the community[25] and became OpenMandriva Lx, which ships the original cdrtools.[26]
• openSUSE, which had dropped its customized cdrtools package in 2007,[27] added back the original cdrtools in Fall 2013.
• Since building cdrtools from source is widely accepted as legal, there exist compile instructions for many Linux distributions.[28]

Cdrtools are now included into Jörg Schillings heavily maintained toolset Schily-Tools[29] aka schilytools as superseeding toolset.

As of 2019-07-17 he stopped maintaining the cdrtools only alpha and stable branch with version 3.02a9,[30] version 3.02a10 to further 2020 are only included in the source package schilytools.

The "Schily" Tool Box is a set of tools written or managed by Jörg Schilling. It includes the programs: cdrecord, cdda2wav, readcd, mkisofs, smake, bsh, btcflash, calc, calltree, change, compare, count, devdump, dmake based on SunPro Make, hdump, isodebug, isodump, isoinfo, isovfy, label, mt, obosh, od, p, POSIX patch, pbosh, sccs, scgcheck, scpio, sdd, sfind, sformat, smake, sh/bosh (Bourne sh), star, star_sym, strar, suntar, gnutar, tartest, termcap, and ved.

• cdrkit
• dvdrtools[36][37] (not to confuse with dvd+rw-tools)

• Brasero (Unix-like)
• InfraRecorder (Windows)
• K3b (Unix-like)
• X-CD-Roast (Unix-like)
• cdrtfe^(ru)[38] (Windows)